ISACARuSec – Telegram
ISACARuSec
2.26K subscribers
1.78K photos
13 videos
308 files
5.67K links
Канал направления ИБ Московского отделения ISACA

Направление канала новости ISACA, новости в области управления ИБ в России и мире, обмен лучшими практиками.



Связь с администрацией
@popepiusXIII
Download Telegram
Маппинг ММУ ФСТЭК и MITRE ATTACK.xlsx
54.8 KB
Маппинг техник ФСТЭК в техники MITRE ATT&CK
Forwarded from k8s (in)security (D1g1)
Много шума наделал статья "Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances"

Кратко:
- Используя данную проблему вредоносный пользователь может выйти из своего окружений и попасть в соседние окружения других клиентов облака
- Дело касается Azure Container Instances (ACI) это CaaS/serverless от Microsoft
- У Microsoft реализация ACI есть на Kubernetes и Service Fabric Clusters, проблему удалось проверить только в первом случае
- В реализации на Kubernetes для размещения клиентов использовался node-based multi-tenancy подход
- Azure Kubernetes Service (AKS) мог пострадать только в том случае, если он интегрирован с ACI
- Атака: 1) Побег из контейнера через 1-day уязвимость CVE-2019-5736 в runC 2) получение доступа к privileged Kubernetes service account token 3) выполнение команд на Kubernetes api-server
- На первом шаге использовали контейнер WhoC, который позволяет прочитать и отправить исполняющий его container runtime
- На втором шаге исследователи поняли, что им доступен service account token, который имеет права на pods/exec в любом namespace, включая kube-system
- На третьем шаге исследовали просто получили shell в контейнере Kubernetes api-server - Game Over!
- Также исследователи нашли возможность получить shell в контейнере Kubernetes api-server через SSRF ;)

После прочтения я большое всего в шоке от того что в этой части облака (непонятно как в других) использовался runC 2016 года и Kubernetes от ноября 2017 - октября 2018 ...