5-ти минутная интеграция SAST в Gitlab CI/CD

Если ты используешь Gitlab как инструмент для хранения и управления репозиториями, но все еще не внедрил SAST в свой CI/CD, то этот пост для тебя.

Gitlab дает возможность одной строчкой внедрить статический анализатор кода в проект. Для этого необходимо в файл .gitlab-ci.yml добавить необходимый шаблон: Security/SAST.gitlab-ci.yml. Сервис сам определит на каком стеке написан проект и запустит нужный анализатор кода, а результаты можно будет посмотреть в отдельном стейдже или в security dashboard.

Конечно, инструменты нужно настраивать под себя. К сожалению, в community версии можно определить только некоторые переменные, например, SAST_GOSEC_LEVEL (игнорировать уязвимости, найденные Gosec при заданном уровне,. 0 = Не определено, 1 = Низкие, 2 = Средние, 3 = Высокие). В enterprise же можно добавлять и изменять rulesets.

Поддерживаемые языки программирования для быстрой интеграции: https://docs.gitlab.com/ee/user/application_security/sast/

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

#soft #ssdlc

Это я пытаюсь сделать скрытный пентест

Что изменилось в OWASP Top 10 с 2017 года

Broken Access Control - данная категория стала наиболее серьезной угрозой для веб-приложений. Например, доступ к API интерфейсам без аутентификации с возможностью отправки POST, PUT, DELETE запросов.

Cryptographic Failures - новое название для категории Sensitive Data Exposure, внимание уделяется ошибкам, которые приводит к раскрытию конфиденциальных данных. Категория выходит на 2-ое место.

Insecure Design - новая категория в 2021, в которой основное внимание уделяется рискам, связанными с недостатками проектирования и реализации веб-приложений.

Многие категории переместились, появились новые, более подробно можно ознакомиться на официальном сайте: https://owasp.org/Top10/

Собственный SOC на OpenSource

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

Уже несколько лет компания Elastic дает возможность воспользоваться их SIEM на базе стека ELK (Elasticsearch, Logstash и Kibana).

Можно собирать все типы журналов и событий с серверов, сетевых устройств, АРМов пользователей с помощью Beats.

После сбора логов с конечных точек, нужно собрать данные со средств защиты. В ELK SIEM уже встроена функциональность сбора данных с Network и Host Based IDS (Suricata, Wazuh), Iptables, Cisco ASA, Palo Alto FW, это позволяет достаточно быстро получить события с СЗИ и красиво визуализировать их.

Кроме того, в ELK SIEM можно посмотреть сетевые потоки, DNS, для поиска и анализа трафика.

Все данные: системные журналы, события ИБ попадают в Logstash. Logstash — это инструмент для сбора, фильтрации и нормализации логов. Более понятным языком – это штука, в которую закидываются логи в непонятном виде, а на выходе получается структурированный JSON. После обработки данных Elasticsearch будет обрабатывать индексацию данных, это нужно для оптимизации процесса хранения и поиска данных. Затем данные передаются в Kibana, которая, в свою очередь, проводит анализ и визуализацию сохраненных данных.

В расширенной версии ELK SIEM можно применить машинное обучение для выявления аномалий. Сам ELK SIEM можно развернуть у себя или воспользоваться Cloud решением.

Ссылка на официальный сайт: https://www.elastic.co/siem/

Когда понял, что оставил данные на фишинговом сайте.

Уязвимости в бизнес-логике, которые не распознает ни один сканер (сфера финтех)

С каждым годом банковские веб-приложения становятся более отказоустойчивыми и имеют все меньше технических уязвимостей: SQL-инъекции, XSS, RFI/LFI и так далее. Более актуальными становятся атаки, направленные на эксплуатацию уязвимостей в бизнес-логике.

Злоумышленники могут:

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

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

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

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

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

Избегать проблем в логике приложений позволяют анализ кода и процессы безопасной разработки (Secure SDLC), о которых мы так много говорили на митапе.

#pentest

Безопасность Docker-контейнеров

Если вы используете Docker, то наверняка задумывались о том, как правильно, с точки зрения безопасности, собрать образ и развернуть контейнер. Компания Linode подготовила интересный документ - “Основы безопасности Docker”, в котором разобрали следующие темы:

