В продолжении темы про возможность supply chain атак на реестр образов контейнеров AWS ECR, рассмотрим утилиту Cloud Container Attack Tool (CCAT). С помощью этого инструмента, можно автоматизировать создание и загрузку вредоносного образа контейнера в репозитории AWS ECR, во время проведения тестирований на проникновение в облачной инфраструктуре AWS.

Предположим, что злоумышленнику удалось каким-либо образом получить учетные данные аккаунта мэйнтейнера репозитория популярных и часто загружаемых образов контейнеров в ECR. CCAT позволяет выгрузить все образы, на лету создать на основе интересующего образа новый Dockerfile содержащий, например reverse shell отрабатывающий по cron'у. Далее собрать вредоносный контейнер и загрузить обратно в AWS ECR и уже ловить шеллы от других пользователей, которые будут им пользоваться в дальнейшем. Подобная простая в реализации атака на единственный аккаунт AWS может потенциально привести к печальным последствиям для большого количества пользователей, использующих забекдоренный контейнер.

Осознавая риски и последствия подобных атак в начале 2021 года более 200 крупных технологических компаний присоединились к программе Docker Verified Publisher, которая призвана обеспечить безопасность и регулярный аудит образов контейнеров популярного ПО. Но это вовсе не значит что образ помеченный, как Verified по умолчанию безопасен и не нуждается в самостоятельном аудите содержимого.

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

