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

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

Предисловие

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

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

Ну. И что?
Реклама
Комментарии 115
  • +3
    извне — слитно, никакого «вна» не существует. если сложно запомнить, то надо писать «снаружи»
    • +2
      В личку надо такие вещи отсылать.
      • +49
        а я уже затрахался в личку отсылать. пусть не только написавший статью видит элементарные ошибки, но и все, кто пишет комментарии.
        • +1
          public grammar nazi
          • +2
            … Буддизм учит людей быть доброжелательными, терпимыми к окружающему.

            • –1
              Отлично. Пусть учит. Я тоже из благих побуждений.
          • –6
            И еще опечатка: интерпрЕтатор. Мне тоже влом в личку.
          • 0
            А «по средствам .htaccess», по-вашему, ничего? )
            • 0
              некоторые тексты тут читаешь и просто плачешь. хана всеобщему образованию.
              • 0
                Мне начинает казаться, что образование такого качества нахрен не нужно.
                • 0
                  Ну да, они уже собираются отказаться от него, просто пока делают вид, что оно есть и еще нужно.
          • +4
            И тестовые варианты скриптов тоже лучше не оставлять
            • 0
              странно — если все данные игры генерируются через базу данных — с нее и надо было начать
              • +57
                Читаешь третий абзац и диву даешься − при всех своих «навыках» администрирования серверов этим людям удалось поднять и монетизировать браузерную игру, офигеть.
                • +3
                  Надеюсь вам не нужно говорить сколько говнобраузерок наплодилось на движке от БК? И как не странно, некоторые из них вполне стабильно получают прибыль.
                  • +2
                    движок бк перловый, а не пхпшный. и все супербаги были пофикшены еще году в 2002. (хотя в 2004 всплывал баг с регэкспом /e)

                    хотя мелкие, приятные для игроков баги оставались, но это уже ошибки геймдиза и геймстроя, а не безопасности.
                    • +2
                      человек имел в виду клон БК, написанный на php очень неграмотным программистом и дорабатываемый такими же новичками
                      • 0
                        В точку.
                        • 0
                          > на движке от БК
                          > движок бк перловый
                          > клон БК, написанный на php
                          okay
                    • +2
                      с администрированием силами хостера

                      Вполне возможно, что взяли «коробку» от хостера со всеми настройками по умолчанию, а дальше и не думали.
                      • +3
                        Как обеспечивающий иногда административную поддержку в своем хостинге, скажу что установка доводится до уровня поставки панели управления, любые иные настройки нулевые. Взлом клиентского ПО — не наша забота, пока оттуда спам не шлют. Как шлют, можем закрывать порты внешне и все.
                        Клиент обязан разбираться и знать как настраивать ПО. В противном случае пусть платит за разбор его скриптов. Будь его скрипты правильно написаны, никакие танцы с chmod и запуском php не нужны были бы.
                        Все остальное карма. Не умеешь настраивать сервер, клонируешь игру, пытаешься поднять деньги, тебя взламывают — карма, ибо без ума не стоит воровать.
                        • 0
                          Подождите — клиентское ПО или система? Вот в тексте «Настройка PHP позволяла ...» это вы так же оставляете, или клиент сам портит?
                          • 0
                            Как панель ставится, так оно и работает, чаще всего панель либо не ставит ВООБЩЕ никакой настройки для PHP (дефолт), либо рекомендуемый.
                      • +5
                        ничего странного не вижу, скорее закономерно, если бы в России все кто генерируют продукт умели бы его продавать)))
                        • +4
                          то я даже боюсь представить каким по счету регионом РФ была бы Калифорния)))
                        • +14
                          Людей, пишущий говнокодом работающие и приносящие деньги владельцу, вещи, куда меньше (и они куда успешнее), чем тех, кто считает себя гуру, но «взять и сделать» им мешают миллион важных причин.
                          • 0
                            Аналогично. Тут не только администрирование, но и само программирование ввергает в ужас, судя по описанию…
                          • +3
                            Почему владельцы игры не обратились в соответствующие органы?
                            • +6
                              Когда в органах появятся такие специалисты как автор, вероятно тогда и будет смысл обращаться.
                              • +1
                                А они там есть, просто их мало.
                                • +1
                                  А зачем в органах такие специалисты? Делать выводы на основе технических данных — работа для экспертизы.
                                  Вообще таких довольно часто ловят, доводят до суда и признают виновным.
                                  • 0
                                    Ловят таких специалистов или злоумышленников?:)
                                    • 0
                                      Кого потребуется:)
                                      На самом деле вы недооцениваете следственные органы. По таким примитивным случаям ловят и доказывают вину только так.
                                      • 0
                                        Я ничего про следственные органы не говорил :)
                                        Как раз по причинам связанным с законодательством недавно перешёл полностью на «белые рельсы» — договора, белая бухгалтерия, юр. гарантии и прочее. А то разные случаи бывают, можно и при проведении проверки нахватать себе проблем, если она проводится по устной договорённости.
                                • 0
                                  Не знаю. Видимо по какой-то причине не нужно было.
                                • +5
                                  Спасибо за советы. И добро пожаловать на Хабр!
                                  • –1
                                    Движок игры разрабатывался без использования системы контроля версий. Всё правилось «по живому», а если нужно было создать резервную копию файла, её прямо на FTP называли чем-то типа script_name111111111.php, после чего загружали свежий script_name.php.


                                    Что-то сложно испытывать симпатию к авторам «игры». Ненавижу дешевые говнопроекты.
                                    • +7
                                      если такое говно работает и пользователю интересно в него играть, то на организацию работы можно закрыть глаза… какое-то время.

                                      жизнь к некоторому моменту все равно приводит к появлению специалиста по безопасности.

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

                                      скорее всего над проектом работала группа энтузиастов у которых было мало опыта, но горели глаза…
                                      • +7
                                        По-вашему, это авторы игры виноваты в том, что какой-то уродец их взломал?
                                        Они написали игру, как умели, игра стала популярной, значит, людям нравится. Они сделали добро.
                                        А кулхацкер — зло.

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

                                        Или если Вас побили на улице, то это не хулиганы виноваты, а просто Вы не научились хорошо защищаться? А те, кто побил — молодцы и обнаружили уязвимости в обороне вашего тела?
                                        • 0
                                          Работа должна быть выполнена качественно, а это это напоминает отечественный автопром. Все довольны с новыми программами по утилизации старого авто, получают новую ладу. Но ведь она и новая то дрысло, а люди довольны?
                                          Если вас побили на улице — значит виноваты вы, раз не смогли даже убежать.
                                          • +6
                                            Качество работы не имеет пределов совершенства. Для всего есть оптимальное качество, которое позволяет выполнять поставленные задачи. Знаю двух людей с Ладой-Калиной, оба очень довольны. Конкуренцию ВАЗу могут составить разве что китайские производители. У ВАЗа своя ниша и свои потребители. Я сам несколько лет ездил на москвиче и 8-ке и скажу Вам, что я был вполне доволен. И сейчас, пересев на премиум-класс, я иногда задумываюсь, стоит ли весь этот комфорт тех денег, которые я за него заплатил, действительно ли машина в 10 раз лучше? И прихожу к выводу, что нет, не в 10, что просто производителям очень денег хочется, и достойных альтернатив нет, вот и снимают сливки с тех, кто готов расстаться с деньгами.
                                            • 0
                                              Ваша позиция понятна.
                                              Позор плохим бегунам!
                                              Слава хорошим хулиганам!
                                              • +1
                                                «Если вас побили на улице — значит виноваты вы, раз не смогли даже убежать. „

                                                Семья из Бутово, перехав в Лондон, не поняла о каких беспорядках идет речь ))

                                                Судя по всему, когда-то в детстве, вам так же не удалось убежать и удары наносились в основном в голову.
                                              • 0
                                                Да, несомненно, БК и его клоны — это добрые, гениальные проекты. Во как популярны! И куча дешевых переделок десктопных игр на ФБ/Контакте, популярность которых определяется по «кто первый спи*дит» тоже концентрат добра. Даешь добра поцанам!

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

                                                Еще раз: я не поддерживаю ни одну из сторон. Взломщик по поведению (если верить статье) кулхацкер. Создатели игры — зеленые гавнокодеры. Для новичков это нормально, все мы писали гавнокод. Проблема, что с деньгами растет ЧСВ, и такой гавнокодер скорее всего развиваться не будет, а будет плодить подобные продукты.
                                                • 0
                                                  +1

                                                  Вообще ЧСВ растет даже не с деньгами, а с тем что «вот моя мега игра, в неё играют сотни тысяч», и то, что игра есть самое настоящее говно с целью срубить бабла на мышкокликательных инстинктах хомячков это для большей части участников процесса есть дело десятое. Добро пожаловать в современный гейм-дев.

                                                  А мне вот жалко только художников, дизайнеров и моделлеров, за то что их шедевры иной раз попадают в такие отстойные игры, и что каждый проходящий мимо скрипткиддис может лишить их зарплаты из за отсутствия мозгов и совести у того, кто позволяет новичкам писать такие проекты за еду, без присмотра опытных разработчиков.
                                            • +4
                                              К сожалению большинству разработчиков по барабану на безопасность их продукта — главное чтобы он работал. На работе ежедневно кто-нибудь из разрабов обращается с просьбами выставить права 777 на корень сайта или что то подобное, но мы с этим боремся ;).
                                              • +15
                                                В один прекрасный день среди игроков появился взломщик, который найдя несколько уязвимостей в движке игры стал нарушать игровой баланс различными способами. Он увеличивал количество денег, как у себя, так и у других игроков, повышал всем желающим игровой опыт, генерировал редкие игровые предметы. Естественно платежи от пользователей почти сразу сошли на нет. Зачем платить за что-то если это что-то бесплатно раздают?
                                                — Без персоналий, но мошенниками я считаю тех кто создает эти бездарные браузерные игры, а этот взломщик больше похож на Робин Гуда.
                                                • +2
                                                  Мне почему-то 2FED из БК вспомнился.
                                                  • 0
                                                    В, кажиесь, «Полный root» еще герой 2FED есть, правильно?
                                                    • 0
                                                      Насколько я помню, большинство персонажей этой книги писались с «натуры» — с друзей автора из БК
                                                      • 0
                                                        Кстати да, сейчас посмотрел в описании :)
                                                  • +3
                                                    Тогда вор, который залез в вашу квартиру, скажем, по балконам, и в последствии дал возможность простым бедным людям приобщиться к вашим вещам посредством ломбардов, рынков и сервисов продажи б.у. вещей, тоже Робин Гуд?

                                                    К слову, в бездарные браузерные игры никто не играет и игроки денег не вкладывают. И у Вас нет никаких оснований считать эту игру бездарной. Плохо защищенной — да, но не бездарной.
                                                    • –1
                                                      Да вы эксперт игровой индустрии. В СНГ особенно, вкладывают в игры, которые быстро себя окупят — то есть клон другой игры, с минимумом изменений.
                                                      • +2
                                                        Одного не могу понять, с чего Вы взяли, что это клон какой-то игры, а не собственная разработка группы энтузиастов? Потому что сами не писали бы ничего, раз можно клонировать?

                                                        Обоснуйте, почему непрофессионализм авторов в защите своей программы от взлома Вы в легкую перенесли и на геймплей?

                                                        К слову, тетрис тоже был написан непрофессионально, зато потом эту идею «клонировали», ой, извините, «портировали» на кучу разных платформ. Потому что идея гениальна и не важно, как она реализована в начале.
                                                        • –1
                                                          Одного не могу понять, с чего Вы взяли, что это клон какой-то игры, а не собственная разработка группы энтузиастов?


                                                          Почитайте статьи на тему. Здесь, на хабре. Ссылки давать нет времени. Захотите — найдете.

                                                          Обоснуйте, почему непрофессионализм авторов в защите своей программы от взлома Вы в легкую перенесли и на геймплей?


                                                          Игра — это система. Подход к деплою — бессистемный. Sapienti sat.

                                                          К слову, тетрис тоже был написан непрофессионально, зато потом эту идею «клонировали», ой, извините, «портировали» на кучу разных платформ

                                                          Украли.

                                                  • +5
                                                    Как можно писать что-то без системы контроля версий? У меня даже для экспериментов и двухстрочников есть отдельный labs репозиторий. Не понимаю.
                                                    • 0
                                                      Например, когда нужно в течение 5 минут поднять сервер и написать rc script для кастомной программульки.
                                                      Тогда времени на репо нет.
                                                      • 0
                                                        Обычно никто на development писать что-то за пять минут не лезет. Ну да что я вам буду про разработку рассказывать.
                                                        Хотя я бы и в вашем случае использовал repo. Хрен знает что там нужно будет через год изменить или кто свои руки засунет. А мозг лучше другим занимать.
                                                        • 0
                                                          Да я не противник репо.
                                                          Очень их полюбил, после знакомства с меркуриал, сейчас туда всю базу скриптов переносить буду.
                                                          Жаль ранее (2005) не был с ними знаком.
                                                    • +7
                                                      У вас невероятная выдержка: таких высококвалифицированных специалистов сложно терпеть. Либо вам очень хорошо заплатили.
                                                      • 0
                                                        Специалисты попадаются разные. Но ведь не отказывать им в помощи из-за низкой квалификации, особенно когда ситуация критична. Тем более если они согласны платить.
                                                        Конечно, можно нарваться на такой код который просто нереально читать, но я с этим сталкивался всего 1 раз. Тут, к сожалению, ничего не поделаешь — только отказываться от сотрудничества :(
                                                      • –1
                                                        Еще один хороший вариант админки — размещать её на случайном поддомене (a74m8e.***.ru) на нестандартном порту и обязательной аутентификацией по ssl сертификату
                                                        • +2
                                                          Никогда такого не мог представить) Всегда, в случае крупных проектов, ограничивался только отдельным доменом.
                                                        • +2
                                                          В копилку полезных советов — если возможно, то удобно разделить «генерацию» каких-то игровых команд (игрок убил кабана: уничтожить кабана, создать на его месте труп кабана, создать «старый ржавый меч» в трупе кабана; игрок взял меч: убрать меч из трупа, создать меч в сумке ) и исполнение потока команд.

                                                          Тогда помимо логирования, будет всегда еще и возможность «переиграть». Удалить все действия, которые делались игроком с таким-то IP, загрузить старый дамп, и обработать все действия всех, кроме «плохого» игрока.

                                                          В результате, если игрок насоздавал много каких-нибудь «топор судьбы», можно все восстановить, при этом и вручную не надо будет все отслеживать, и честные топоры ни у кого не пропадут.

                                                          • +1
                                                            проще написать скрипт, который грохнет аккаунт вредителя и отследит и изымет все переданные шмотки и деньги (ну и/или заблокирует аккаунты всех, кто похож на передаточное звено).

                                                            вы не представляете себе объем логов игры хотя бы с тысячью онлайна.

                                                            а «накат» по ресурсозатратам где-то на порядок отличается от реалтайма. соответсвенно, «накат» за две недели может вполне занять часов 12, в течении которых сервер, ессно, должен быть отключён.

                                                            а если еще в скриптах наката есть маааленькая ошибка…
                                                            • +3
                                                              Когда-то давно, когда Lineage2 chronicle 4 была сверхновомодной игрой (а было это году эдак в 2005-2006), админил я фришард, написанный на Java. Был там один досадный, но сложно повторяемый баг с клонированием игровых объектов. Одному умному парню удалось этот баг повторить и даже написать скрипт для его автоматизации, он стал Робин Гудом и начал раздавать скопированное всяких Робин Бэдам. Боролись с ним где-то неделю, вручную смотрели логи подбора объектов с земли (а они менно так дюпались, через дроп на землю, дюп, затем пикап) и выискивали строки "%username% dropped: 1x %itemname%, 100x adena (деньги)" и вторая: "%username% earned 101x %itemname%". Что бы автоматизировать процесс, в исходный код были внесены изменения, которые дроп/пикап/получение предметов записывали не в лог, а в отдельную БД на другом серере (ибо лог дропа на 1000 онлайна растет неимоверно быстро), причем записывался не только ID игрока передавшего через трейд предмет, но и ID игрока получившего, а благодаря добавлению случайных ID для предметов во время первого трейда, стало возможным одним запросом отслеживать всю историю перемещений любого предмета :)
                                                              Таким образом после фикса бага разработчиками сервера, мне удалось тремя запросами грохнуть все предметы, которые дюпал этот Робин Гуд.
                                                            • +5
                                                              О Боже, а я думал, что я недостаточно знаю об обеспечении безопасности сервера. Фантастическая халатность.
                                                              По моему достаточно очевидные вещи написаны. Особенно удивило отсутствие системы контроля версий и мониторинга происходящего на сервере.
                                                              Что ж, свой урок парни получили.
                                                              • 0
                                                                Вещи, в общем, очевидные, но как чеклист для знающих и как пособие для ещё незнающий данный пост, имхо, очень полезен
                                                              • +3
                                                                Из своего опыта.
                                                                Если в игре существуют «админы», то необходимо логировать и проверять действия админов. Даже если админ один, и имеет вседозволенность.

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

                                                                И да, регулярные бэкапы базы данных. Причем хранить несколько копий за какое-то время. Чем больше, тем лучше.
                                                                • +1
                                                                  Что-то глупости про 7 раз высчитывать хеш md5. Если начальное множество данных стремится к бесконечность, то после первого md5 мн-во входных данных сокращается до кол-ва значений, которые вмещаются в 16 байт. Прокрутите md5 7 раз и вероятность коллизии нереально возрастает. Я считаю, что лучше чем md5(соль+пасс) трудно придумать, а все остальное это детские игры для тех, кто привык считать rand()*rand() тоже псевдослучайным числом.
                                                                  • +2
                                                                    Вот только последующие хеширования уже не столь сильно сократят количество значений. Статейка даже была на эту тему.
                                                                    • 0
                                                                      Сенк. Прочитаю как будет время, тоже интересны были более конкретные расчеты.
                                                                  • 0
                                                                    Спасибо.
                                                                    В будущем хочется разбора каких-то более интересных случаев.
                                                                    • +2
                                                                      Ну почему люди думаю, что если они создали что-то «виртуальное», то к этому не надо вести очень реальную бухгалтерию?! И так, если создать механизм ежедневного/еженедельного аудита, можно прекрасно видеть что происходит в экономике игры. И уже на первых же днях/часах отлавливать косяки. Как ошибки разрабов, так и всякие «взломы» и накрутки.
                                                                      • +2
                                                                        Хм, все эти пункты написаны считай-что в каждой статье про безопасность, как так то?
                                                                        • +2
                                                                          0) не будьте говнокодером
                                                                          • +8
                                                                            Все хорошо, но safe_mode вам зачем? В 5.3 уже депрекейтед.
                                                                            • 0
                                                                              Спасибо, очень интересная и познавательная статья!
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • 0
                                                                                  Я плохо разбираюсь в отдельных жанрах, но знаю точно что основной класс игры — RPG.
                                                                                • +1
                                                                                  Спасибо, интересная тема. Любая браузерка — это проект с очень сложной логикой. Кроме очевидных проблем с безопасностью, общих для любых веб-приложений, есть и специфичные игровые ошибки, поиск которых тоже бывает очень кропотливым занятием: нападение на персонажей в оффлайне, доступ к чужому инвентарю, чтение чужой переписки, управление чужим кланом, раскрытие невидимости и множество других ошибок, которые разработчик может не учесть. Каждую игровую возможность в играх, которые мы делаем, сопровождает десяток условий — кто, на кого, при каких условиях может использовать, какие данные ему доступны, какие нет и т.д.
                                                                                  • +1
                                                                                    … и агрессивным окружением… будьте уверены, что уязвимость найдут быстрее в браузерке, чем на форуме и, возможно, даже в интернет банкинге.

                                                                                    особенно, если уязвимость банальная.
                                                                                    • 0
                                                                                      Кхм. Сложная логика много где. Однако многие кто пишет «браузерки», оригинальные «чатики» и прочее следуют логике — быстрее напишем быстрее пойдут деньги. Зачастую архитектура PHP-проектов представляет из себя лапшеобразный код, без какой либо адекватной связки(Ну или как вариант попытка использования каких то ООП или ORM не понимая как это все между собой связано). А потом массы удивлений «А что это у нас такая логика сложная?!».

                                                                                      Как по мне логика Веба проста до нельзя. Есть какой либо URI он отдает либо страницу, либо результат Ajax запроса. Соответственно 1 URI равен 1 Функции (и только одной!) формирующей тот или иной результат. Следовательно чтобы не было «Очень сложной логики», достаточно написать грамотный диспетчер URI, а во вторых построить адекватную архитектуру проекта, которая позволит сохранить атомарность и хорошую логическую связность кода, в этом случае масса логических геймплейных ошибок будет просто невозможна.
                                                                                      • 0
                                                                                        В том, что код должен быть аккуратно организован, вы безусловно правы. Но отличие игр заключается именно в том, что их бизнес-логика очень сложна. Это не от недостатка проектирования, а именно потому что правила сложные. И это даёт свои ошибки, которые по опасности для бизнеса сравнимы с низкоуровневыми косяками типа SQL-инъекций. Я только про это говорю.
                                                                                        • 0
                                                                                          Ну вот смотрите. Есть набор каких либо взаимодействий объектов. Если они формализованы то при правильно спроектированом коде ошибок будет гораздо меньше. Понято что можно где-то скосячить с бизнес-логикой, но в целом все решаемо. И тут уж не от безопасности технической зависит.
                                                                                    • 0
                                                                                      Захватывающий детектив получился!
                                                                                      • +1
                                                                                        Разработчики пробовали бороться с этим, даже нанимали человека, который за 200$ брался устранить «все уязвимости» в коде
                                                                                        это меня действительно насмешило. Не гонялся бы ты Поп за дешевизной!
                                                                                        • –2
                                                                                          > Безопасный режим (safe_mode) был выключен
                                                                                           жесть! не удивительно, что их взломали. дальше можно и не читать…
                                                                                          • 0
                                                                                            выводы нужные и полезные для молодых разработчиков
                                                                                            • 0
                                                                                              а вообще теме безопасности в РНР написано море статей, даже посвящены целые сайты:
                                                                                              phpsec.org/
                                                                                              blog.php-security.org/
                                                                                              www.php-security.org/
                                                                                              однако живем русским менталитетом: пока гром не грянет — русский мужик не перекрестится.
                                                                                            • 0
                                                                                              Расскажите, пожалуйста, подробнее про различие ситуаций с точки зрения безопасности, когда в mysql_query() передается строка с закавыченными значениями параметров и незакавыченными, с применением в обоих случаях функции mysql_real_escape_string() для экранирования? Почему вторая ситуация опаснее?
                                                                                              • +3
                                                                                                mysql_query('SELECT id, name, pass FROM table WHERE id = '.mysql_real_escape_string($_GET['id']);
                                                                                                

                                                                                                Передаю в $_GET['id'] "1 AND 1=0 UNION SELECT id, name, pass FROM table2", получится запрос
                                                                                                SELECT id, name, pass FROM table WHERE id = 1 AND 1=0 UNION SELECT id, name, pass FROM table2
                                                                                                

                                                                                                получу доступ к table2
                                                                                                • 0
                                                                                                  не получишь если идти до конца и типизировать результат из гет к целочисленным )
                                                                                                  • +1
                                                                                                    мы сейчас рассматривали случай «незакавыченными значениями, с применением функции mysql_real_escape_string() для экранирования», а так да, меняем mysql_real_escape_string на intval и пока уязвимость, но речь не об этом.
                                                                                                • +1
                                                                                                  При заключении параметров в кавычки, вам требуется выйти за них, чтоб как-то изменять код запроса. То есть нужно либо поставить кавычку (вы закрыли первую, дальше вы уже в теле запроса), либо обратный слеш в конце значения (превратили закрывающую кавычку в обычный текст). И то и то нейтрализует mysql_real_escape_string(). А если значение параметра в кавычки не обрамлено, то помещая туда данные вы уже находитесь прям в теле самого запроса, а не в каком-то тексте как в первом варианте.
                                                                                                • 0
                                                                                                  не совсем понял из поста, дыры вы закрыли, но через какую именно была совершена атака не нашли?
                                                                                                  • 0
                                                                                                    > Позже удалось выяснить что все свои действия хакер совершал через PMA.
                                                                                                    • +2
                                                                                                      Дыр было много, предположительно изначально злоумышленник добрался через инъекцию до админки, а там смог оперировать файлами сайта. Считал данные для подключения к БД, и стал работать напрямую через PMA.
                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                    • 0
                                                                                                      у меня был коллега, который ухитрялся оставить уязвимости во всем что писал первый год работы… язык роли не играл. банальная несобранность/лень
                                                                                                      • 0
                                                                                                        Это каким таким возможным образом? :) Расскажите ну очень интересно =) Что такого в других ЯП? :)
                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                          • 0
                                                                                                            И где проблемы то в самом языке? :) Есть мнение что где-то в глубине Java есть свои функции работы с mysql_ примерно такого же вида, но для конечного разработчика они обернуты красивой оберткой куда можно написать название драйвера, так что мимо кассы. А кто тебе в PHP тоже самое мешает делать или взять такую же обертку? Что вообще за мода сравнивать человека который вчера начал писать на PHP и среднего специалиста на Java? и говном у PHP программистов башка не забита, просто там нет знаний. Которых также может не быть у тех кто программит на Java. На PHP начать быстрее и проще, но при прочих равных PHP я бы не сказал что сильно уступает другим ЯП. Да есть недостатки и именно в языке, в ООП, и не только. Ты не назвал ни одного — вывод это ололо-трололо и оголтетлый фанатизм. Причем глядя на уровень «претензий» к PHP есть мнение что и вы, достаточно посредственный разработчик на java. Так как вместо адекватного сравнения двух ЯП удалились в дебри «разработчики Похапе дерьмо, а разработчики Java рыцари» =)
                                                                                                      • 0
                                                                                                        Одного не пойму, чего ещё пытается добиться злоумышленник, выходя на контакт и блефуя?
                                                                                                      • 0
                                                                                                        Статья какая-то сумбурная. В принципе описывается все тоже самое что и везде про безопасность Web. Причем какой-либо конкретики нет.
                                                                                                        • 0
                                                                                                          и на стене PHPClubа появилось объявление: «Предлагаю услуги WEB аудита»
                                                                                                        • 0
                                                                                                          прочитал я статью и решил отказаться от использования MySQL в браузерных играх.
                                                                                                          Кто что может посоветовать?
                                                                                                          • +2
                                                                                                            А почему именно отказаться? Сам MySQL в себе никаких проблем не несёт.
                                                                                                            • 0
                                                                                                              шутки народ плохо понимает…
                                                                                                            • 0
                                                                                                              если без шуток, то:
                                                                                                              1) нет MySQL — нет проблем
                                                                                                              2) есть альтернативные хранилища, более производительные нежели MySQL

                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                          Самое читаемое