- Как правильно настроить сервер, на котором будет работать Docker
- Настройка логирования
- Конфигурация Docker Deamon
- Безопасность Docker-контейнеров
- Аудит и сканирование безопасности Docker-контейнеров
- Безопасная сборка Docker-образов

И еще много всего интересного, с радостью делюсь материалом :)

Уязвимости в бизнес-логике, которые не распознает ни один сканер (сфера ecom)

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

Несколько популярных примеров логических уязвимостей:

— Заказ без подтверждения, который ломает логистику. Если функциональность интернет-магазина позволяет оформить заказ без подтверждения по телефону, то оператор не сможет отличить его от фейка. Примет заказ и отправит товар со склада по адресу, где никого нет. При многократном повторении злоумышленник может перегрузить логистику, остановить работу магазина и нанести огромный ущерб бизнесу. Необходимо всегда делать подтверждение по SMS/звонку и использовать механизм ограничения множественных запросов.

— Некорректная авторизация по номеру телефона. Многие онлайн-сервисы используют SMS-коды в качестве механизма авторизации пользователей. Но допускают ошибки, например, не делают ограничений по количеству попыток или сроку жизни кода подтверждения. Как правило, код состоит из 4-6 цифр, так что максимальное количество запросов, необходимых для перебора — 1 миллион, что совсем немного.

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

— Класс атаки Circumvention of Work Flows
Позволяет злоумышленнику обойти последовательность взаимодействия с приложением или условия его бизнес-логики. Например, если механизм реализован некорректно, то злоумышленник сможет оформить заказ, пропустив этап оплаты, и получить подтверждение заказа в CRM.

В следующий раз расскажу о популярных логических уязвимостях в интернет-сервисах.

#pentest

Каждого компетентного специалиста рано или поздно настигает профессиональная деформация. Безопасники не исключение. Загибай пальцы если ты:

1. Используешь больше 32 символов для пароля на WiFi;
2. Можешь вытащить модуль микрофона из телефона;
3. Не используешь WiFi, кроме домашнего;
4. Всегда пользуешься VPN;
5. Всегда шифруешь данные;
6. Выпаеваешь USB-порты на ноутбуке;
7. Испытываешь проблемы с оформлением визы;
8. Блокируешь компьютер, каждый раз отходя от него;
9. В социальных сетях и мессенджерах тебя нельзя узнать по аватарке или имени.

Если загнул больше 5 — значит у тебя безопасность головного мозга :)

Пишите, какие признаки и стереотипы про нашу профессию слышали вы 👇

Не так давно вышла новость про новую активность хакеров RedCurl в крупном ритейлере. Мы в Awillix рассматриваем подобные кейсы в разрезе supply chain атак, которые представляют целый спектр возможностей для хакерских группировок и только набирают обороты в последнее время.

Supply chain атаки производятся на жертву не напрямую, а через цепочку ее поставщиков. Целью группировок подобных RedCurl, описанных специалистами Group-IB, необязательно должна быть сама компания-жертва.

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

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

У крупнейших ритейлеров гигантский масштаб ИТ-инфраструктуры — тысячи серверов. Факт того, что группировка навсегда покинула ее, остается спорным. Хакеры могли оставить множество имплантов, которые позволят им в любой момент вернуться и продолжить контролировать различные узлы инфраструктуры.

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

Компрометация одной такой компании автоматически ведет к компрометации всех их клиентов. Наиболее ярким примером является кейс Solar Winds, когда в результате их взлома только в США пострадали десятки (возможно сотни) тысяч компаний, включая Microsoft, Cisco, FireEye, а также множество правительственных агентств США, включая Гос­деп и Национальное управление по ядерной безопасности.

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

Ссылка на статью-первоисточник —
https://xakep.ru/2021/11/18/redcurl-attacks/

Когда с друганом нашел критическую багу в защищенной приложухе:

Безопасность REST API

Привет! Мне вдруг стало интересно, а есть ли у вас политика безопасности для API?

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

OWASP уже предложил несколько стандартных пунктов в своем документе:

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

— Контроль доступа: не должно быть публичных интерфейсов, которые работают с чувствительными данными.

— Ограничение использования HTTP-методов: каждый интерфейс API должен работать только с нужными методами, например GET, POST, PUT. На все остальные методы сервер должен возвращать 405 Method not allowed.