Решение: У kubectl есть замечательный параметр -v, отвечающий за verbosity вывода. Так вот если его использовать в значении --v=8, то будет отображено все содержимое HTTP запроса`. На пример:

kubectl get services -A -l environment=production -ojson -v=8

Далее уже можно этот запрос добавить, как себе в код так в любимый инструмент типа Burp ;) На просторах интернета можно еще найти много других полезных трюков с этим параметром.

30 июня в Санкт-Петербурге offline пройдет юбилейная 10-я конференция по информационной безопасности ZeroNights.

На ней я в рамках секции Defensive Track представлю доклад "Container escapes: Kubernetes edition" - поговорим о том, как и что могут атакующие и что можно сделать, чтобы усложнить побег из Pod’а.

Также в рамках данной секции для аудитории данного канала точно будет интересен доклад "Attacking the microservice applications: methods and practical tips".

Приходите буду рад познакомится и пообщаться в живую =)

На канале уже не раз писали о важности правильно выдавать/контролировать своим workload'ам Capabilities (особенно про CAP_NET_RAW [1,2,3,4]). Напомним, что, Capabilities является частью securityContext и здесь ими можно управлять.

И вот вышла замечательная статья “Linux Privilege Escalation – Exploiting Capabilities”, в которой есть:
- полный список Capabilities с их описанием
- список опасных
- как определить имеющиеся
- пример поднятия привилегий

И еще упоминается полезные проекты LinPEAS, GTFOBins и статья с HackTricks по этой теме. К этому, я могу добавить еще старый, но хороший документ "Exploiting capabilities: Parcel root power, the dark side of capabilities".

Также рекомендую вспомнить наш пост про GKE Autopilot и как он работает с Capabilities.

Как сделать аутентификацию в приложении в GKE?

В обычном варианте обычно это происходит так — средствами ingress controller добавляется аутентификация через Basic Auth/OAuth.
Недостатки данного метода:
- в случае с Basic Auth, где-то надо хранить хеши паролей и уметь их обновлять
- в случае с OAuth, надо полагаться на внешний OAuth provider, либо держать свой (самые популярные Dex, Keycloak, ORY Hydra)

Google позволяет нам забыть про всё это и использовать уже известный нам IAM.
Identity-Aware-Proxy (IAP) — инструмент реализующий централизованную авторизацию для приложений в GCP.

Принцип работы прост:
- Google Sign-In аутентифицирует клиента (живого человека или ServiceAccount)
- IAM проверяет доступ и проводит aвторизацию клиента
- если проверка прошла, запрос проксируется на backend c JWT токеном, подписанным IAP'ом

Нюанс №1 — необходимо проверять заголовки от IAP.
Если вы используете GKE, то за вас это сделает Ingress Controller, необходимо лишь создать нужные ресурсы в Kubernetes. Если нет, то заголовки придется проверять самому.

В качестве backend IAP поддерживает Compute, GKE, Cloud Run, App Engine, и даже on-premises через Interconnect.
Также, IAP поддерживает Google Workspaces, что позволяет организовать доступ сотрудников к ресурсам компании.

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

Про второй неочевидный нюанс в следующем посте.

Классная заметка/инструкция "How to protect your ~/.kube/ configuration".

По итогу, с помощью encfs - вы сможете шифровать данную директорию, делать ее доступной только на определенное время и только по паролю.

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

Недавно я стал гостем замечательно подкаста по информационной безопасности под названием "Мимокрокодил". Выпуск называется "Qu3b3c: Немного про K8s и Cloud Native" и там мы поговорили о Kubernetes, DevSecOps, Shift Left Security, Observability и многом другом что связано с Cloud Native.

Подкаст можно послушать на:
Яндекс.Музыка
Apple.Podcasts
Google Podcast
Anchor
Castbox
Spotify (за пределами РФ)

P.S. Рекомендую послушать и другие выпуски - там в гостях уже побывало много моих хороших друзей и знакомых!

Замечательный документ "Cloud Incident Response Framework" от Cloud Security Alliance про реагирование на инциденты в облачных окружениях.

Авторы все разбили на четыре фазы:
1) Preparation
2) Detection and Analysis
3) Containment, Eradication and Recovery
4) Postmortem

Если вы уже живете в облаках есть ли у вас это в ваших процессах?)

Отдельно выделю еще Incident Evaluation Metrics, где описываются, рассматриваемые нами ранее:
- Mean time to detect (MTTD)
- Mean time to acknowledge (MTTA)
- Mean time to recovery (MTTR)
- Mean time to containment (MTTC)

И мое любимое: "A lack of visibility in the cloud means that incidents that could have been remediated quickly are not addressed immediately and are at risk of further escalation."

В преддверии моего выступления на Kuber Conf поучаствовал в легендарном подкасте «The Art Of Programming» (выходит с 2008 года). Мы записали небольшой выпуск на злободневную тему: «Безопасные безопасности».

Список тем из выпуска:
- Город поребриков и контекст
- Безопасность и регуляторы
- Ностальгия и мотивация
- Очный DevOpsConf и Security champions
- SRE, Observability, Root Cause Analysis
- Наш путь и международный ландшафт
- Безопасность и open source
- Важное и полезное


Слушайте нас в 254 подкаста!

Telegram
VK
Twitter
FB

Почти спустя месяц после релиза "ATT&CK® for Containers" мои руки дошли до него. Теперь это уже официальная часть ATT&CK версии 9.0.

Матрица от Microsoft для Kubernetes мне нравится больше. Почему?
Рассматривать контейнер в отрыве от окружения по мне неправильно - много важных моментов теряется. Мне кажется, это поняли и авторы, так как в части пунктов упоминается "orchestration", а если зайти в каждую из техник, то там часто встречается либо пример, либо метод детектирования связанный с Kubernetes. А еще не очень приятный момент что часть техник они просто пересекли с техниками из Enetrprise матрицы и в итоге читаете описание и примеры, вообще никак не связанные с контейнерами ...

Но тем не менее можно эту матрицу сочетать с матрицей Microsoft.

Достаточно неплохая статья "PCI DSS compliance in Kubernetes-based platforms" для тех, у кого голова об этом болит ;) Базовые пункты и рекомендации покрыты не плохо с примерами OpenSource проектов. Но назвать это полноценным и лучшим выбором нельзя. Но для тех, кто только начинает - хороший старт.

Скоро начнётся мой доклад на Kuber Conf https://youtu.be/VLcMAS_lIQw

Знаю, что многие очень негативно или скептически относятся к Kubernetes c Node на Windows ...

Но злоумышленники уже прощупывают эту почву. И даже container escape делают через технику Thread Impersonation, используя недокументированный вызов Windows под названием NtImpersonateThread, а далее уже NtSetInformationSymbolicLink для самого побега. По сути это продолжение вот этой истории. Ну и тут все как положено с Microsoft)))

Далее уже вредоносное ПО на Node ищет kubectl.exe и config файл по RegExp для продолжения атаки.

Продолжение статьи про Identity Aware Proxy

Для аутентификации с помощью ServiceAccount, необходимо иметь permission iam.serviceAccounts.getOpenIdToken и получить OIDC токен

Нюанс №2
ServiceAccount с permission iam.serviceAccounts.getOpenIdToken может выписывать OIDC токен для любого другого ServiceAccount
Соответственно, обладая ServiceAccount'ом с таким permission, можно имперсонировать другой аккаунт и обойти IAP.
К сожалению ограничить действие permission на определенные ServiceAccount через Conditions не представляется возможным.

Используя этот нюанс можно было решить мою таску на Hack and Learn Initiative про мисконфиги в GCP. В ней также был реализован нюанс из прошлой статьи — кривая проверка хедеров от IAP
Подробный write-up можно почитать тут

Как бы удобны не казались облачные сервисы, нужно вдумчиво читать всю документацию, чтобы по пути не сделать несколько ошибок, в попытке сделать своё приложение безопаснее.

Сегодняшняя новость будет актуальна пользователям Istio в своих Kubernetes владениях или тем, кто проводит аудиты безопасности и понятное дело время от времени нуждается в уязвимостях во встречаемых, сторонних решениях.

Буквально несколько дней назад было объявлено о CVE-2021-34824 (или по внутренней нумерации ISTIO-SECURITY-2021-007), которая звучит как: "Istio contains a remotely exploitable vulnerability where credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces." с CVSS Impact Score равным 9.1. Так что патчимся ;)

А вообще у Istio есть хорошая официальная страничка о найденных в нем уязвимостях (как раз та внутренняя нумерация) и там можно отметить, что за 2021 год было уже закрыто 7 уязвимостей и их CVSS не ниже 7.5! Так что обратите внимание на этот момент.

Есть легендарный пост на GitHub: "What happens when you type google.com into your browser's address box and press enter?" (и подобные), объясняющий что же там за магия творится .

Некоторое время назад на канале мы публиковали похожий материал "What happens when ... Kubernetes edition!", где описывается что происходит при создании Pods, через команду:

kubectl run nginx --image=nginx --replicas=3

В продолжении данной темы мы рекомендуем обратить свое внимание на статьи про то, что происходит, когда используется kubectl exec (не малозначимая команда для ИБ):
- "How It Works — kubectl exec" (Docker shim)
- "How does 'kubectl exec' work?" (CRI-O)

Если вы как и наша команда хотите не просто использовать k8s, но и понимать его, понимать как он работает, то это определенно MUST READ!

А сегодня, в продолжении прошлого поста, давайте посмотрим на kubectl exec или на POST запрос /api/v1/namespaces/{namespace}/pods/{name}/exec кому как удобнее и приятнее - с точки зрения RBAC.

И тут для начала нужно вспомнить, что некоторые Kubernetes ресурсы имеют так называемые subresource, к которым как раз и относится exec, как и те же logs, attach, portforward и т.д. По итогу, чтобы пользователь мог делать exec ему необходимо иметь pods/exec:

- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

Ну или "*" в графе resources ;)

Помните о "subresource" и управляйте правами в соответствии с принципом наименьших привилегий (Principle of least privilege).

Малоизвестный факт о Kubernetes RBAC: каждому действию (verb) в RBAC есть четкое сопоставление HTTP команды. Так что даже по HTTP логам можно определить какие действия совершались над тем или иным ресурсом. Или даже можно попытаться по HTTP логу за какой-то промежуток времени сгенерировать Role типа как тут.

Сегодня пятничный пост, который в первую очередь нацелен на вашу активность ;)

Поделитесь в комментариях интересными, полезными operator'ами для Kubernetes, которые как могут связаны с ИБ, так и нет. А может быть просто инструмент завязан на Mutating и/или validating admission webhook. При этом они могут быть очень маленькими, малоизвестными или даже уже не поддерживаемыми, но у них очень классная идея, которая вам очень нравится. В общем то, что так или иначе нельзя найти на OperatorHub.io и не просто найти на GitHub, Bitbucket и т.д.

Лично для меня таким является проект Kubernetes Janitor (хоть Custom Resources он не использует), о котором я писал ранее, и Kubernetes Security Profiles Operator - писал тут. В общем, давайте поделимся малоизвестными operator'ами =)

В рамках CNCF сейчас активно работает Policy Working Group. Как можно догадаться из названия она работает над тем, как будет в Kubernetes выглядеть сущность Policy. А именно ресурсы из wgpolicyk8s.io/v1alpha2:
- ClusterPolicyReport
- PolicyReport
Основную часть которых занимают PolicyReportSummary и PolicyReportResult.

Какую они проблемы решают и вообще, для чего это надо?

Сейчас уже существует множество разных инструментов для Kubernetes, которые проводят те или иные анализы, проверки и создают свой отчет. И вот каждый из них последнее делает как хочет. А ClusterPolicyReport и PolicyReport призваны унифицировать это в виде конкретных типов ресурсов и еще на один шаг приблизить работу со всеми инструментами к концепции Policy-as-Code!

Так на работу прототипа можно посмотреть на примере проекта kube-bench (CIS benchmark) в этом репе.

А еще подробнее можно узнать из документа "Kubernetes Policy Management Whitepaper Proposal" (находится еще в работе).

P.S. Далее мы рассмотрим какое сильное влияние это должно оказать на весь процесс работы с Kubernetes ;)

В продолжении темы о необходимости регулярного аудита конфигурации AWS IAM, рассмотрим еще один инструмент - Red-Shadow. Данная утилита позволяет проверить конфигурацию политик IAM на предмет несоответствия привилегий относительно групп и конкретных users/roles, с целью поиска Shadow Admins.
Другими словами, представим что IAM политиками группы строго запрещено взаимодействие, например директива
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::13371337:group/k8s-admins"
запрещает любое взаимодействия для этой группы, но данный запрет не распространяется на конкретных пользователей/роли. Данная ошибка конфигурации может повлечь существование Shadow Admins, по аналогии с мисконфигами Active Directory, это позволяет атакующему без особого труда повысить привилегии.

В этом примере политика должна запрещать любое действие IAM, выполняемое пользователями, группами или ролями, к которым эта политика привязана, с помощью, например condition policy iam:ResourceTag.