SQL-injection и Rising Force Online

[Den1S]

Что ж, вот я и решил рассказать от чего на planetwars.ru произошёл самый первый вайп, а также откуда на фришках то там, то тут появлялась GM-бижутерия, которая давала по +1000000% к атаке, 10000/10000 атака/защита, +7 вещи, snake-бижутерия на варзоне и так далее. Вы думали, это GM-ы продавали? А вот и нет.
Сразу скажу, данный материал носит чисто образовательный характер, так как баг работал на всех серверах до Update5. На данный момент найти сервер старее up5 довольно сложно, что собственно и послужило причиной публикации этого бага.

Поехали
Вы помните дюп через банк? Когда кто-то случайно послал пакет на смену пароля, где один из паролей содержал кавычку " ' ". От такого пакета сервер падал, после чего откат и, как результат, дюп. Но на самом деле дюп - это самое девственное, что можно сделать с багами подобного класса.
Не многие знают, что кавычка служит для завершения стринги в SQL-запросе. Например, при смене пароля на банк RFO-сервер генерирует и посылает примерно такой SQL-запрос:

UPDATE tbl_AccountTrunk SET password='pass' WHERE Serial=666
(название ячейки с паролем писал наобум, т.к. уже не помню настоящие, да и это не важно).

Обратите внимание на кавычки, в которые заключены все данные. Так вот, когда появляется ещё одна лишняя кавычка, MSSQL-сервер считает, что она закрывает или открывает стрингу (в зависимости от того, была ли она открыта). А т.к. закрывающая уже есть, она считается лишней и SQL-сервер возвращает ошибку, на которую RFO-сервер в свою очередь реагирует падением (что между прочим странно, я пришёл к выводу, что в RFO-сервере есть ещё и свой sql-парсер).
И фишка вся в том, что мы можем, используя кавычку, закрыть стрингу и инжектировать свои собственные данные в SQL-запрос! Это позволит делать просто невероятные вещи.
К примеру, в случае со сменой пароля, это будет выглядеть так:

UPDATE tbl_AccountTrunk SET password='pass''my_sql_query--WHERE Serial=666

о проблема в том, что пароль слишком короткий, чтобы поместить в SQL-запрос хоть что-нибудь рациональное. И вот тут то и всплыл ещё один SQL-injection баг, о котором знали только мы и администрация некоторых RFO-серверов.
Вам знакомы макросы? Замечали, что макросы чата восстанавливаются при релогине? Это абсолютно точно означает, что они храняться в MSSQL-базе, а следовательно теоретически могут быть подвержены SQL-инъекции. Но проблема в том, что никто не догадывался , а кто догадывался - просто не мог проверить, так как ввести кавычку в поле ввода макроса нельзя. А пакетами можно Следующий пакет успешно приводил к падению:

0x00 | BE 03 0D 24 FF FF FF FF FF FF FF FF FF FF FF FF 
0x10 | 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF 
0x20 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x30 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x40 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x50 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x60 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x70 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x80 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x90 | FF FF FF FF 60 00 00 00 00 00 00 00 00 00 00 00
0xa0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xb0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xc0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xd0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...... и так далее нульбиты до конца пакета.
Красным как раз выделена кавычка. С неё и начинается блок сохранённых макросов (сообщений). До неё идут координаты окон, панелей, которые были открыты у пользователя до последнего логаута.
0xFFFFFFFF - означает, что окно закрыто. В ином случае - X и Y координаты расположения окна.

Но падения не интересовало абсолютно, т.к. в RFO и так DoS-багов полно. Возможность доступа к MSSQL базам всех RFO-серверов мира - вот, что интересно. В макрос оказалось возможным вписать достаточно большой объём данных (где-то в районе 300 байт после кавычки), которого хватало на то, чтобы прописать в инвентарь сразу 4 (!!!) вещи. Исходя из того, что таблица с инвентарём в MSSQL-базе RFO называется "tbl_inven", а ячейки:
KX - ID вещи (GID и группа), где X - номер слота в инвентаре.
UX - заточка вещи из слота X
Был составлен следующий SQL-запрос:

