Evolution of Attacks in the Wild on Container Infrastructure 2020

Только что прилетел на почту первый отчет по Cloud Native угрозам от Aqua Security. В нем можно прочитать про современные атаки, их классификацию, этапы, статистику, описание, примеры использования MITRE Techniques. Хочется отметить, что на первый взгляд материал не является каким-то маркетинговым булшитом (как часто бывает в вендорских отчетах).

#report #ops #k8s #docker #attack

BSIMM 11 - Что изменилось, event-driven security и платформа о рисках артефактов

Два дня назад вышла новая версия BSIMM, главного документа по организации безопасности SDLC с точки зрения оценки зрелости процессов и предоставления лучших практик. Для написания BSIMM независимая группа проводит исследование сотни компаний разных размеров, агрегируя их активности по безопасности SDLC в этот сборник.

Что изменилось, помимо перестановки активностей между практиками?

1) Появление активности "[ST3.6:0] Implement event-driven security testing in automation". Исследования BSIMM гласят, что инженеры в опрашиваемых компаниях идут по пути поиска дефектов на основе событий в процессе непрерывного мониторинга, а не поиска их на ранних стадиях жизненного цикла ПО. Тем не менее, развивается тенденция, при которой группа безопасности задает события-тригеры в рамках пайплайнов. То есть, например, привлекать инженеров ИБ не когда валится одна из проверок безопасности в пайплайне, а когда поступает какое-то конкретное событие от ботов или агентов. Эти агенты/боты могут следить как за результатами самого пайплайна, так и за реакцией со стороны dev-окружения. Также эти агенты/боты могут запускать собственные автоматические задачи по мере обнаружения необычных событий. Идею с event-driven automation можно найти в статьях Netflix от 2016 года. Тогда они описали свою платформу Winston, которая позволяла помочь инженерам не вскакивать посреди ночи из-за ложных событий.

2) Появление активности "[CMVM3.6: 0] Publish risk data for deployable artifacts", согласно которой растет значимость централизованных платформ управления безопасностью. Согласно BSIMM платформа должна содержать информацию об активах организации (артефактов, зависимостей) и связанных с ними рисками. При этом автоматическая актуализация информации и ее визуализация в платформе положительно сказывается на принятии стейкхолдерами решений, связанных с рисками.

#bsimm

🆖 Тут ребята взяли и прокачали секурити для Nginx. Запаковали это всё в образ и выложили на Github. Из коробки у нас доступен WAF, антивирусная проверка и подкрученные настройки безопасности. Интересно. https://github.com/bunkerity/bunkerized-nginx

#nginx #security

