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

Рассказал про типы анализа, какие тулы использовать и что делать с результатами. Поговорили и про кастомизацию сканеров и написание своих Semgrep / Nuclei правил.

Где веб приложения хранят секреты пользователя после аутентификации? Куки это хорошо, но если надо больше?

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

В IndexedDB браузера. И что такого? Как выяснилось, браузеры Chrome, Edge и т.п. не шифруют свои хранилища, кроме Cookies. То есть ключи они просто там, в файлах.

В случае с IndexedDB на винде они лежат в %LocalAppData%\Google\Chrome\User Data\Default\IndexedDB.

Есть другие варианты хранилищ - Local Storage, Session Storage, там та же история.

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

Или в пентесте, при получении удаленного/локального доступа к компу с профилем нужного пользователя можно выкачать эти файлики и подложить к себе.

И вот ты уже участник секретного p2p сообщества. Или крипто кошеля.

Когда тестируете веб, смотрите где приложение хранит секреты, может быть интересно.

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

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

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

Эффективные решения по защите есть, но проще отказаться от СМС в пользу мейлов, OTP и т.п.

https://www.guardsquare.com/blog/how-android-malware-works

Всем привет и с Новым Годом!

Интересный вебинар по возможностям малвари для Android и методам защиты. Помогает для аргументации найденных уязвимостей мобильных приложений и в целом для понимания угроз.

Смотрим, ужасаемся, бежим отключать Accessibility в телефонах.

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

Это вызывает дискуссии между безопасниками и разработчиками, последние часто используют сторонние решения для хранения файлов, которые передают идентификаторы только через GET/URL, прикрутить к ним аутентификацию запросов сложно или невозможно. Например, почти все S3 хранилища такие, включая AWS, MinIO и т.д.

Теперь о рисках, многим известно, что URLы кэшируются в браузерах, на прокси, в логах веб серверов и балансеров, можно собирать их через WiFi, VPNы и других MiTM устройствах.

Но немногие знают про функцию проверки URLов, которая есть и включена по умолчанию во многих браузерах. В Chrome она называется Safe Browsing, в Edge Safesearch и т.п. По некоторой логике "подозрительные" ссылки автоматически направляются браузерами в Google, Microsoft, Яндекс и другим корпорациям добра для анализа ссылки на "вредоносность".

И да, часто это обычные ссылки на скачивание файлов, с секретными небрутабельными идентификаторами.

Проблема это или нет зависит от модели угроз, но как минимум это ещё один вектор утечки идентификаторов и аргумент в пользу аутентификации таких запросов.

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

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

Несколько примеров из реальных тестов:

1. Находим HTTP запрос на обработку которого у сервера уходит > 5-10 секунд. Обычно это сложные вычисления, запросы с ожиданием ответа с бэк энда или стороннего API. Отправляем такие запросы в 50-100 одновременных потоков в бесконечном цикле. Почти сразу сервер уходит в ошибку 500, 503 и т.п. для всех пользователей.

2. Фаззингом или перебором выявляем значения параметров запроса, которые могут привести к долгому ответу сервера, скорее всего с ошибкой. Например слишком большие числовые значения, неверные типы (string вместо integer), "тяжелый" regex или что-то, влияющее на внутренние циклы или итерации вычислений сервера. В итоге, вместо доли секунды заставляем сервер работать несколько секунд, после чего см п 1.

3. Желая защитить приложение от злоупотреблений, разработчики часто ставят ограничение на количество запросов. Например, скрине выше приложение возвращает ошибку 429 Too Many Requests после нескольких десятков запросов определенного типа. Обычно нужно ждать около минуты до направления следующего запроса.

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

Хорошая презентация по безопасности API с конференции HITB в Амстердаме, на которой мне удалось поприсутствовать.

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

Полный список презентаций с этой конференции: https://conference.hitb.org/hitbsecconf2023ams/materials/

Немного о типичных ошибках реализации 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 из своего опыта, от анализа исходного кода до генерации описания уязвимостей и пентест отчетов.

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