Близится день искрометного юмора, и пока кто-то готовится постить бояны десятилетней давности, IT-специалисты готовят по-настоящему крутые розыгрыши. Как, к примеру, Руби Нилон – автор захватывающей игры “Смотри, как сохнет краска”, вся соль которой в названии. Это несуществующая игра-шутка, которую разработчик смог выложить на Steam самостоятельно, просто используя некоторые уязвимости в платформе. Эти “дыры” уже пофиксили, но стоит почитать о самом опыте взлома самого известного в мире игрового онлайн-магазина, тем более, что Руби описал его в деталях.
К слову, Руби – 16 лет. В 2012 году он получил благодарность от Microsoft за обнаружение уязвимости, поступил в вуз в 14 лет и стал “одним из самых юных студентов на специальности Computer Science в Британии”.
Если вы заходили на домашнюю Steam в воскресенье вечером, вы могли заметить нечто интересное. Новую игру под названием Watch Paint Dry (“Смотри, как сохнет краска”). Она вызвала много шума (если честно, я поразвлекся на форумах), поскольку люди жаловались, что Valve/Steam вообще забила на качество контроля игр по Greenlight (это система, которая позволяет разработчикам игр заручиться помощью сообщества для выпуска на Steam – ред.). Но эта игра никогда не попадала на Greenlight. Хоть я и считаю, что это отличная платформа для тех, кто рассматривает инди-разработку как привлекательную для себя карьеру.
Я хотел бы извиниться, если задел кого-то из инди-разработчиков, которые изо всех сил пытаются попасть на Steam. Это всего лишь шутка, я хотел проверить кое-что, о чем писал отчеты в Valve несколько последних месяцев. Речь о возможности вывести в Steam абсолютно любую игру, так, чтобы парни из Valve даже краем глаза ее не видели. Это устаревший гайд, поскольку Valve уже закрыла эти “дыры”.
Получение аккаунта в Steamworks
Технические детали будут приведены ниже, но все мое исследование этих уязвимостей началось с получения доступа к Steamworks. Не буду рассказывать, как или зачем я это сделал. Но могу сказать, что не использовал уязвимостей в веб-формах или Greenlight, не действовал через кого-то, кого лично знаю в Valve. И хотя эта уязвимость больше недоступна, деталей рассказывать не буду и не просите. У меня свои причины молчать.
В любом случае, я получил доступ к Steamworks (это внутренняя платформа Valve по публикации контента на Steam, она же поддерживает мультиплееры, DRM, достижения в играх и т.д.). И это привело меня к идее осмотреться вокруг на предмет уязвимостей.
Я пытался связаться с Valve, но мне не ответили. В конце-концов, время шло к апрелю, так что я решил использовать “неназванную игру”, чтобы разыграть шутку на 1 апреля и привлечь внимание Valve к этим “дыркам”.
Часть рассказа о том, как я делал 45-секундный симулятор высыхающей краски в RPG Maker я, пожалуй, опущу. Я им отнюдь не горжусь, да это и неважно.
Получение Steam Trading Cards
Ну какая же игра вроде ‘Watch Paint Dry’ обойдется без замечательных обменных карточек (в Steam trading cards – это виртуальные коллекционные карточки, которые выпадают игрокам во время игры и которые можно менять на игровые значки и обмениваемые предметы – ред.)? После 10 минут фотошопа я набросал базовый шутливый набор таких карточек. Valve должна проверить карточки, смайлы, фоны для профиля, прежде чем я их выпущу. Но так ли это на самом деле?
С первого взгляда видно, что у статуса релиза несколько состояний.
Интересно, а какой за ними код?
Что занятно, они отслеживают и мою сессию, и ID аккаунта редактора. Давайте-ка попробуем поменять это все на данные кого-то, кто мог бы работать в Valve, поменять значение на какое-нибудь несуществующее, и посмотрим, не получится ли на выходе другая форма.
Интересненько… Новый “последний редактор” – кто-то из Valve. А если мы сохраним форму снова, но со значением Released (“Опубликовано”)?
Так что же случилось? Вкратце, когда я ввел “неправильный” запрос, мне возвратили полный список опций с их значениями. В этом случае я увидел, что опции Released соответствует значение 5. Я обновил форму, чтобы заново получить editor_accountid, поменял значение статуса релиза с 3 до 5 (Released), сохранил это все – и сервер решил, что это – настоящий запрос от настоящего разработчика, чьи виртуальные карточки были одобрены в компании. Сервер не контролировал, проверял ли кто-то из Valve мое творение, а просто установил его статус как Released. Ну ладно, перейдем к публикации игры в магазине.
Процесс получения одобрения от Valve
Чтобы вы понимали, прежде чем Valve выкладывает что угодно на Steam, это что-то должно пройти три этапа релиза. Сначала ты выставляешь свою страницу в очередь на ревью, затем – финальный или почти финальный билд своей игры, и только после этого получаешь возможность выпустить ее.
Основное: релиз игры
Сайт Steamworks – преимущественно на AJAX. Весь код для Javascript-функций, который отвечает за основные возможности, совсем не спрятан и может быть прочтен любым (кто залогинен в Steamworks).
Этот код сам по себе интересен, но мне нужно было прежде всего доказать работоспособность своей идеи, так что я обращал внимание только на релевантные вещи. Так я нашел интересную Javascript-функцию под названием “ReleaseGame(appid, data)”. Похоже было, что она задает типичный AJAX-запрос (и здесь не было вообще никакой верификации) к Steam и приводит к релизу приложения.
Вызов функции ReleaseGame с параметрами 445730 (мой appid) и пустым полем данных привело к ошибке 403 (доступ запрещен). Интересно. Я глянул на некоторые другие функции в файле и заметил, что почти все они добавляют к запросу JSON параметр под названием sessionid с Session ID, который мы уже видели ранее, когда выпускали набор карточек.
Вызываем ReleaseGame(445730, { ‘sessionid’: ‘my_session_id’)?
А теперь – в магазин Steam…
Та-дам! Признаюсь, ее появление в секции с новыми релизами было недосмотром с моей стороны. Я изначально хотел, чтобы она была со статусом “Выходит 1 апреля” и не появлялась до пятницы (хотя столько времени игре не дали бы провисеть). Также признаюсь, что был большой соблазн посмотреть, до какой стадии релиза я могу добраться, но думаю, это к лучшему, что такое “приложение” не попало в продажи.
Я связался с Valve и они пофиксили уязвимость.
Чему я научился? Работая с пользовательским контентом, который сначала нужно одобрить, не используйте статусы Review Ready и Reviewed как два состояния для пользовательского контента. Лучше, чтобы проверка контента состояла из нескольких этапов, на каждом из которых каждый кусок контента получал бы что-то вроде “талончика”. И чтобы контент не мог уйти в релиз, пока все его части не получат этого одобрения. Ну или просто не разрешайте пользователям устанавливать статус контента как Released.
¯\_(ツ)_/¯