— Валидация данных: на эту тему уже много всего написано) параметризация, ограничение по длине, санитизация.

— Использование точного content type: если приложение отдает JSON, то content type обязательно должен быть application/json, иначе возможны атаки, например XSS.

— Обработка ошибок: исключать подробный вывод ошибок приложения пользователю, например, стектрейсы или экспешены.

— Логирование: тут все должно быть понятно, пишем audit log, коррелируем события, выявляем аномалии.

— Использование заголовков безопасности: не забываем про заголовки, такие как HSTS, CSP, X-Frame и т.д.

И еще много-много всего интересного можно найти для себя, прочитав тот самый REST Security Cheat Sheet.

Например, когда я разбираю дизайн API, люблю делить интерфейсы по уровням критичности, допустим:

- работают с финансами — Critical
- работают с данными пользователей — High
- работают с данными приложения/окружения косвенно с данными пользователя — Medium
- работают со статикой, например, изображения — Low
- работают с открытыми данными приложения — Info

Каждая такая градация, должна покрываться соответствующими мерами, например, Critical обязательно находится под мониторингом и логированием 24/7, должны быть за аутентификацией и так далее, все зависит от модели угроз.

Делюсь интересными ссылками по безопасности API:

- API Security Checklist: Cheatsheet
- API Audit Checklist
- JSON Web Token Security Cheat Sheet
- REST API Design Guide

Всем привет! В последнее время мы в Awillix наблюдаем растущий интерес компаний к процессам безопасной разработки и много противоречивых мнений.

SSDLС – Secure Software development lifecycle исповедует идею, что в процессе разработки ПО нужно оценивать возможные уязвимости и сразу предусматривать меры, которые их нейтрализуют.
Качественный код и безопасный код — далеко не одно и тоже. Например:

У бизнеса есть сервис, позволяющий привязать накопительную скидочную карту к аккаунту клиента. Пользователю становится доступно накопление бонусных баллов. Бизнес-заказчик описывает разработчику задачу: после авторизации в личном кабинете, пользователю предлагается заполнить поля «Номер карты» и «sms-код». Если введенные данные верны — карта привязывается к пользователю и ему предоставляется скидка.

Разработчик реализует нужную форму и запрос к базе данных, в котором проверяется соответствие номера карты и коды. Программный код качественный, все тесты пройдены, ошибок нет. Обновление выкатывается в production, и в этот момент выясняется, что количество попыток ввода данных было неограниченно. В результате — злоумышленник, завладев номером карты, может подобрать sms-код простым перебором вариантов. Программный код в нашем примере оказался небезопасным.

Качество кода — определяется уровнем квалификации разработчиков. А его безопасность — в первую очередь зависит от анализа модели угроз.

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

Какие вопросы относительно SSDLС есть у вас?

Всем привет! В прошлую пятницу мы снова организовали митап для ИБ-специалистов. На этот раз посвятили вечер безопасности доменной инфраструктуры на базе Microsoft Active Directory.
⠀
Менеджер практики кибербезопасности PwC Дмитрий Забелин и руководитель направления анализа защищенности Awillix Илья Костюлин выступили с докладами.
⠀
Рассказали про:
⠀
— Защиту доменов: ошибки, которые хакеры используют, чтобы получить контроль над доменом, паттерны взлома, кейсы захвата, стратегии по защите и многое другое.
⠀
— Оптимальный набор сценариев выявления инцидентов, SOC и мониторинг безопасности.
⠀
Запись трансляции доступна по ссылке: https://www.youtube.com/watch?v=08dVYePNW_E

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

Мы наконец выпустили статью, где просто и по-существу рассказываем о принципах «безопасной» разработки и главных мифах связанных с ней 👇(лайк/шэр/коммент)

https://vc.ru/services/337251-bezopasnaya-razrabotka-kak-sokratit-zatraty-na-kiberzashchitu-do-reliza-produkta

Уязвимости в бизнес-логике, которые не распознает ни один сканер (интернет-сервисы)

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

Такси

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

Иногда приложение может быть уязвимо для получения информации о клиенте. Были случаи, когда водители находили номер клиента, звонили и предлагали отменить поездку — отвезти за наличные деньги и меньшую сумму.

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

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

