Кстати, в начале года сравнивали полную версию PT AI с набором open source аналогов (Semgrep, Bandit, FindSecBugs, Security Code Scan и т.д.) под общим названием ScanSuite.

Сравнение субъективное, на полноту не претендует, результат тогда был в пользу open source.

На днях прошел SafeCode Meetup №2. Понравился доклад по безопасной настройке GitLab:

https://www.youtube.com/live/Hg5X5LIZP6E

Отличный курс по безопасности приложений и окружения:

https://www.youtube.com/playlist?list=PLQC2_0cDcSKD_JHWtEJGIFQUVh7Z5JM8E

Как просканировать сайт на CMS Bitrix на уязвимости?

Качаем шаблоны для Nuclei:

git clone https://github.com/jhonnybonny/nuclei-templates-bitrix.git

Сканируем:

docker run --rm -v $(pwd):/tmp -v $(pwd)/nuclei-templates-bitrix:/nuclei-templates projectdiscovery/nuclei -t /nuclei-templates -u https://example.com

вместо -u https://example.com можно указать файл с со списком сайтов через -l TARGETS.txt

В качестве бонуса, репа с эксплоитами: https://github.com/JackPot777/bitrix

Сканируем python код на уязвимости сканером Bandit. Из папки с исходниками запускаем:

docker run --rm -v "${PWD}:/src" ghcr.io/pycqa/bandit/bandit -r /src -f json -o /src/bandit.json

Есть ещё Semgrep, можно любой код сканировать, сам определяет языки и применяет правила:

docker run --rm -v "${PWD}:/src" returntocorp/semgrep semgrep --json -o semgrep.json

Вопрос что делать с 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, указав соответствующий тип теста.

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=https://flask:5000 owasp/modsecurity-crs:3.3.4-nginx-alpine-202304160904

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

Проверяем удаленный 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 и уже добавлен в разрешенные на удаленном сервере.

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

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

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

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

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

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

Рассказал про типы анализа, какие тулы использовать и что делать с результатами. Поговорили и про кастомизацию сканеров и написание своих 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/