ANTICHAT — форум по информационной безопасности, OSINT и технологиям

Тема провисела на форуме 2 суток, набрала 500 просмотров и 0 ответов. Куда подевались все гуру-хакеры?

Ладно, попробую задать более конкретный вопрос.

Что имеем:

Последние несколько дней я пытаюсь сделать игре SQL-инъекцию.

Как я уже говорил, клиент обменивается с сервером HTTPS запросами.

На сервер отправляются обыкновенные POST-запросы вида https://www.game.ru/public/api/scrip...ta1&var2=data2...

В ответ приходит целая гора данных в формате JSON, основываясь на которых, клиент выдает картинку игровых действий (передвижение, битвы, игровой инвентарь ит.д.)

Разумеется никаких html-страниц и форм нет и в помине. Но поскольку я могу слушать трафик напрямую, то и вмешиваться в него могу тоже напрямую. Следовательно - изменять переменные отправляемые на сервер так, как если бы я это делал в строке запроса GET.

Я могу придать переменной любое значение, однако часть символов экранируется.

А именно символы / (слэш), \ (обратный слэш) и "(двойная кавычка).

Все остальные символы поступают на сервер без экранирования. По крайней мере символы ['],[`],[*],[:],[;],[&],[%],[$],[@],[?],[(],[)],[{],[}],[,],[.],[!],[-],[|],[=],[^],[#] можно передать в исходном виде.

Однако SQL-инъекцию затрудняет то, что часть переменных защищена проверками на валидность, а другая часть, по видимому, в SQL-запросах не участвует. Но я таки отыскал одну переменную, через которую инъекция возможна. Как не удивительно, но это переменная uid (id игрока).

Что работает:

Предположим мы работаем с исходной переменной uid=99


Если привести ее к виду uid=99' получим ошибку 500 (Internal Server Error), т.е. ошибочный SQL-запрос который сервер выполнять откажется.

Значение uid=99/* передать к сожалению нельзя из-за экранирования слэша.

Значение uid=99-- будет обработано.

Так же будет обработано: uid=99--+любой текст

Будет обработано: uid=99+and+null--

Будет обработано: 99+and+null

Будет обработано: 99+and+concat('1','2')

Будет обработано: 99+and+version()

Будет обработано: 99+and+@@version

Приведет к небольшому зависанию и ошибке 504 Gateway Time-out: uid=99+or+1--

Ну еще бы, аккаунтов в игре зарегистрировано более 13 млн.

Вот такая переменная затянет выполнение запроса на ~2300мс: uid=99+and+BENCHMARK(10000000,md5(current_date))

Обычно запрос выполняется за 5-15мс.

Скорее всего есть возможность провести DOS атаку, но меня это не интересует.

Что не работает (подводные камни):

Проблема 1.


Первая проблема состоит в том, что значение переменной uid используется не только в запросе к БД, но и каким-то образом связано с проверкой валидности игровой сессии. Всего в проверке сессии их учавствует три - uid (номер игрока), serverid (номер сервера) и sessionToken (ключ сессии).

uid - всегда неизменный для отдельного игрока

serverid - неизменен до тех пор пока мы играем на одном и том же сервере

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

Если поменять хотя бы один символ в любой из этих переменных, получим обрабатываемую игровым движком ошибку "Ключ сессии неверный!". При этом, несмотря на то, что запрос к БД будет выполнен, обычный набор данных в JSON-формате PHP-скрипт нам не отправит. А если он их не отправит, то и результаты SQL-запроса вставлены никуда не будут...

То есть не представляется возможным получить какую-либо пользу даже от успешного внедрения в запрос конструкции UNION SELECT...

Как решить данную проблему я не понимаю и очень рассчитываю на вашу помощь.

Проблема 2.

Собственно, мне не удается узнать число столбцов между SELECT и FROM.

Я пытался это сделать вот так:

uid=99+union+select+null

uid=99+union+select+null,null

uid=99+union+select+null,null,null

...

и т.д.


К сожалению сервер все время возвращает ошибку 500. То есть запрос не выполняется. Предположим это может быть просто результатом неверного числа добавленный мной null. Я утомился после 30-го по счету. Конечно, их может быть 100 или 300. Ну да черт с ним. В случае чего я пару часов своего времени на перебор убить могу. Но что если сервер отказывается принимать саму конструкцию select+null? Или оператор union? Или еще что-нибудь в синтаксисе моего запроса?

У меня есть основания полагать что это так, поскольку переменная uid=99; (добавлена точка с запятой) сервером обрабатывается. В то время как uid=99;+select+null приводит к ошибке 500, хотя после точки с запятой количество нуль-значений в запросе никак не должно влиять на его валидность. Ведь мы не объединяем результат с предыдущим, а делаем новый независимый запрос.

Почему конструкция uid=99;+select+null не работает?

Я не знаю какая именно СУБД там находится. Но поскольку сервер на CentOS думаю я не ошибусь если предположу что это MySQL, причем с версией никак не ниже 4.* Мне точно известно что Apache имеет версию 2.2.15, а PHP версию 5.4.11. По-моему крайне маловероятно, что вместе с ними стали устанавливать бы такую древность как MySQL 3.* А современные версии MySQL поддерживают, как UNION, так и расщепление запросов оператором ; (точка с запятой).

Следовательно, существует какая-то другая причина, по которой uid=99;+select+null не работает. Но какая?

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

Требуется ваша помощь.

Возможно слепая инъекция. Пробуй так:

Так же, полистай эту тему https://rdot.org/forum/showthread.php?t=60

Не понял как ты хочеш узнать число стлобцов:

Если:

Скорее всего точка с запятой просто удаляеться, перед подачей скуль-серверу, ибо иначе ты ею рвешь неизвестный тебе запрос, и должна возвращаться ошибка скуль - ошибка.

На самом деле очень хорошо, ресёрча продвинутая

Спасибо. Про слепые инъекции не знал, весьма любопытная штука оказывается!

Поскольку никаких данных, кроме злосчастной ошибки о неверном ключе сессии, скрипт не выводит - пришлось в качестве критерия угадывания использовать HTTP ошибку 504.

Постепенно по одной цифре узнал версию базы данных: MySQL 5.6.21

Использовал такие запросы:

До тех пор пока не получал ошибку 504, говорящую что цифра была угадана.

После чего переходил к следующей цифре.

Самое интересное, что после каждого такого угадывания сервер переставал отвечать на мои запросы на 10 минут, даже самые безобидные. Через 10 мин все возвращалось на круги своя. Причину такого поведения не понимаю. С одной стороны запрос возвращает 13 миллионов строк, это серьезная нагрузка на сервер. Но с другой сам по себе сервер не уходил в даун. Я проверял это входя в игру обычным способом, через клиент.

Что ж, еще раз спасибо. Ссылка тоже полезная, я пока прочитал не все, так что когда закончу - отпишусь о результатах.

Очень просто.

Дело в том, что игровой движок сперва выполняет SQL-запрос и только после этого проверяет игровую сессию на валидность.

Я бы на месте разработчиков игры сделал с точностью до наоборот - сперва проверял нужно ли вообще делать запрос к БД, и только потом бы его делал. Но они решили иначе

В результате получаем следующую картину:

Когда запрос к БД успешно выполнен - я получаю движковую ошибку "Ключ сессии неверный!", ведь для инъекции мне волей-неволей пришлось изменить значение uid.

Если же запрос к БД завершается ошибкой (например при добавлении символа кавычки), я получаю HTTP ошибку с кодом 500.

Таким образом, постепенно добавляя к запросу uid=99+union+select+null новые и новыеnull через запятую, я буду получать ошибку 500 до тех пор пока количество null не станет равнымм количеству столбцов. В этом случае я должен буду получить сообщение о неверном ключе сессии.

В теории должен, на практике пока ни разу не получил...

Хочу уточнить, что SQL-ошибок мне не возвращается в принципе, ни при каких условиях. Ошибок Apache тоже.

У меня бывает всего 4 ситуации:

1. Если переменная uid находится в девственно неприкосновенном виде, я получаю: JSON-текст, содержащий данные из БД.

2. Если переменная uid была изменена и SQL-запрос был выполнен, я получаю: ошибку движка throwException("Ключ сессии неверный!");

3. Если переменная uid была изменена и SQL-запрос НЕ был выполнен (например добавлен символ кавычки), я получаю: HTTP 500 Internal Server Error

4. Если переменная uid была изменена, SQL-запрос был выполнен, при этом он попытался вернуть всю таблицу целиком (в ней 13млн. строк), я получаю: HTTP504 Gateway Time-out

Других ситуаций не бывает.

В идеале я хочу получить 5-тую ситуацию, когда uid была изменена, SQL-запрос был выполнен, и я получаю JSON-текст, с данными из запроса. Но пока не получается...

В этом и заключается Проблема №1, описанная во втором посте данной темы.

А почему символ ; должен удаляться перед подачей в БД?

Ты думаешь разработчики сделали специальную функцию для этого?

Версию скуля я узнал просто в виде эксперимента.

Все-таки я впервые в жизни слепую инъекцию делал, хотел понять как она работает.

Юзера я хочу и сам, но никак не могу сообразить, как его выцепить из БД. Я ведь даже имен таблиц не знаю.

Наверно потому что спать пора и соображалка туго работает... Завтра продолжу.

Используй and, а не or.

Для, простого, быстрого перебора:

[CODE]
Code:
id=99 and ascii(substring(version(),1,1)) > 100 -- false
id=99 and ascii(substring(version(),1,1)) > 50 -- true
id=99 and ascii(substring(version(),1,1)) > 55 -- false
id=99 and ascii(substring(version(),1,1))

2crlf, спасибо, ваши советы бессценны! Попробую применить все, что смогу.

К великому сожалению, я вынужден использовать именно orвместоand, поскольку из-за "ошибки сессии" не имею возможности возможности отличить обычный результат запроса от нулевого.

Да, and удобнее. Но если я буду использовать and- я получу throwException("Ключ сессии неверный!"); в не зависимости от результатов запроса. Я писал об этом ранее.

Идея бинарного поиска просто гениальна, спасибо!

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

Если я попробую автоматизировать этот процесс, рискую привлечь нежелательное внимание админов. все-таки столь большая нагрузка на сервер - плохо. Но другого выхода пока не вижу. Вот если б заставить работать оператор LIMIT... но он работать отказывается...

Не знаю почему, но такие инъекции приводят к ошибке:

На локалхосте всё вышеперечисленное выполняется на ура! А вот на атакуемом сервере не хочет. Почему-то вообще ничего кроме эндов и оров НЕ ПРОХОДИТ.

Такое может быть, если инъекция производится не в хвост а в середину запроса (я ведь не знаю какой он там). Но это предположение опровергается тем, что запрос id=99; обрабатывается корректно. Кроме того, я, на всякий случай, отбрасываю ввероятный хвост при помощи --, но и это не помогает.

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