Подмена локации

Игра Pokеmon GO — еще один забавный пример. Охотники за эксклюзивными покемонами брали эмулятор андроида на компьютере, меняли локацию на Иран, где водились редкие покемоны и ловили их там :)

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

Часто при тестировании API встречается уязвимость класса Broken Access Control. Она может быть связана с недостаточным контролем доступа к тому или иному интерфейсу API. Например, в одном из приложений был найден эндпоинт /api/v1/admin/notifications, который отдавал информацию обо всех событиях, в том числе о смене пароля. В событиях о смене пароля фигурировала ссылка на сброс. Таким образом, можно запросить смену пароля для администратора, обратиться к интерфейсу /api/v1/admin/notifications, получить ссылку на сброс пароля, установить новый пароль и войти в систему как администратор.

С чего можно начать путь DevSecOps?

Есть интересный ресурс DevSecOps University. Там собрано много материалов в одном месте: статьи, книги, видеоуроки, инфографика, инструменты. Есть даже лабораторные работы ☝🏻

Ребята покрывают следующие темы:

- Системы управления версиями (git).
- CI/CD и все что связано с ним. Можно потренироваться на лабораторных работах.
- Управление артефактами сборки.
- IAC: инфраструктура как код. Ansible, Vagrant и другие умные слова))
- Облачные решения и их безопасность, в основном рассматривают AWS
- Модель угроз: расскажут, как правильно реализовать модель угроз под свой проект.
- Статическое тестирование безопасности (SAST): что такое, как внедрить, какие инструменты существуют.
- Динамическое тестирование безопасности (DAST): темы аналогичные SAST.
- И другие интересные темы, вроде: Security as Code, Compliance as Code.

Делитесь своими ресурсами на тему DevSecOps в комментариях)

Разрываем k8s

Вы наверняка уже встречались с Kubernetes. Уверен, кто-то из вас активно использует их у себя в компании и заботится о том, чтобы злоумышленник, попав в контейнер, не устроил побег.

Для того чтобы проаудировать k8s можно воспользоваться различными чек-листами, документами вроде CIS Benchmarks. Но куда быстрее и нагляднее воспользоваться автоматизированными инструментами.

Есть на github интересный репозиторий, в котором собраны документы, утилиты, подкасты, презентации и все-все, что связано с безопасностью k8s. Бери и пользуйся, например, kube-bench в автоматическом режиме проверяет соответствие по CIS Benchmarks, а peirates проверяет известные недостатки конфигурации и уязвимости.

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

#soft #k8s

Для чего нужна база знаний MITRE ATT&CK

База MITRE ATT&CK представляется в виде матриц, в которых столбцы — это основные этапы кибератаки, а ячейки — способы и техники их реализации. Например, этап - «Рекогносцировка», а «Активное сканирование» — техника.

MITRE ATT&CK достаточно полно отображает поведение злоумышленников и становится полезной, например, для реагирования на киберинциденты и применения защитных мер. Кроме того, для каждой техники представлено детальное описание, защитные меры и способы обнаружения.

Существует несколько матриц, и каждая из них покрывает разные системы, например:

— Матрица Enterprise: состоит из техник, которые применяются в ходе атак на организацию. В частности, содержатся тактики и техники кибератак на определенные операционные системы.
— Матрица Mobile: содержит тактики и техники, которые применяются к мобильным устройствам.
— Матрица PRE-ATT&CK: содержит тактики и техники, которые злоумышленники используют, до эксплуатации уязвимостей и проникновения, другими словами, на этапе подготовки к кибератаке.
— ATT&CK for ICS: из названия становится ясно, что в ней содержатся тактики и техники, которые используются в кибератаках на промышленные системы.

Имея перед собой эти инструменты, специалисты по информационной безопасности могут:

— Проанализировать текущие защитные меры и оценить угрозы, узнать какие техники могут быть реализованы в системах и принять соответствующие меры .
— Правильно реагировать на возникающие инциденты. Достаточно найти в матрице соответствующую технику и определить на каком из этапов находится кибератака, а дальше использовать предложенные меры.
— Изучать модель поведения APT-группировок. Это позволяет расширить текущие знания и быть готовым к возможным атакам.