Как и обещал, начинаем разбирать различные полезные материалы. В первую очередь хочется порекомендовать отличное (на мой взгляд) выступление https://www.youtube.com/watch?v=vV7xN2JQNOU , спикер разбирает базовые принципы AWS и даже проводит некую параллель между AWS и AD, после чего переходит к рассказу о инструментах и разных техниках. Чем-то схоже с тем что расказывал я на WV, но у этого спикера есть запись выступления в хорошем качестве) Так что это отличный способ начать приобщаться к AWS Security, если вы упустили моё выступление на Zeronights WV 2019.

Тем временем Amazon анонсировал крайне любопытную новость. Ребята планируют выкатить вторую версию метадата API (IMDSv2). Занятно, что в отличии от других облачных решений амазон предлагает не просто добавлять статичный заголовок, а целую схему с получением динамического токена с помощью метода PUT и внедрением его в каждый последующий запрос через заголовки. Это серьёзно усложнит жизнь злоумышленникам пытающимся эксплуатировать SSRF до метадата API. Фишка с блокировкой запросов содержащих X-Forwarded-For заголовок, кстати, тоже на месте, это не позволит эксплуатировать излишне широко сконфигурированные прокси. Но и это ещё не всё, теперь ответы от метадате API содержащие токен будут снабжаться TTL равным 1, что не позволит получать их через обходные пути типа NAT или VPN туннелей, впрочем, я пока не до конца понимаю как это будет работать. Такое вообще есть у кого из конкурентов?
Одна беда, старая версию метадата API (IMDSv1) всё ещё на месте и будет доступна по умолчанию ещё долгое время (а что вы хотели, обратную совместимость для клиентов надо же обеспечивать), так что багхантерам пока не стоит хвататься за сердце, все старые трюки продолжают работать на IMDSv1. Подробнее про новую версию API: https://aws.amazon.com/ru/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

Тут недавно появился новый интересный инструмент для визуализации и анализа прав и связей внутри вашей AWS инфраструктуры. Инструмент сделан ребятами подарившими миру dref, drozer, needle и ещё пару стоящих инструментов. (Вы могли слышать о них как о MWR labs, но теперь они в крепких руках F-secure и зовут себя F-secure labs 😄)

Для работы как обычно нужны политики SecurityAudit + ReadOnlyAccess.

Сам инcтрумент: https://github.com/fsecurelabs/awspx
Пост о нём в блоге: https://labs.f-secure.com/blog/awspx/

P.S. А ещё у них крутое лого с воронами

Поскольку канал у нас в целом о безопасности облачных решений, а не только AWS (как может показаться, судя по постам) хочется разбавить контент другой технологией. Посмотрим в сторону Azure, а если быть точнее Azure AD. Не стоит путать его с привычным Active Directory. С ним у Azure AD куда меньше связи, чем может показаться на первый взгляд. В общем, что это я, вот ссылка на оригинальный доклад с Def Con 27, где подробно рассматривается тема Azure AD.

https://www.youtube.com/watch?v=xei8lAPitX8&list=PL9fPq3eQfaaA4qJEQQyXDYtTIfxCNA0wB

Всё больше разных фреймворков для постэкплуатации AWS появляется на свет. Вот, например, на Black Hat Europe 2019 релизнулся ещё один инструмент. Прикольной "фичей" которого, можно считать автоматизацию развёртки метасплоит/эмпире пейлоадов на EC2 инстансах и обещание доделать полную интеграции с ними. Впрочем, имхо выглядит скорее, как yet another tool, но дело вкуса.

Сам инструмент: https://github.com/Voulnet/barq
Немного больше слов тут: https://portswigger.net/daily-swig/barq-post-exploitation-framework-plays-havoc-with-aws-infrastructure

Крайне интересный, на мой вгляд, сценарий пост-эксплуатации в Azure описали ребята из NETSPI. Оказывается для работы Azure Cloud Shell используются образы монтируемых файловых систем хранящиеся в общем на весь аккаунт Azure Storage, таким образом, скомпрометированный пользователь Bob, может поправить/почитать чужой образ ФС пользователя Alice выудив оттуда секреты или дописав команды в автозапуск. Они сработают на старте следующей shell сессии Alice. Ну, я так понял)

Оригинальная статья со всеми деталями: https://blog.netspi.com/attacking-azure-cloud-shell/

Отдельно стоит обратить внимание, на упоминаемый в статье из прошлого поста репозиторий с набором powershell скриптов для анализа и эксплуатации уязвимостей в Azure. Репозиторий так же содержит ссылки на статьи и презентации посвещённые анализу защишености инфраструктуры Azure.

Ссылка на репозиторий: https://github.com/NetSPI/MicroBurst

Ничего на свете лучше нету, чем позалипать на пушистый граф после новогодних праздников. Именно по этому вашему вниманию представляется еще один инструмент в области визуализации IAM - AAIA. Лучше ли он чем  lyft/cartography?  Нунинаю...

Ссылка на репозиторий: https://github.com/rams3sh/Aaia

В твиттере постят и я запощу. Интересный инструмент для автоматизированной работы с возникающими алертами в AWS. При возникновении алерта автоматически собираются данные по причинам его тригера, генерируется отчет и даже может высылаться в ваш любимый Slack, PageDuty, Github Enterprise. Имхо, звучит интересно, слава богу в этот раз не пришлось постить еще обертку над Neo4j )

Ссылка на репозиторий: https://github.com/m-mizutani/AlertResponder

cfn-nag

