Пока собирал валидные CVE по Moodle для следующего поста столкнулся с мини болью...

Если мы говорим про Moodle, то у него примерно ~500 CVE'шек. И читать каждую, и ,ТЕМ БОЛЕЕ, искать POC под каждую - это адская боль и трата огромного кол-ва времени. Я долго ломал голову как ускорить этот процесс, пока не додумался до следующих двух вещей.

Способы

1) Есть такой прекрасный инструмент, как CVEMap от команды Project Discovery. Этому инструменту можно скормить файл с CVE'шками, и он выведет информацию об этих CVE'шках из своей БД. Причём можно дополнительно накинуть поле, которое будет показывать есть ли POC под эту CVE или нет.
Единственная проблема, что для её использования нужно использовать свой API-ключ с https://cloud.projectdiscovery.io/, но я думаю не так сложно войти на портал со своим гугл аккаунтом и взять ключ=)
Также, к сожалению, данный инструмент работает без таких БД как Exploit-DB, поэтому некоторые CVE он может пропустить. Поэтому используем и этот вариант и второй.

Применение

Отдать на вход список с CVE и показать вывод с полем "POC"(есть ли POC на эту CVE или нет)

cat cve.txt | cvemap -field poc

Та же команда, но с фильтрацией только тех CVE, что имеют POC:

cat cve.txt | cvemap -field poc | grep TRUE

2) Можно также применить в поиске и Exploit-DB, но у него нет удобного API..
Но это не проблема! Можно просто перехватить API-запрос с exploit-db на поиск информации о CVE и просто через интрудер перебрать интересующие вас номера с задержкой в 2 секунды, чтобы не словить бан. А дальше отсеять невалидные по длине ответа:

GET /search?text=<CVE_id> HTTP/2 
Host: www.exploit-db.com 
User-Agent: ... 
Accept: application/json, text/javascript, */*; q=0.01 
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 
Accept-Encoding: gzip, deflate, br 
Referer: https://www.exploit-db.com/search?text=2018-1042 
X-Requested-With: XMLHttpRequest 
Sec-Fetch-Dest: empty 
Sec-Fetch-Mode: cors 
Sec-Fetch-Site: same-origin 
Te: trailers

Итог
Эти 2 способа значительно сократят время поиска валидных CVE'шек, однако, возможно надо будет поискать и какой-нибудь 3 способ/ресурс, например, если вы ищите CVE на jira, то можете использовать ресурс jira.atlassian.com. Поэтому всё зависит также и от контекста)

Также меня просветили(Спасибо @katok) про searchsploit, поэтому вместо второго способа можно также юзать эту тулу следующим способом:

searchsploit moodle

searchsploit -t moodle --cve --www

И ещё можно использовать следующие ресурсы(Спасибо @XxX_S4ar_XxX и ещё раз @katok):
- https://sploitify.haxx.it/
- https://vulners.com/search (позволяет отфильтровать по ключевому слово exploit и искать поки также на гите и др. ресурсах)

Как-то увидел, как человек всем доказывал, что нашёл валидную CORS-мисконфигурацию следующего типа:

Origin: https://site.ru - валидный Origin, на который возвращается ACAO и ACAC

Origin: https://site.ru:[email protected] - Origin, на который тоже возвращается ACAO и ACAC

Это, конечно, выглядит как валидный кейс, однако не стоит забывать, что у Origin'а есть определённая структура:

<scheme>://<hostname>:<port>

Поэтому удачи ему доказать, что это валидная бага=)

Максимум, что можно сделать при поиске CORS-мисконфигураций это:
1) Подставить null
2) Указать изначальный домен, как поддомен вашего: https://site.ru.arroizx.ru
3) Подставить домен, на котором вы нашли XSS'ку
4) Указать домен, который начинается/заканчивается как валидный, а по факту это совершенно другой домен: https://arroizxsite.ru && https://site.ruarroizx.ru
5) Ну и всякие другие специфичные кейсы, которые можно найти в той же шпаргалке portswigger.

Иногда на ББ могут даже принять подстановку https://localhost, на который возвращается ACAO и ACAC, но я вам этого не говорил🌚

Ох уж этот странный 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-формата ¯\_(ツ)_/¯

А на чём ты стоишь, дружище?

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

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)

Особенности тестирования 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

А вы когда-нибудь смотрели веб-приложение на 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

Мне бы хотелось, чтобы этот пост был полезным для всех, кто будет анализировать perl-приложения, поэтому если у вас есть какие-то комментарии/дополнения, то пишите мне в личку(@ArroizX), обсудим, и упомяну в посте:D
P.S. Да, я знаю что регулярку можно написать чуть меньше и проще, а не дублировать методы 2 раза из-за особенности perl'а, где можно аргументы передать как в скобках, так и через пробел, но мне впадлу это сидеть и редачить.

Встретил на проекте WordPress, который уже забыл как тестить. Пришлось заново собирать все заметки по нему с разных концов интернета=)
Поэтому чтобы больше таким не заниматься, решил сделать удобный CheatSheet со всем необходимым.

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

И на моей улице настал праздник

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

А для интересующихся вот ссылка:
https://github.com/advisories/GHSA-m9x4-w7p9-mxhx

Я сделал это, чтобы вы этим не занимались

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

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

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

Если есть какие-то предложения по доработке/дополнению - пишите в личку, обсудим=)

Вы думаете только на 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, которую нельзя назвать своей, потому что хрен ты докажешь, что именно ты её зарепортил=)