MyAppSec

https://github.com/cepxeo/send4creds

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Позитивы выкатили свою версию методологии внедрения безопасной разработки AppSec Table Top. Документ объемный, включает многие аспекты DevSecOps, подробно описаны подходы и ключевые этапы.

Это далеко не первая попытка систематизировать процесс внедрения безопасной разработки, AppSec велосипеды изобретают в OWASP с их SAMM и BSIMM, есть хорошие их адаптации к российским реалиям в виде ГОСТа 56939 или фреймворка DAF от Джета.

В целом материала для внедрения достаточно, осталось выделить приоритетные направления и вкладываться в безопасность.

Ссылки на учебные видео по вебу, если есть пробелы в понимании чек листа.

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

Проверяем удаленный Linux сервер на соответствие лучшим практикам харденинга:

docker run --rm -v ~/.ssh:/root/.ssh -v $(pwd):/share hysnsec/inspec exec https://github.com/dev-sec/linux-baseline.git -t ssh://имя_sudo_юзера@удаленный_сервер -i ~/.ssh/id_rsa --chef-license accept --reporter json:/share/inspec-output.json

Предполагается, что id_rsa ключ лежит в ~/.ssh и уже добавлен в разрешенные на удаленном сервере.

Modsecurity WAF можно поднять быстро и бесплатно с неплохим набором правил, поддерживаемых owasp (https://owasp.org/www-project-modsecurity-core-rule-set/)

Например, есть уязвимый фронт на докере с именем flask, который слушает на порту 5000. Перед ним поднимаем modsecurity-crs:

docker run -dti --name modsecurity -p 80:80 -e PARANOIA=1 -e PROXY=1 -e BACKEND=http://flask:5000 owasp/modsecurity-crs:3.3.4-nginx-alpine-202304160904

Само собой можно настроить TLS с правильными сертификатами и другими плюшками.

Вопрос что делать с json. Можно выгружать в Defect Dojo, ставится легко:

git clone https://github.com/DefectDojo/django-DefectDojo
cd django-DefectDojo && ./dc-up-d.sh postgres-redis

После установки получаем админский пароль:

docker compose logs initializer | grep "Admin password:"

Логинимся в веб консоль, создаем новый Product, в нем новый Engagement и далее выгружаем json, указав соответствующий тип теста.