Как найти уязвимости в игре

Мы привыкли слышать, что хакеры делают плохие вещи, за ними обязательно охотятся правоохранительные органы и карьера взломщика может закончиться за решеткой. Этот набор стереотипов формировался много лет, поэтому многие новички считают их правдивыми.

В статье мы разрушим мифы профессии хакера и расскажем о направлении этичного хакинга. Разберемся, можно ли заработать на легальном взломе, какие навыки для этого нужны и поделимся советами эксперта. 

Что такое баг баунти

Bug Bounty — собирательное название программ поощрений за поиск багов и уязвимостей. Компании разного уровня заинтересованы в том, чтобы хакеры не пользовались пробелами в системе безопасности для обогащения, а отправляли отчеты им и зарабатывали на этом. 

К примеру, в начале ноября стали известны подробности схемы покупки дешевой подписки Telegram Premium. Оказалось, что исследователи безопасности нашли баг, который позволял оформлять премиум-услугу бесплатно. Они использовали его для заработка, и мессенджер потерял на этом от 3 до 5 млн долларов. 

В качестве альтернативы можно было подать отчет по программе Telegram Bug Bounty и заработать минимум несколько тысяч долларов. Размер вознаграждения колеблется от 100 до 100 000$, но за уязвимость критического уровня, скорее всего, исследователи получили бы достойное вознаграждение. 

В случае с багом в Телеграме «белые» хакеры пошли другим путем. В итоге они получили много денег и тысячи жалоб от недовольных клиентов, которым мессенджер обнулил подписки в конце октября. 

Программы Bug Bounty есть преимущественно у крупных IT-компаний, которые заинтересованы в том, чтобы сохранить репутацию и защитить персональные данные клиентов от утечки. Например, платежный сервис VK Pay платит до 1,8 млн рублей за уязвимости разного характера. В программе четко описаны критерии для принятия отчетов, домены для анализа и другие данные. 

Аналогичные программы есть у Google, Facebook*, Amazon, Discord, Microsoft и других брендов. С ними выгоднее работать, чем с локальными компаниями, потому что шансы получить вознаграждение в случае успешного принятия отчета гораздо выше. 

Какие навыки нужны для поиска багов?

Человеку без технического образования может показаться, что компании платят исключительно за критические уязвимости, и повторить результаты опытных коллег невозможно. На самом деле, для периодического заработка на Bug Bounty необязательно знать в совершенстве Python, JavaScript или другие языки программирования. Достаточно владеть базовыми инструментами вроде анализаторов кода и понимать принципы работы разных типов уязвимостей. 

В интервью медиа Skillbox один из багхантеров отметил, что умеет писать несложный код, но даже такой уровень знаний обеспечивает постоянные приглашения в закрытые программы Bug Bounty, куда не берут случайных людей. 

Часть задач по поиску уязвимостей можно автоматизировать. У специалистов по безопасности пользуются спросом анализаторы кода вроде PVS-Studio, которые сканируют ошибки и помогают определить направление для проверки уязвимостей. 

Компании больше всего заинтересованы в том, чтобы закрывать критические баги. Они готовы щедро платить за это, но новичкам будет сложно их обнаружить. Расстраиваться не стоит — заработать можно и на небольших уязвимостях.

К примеру, хакер обнаружил маленькую уязвимость с параметром utm_source в конструкторе интернет-магазинов Shopify, которая позволяла украсть cookies пользователя или создать фишинговую страницу. Компания посчитала, что проблема не влияет на конфиденциальность, но выплатила бонус в размере 700$.

Пример Shopify наглядно демонстрирует, что зарабатывать на багхантинге можно и без знания языка программирования. Для обнаружения уязвимостей межсайтового скриптинга (XSS) достаточно понимания принципов работы сетевых протоколов. 

Компаниям интересно работать с отчетами по уязвимостям любого уровня, но есть две главные метрики, которые влияют на получение оплаты: 

1. Возможность повторения сценария атаки.
2. Влияние на стабильность проекта.

Если инженеры компании не смогут использовать уязвимость на практике, багхантер останется без выплаты. Что касается уровня критичности, то все зависит от конкретного кейса. Например, если в ходе атаки получится узнать никнейм пользователя, вряд ли за это заплатят.

Где искать программы баг баунти?

Интерес к Bug Bounty как инструменту для манимейкинга высокий, но медийность ниши на просторах СНГ низкая. Поэтому многие пользователи даже не знают, что можно заработать на поиске багов и уязвимостей.

В бурже есть площадки, которые работают более 10 лет и успешно помогают найти точки соприкосновения между исследователями безопасности и компаниями. Новичкам обязательно стоит добавить их в список повседневных инструментов.

На какие ресурсы обратить внимание:

1. HackerOne. Самая популярная платформа с большим каталогом Bug Bounty программ. С помощью нее этичные хакеры могут отправить отчет об уязвимостях, а компании — отреагировать на них. 
2. Bugcrowd. Краудсорсинговая платформа работает в 30 странах мира. В каталоге доступно 332 программы от проектов разного уровня. 
3. HackenProof. Сервис для поиска уязвимостей в криптопроектах. С помощью него хакеры отправили более 7 1000 отчетов на сумму 842 000$.
4. Standoff 365. Свежая платформа с упором на рынок СНГ. Ее можно назвать мини-соцсетью для багхантеров. Здесь есть каталог программ, профили хакеров, рейтинг пользователей и другие фишки.