UPDATE tbl_inven SET K1=43582208,K2=43582208 WHERE Serial=666--
Обратите внимание на кончик запроса. Все данные, которые идут в запросе после тире воспринимаются сервером как комментарии, иначе наш запрос обработан не будет.

Его можно было поместить сразу после кавычки в вышеописанном пакете и, после его получения, сервер падал. После рестарта в инвентаре персонажа с ID 666 в соответствующих ячейках (1 и 2) появлялись прописанные в SQL-запросе вещи Таким же образом можно было точить:

UPDATE tbl_inven SET U0=1879048192 WHERE Serial=666

Этот запрос точил невежами на +7 вещь из нулевого слота (причём вне зависимости от того, что там лежит ). А вот этот запрос:

UPDATE tbl_inven SET K1=43582208,U1=1879048192,K2=43582208,U2=187904819 2 WHERE Serial=666--

Рисует две пушки в первый и второй слоты и точит их на +7.
Запрос:

UPDATE tbl_AccountTrunk SET Gold1=9999999 WHERE Serial=666

Прописывал в банк персонажа расы Кора 9999999 золота. Помеченный красным байт как раз отвечает за расу.
А вот это для фана:

UPDATE tbl_general SET Map = 0, HP = 110000 WHERE Serial=666

Этот запрос прописывал персонажу с ID 666 110к ХП и телепортирует в ГШ белок =) Разумеется без разницы какой персонаж расы на самом деле.
Прописывать уровень получались (в меню выбора перса он был виден), но персонажи запарывались. Видимо есть какие-то связи с экспой и нужно менять сразу несколько значений в базе. Но я это исследовать не стал, т.к. можно было левелапить персонажа через хранимую процедуру в MSSQL базе, которая, собственно, вызывается при легальном левелапе персонажа.

Единственным огорчением было в том, что нам так и не удалось заставить сервер держаться и не падать при SQL-инъекции. Моё субъёктивное мнение заключаётся в том, что этот "бэкдор" был специально оставлен Корейцами, дабы нельзя было использовать подобные баги "беспалевно".
Игроки фришардов наверняка помнят надпись: "Невозможно получить информацию о персонаже". Так вот это и был результат падения базы при SQL-инъекции

Одно в этом баге осталось не ясно. Согласно принципам обработки SQL-запросов, после кавычки должен идти символ завершения запроса - точка с запятой. Но в RFO с ней наш запрос не проходил.. А без неё на удивление всё ок. Я лично никогда не встречал таких инъекцией. Видимо в RFO действительно встроен какой-то парсер, который, если видит несколько запросов в одном, разбивает их на несколько частей. Это единственное объяснение тому, что такая странная инъекция проходила и что сервер от неё падал.

Я намеренно не стал описывать, что за числа были прописаны в SQL-запросах для получения необходимой вещи, т.к. такие баги есть до сих пор и будут ещё всплывать и всплывать. Этот пост не несёт цели научить нубов и читеров юзать SQL-инъекции, а просто показать, что возможно тварить в RFO Также хочу сказать, что благодаря тому, что информация была доступна всего нескольким людям из рунета, баг был пофиксан лишь на двух серверах (planetwars и rfonline.ru) спустя 5 месяцев после его обнаружения, а на всех остальных только после перехода на update5. Делайте выводы те нубы, кто любит побегать с оружием класса Пи

Вот так вот.

К теме прикреплены три скриншота с бижей, которая была нарисована именно таким способом. На последнем скриншоте PlanetWars до вайпа. На первых двух уже не помню какие серверы... Про офф умолчу

ЗЫ В принципе всё описано очень просто, но на самом деле на изучение бага и реализацию ушло недели 3. Не стоит думать, что это нам легко далось.
Статья является плодом воображения и все совпадения с реальностью случайны. ГМ бижа существовала, но мы к этому никакого отношения не имеем.

[Ссылки могут видеть только зарегистрированные пользователи. ]
[Ссылки могут видеть только зарегистрированные пользователи. ]

(c)dark