Инструмент cfn-nag ищет шаблоны в CloudFormation , которые могут указывать на небезапасную инфраструктуру.

Что проверяется:
1) IAM и политики ресурсов (S3 Bucket, SQS и т. д.)
2) Security Group - например, ingress правило открыто для 0.0.0.0/0 , открыт диапазон 1-65535
3) Журналы доступа
Ищет журналы доступа, которые не включены для соответствующих ресурсов (например, Elastic Load Balancers и CloudFront Distributions)
4) Шифрование (на стороне сервера), которое не включено или не применяется для соответствующих ресурсов (например, томов EBS или для вызовов PutObject в корзине S3)

https://github.com/stelligent/cfn_nag

#tools #aws

Интересная история о битве с Docker Registry от господина @sab0tag3d:

Я часто использую словарь уважаемого Бума (https://github.com/Bo0oM/fuzz.txt) для брута веб-директорий и поиска низковисящих багов.

В этот раз во время внешнего пентеста, я нашел директорию https://example.com:5000/v2/_catalog в которой был примерно следующий список:


{"repositories":["centos.6.10","centos_temp","example.com/jenkins","example.com/ubuntu16.04"]}

Выяснив, что это Docker API, я решил копнуть дальше и просмотреть, что этот может быть, и наткнулся на отличную статью https://www.notsosecure.com/anatomy-of-a-hack-docker-registry/
С помощью утилиты, упомянутой в статье, я скачал образ контейнера jenkins.

Внутри разработчики заботливо приложили sh-скрипт, наверное, для удобства:

$ cat start_point.sh
#! /bin/bash -e
mkdir -p /var/jenkins_home/.ssh
mv /usr/share/jenkins/ref/.ssh/id_rsa /var/jenkins_home/.ssh
chmod 600 /var/jenkins_home/.ssh/id_rsa


Я сразу обрадовался, что возможно нашел приватный ключ, и начал пробовать его использовать на всех хостах в сети, но безуспешно.
Но потом до меня дошло, что нужно заглянуть в директорию /usr/share/jenkins/ref/.ssh, (ну кому прийдет в голову класть в эту папку что-то кроме ключей).
Вот примерный список что там нашлось: Дополнительный набор приватных ssh-ключей, а также пароли от ssh к хостам, если вдруг что-то пойдет не так, тестовые пароли: от JIRA, BUGZILLA и кучи сервисов о назначении который я могу только догадываться.

Резюме от автора канала: Мораль этой истории должна быть понятна каждому,  registry и печень надо беречь с молодости.

Hacktory

Когда как не во время самоизоляции стоит рассказать о интересном проекте по онлайн обучению в сфере ИБ. Команда специалистов с хорошей экспертизой в сфере информационной безопасности запускает площадку https://hacktory.ai/

Из интересных моментов - есть полный курс по web-безопасности. Курс бесплатный на месяц (есть ограничения). Есть еще демо курс на Java где нужно править код и он будет проверяться , но он пока не полный и находится в разработке.

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

Cloud Security Wine

Канал cloudsec начался с доклада на Zero Night 2019 про AWS Security. С тех пор многое поменялось, в том числе вектор развития и интересов первоначального автора канала @ttffdd. Однако интересный материал продолжает появляться и, кажется, что он не должен проходить мимо подписчиков.

Чтобы дать новую жизнь каналу, было принято решение, что он станет побратимом DevSecOps Wine и получит новое название CloudSec Wine. Материал про AWS, Azure, GCP Security будет публиковать @dvyakimov на английском языке дабы осветить как можно больше без временных затрат на разбор и перевод.

Let's go on!

🔸AWS Security Hub launches new automated security controls

Seven new automated security controls, which seem to be things you should generally do.

- S3 buckets should require requests to use Secure Socket Layer
- Amazon SageMaker notebook instances should not have direct internet access
- AWS Database Migration Service -replication instances should not be public
- EC2 instances managed by Systems Manager should have an association compliance status of COMPLIANT
- AWS Auto scaling groups associated with a load balancer should use load balancer health checks
- Stopped EC2 instances should be removed after a specified time period
- VPC flow logging should be enabled in all VPCs.

https://aws.amazon.com/ru/about-aws/whats-new/2020/07/aws-security-hub-launches-new-automated-security-controls/

#aws

🔸🔹Сyberark/SkyArk: Detect “shadow admin accounts” in AWS and Azure

Certain (combinations of) seemingly limited cloud permissions can be used by attackers to escalate their privileges. This tool aims to enumerate Azure and AWS accounts with permissions that in reality are quite privileged.

https://github.com/cyberark/SkyArk

#aws #azure

🔸AWS IAM Permissions Guardrails

A collection of SCPs that you can use to protect all accounts under your Organization.

https://aws-samples.github.io/aws-iam-permissions-guardrails/guardrails/scp-guardrails.html

🔸AWS Incident Response

This project explores useful CloudTrail events that support incident response and detection of misconfigurations.

https://github.com/easttimor/aws-incident-response

🔸Amazon Fraud Detector is now Generally Available

“A fully managed service that makes it easy to identify potentially fraudulent online activities such as online payment fraud and the creation of fake accounts.”

https://aws.amazon.com/ru/blogs/aws/amazon-fraud-detector-is-now-generally-available/

#aws

🔹Azure security best practices and patterns

Security best practices to use when designing, deploying, and managing cloud solutions by using Azure.

https://docs.microsoft.com/en-us/azure/security/fundamentals/best-practices-and-patterns

#azure