Мониторинг профильных площадок помогает оперативно замечать новые программы и быть в числе первых исследователей безопасности, которые начнут поиск уязвимостей раньше других. 

Ресурсы для багхантеров также помогают прокачивать скиллы. Можно проанализировать, какие типы уязвимостей находят опытные специалисты и перенять их опыт для получения аналогичных результатов в будущем.

Сколько можно заработать на Bug Bounty

Когда новички спрашивают, сколько можно заработать на арбитраже, они могут получить стандартный ответ: от нуля до миллионов долларов. С доходом от Bug Bounty аналогичная ситуация.

В 2018 году площадка HackerOne проводила опрос и выяснила, что для большинства исследователей безопасности поиск багов и уязвимостей — хобби, а не основная специализация. Они занимаются этим преимущественно в свободное время. 

HackerOne позволяет отслеживать публикацию отчетов хакеров. Из них можно сделать вывод, что специалисты ведут активность без перерыва. За месяц может набраться несколько десятков репортов, и это только маленькая часть данных в общем доступе. 

По результатам масштабного исследования HackerOne отчиталась о том, что только за 2020 год участникам программ Bug Bounty выплатили вознаграждений на 40 млн долларов. 9 членов сообщества заработали на платформе более $1 млн с 2019 года, а топовый хакер преодолел отметку в $2 млн в 2020 году. 

В интервью Skillbox, которое мы отмечали раньше, багхантеры говорят о непостоянности дохода. В один месяц они могут заработать 10 000$, а в другой 100$. Эта ситуация очень напоминает качели в арбитраже трафика, но то, что новички могут заработать, — это факт. 

В некоторых случаях вознаграждение может достигать суммы с тремя нулями, но такие деньги зарабатывают опытные специалисты. Новичкам не стоит рассчитывать на быстрый профит. 

Выводы и советы эксперта

Багхантинг — интересная, но специфическая ниша в манимейкинге. Порог входа низкий, и начинающие специалисты часто переоценивают свои силы или допускают грубые ошибки. К примеру, они считают, что компания обязательно должна заплатить за баг. Но как показывает практика, все зависит от особенностей конкретной ситуации. Некоторые багхантеры завершают карьеру из-за конфликтов, связанных с тем, что проект отказывается выплачивать вознаграждение. 

Важно понимать, что если на сайте компании нет официальной оферты с конкретными обязательствами, любые программы поощрений носят необязательный характер. А вот если соглашение есть и хакер сможет найти критическую уязвимость, за невыплату вознаграждения можно подать в суд.

Компания может не оплатить потраченное время, если посчитает поведение специалиста некорректным. И ни в коем случае нельзя выкладывать информацию о том, как воспроизвести баг до получения разрешения от разработчиков проекта.

Участие в Bug Bounty может стать источником дополнительного дохода, но сделать его основной специализацией получается не у всех. В то же время, не в каждой нише можно получить несколько тысяч долларов за 1-2 дня работы.

История взлома одной браузерной игры. Возврат контроля

Доброго времени суток. Я занимаюсь аудитом защищённости веб-приложений. По простому — тестами на проникновение в отношении веб-сайтов. Иногда в моей практике встречаются интересные и познавательные случаи, которые я бы хотел описывать в виде таких вот статей, но редко (для меня это первый случай) бывают ситуации когда клиент разрешает публикацию подобного материала с подробным описанием всех имевшихся проблем и предпринятых действий. Естественно, тут вы не встретите никаких конкретных имён, названия фирмы-заказчика и т. д. Упоминания таких данных мне, наверное, никто никогда не разрешит. Надеюсь что для вас, уважаемые читатели, данная статья окажется интересной и полезной.

Предисловие

Изначальная ситуация была следующая. Жила и развивалась одна браузерная игра со сравнительно высоким он-лайном. Проект монетизировался за счёт покупок игроками виртуальных вещей за реальные деньги. В один прекрасный день среди игроков появился взломщик, который найдя несколько уязвимостей в движке игры стал нарушать игровой баланс различными способами. Он увеличивал количество денег, как у себя, так и у других игроков, повышал всем желающим игровой опыт, генерировал редкие игровые предметы. Естественно платежи от пользователей почти сразу сошли на нет. Зачем платить за что-то если это что-то бесплатно раздают? Разработчики пробовали бороться с этим, даже нанимали человека, который за 200$ брался устранить «все уязвимости» в коде, но результата не было. Их терпение окончательно лопнуло когда злоумышленник слил дамп БД + все исходные коды игры и разместил их на одном публичном форуме, с предложением использовать игру кто где хочет совершенно свободно. И если раньше, в процессе борьбы с хакером, игра хоть как-то развивалась, то теперь делать это было просто нельзя — любые доработки или новые модули сразу же могли утечь в сеть.

Первичный осмотр

Игра базировалась на VPS под управлением Debian с администрированием силами хостера. От последнего, кроме самого сервера, давалась ещё панель управления и PhpMyAdmin.
Конфигурация внутреннего ПО очень располагала ко взлому. Настройка PHP позволяла и открывать и подключать внешние файлы (allow_url_fopen/include), хотя для работы игры ни того, ни другого не требовалось. Безопасный режим (safe_mode) был выключен, опция open_basedir не установлена. Функции типа system(), exec(), и других, обеспечивающих выполнение системных команд, запрещены с помощью disable_functions не были. Вывод ошибок был включен, а об их логировании не шло и речи.
Что касается веб-сервера (Apache), то под его управлением крутилось несколько поддоменов имеющих отношение к игре — форум, тестовая площадка и прочее. Работа веб-сервера с PHP велась в режиме FastCGI, но главный козырь в плане безопасности — запуск скриптов с правами их владельцев — был сведён на нет простым фактором — владельцем содержимого всех поддоменов был один и тот же пользователь. На этом моменте стало ясно что уязвимости не обязательно должны быть в движке самой игры, они могут находиться и на периферийных доменах.
В MySQL ситуация была аналогичная. Для каждого из поддоменов имелась своя БД, а работа из скриптов с ними шла через одного и того же пользователя.
Доступ к серверу извне осуществлялся с помощью SSH и FTP. И если в адрес первого ничего плохого сказать не могу, то с FTP ситуация была совершенно иная. Попав на FTP, пользователь сразу получал доступ к содержимому всех поддоменов. Кроме того, здесь же, в корне FTP, лежала папка с бэкапами базы данных. В них было всё вплоть до паролей пользователей. Тут же находились и архивы с логами FTP. Апогеем всего этого, как наверное уже многие догадались, являлось то, что логин и пароль были одни и те же на SSH, FTP и MySQL.
После более тесного ознакомления всплыл ещё один не хороший момент. Движок игры разрабатывался без использования системы контроля версий. Всё правилось «по живому», а если нужно было создать резервную копию файла, её прямо на FTP называли чем-то типа script_name111111111.php, после чего загружали свежий script_name.php. Работа над движком велась уже достаточно долгое время, и таких «откатных» файлов были десятки. Своим присутствием они сильно осложняли поиск веб-шеллов и прочих бэкдоров, которые мог загрузить нападающий. А анализ исходного кода, на предмет наличия в нём уязвимостей, становился просто не возможен. Вообщем, нужно было срочно исправлять ситуацию.

Попытка номер раз

