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

Достиг следующих успехов:


1.Методом blind-инъекции + брутфорса нащупал в базе данных названия четырех таблиц. Внутри этих таблиц нащупал 23 названия столбцов.

2.С помощью того же блайнда наловчился двоичным перебором ASCII кодов, вытаскивать данные из БД. То есть любые данные из любого столбца любой таблицы, названия которых мне известны.

3.Наконец-то обошел злосчастную проблему с ключом сессии. Нашел еще одну уязвимую переменную в другом скрипте. Инъекция в данную переменную позволяет получать php и скуль-ошибки. А это уже делает иньекцию не такой слепой, как до сих пор.

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

Например отправляю:

Получаю:

Теперь о том, что не получается:


Брутфорсом я нащупал едва ли сотую часть БД. И мне по зарез нужны названия других таблиц/столбцов. Но я никак не могу извлечь их напрямую из information_schema.

Когда, описанным выше способом, я пытаюсь вытащить из базы данные:

то получаю ошибку

Долго не мог понять откуда растут ноги у проблемы. Но проведя пару десятков других запросов, выяснил странный факт. Дело в том, что я не могу использовать в инъекциях символ точки [.]

Проблема даже не в том, что точка фильтруется. Просто символ точки, почему-то, срабатывает как комментарий. Причем комментарий с довольно странными свойствами.

Допустим в исходном виде без инъекции var=99


Запрос: var=99 -- abra cadabra comment(скрипт выполнится корректно)

Запрос: var=99 abra cadabra comment(приводит к ошибке)

Запрос: var=99 .abra cadabra comment(приводит к другой ошибке)

Ошибка другая, возможно не MySQL, а движковая. Набор PHP-ошибок следующих за ней тоже отличается.

Более того запросы вида:

var=99 -- .abra cadabra comment

приведет к такой же ошибке. То есть точка (.) каким-то образом работает даже в закомментированном виде уже после двух дефисов (--) !

Что еще более удивительно, по заголовкам функций в apache-ошибках можно обнаружить, что в одну из функций попало значение нашей строковой переменной varдополненное еще двумя символами, а именно '99 -- .abra cadabra comment.7'

Кстати происхождение числа 7 мне известно. Это номер игрового сервера, который был передан в том же самом HTTP-запросе, однако в совсем другой переменной, никаким модификациям не подвергавшейся.

То есть, если я все правильно понимаю, на каком-то этапе обработки данных моя точка спровоцировала конкатенацию строк. Причем произошло это в какой-то другой среде, еще до того, как строка попала в среду MySQL и запрос к БД был выполнен. В пользу этого говорит так же и тот факт, что точка генерирует ошибку даже после двойного дефиса. Хотя может я ошибаюсь и конкатенация изначально была задумана движком. Поправьте если не прав.

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

var=99 -- ..abra cadabra comment

Запрос был обработан и выполнен без ошибок!



var=99 ..abra cadabra comment

Привел так же привел к корректной обработке без ошибок.

То же самое верно для запросов с любым количеством точек от 2-х штук. Независимо от наличия или отсутствия комментариев SQL. Самое главное чтобы за самой первой точкой, следовала еще одна, причем вплотную. При этом все, что следует за двойной точкой будет в SQL-запросе отсечено, как если бы точки были однострочным комментарием.

var=99 . .abra cadabra comment

Если между точками вставить пробел или любой другой символ ошибка снова появится.

Резюмируя проблему:

Если одинарную точку, либо точку с другими символами после нее, поставить ДО инъекции, получим вышеуказанную ошибку "host config can not be empty!". Работа скрипта будет прервана так же до выполнения инъекции.

Если одинарную точку, либо точку с другими символами после нее, поставить ПОСЛЕ инъекции, то сперва будет выполнена инъекция. Если инъекция привела к SQL-ошибке, получим SQL-ошибку. Если инъекция выполнена без SQL-ошибок - получим "host config can not be empty!"


Если одинарную точку, либо точку с другими символами после нее, поставить ВНУТРИ инъекции (например при обращении к information_schema.tables), то вся инъекция после точки будет отсечена. Соответственно мы получим SQL-ошибку "... error in your SQL syntax ... near '...огрызок нашей инъекции до точки' at line 1"


Если поставить две точки подряд в любом месте, они сработают как однострочный комментарий.



Вопрос:


Как получить доступ к information_scherma?

Сделать это можно либо разобравшись в свойствах этой загадочной точки и заставить ее работать на нас. Что это за странный баг и с чем его едят?

Либо обратится к information_scherma каким-то обходным путем, не используя точек в запросе. Существует ли такой способ? Если да, то как?

Оговорюсь сразу что функция char() и HEX-строки здесь не помогут, я пробовал. Они работают со строковыми параметрами в операциях сравнения после WHERE, однако не годятся для обращения к именам таблиц в операторе FROM.


Очень надеюсь на вашу помощь)