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

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

Надеюсь что в процессе чтения этой статьи вы узнали что-то новое и она оказалась вам полезна. Буду рад ответить на любые ваши вопросы. Их можно задать мне в этой теме или по электронной почте на адрес anton.kuzmin.russia@gmail.com .