Нужно упомянуть об одной форе, если так можно выразиться, которая работала на нас. К тому времени как разработчики обратились ко мне, развитие игры практически встало, количество игроков упало и взломщику самому наскучило в ней сидеть. Он заходил раз в день, примерно час занимался всякими переписками и уходил. Активно себя вести он начинал только когда начинали действовать разработчики — вводили какие-то дополнения, блокировали его аккаунт и т. д. То есть можно было с уверенностью говорить о том, что пока мы не начнём вносить заметные, для него, изменения в ПО сервера и игры, взломщик сам шевелиться не начнёт.
Исходя из этого нужно было действовать так, чтоб злоумышленник после осознания изменений касающихся защиты, никак на них повлиять уже не смог. Поэтому в первую очередь мы занялись максимальным уменьшением площади его влияния.
Сперва было решено ограничить доступ извне на все жизненно-важные сервисы (панель управления VPS, PMA, SSH, FTP, MySQL) по IP-адресам. Далее в системе были созданы пользователи для каждого поддомена, и всё их содержимое было перемещено в соответствующие домашние директории. Аналогичным образом поступили с базой данных. Теперь злоумышленник не мог имея контроль над одним сайтом, как-то воздействовать на другие.
Чуть не забыл. Права 777 мы сняли со всех директорий, которые их имели. Сайты полностью стали отделены друг от друга.
Затем поправили конфигурацию PHP. Функции запуска команд ОС, а также возможность подключения и чтения файлов по URL стали запрещены. Вывод ошибок отключили, попутно включив их запись в файл (error_log). К сожалению, по причинам связанным с особенностями работы движка, сразу не получилось включить безопасный режим (safe_mode), или хотя бы установить open_basedir. Поэтому далее пришлось работать без их помощи.
Как ни странно, все наши действия ни коим образом не привлекли внимания злоумышленника.
Видимо ему в конец наскучило лазанье по серверу и кроме самой игры он никуда не заходил. Это давало ещё некоторое количество времени. Как раз к этому моменту разработчики удалили все резервные скрипты и можно было приступать к анализу используемых веб-приложений.
Сразу была обнаружена одна очень популярная проблема — к содержимому директорий с библиотеками, конфигурационными файлами и пр. доступ извне был открыт. Конечно, критичной брешью это не является (те же конфигурационные файлы представляли из себя php-скрипты и прямое обращение к ним ничего не давало), но если их содержимое доступно извне, они представляют собой хорошее место для хранения вредоносного кода. Когда в такие папки доступ закрывают, количество мест для поиска «подарков» от злоумышленника резко снижается. В случае с движком игры, возможность обращения извне мы оставили в одну директорию со скриптами и в несколько с JS-файлами, стилями и изображениями. В последних просто запретили выполнение скриптов. Таким образом осталась одна папка где вообще внешним пользователем могло быть вызвано выполнение PHP-кода. В принципе, злоумышленник мог внести опасные изменения в какой-нибудь внутренний скрипт, и попытаться обращаться к своему коду уже из общедоступных скриптов. Но и эту проблему мы решили, правда не сразу (об этом чуть ниже).
Сам исходный код игры оказался просто нашпигован слепыми SQL-инъекциями. За всё время нашего сотрудничества их было обнаружено несколько десятков. Нанятый для их устранения человек, о котором я уже упоминал в начале статьи, банально приписал к каждым попадающим в запрос переменным использование функции mysql_real_escape_string(). Но по каким-то причинам он не учёл того, что в этих переменных разработчиками ожидалось наличие числовых значений, поэтому в SQL-запросах места их включения кавычками обрамлены не были. Следовательно, не смотря на экранирование средствами mysql_real_escape_string() инъекции можно было использовать, главное не включать в опасные запросы спец. символы.
Что интересно, различных вредоносных скриптов ни на одном домене на тот момент обнаружено не было, хотя мы ожидали наличие как минимум одного. Позже удалось выяснить что все свои действия хакер совершал через PMA.
В качестве последнего штриха мы решили подключить к PHP логгер информации обо всех входящих запросах (запись сериализованных GET/POST/SERVER/COOKIE/SESSION-массивов) с помощью опции auto_prepend_file, и спровоцировать атакующего очередным баном. С логгером сразу же возникли проблемы. Хоть и средний онлайн к тому времени был не велик, запросов игроки совершали столько, что логгер съедал место на жёстком диске не по дням, а по часам. Как решение пробовали использовать сжатие записываемых данных gzip`ом. Помогло. С учётом свободного места на винчестере + 1Гб про запас, логгер мог работать примерно 17 часов. В связи с этим было решено писать лог для каждого часа отдельно, а в середине дня сливать все имеющиеся лог-файлы на локальный компьютер, попутно затирая их оригиналы. Так как злоумышленник после бана начал бы действовать максимум через 24 часа (он появлялся в игре каждый день), то нужно было бы выкачивать логи всего 2-3 раза. Так и получилось.

Попытка номер два

В назначенное время мы включили логгер, проверили нормально ли идёт запись данных, сменили все старые пароли и забанили злоумышленника. Настало время ожидания. Приблизительно через 12 часов он дал о себе знать. К нашему удивлению хакер снова снял с себя бан и продолжил играть.
Сразу после этого мы начали обсуждение всех предпринятых мер с целью понять что же мы упустили. И быстро обнаружили один промах. Он был прост и банален — пароли на всех управляющих сервисах сменили, но забыли про админ-панель. Там пароли остались старые.
Затем я решил снова обратить внимание на исходные коды самой игры. Мало ли что туда могло быть загружено злоумышленником после недавней провокации. У меня как раз был последний рабочий вариант на винчестере. Я принялся скачивать движок с FTP и сравнивать копии локально. Ни один файл не был изменён, но появился один новый скрипт (анализ записей логгера, который был проведён позднее, показал к нему обращения). Это был веб-шелл. По дате его создания я сразу понял в чём дело. Проверяя исходные коды я проходил папку за папкой, сдавая разработчикам найденные уязвимости и выискивая подозрительные скрипты. Когда была изучена примерно половина всего объёма, злоумышленник залил веб-шелл в директорию, содержимое которой я проверил в самом начале. Соответственно никто этого сразу не обнаружил. А нападающий смог воспользоваться им для снятия бана. Тут уже стало ясно что нужно как-то решать вопрос с контролем целостности файловой структуры движка. Так как систему контроля версий использовать ещё не начали (её внедрили позднее), то пришлось выкручиваться bash-скриптом, который запускался кроном раз в 10 минут, и проверял наличие новых/удалённых файлов, а также сверял контрольные суммы скриптов с суммами-оригиналами. Его прототип я описал в одной из своих статей — anton-kuzmin.blogspot.com/2011/01/blog-post.html.
Теперь, когда шелл был удалён, пароли снова изменены (на этот раз все), а bash-скрипт запущен, настал момент очередного бана.

Заключение

Принятые меры подействовали. Нападающий зарегистрировал в игре нового персонажа, но даже по прошествии суток (и до текущего времени) его аккаунт оставался таким же простым как и у остальных игроков. В файловой структуре сервера изменений больше не происходило, игровой баланс начал потихоньку восстанавливаться, а разработчики стали массово применять обновления которые готовили ранее, но не хотели загружать на сервер пока проблема с хакером не будет решена.
Кстати, взломщик сразу не успокоился. Он выложил в этот же день на форуме, где обычно выкладывал внутренности игры, очередной дамп, который был достаточно старым, под видом самого свежего. После этого он зачем-то связался с одним из разработчиков и стал убеждать его в том, что доступ к серверу до сих пор не потерян. Но на просьбы подтверждения этого (например, дать пароль одного из администраторов) он либо вообще не отвечал, либо давал какие-то не актуальные данные.

P.S.

В завершении этой статьи хотелось бы выделить несколько важных правил для разработчиков и администраторов веб-приложений. Для кого-то они покажутся банальными, но я уверен что некоторым могут пригодиться.
1) По максимуму ограничивайте PHP. Запрещайте функции выполнения команд ОС, включайте безопасный режим, отключайте модули которые вы не используете. Логируйте ошибки интерпретатора, отключайте их вывод на рабочих серверах.
2) При формировании резервных копий удаляйте из них любую чувствительную информацию, такую как пароли пользователей, ответы на секретные вопросы, реквизиты подключения к БД.
3) При хешировании данных используйте не простые схемы типа одного вызова md5() или sha1(). Не стоит использовать и решения взятые из популярных веб-движков. Организовать их расшифровку могут уже большинство программ занимающихся работой с хешами. Если вы будете использовать свою уникальную схему, пусть даже это будут 7 вызовов md5() подряд, то злоумышленник, скорее всего, не сможет ничего расшифровать. Ведь если используемой вами схемы нет ни в одной известной программе, то ему придётся либо писать отдельный модуль конкретно для вашего случая, либо заказывать его за деньги. Подумайте, сколько процентов из общего числа злоумышленников станет это делать? Не стоит забывать и о сложных паролях.
4) В приложениях используйте жёсткое разделение на административные и простые аккаунты. То есть чтоб в ту же игру, администратор не смог войти с использованием реквизитов админ-панели, и на оборот.
5) Если вы решили хранить какие-либо пароли прям в коде приложения, храните не их самих, а их хеши.
6) Пароли привилегированных пользователей должны быть уникальны для вашего приложения. Очень не хорошие последствия может сулить ситуация, когда, например, у модератора пароль на вход в основное приложение и на доступ к форуму один и тот же.
7) Используйте для работы с БД готовые библиотеки типа PEAR::MDB2. В них функция экранирования данных, попадающих в запрос, вызывается автоматически, что предотвращает множество проблем. Аналогично дело обстоит и с фреймворками. Если уж вам приходится помещать данные в SQL-запрос прямо в коде (например используете mysql_query()), то обрамляйте кавычками каждое помещаемое в запрос значение и не забывайте про mysql_real_escape_string().
8) Избегайте выставления прав 777 на директории веб-приложений. Хотя тут всё зависит от ситуации. Иногда без этого никак.
9) Запретите выполнение скриптов в директориях, которые доступны извне и не имеют никаких скриптов внутри себя. Это могут быть папки с JS-файлами, CSS-стилями, шрифтами, картинками и т. д. А к директориям (и их содержимому), к которым пользователи не должны обращаться, вообще закройте доступ. По возможности их лучше вынести за пределы веб-директории.
10) Очень желательно все ограничения и настройки связанные с веб-сервером хранить в общем конфигурационном файле (httpd.conf), а настройки «на местах» (по средствам .htaccess) отключить. Это обеспечит централизованное хранение конфигурации, а также не позволит человеку получившему доступ к сайту что-то менять в отношении конкретных его директорий. Если же такой возможности нет, и вы, например, используете .htaccess, то старайтесь выставить на него такие права и владельца, чтоб от имени веб-сервера туда невозможно было вносить изменения.
11) Ограничивайте доступ на важные сервисы и панели управления по IP-адресам.
12) Используйте систему контроля версий.
13) Размещайте домены и БД, для приложений находящихся на них, таким образом, чтоб они не имели влияния друг на друга. Чтоб злоумышленник, взломав один сайт, не смог через него попасть на другой.
14) Не ставьте всяческих анти-хакерских скриптов и аналогичных модулей, предварительно их тщательно не протестировав. Особенно досконально изучите их если вы собираетесь ставить вместе 2-3 таких скрипта. Чаще всего это приводит к большим проблемам.
15) Если вдруг злоумышленник после отражённой атаки связывается с вами и начинает убеждать вас в том, что ваши действия бесполезны, тщательно проверяйте всё что он вам говорит. Возможно он просто блефует.
16) При возникновении каких-либо инцидентов, если по логам веб-сервера обнаружить уязвимое место невозможно, попробуйте логировать все данные обращений всех пользователей. Это можно делать как с помощью самописных скриптов, так и отдельных модулей веб-сервера.

И два отдельных правила, касающихся контроля пользователей в онлайн-играх, к которым я пришёл в процессе работы над этим случаем:
1) Автоматизируйте подсчёт количества игровых денег (полученных, потраченных) и опыта, ведите их ежедневную статистику. Раз в сутки собирайте эти данные и сравнивайте с прошлым днём. Так вы уже через неделю определите средний процент общего их увеличения за 24 часа при нормальном течении игры. Как только появится нечестный игрок, сумевший, к примеру, начислить себе огромное количество игровой валюты, вы сразу об этом узнаете.
2) Логируйте все операции с игровыми вещами. Вещь создалась при убийстве монстра, вещь передали, вещь продали — записывайте всё. Аналогично предыдущему пункту можно с определённым временным интервалом выбирать из базы вещи, которые до появления у игрока никакой истории не имели. То есть появились практически из ниоткуда. Кстати, этот же механизм поможет возвращать владельцам украденные вещи, а нечестных игроков быстро отлавливать.

Надеюсь что в процессе чтения этой статьи вы узнали что-то новое и она оказалась вам полезна. Буду рад ответить на любые ваши вопросы.

На днях была обнаружена критическая уязвимость в библиотеке apache log4j2, которую Minecraft использует для логгирования.
С помощью найденного эксплоита можно не только убивать сервера, но и ВЫПОЛНЯТЬ ПРОИЗВОЛЬНЫЙ КОД (. ) как на клиенте, так и на сервере.

Отмечается, что проблеме подвержены почти все проекты, использующие такие фреймворки, как Apache Struts, Apache Solr, Apache Druid или Apache Flink, включая Steam, Apple iCloud, клиенты и серверы игры Minecraft. Ожидается, что уязвимость может привести к волне массовых атак на корпоративные приложения, повторив историю критических уязвимостей во фреймворке Apache Struts, который по приблизительной оценке применяется в web-приложениях 65% компаний из списка Fortune 100. В том числе уже зафиксированы попытки сканирования сети на предмет уязвимых систем.

Проблема была вызвана тем, что Log4j2 поддерживает обработку специальных масок <> в выводимых в лог строках, в которых могли выполняться запросы JNDI (Java Naming and Directory Interface). Атака сводится к передаче строки с подстановкой $ , при обработке которой Log4j2 отправит на сервер attacker.com LDAP-запрос пути к Java-классу. Возвращённый сервером атакующего путь (например, http://second-stage.attacker.com/Exploit.class ) будет загружен и выполнен в контексте текущего процесса, что позволяет атакующему добиться выполнения произвольного кода в системе с правами текущего приложения.

Уязвимость Log4j | Эта Команда в Чате ЛОМАЕТ СЕРВЕРА MINECRAFT

Microsoft сообщили, что устранили уязвимость для последних версий Minecraft, но что до более старых версий — не известно когда они будут исправлены и будут ли вообще. Когда исправят в сторонних лаунчерах (TLauncher и др.) так же ничего неизвестно.

ПОЭТОМУ НАСТОЯТЕЛЬНО НЕ РЕКОМЕНДУЕТСЯ СЕЙЧАС ВООБЩЕ ИГРАТЬ НА СЕРВЕРАХ.
Будь то проект со своим лаунчером или публичный сервер.
Если вы играете на каком-то сервере, сообщите администратору об этой уязвимости, отправив ссылку на эту тему.

Решение для владельцев серверов:
1. Обновить библиотеку log4j2 до последней актуальной версии и на клиенте, и на сервере;
2. Добавить в JVM аргументы запуска данную строку: -Dlog4j2.formatMsgNoLookups=true и на клиенте, и на сервере.

Если не получается обновить библиотеку на старых версиях игры, я написал небольшую утилиту, которая патчит log4j2 и вырезает уязвимость.

GitHub — tox1cozZ/log4j2-jndi-exploit-patcher: A utility that looks for log4j2 JNDI vulnerabilities in your jar files and fixes them.

A utility that looks for log4j2 JNDI vulnerabilities in your jar files and fixes them. — GitHub — tox1cozZ/log4j2-jndi-exploit-patcher: A utility that looks for log4j2 JNDI vulnerabilities in your .

В репозитории есть инструкция по применению.

Ещё материалы по теме:

Mitigating CVE-2021-44. | CreeperHost Wiki

If you are using Minecraft 1.18 or older we recommend following this guide to install a patch to mit.

Источник: forum.mcmodding.ru

Шифровальщик Khonsari атакует серверы Minecraft

Рекомендуем почитать:

Xakep #287. Атаки на хардвер

• Содержание выпуска
• Подписка на «Хакер» -60%

Компания Microsoft призвала администраторов частных серверов Minecraft (расположенных на собственном хостинге) как можно скорее обновиться до последних версий. Дело в том, что их атакует вымогатель Khonsari, использующий критическую уязвимость Log4Shell.

Еще на прошлой неделе стоящие за Minecraft разработчики из Mojang Studios выпустили экстренное обновление безопасности для устранения критической ошибки CVE-2021-44228. Об этой проблеме, недавно обнаруженной в библиотеке журналирования Log4j, мы уже рассказывали детально, и в последние недели о ней говорит весь мир. Эта уязвимость также известна под названием Log4Shell и имеет все шансы стать одним из худших багов последних лет.

В Minecraft библиотека Log4j используется Java Edition клиентом игры и многопользовательскими серверами. Как теперь предупредили специалисты Microsoft, новая уязвимость уже активно применяется для атак на частные серверы:

«Злоумышленник отправляет вредоносное внутриигровое сообщение на уязвимый сервер Minecraft, которое эксплуатирует CVE-2021-44228 для извлечения и выполнения полезной нагрузки, размещенной злоумышленником, как на сервере, так и на подключенных уязвимых клиентах.

Мы наблюдали использование вредоносного класса Java, который представляет собой шифровальщик Khonsari и выполняется в контексте javaw.exe, чтобы затем потребовать выкуп».

Также специалисты Microsoft 365 Defender Threat Intelligence и Microsoft Threat Intelligence Center (MSTIC) сообщают, что наблюдали реверс-шеллы на базе PowerShell, развернутые на корпоративных эндпоинтах, где эксплоиты для Log4j, нацеленные на серверы Minecraft, являлись лишь точкой входа.

В итоге Microsoft простив всех администраторов немедленно установить последние обновления, чтобы защититься от атак, а игрокам рекомендует подключаться только к доверенным серверам Minecraft и использовать официальную и самую новую версию клиента. Администраторы серверов Minecraft: Java Edition могут найти все необходимые инструкции по обновлению здесь.

О шифровальщике Khonsari мы уже рассказывали отдельно. На первый взгляд кажется, что эта малварь эксплуатирует проблему Log4Shell для вымогательских атак. Однако на самом деле Khonsari ско­рее похож на вай­пера, то есть это умыш­ленно дес­трук­тивная мал­варь, которая нароч­но шиф­рует дан­ные без воз­можнос­ти вос­ста­нов­ления. Дело в том, что жер­твы не могут свя­зать­ся с опе­рато­рами вре­доно­са для вып­латы выкупа (в послании, которое оставляют после себя вымогатели, просто нет контактов), а зна­чит, не могут и спас­ти свою информа­цию.

Судя по всему, начавшиеся теперь атаки на серверы Minecraft тоже осуществляются исключительно ради грифинга и троллинга, и операторы малвари не преследуют финансовую выгоду.

Источник: xakep.ru

Как хакеры поставили на колени самый анархичный сервер Minecraft

На первый взгляд, Minecraft — все о веселье и забаве. Здесь мы восхищаемся людьми, воссоздающими мир «Властелина колец», а также невероятными визуальными трюками, для создания которых достаточно приложить небольшую изобретательность. Но у игры есть куда менее известная (хотя зачастую не менее популярная), более мрачная сторона.

2B2T — один из наиболее популярных «анархичных» серверов игры, где отсутствуют какие-либо правила, а карта размером в несколько терабайт и вовсе не сбрасывалась с далекого 2010 года. Сервер, название которого расшифровывается как 2 Builders 2 Tools, по своей задумке должен был стать негостеприимным и злобным, поэтому временами его награждали титулом «худшего» сервера Minecraft. Само собой, геймеры с сервера не поддерживали подобных высказываний. В соответствии с их точкой зрения, 2B2T — пример невероятно широкой привлекательности и способности Minecraft привлекать игроков к творчеству: это место с реальной историей и действиями, определяющими ландшафт. Благодаря сформировавшемуся сообществу 2B2T и тому, как сервер развивался с годами, он стал частью выставки Videogames: Design / Play / Disrupt, которая прошла в залах лондонского Музея Виктории и Альберта.

Но эта история началась в 2018 году, когда два игрока обнаружили уязвимость в плагине Paper, которые призван исправлять ошибки и повышать производительность многопользовательских серверов Minecraft. Эксплойт, по сути, обманывал сервер, заставляя его думать, что они щелкают по всем блокам на карте — даже тем, которые находятся за областью рендеринга. В результате сервер был вынужден мгновенно обрабатывать тысячи чанков (блоков 16×16, из которых состоят карты Minecraft), что приводило к гарантированному сбою. Казалось бы, это просто очередная фатальная ошибка, которую очень быстро исправят разработчики программного обеспечения PaperMC.

И как раз «быстро» стало главной проблемой.

Лейджурв — один из программистов, работавших над NoCom (но уже с начала 2020 года) — написал большой и подробный пост, в котором объяснил, что именно сумела сделать группа и почему это сработало.

В начале сообщения даётся ссылка на видеоролик YouTube за авторством FitMC, который был создан совместно со злоумышленниками.

Со слов Лейджурва, причина, по которой NoCom так долго оставалась незамеченной, заключается «в том, что в действительности нет «эксплойта» или «бэкдора», который представлял каждый. Другими словами, сервер «не хулиганит» и не делает ничего подозрительного. Это абсолютно ожидаемая и запланированная реакция, код не делает ничего скрытно или тайком, на самом деле все куда проще».

PaperMC, создатель Paper, «исправил» исходный эксплойт таким способом, который ожидали хакеры, впоследствии создавшие NoCom. Теперь нажимать на блоки можно было лишь в той области, которая была зарендерена конкретным игроком. Таким образом, хакеры по-прежнему могли прокликивать блоки, чтобы узнать об их содержимом — и это обычный процесс для Minecraft. При этом блокировались все попытки взаимодействовать с блоками, расположенными далеко за пределами области, где на самом деле находится «игрок»: то есть возможность «щелкнуть» по блоку в любом месте этого бесконечного, генерируемого мира, и получить о нем информацию.

Поэтому это известная и ожидаемая реакция со стороны 2b2t. Не многие люди задумывались о том, что при помощи выхода за пределы рендеринга можно было бы извлечь информацию. Таким образом, вы щелкаете по любому блоку в любом месте сервера, даже если он находится за миллион блоков от вас, и по тому, отвечает вам сервер или нет, узнаете, загружен ли блок в настоящее время.

Руководствуясь здравым смыслом, разработчики Paper сделали патч, который гарантировал ответ сервера лишь в том случае, если чанки были загружены этим игроком (отрендерены), поскольку это имело логический смысл (только те блоки, которые вы могли бы копать, не нарушая правил). Проблема в построении кода связана с тем, что сервер отвечал вам, даже если бы блок был загружен любым игроком на сервере. Явный побочный эффект.

Лейджурв

Как вы думаете, почему это так важно? Как только этот эксплойт стал доступен, люди, стоящие за NoCom, начали проверять, загружены или выгружены определенные чанки карты. Первое указывало на присутствие в конкретной области других игроков, и их местоположения регистрировались и сохранялись, указывая на то, где находятся базы или другие полезные места. Этот гениальный эксплойт NoCom в последние три года огорчал и раздражал игроков сервера, выбранного грифферами в качестве цели для харасмента.

Вот тепловая карта 2B2T, показывающая, где сосредоточены игроки и группы. И тут начинает проявляться дьявольская хитрость хака.

При первом обнаружении эксплойтом пришлось использовать вручную. Было очевидно, что бесконечное прокликивание блоков в попытках узнать, что и где находится — не самый лучший метод. Создатели NoCom начали автоматизировать процесс, внедряя на сервер ботов, работавших посменно так, чтобы один из них обязательно был в сети: и эти боты наблюдали за основными маршрутами передвижения.

Когда один из них регистрировал игрока, он отслеживал его движения с помощью программы и обращал особое внимание на то, сколько времени он проводил в определенных областях.

Далее Лейджрув максимально просто объяснил, что будет делать бот Elon_Musk:

Происходит сканирование маршрутов (пробивание одного блока на каждые девять с расширением наружу по каждой дороге и диагонали — наподобие радара). В случае успешного попадания происходит регистрация передвигающегося геймера. А вдруг он движется на базу?

И после этого мы просто следуем за ним.

Мы разработали систему, использующую фильтр частиц Монте-Карло для имитации и отслеживания движения, которая запускала около двух проверок в секунду, чтобы не отставать от игрока, который движется с произвольной скоростью — от ходьбы до спринта. Даже в режиме наблюдателя! Все, что нас волнует — загружаются ли чанки.

По сути, мы создали радар, который использует несколько сотен проверок в секунду, чтобы следить за передвижением кораблей, словно это морской бой с читами.

И когда «линкор» исчезает с одного маршрута, мы переключаемся на другой и продолжаем движение (боты, безусловно, координируют друг друга).

Таким образом, мы, не отставая, следим за игроками прямо до их баз, пока они продолжают загружать свои чанки (рендерить блоки на карте). Используя наши наблюдательные посты, мы свободно проверяем фрагменты по всей карте, на любом расстоянии.

В конце концов, NoCom удалось собрать 1.7 TB и 13.5 млрд строк данных о мире 2B2T. Данные, которые используются для того, чтобы сеять настоящий хаос: «распечатываешь список баз с самым большим числом сундуков, отправляешься в помеченные локации и занимаешься грабежом».

В 2020 году активность NoCom начала достигать пика — данных становилось все больше, они были максимально точны, и поэтому игроки все чаще поддавались соблазну. Были разрушены бесчисленные базы, разграблены несметные богатства, и сообщество погрузилось в полномасштабную панику до такой степени, что многие отказывались входить в игру.

Началось активное обсуждение между сообществом 2B2T, появлялось все больше людей, утверждавших, что на сервере происходит что-то странное. Но создатели NoCom запустили целую кампанию по дезинформации на сабреддитах и серверах Discord (используя мемы, скрывающие эксплойт, и другие методы газлайтинга), заявляя, что все, кто беспокоятся — обычные параноики.

По мере того как NoCom набирал обороты и его присутствие на сервере уже было невозможно скрывать, создатели эксплойта понимали, что конец близок. В июне и июле NoCom работал на максимуме возможностей, пытаясь выжать все до последней капли из имеющихся данных до того, как администратор сервера, наконец, сумел его исправить, ограничив количество пакетов, которые могли отправлять учетные записи за один серверный тик.

NoCom возможно исчез, но его тень еще долго будет виснуть над 2B2T. Извлеченные данные по-прежнему доступны и будут точны до тех пор, пока сообщества и игроки не переместят свои базы: далеко не легкий и удобный процесс. Теперь большинство фантастических творений — банальные заложники удачи. 2B2T продолжает свое существование, но произошедшее — пожалуй, самое знаковое событие в истории сервера.

Больше статей на Shazoo

• Что будет в обновлении Minecraft 1.20 — первая бета стартует в ближайшие дни
• На этот парящий город в Minecraft потратили более 7000 часов
• Фанат Minecraft создал ролик про ночную битву в стиле аниме

Источник: shazoo.ru