Можно использовать time based варианты и обойтись без or, там вывод вообще не нужен.

Так же, стоит попробовать конструкцию с and, без использования комментария. Возможно, дальше идёт важная часть запроса и выборка проходит неправильно, что, по дальнейшей логике сценария, приводит к ошибке.

Либо, нужно каким-то образом попытаться достроить запрос. Как вариант, считать вслепую, таким образом:

2crlf, спасибо, time based работает! Даже не знал что такое возможно.

Вы, как всегда, по делу советуете) Побольше бы таких людей!

Появился кое-какой прогресс во взломе.

Вместе с новыми успехами появились и новые проблемы, требующие решения.

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

Сейчас вынужден заняться другими делами.

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

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


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.


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

Действовать в этом случае можно как при инъекциях в MySQL

Идея здравая, проверил. Правда я не могу ручаться, что ошибки те же самые, поскольку в другом параметре любая SQL-ошибка приводит к "500 internal Server Error"

Если точка внутри запроса - получаем ошибку 500. Если точка после запроса получаем ошибку "Ключ сессии неверный!", о которой я писал еще давно. Что отнюдь не означает отсутствие ошибки "host config can not be empty!".

Единственная разница в том, что точка до запроса работает как комментарий, даже в количестве 1 шт (две точки подряд ставить не обязательно).

Считаете, что есть шансы найти другой уязвимый параметр, в котором проблем с точкой не будет?

Если вы имеете в виду чтение с помощью команды load_file(), то я еще не до конца с ней разобрался. Она у меня все время возвращает NULL.

Возможно я неверно указываю путь до файлов. Затрудняюсь определить правильный. А может быть косячу где-то еще. По правде сказать, я почти не уделял этому времени - попробовал пару раз, а затем переключился на другие задачи. Но возможно стоит углубится в изучение данного вопроса. Буду благодарен за какой-нибудь мануал по файлам.

А вообще - чтение локальных файлов одна из основных целей атаки. Мне интересно почитать их содержимое и так.

load_file('/etc/passwd') или load_file(0x2f6574632f706173737764)

Это я попробовал еще в самом начале.

Результат - NULL

А чё , права есть разве? Я чему не собираюсь читать, слишком много букв . Я вот не пойму, автору делать нечего что ли, или решил цветных тролить тонко? Если так, то не тонко Нифига

[QUOTE="crlf"]
↑
Действовать в этом случае можно как при инъекциях в MySQL

Если речь о правах пользователя БД, то на локалхосте права - GRANT ALL PRIVILEGES ON, на атакуемом сайте - не знаю. Но и там, и там результат - NULL.

А на основании чего вы решили, что я троль?

Спасибо. Когда закончу разбираться с файлами, - гляну что за зверь такой SQLMap.

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

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

Брут по данному листу, нашел четыре таблицы и два десятка столбцов внутри них.

SQLMap брутит намного эффективнее?