Антон Бабенко (https://github.com/antonbabenko) вернул к жизни свой канал на Youtube и теперь пилит там годноту.

Вот, например, он не только потрогал утилиту статического анализа checkov для IaC (https://github.com/bridgecrewio/checkov), но и пригласил на стрим автора оной тулы - Barak Schoster. В общем, если интересен Terraform и мир вокруг него, то рекомендую.

Terraform security tools review (part 1) - checkov
https://www.youtube.com/watch?v=KdH-7_vpFag

Falco Deefault Rule Bypass

Falco - известное open-source решение для предупреждения о подозрительных действиях на рабочих нагрузках Docker/Kubernetes. Так, например, можно определить процессы, которые могут быть запущены в Docker-контейнере и сообщать, если что-то идет не так.

Тем не менее, при определенных условиях Falco может стать бесполезным. В статье рассказывается о том, как можно обойти правила в Falco v.0.25.0 без правильно настроенного Admission Control. Берем во внимание и идем обновлять правила.

https://darkbit.io/blog/falco-rule-bypass

#k8s #ops #attack

"SonarQube in Action" by G.Ann Cambell and Patroklos P.Papapetrou

#literature #sast #dev

Gitlab - достаточно популярный продукт для разработки, благодаря self-hosted решению и его часто можно встретить на поддоменах компаний. Помимо того, что в нем также присутствует регистрация без подтверждения email’а (смотрим в предыдущие посты), это еще и отличная возможность собрать информацию о сотрудниках.

Без аутентификации доступен следующий API метод - gitlab.company.local/api/v4/users/{id}

На самом gitlab - эта ручка также доступна, например https://gitlab.com/api/v4/users/7154957:

{"id":7154957,"name":"Bo0oM","username":"webpwn","state":"active","avatar_url":"https://secure.gravatar.com/avatar/4e99709ca6b52f78d02cb92a5bc65d85?s=80\u0026d=identicon","web_url":"https://gitlab.com/webpwn","created_at":"2020-09-21T17:25:55.046Z","bio":"","bio_html":"","location":"","public_email":"","skype":"","linkedin":"","twitter":"@i_bo0om.ru","website_url":"https://www.tgoop.com/webpwn","organization":"","job_title":"","work_information":null}

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

По логину также можно узнать открытые ключи - https://gitlab.com/webpwn.keys

Отдельного упоминания заслуживает avatar_url:

”avatar_url":"https://secure.gravatar.com/avatar/4e99709ca6b52f78d02cb92a5bc65d85?s=80\u0026d=identicon”

Сервис gavatar содержит email в пути к изображению - 4e99709ca6b52f78d02cb92a5bc65d85. Это ни что иное, как md5 от email’а в нижнем регистре.

echo -n "[email protected]" | md5


4e99709ca6b52f78d02cb92a5bc65d85

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

Меня немного обогнали с описанием CVE, но я все равно дополню мысль примерами

Вот, например, CVE-2016-5195 - Race Condition в старых версиях ядра позволяет сделать docker escape.

PoC:
https://github.com/gebl/dirtycow-docker-vdso

Видео-демо:
https://youtu.be/BwUfHJXgYg0

Текстовое описание:
https://blog.paranoidsoftware.com/dirty-cow-cve-2016-5195-docker-container-escape/

#docker #ops #attack

Замечательная заметка "Impact of CVE-2020-14386 on Kubernetes and Containers (Docker)" лишний раз не дает забыть о том, что безопасность хоста, на котором работает Kubernetes это также часть безопасность Kubernetes инфраструктуры.

Здесь речь идет о критической уязвимости ядра Linux - CVE-2020-14386, благодаря которой можно поднять свои привилегии до root'а или сделать побег из контейнера на Node, на которой он работает. Атакующий способен эксплотировать данную уязвимость, выполняя свой код внутри Pod'а с CAP_NET_RAW capability.

Естественно, это далеко не первая и не последняя уязвимость в ядре Linux которая позволяет делать "container escape". И все это никакими правилами и сигнатурами заранее не описать, не предусмотреть.

Что в таком случае делать для защиты?
1) Можно/нужно мониторить аномальную активность внутри ваших контейнеров. Так или иначе атакующему придётся для побега из контейнера делать то, что ранее в контейнере у вас не происходило. Это позволит вам ловить не только попытки "container escape", но и другу. Вредоносную активность внутри контейнера (Lateral Movement, запуск манейров и т.д.)
2) Можно присмотреться к защищенным/усиленным вариантам Low-level Runtime (OCI Runtimes) о которых говорили ранее. Но стоит учитывать, что они, как и любое ПО сами не застрахованы от уязвимостей, а просто сильно уменьшают и усложняют attack surface. Так GKE Sandbox использует для этого gVisor.

Новый Awesome DevSecOps на русском

В силу того, что последняя статья с подборкой инструментов DevSecOps собрала весьма восторженные отзывы, решил вынести все тулзы (и добавить еще больше) в отдельный Awesome на GitHub. Туда же вставил все статьи и доклады на русском языке, которые я только знаю и смог найти в Интернете.

Итого:
- 16 различных практик
- 100+ инструментов
- 10+ сторонних подборок
- 30 статей на русском
- 26 докладов на русском

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

https://github.com/Swordfish-Security/awesome-devsecops-russia

#dev #ops

DevSecOps Wine Chat

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

https://www.tgoop.com/sec_devops_chat

#talks

Whalescan - vulnerability scanner for Windows containers

Для тех, кто использует Windows base OS контейнеры вроде IIS и .NET есть соответствующий инструмент. Whalescan позволяет искать уязвимости в Windows контейнерах и проводить benchmark проверки, выявлять небезопасные команды в Dockerfile, вышедшие из жизни .NET версии и другое.

https://github.com/nccgroup/whalescan

#tools #docker #dev #ops

Выложены доклады с GitLab Commit Virtual 2020

Там был отдельный поток посвящённый DevSecOps
https://www.youtube.com/playlist?list=PLFGfElNsQthbJaOG4pV450Y_eIdfr2p9Y

Ссылка на все потоки
https://www.youtube.com/c/Gitlab/playlists?view=50&sort=dd&shelf_id=5

Программа
https://about.gitlab.com/events/commit/#schedule

Красота

Ко всему прочему было проведено моделирование угроз через drawio-threatmodeling , выведены требования безопасности, организована проверка IaC и автоматический аудит через ScoutSuite.

#aws

🔸Security Architecture Review Of A Cloud Native Environment

Walkthrough of a cloud security assessment performed on an organisation which had recently moved their infrastructure from an on-prem to a cloud native solution (AWS).

https://notsosecure.com/security-architecture-review-of-a-cloud-native-environment/

#aws

How to enforce Kubernetes network security policies using OPA

Статья на CNCF из серии Open Policy Agent (OPA) про Network Security Policies и усиление мер защиты. В частности, как написать политики OPA на языке Rego
1) Чтобы, нельзя было задеплоить приложение, если сетевая политика не установлена
2) Чтобы сетевая политика удовлетворяла требованиям к приложению (например, подключиться мог только фронтенд)

https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa/

#ops #k8s #opa