Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737
Форумы портала PHP.SU :: История взлома одной браузерной игры

 PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (1): [1]   

> Описание: Возврат контроля
Белый Тигр
Отправлено: 09 Ноября, 2011 - 06:49:49
Post Id



Новичок


Покинул форум
Сообщений всего: 18
Дата рег-ции: Март 2011  
Откуда: Россия


Помог: 1 раз(а)




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

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

Предисловие
Изначальная ситуация была следующая. Жила и развивалась одна браузерная игра со сравнительно высоким он-лайном. Проект монетизировался за счёт покупок игроками виртуальных вещей за реальные деньги. В один прекрасный день среди игроков появился взломщик, который найдя несколько уязвимостей в движке игры стал нарушать игровой баланс различными способами. Он увеличивал количество денег, как у себя, так и у других игроков, повышал всем желающим игровой опыт, генерировал редкие игровые предметы. Естественно платежи от пользователей почти сразу сошли на нет. Зачем платить за что-то если это что-то бесплатно раздают? Разработчики пробовали бороться с этим, даже нанимали человека, который за 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 минут, и проверял наличие новых/удалённых файлов, а также сверял контрольные суммы скриптов с суммами-оригиналами. Его прототип я описал в одной из своих статей - http://anton-kuzmin[dot]blogspot[dot]com[dot][dot][dot]1/blog-post[dot]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) Логируйте все операции с игровыми вещами. Вещь создалась при убийстве монстра, вещь передали, вещь продали — записывайте всё. Аналогично предыдущему пункту можно с определённым временным интервалом выбирать из базы вещи, которые до появления у игрока никакой истории не имели. То есть появились практически из ниоткуда. Кстати, этот же механизм поможет возвращать владельцам украденные вещи, а нечестных игроков быстро отлавливать.

Надеюсь что в процессе чтения этой статьи вы узнали что-то новое и она оказалась вам полезна. Буду рад ответить на любые ваши вопросы. Их можно задать мне в этой теме или по электронной почте на адрес anton.kuzmin.russia@gmail.com .
 
 Top
Самогонщик
Отправлено: 09 Ноября, 2011 - 06:59:01
Post Id



Посетитель


Покинул форум
Сообщений всего: 495
Дата рег-ции: Окт. 2011  


Помог: 8 раз(а)




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

Возник всего один вопрос: а поиск по дате самых последних изменённых файлов мог бы помочь найти свежезалитый веб-шелл?
 
 Top
sKaa
Отправлено: 09 Ноября, 2011 - 07:24:20
Post Id



Частый посетитель


Покинул форум
Сообщений всего: 979
Дата рег-ции: Окт. 2011  
Откуда: Россия г. Нижний Новгород


Помог: 25 раз(а)

[+]


Хорошая статья
 
 Top
DeepVarvar Супермодератор
Отправлено: 09 Ноября, 2011 - 07:31:52
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Спойлер (Отобразить)
 
 Top
Самогонщик
Отправлено: 09 Ноября, 2011 - 08:30:36
Post Id



Посетитель


Покинул форум
Сообщений всего: 495
Дата рег-ции: Окт. 2011  


Помог: 8 раз(а)




DeepVarvar, вопрос ведь не в том как сделать, а помогли бы ли это в том конкретном случае, а если помогло бы, почему автор так не сделал (или сделал, но умолчал)?
 
 Top
DeepVarvar Супермодератор
Отправлено: 09 Ноября, 2011 - 08:42:37
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Судя по тексту топика, автор говорит что нужно делать, а не как...
Естественно он не хотел бы раскрывать свои методы в полной мере..
 
 Top
EuGen Администратор
Отправлено: 09 Ноября, 2011 - 08:44:52
Post Id


Профессионал


Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




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


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
DeepVarvar Супермодератор
Отправлено: 09 Ноября, 2011 - 08:52:27
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




EuGen пишет:
Если то, что описано - правда, то в плане безопасности (а вернее ее отсутствия) эта самая "игра" ушла недалеко от лабораторных работ студентов 2-3 курса.
Действительно, все мыслимые и немыслимые.. Скажем даже если и приврал, то всеравно впрок написано.
 
 Top
DlTA
Отправлено: 09 Ноября, 2011 - 09:38:51
Post Id



Постоянный участник


Покинул форум
Сообщений всего: 2952
Дата рег-ции: Окт. 2010  


Помог: 53 раз(а)




Белый Тигр, а во сколько($) обошлась вся работа по безопасности?
 
 Top
Белый Тигр
Отправлено: 09 Ноября, 2011 - 10:24:03
Post Id



Новичок


Покинул форум
Сообщений всего: 18
Дата рег-ции: Март 2011  
Откуда: Россия


Помог: 1 раз(а)




Спасибо за отзывы!

Цитата:
Возник всего один вопрос: а поиск по дате самых последних изменённых файлов мог бы помочь найти свежезалитый веб-шелл?

Мог бы, но только в том случае, когда шелл был бы залит изначально и был бы очень свежим. В начале статьи я писал что шеллов среди исходников игры не было. Появившийся потом шелл просто попал в подходящий временной промежуток - на шеллы была проверена часть папок в которых он и появился когда изучались уже другие директории. В это время его появления там просто не ждали (мне урок на будущее ;) ).
Цитата:
Белый Тигр, а во сколько($) обошлась вся работа по безопасности?

По условиям договора я не могу разглашать такую информацию. Если интересует стоимость проверки какого-то конкретного сайта, можете кинуть в личку адрес и какой вид проверки интересует (описания видов есть в моей теме о предоставляемых услугах: http://php.su/forum/topic.php?forum=43&topic=878) и я скажу сколько это будет стоить.

(Отредактировано автором: 09 Ноября, 2011 - 10:25:58)

 
 Top
Самогонщик
Отправлено: 09 Ноября, 2011 - 10:40:52
Post Id



Посетитель


Покинул форум
Сообщений всего: 495
Дата рег-ции: Окт. 2011  


Помог: 8 раз(а)




Белый Тигр пишет:
В начале статьи я писал что шеллов среди исходников игры не было. Появившийся потом шелл просто попал в подходящий временной промежуток - на шеллы была проверена часть папок в которых он и появился когда изучались уже другие директории.
Вот это я имел введу. Тоже можно вынести в совет, что мол пока проверяешь на шеллы, а сайт не обновляется можно создать скрипт который будет обнаруживать появление новых файлов. Как то так.
 
 Top
Страниц (1): [1]
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« Обсуждение статей »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB