Вступление
Мы в Rhino Security Labs недавно выпустили следующее поколение нашего инструмента AWS, CloudGoat . Одним из самых больших изменений в этой новой версии является введение сценариев. В рамках нашей постоянной поддержки CloudGoat мы будем публиковать официальные пошаговые руководства по каждому сценарию, объясняя шаги по разведке и эксплуатации, необходимые для их завершения.
В этом первом официальном пошаговом руководстве рассматривается сценарий «rce_web_app» с использованием путей атаки «Lara» и «McDuck». Давайте начнем!
Начальная настройка
Следующее должно быть установлено перед продолжением этого пошагового руководства.
● Linux или MacOS. Windows официально не поддерживается.
○ Для завершения аргумента табуляции требуется bash 4.2+ (Linux или OSX с некоторыми трудностями).
● Python3.6.
● Terraform 0.12 установлен и находится в вашем $ PATH .
● CLI AWS установлен и находится в вашем $ PATH , и в учетной записи AWS с достаточными привилегиями для создания и уничтожения ресурсов.
Установка CloudGoat
CloudGoat можно найти здесь, на нашем Github. Чтобы установить его, вам нужно будет выполнить следующие команды.
Создание пользователя IAM
Убедитесь, что вы следуете рекомендациям и используете пользователя IAM для настройки CloudGoat. Не развертывайте CloudGoat из под root (root keys).
Вам нужно будет перейти в раздел IAM консоли AWS и выбрать «Пользователи» в левом меню, затем выбрать «Добавить пользователя». На следующем экране введите имя пользователя для учетной записи и предоставьте учетной записи программный доступ, который сгенерирует ключи для пользователя. Мы будем использовать эти ключи для настройки профиля в интерфейсе командной строки AWS.
Следующим шагом является присоединение существующей политики непосредственно к новому пользователю. Выберите «прикрепить существующие политики напрямую» из трех приведенных вариантов. Появится список политик - CloudGoat требует административного доступа, поэтому выберите политику «AdministrativeAccess», которая находится вверху списка. Нажмите на раздел «Теги», так как мы не будем использовать его в этом пошаговом руководстве. Проверьте информацию, чтобы убедиться, что она правильная, затем нажмите последнюю кнопку «Создать пользователя». Появится сообщение «Success», и будут показаны ваши ключи AWS. Это единственный раз, когда вы можете получить ключ доступа AWS и секретный ключ AWS, поэтому важно сохранить их. Если они потеряны, вам нужно будет сгенерировать новый набор ключей.
Настройте интерфейс командной строки AWS для использования только что созданных ключей, выполнив приведенную ниже команду и следуя подсказкам.
Затем нам нужно настроить белый список IP-адресов, чтобы никто другой не мог получить доступ к преднамеренно уязвимой среде. Запустите следующую команду и выберите «Да» при появлении запроса.
Настройка сценария веб-приложения
Последний шаг в настройке сценария - запустить команду «create» с настроенным нами профилем CLI AWS и указать, какой сценарий мы создаем. Хотя в одной учетной записи AWS можно создать несколько сценариев, команды создания должны выполняться отдельно. Выполните следующую команду, чтобы создать сценарий CloudGoat «rce_web_app».
Путь атаки Lara
В этом сценарии есть два пути атаки: «Lara» и «McDuck». Два пути начинаются в разных местах, но сходятся в определенной точке. Мы начнем с пути Lara, но здесь вы можете пропустить путь «McDuck» .
Настройка пути атаки Lara
Когда сборка завершится, появится некоторая информация, с которой можно начать. Для сценария «rce_web_app» вам предоставляется два набора ключей. Создайте профили AWS CLI для данных ключей, используя приведенную ниже команду.
Обнаружение уязвимого веб-приложения
Первым шагом в любом пентесте является выяснение того, к чему у нас уже есть доступ - обычно путем подтверждения разрешений. К сожалению, Лара не авторизована для выполнения многих вызовов, обычно используемых для подтверждения разрешений. Из-за этого нам придется вручную осмотреться, чтобы найти то, к чему у нее есть доступ.
Поиск экземпляров EC2
Мы решили начать с выяснения, к каким экземплярам EC2 имеет доступ Лара, выполнив следующую команду.
Выходные данные этой команды показывают, что Lara имеет доступ к экземпляру EC2 с открытым IP. Однако, когда мы пытаемся перейти к IP-адресу в браузере, мы получаем тайм-аут. Мы можем сделать вывод, что стоить взглянуть глубже, но сейчас мы продолжим осматриваться.
Нахождение балансировщиков нагрузки
Далее мы рассмотрим любые балансировщики нагрузки, к которым мы можем иметь доступ, выполнив следующую команду.
Мы видим общедоступный балансировщик нагрузки в выходных данных этой команды. Когда мы пытаемся перейти к нему в браузере, нас приветствует сообщение от «Gold-Star Executive Interstellar Travel Rewards», которое ссылается на «секретный» URL. Изображение ниже показывает эту страницу.
Обнаружение и перечисление S3 Buckets
Поскольку пока мы ничего не можем сделать с этим веб-приложением, перечисление сегментов S3 является хорошим шагом. Выполнение следующей команды показывает нам сегменты, которые мы можем перечислить.
Вывод этой команды показывает нам, что Lara может перечислить 3 сегмента, как показано ниже.
Запустив следующую команду, мы сможем определить, какие сегменты мы можем перечислить, и каково их содержимое.
Мы получили сообщение «Отказано в доступе» при запуске этой команды для двух блоков, но мы смогли получить список содержимого одного блока. Похоже, что эта корзина содержит журналы для балансировщика нагрузки, который мы обнаружили ранее, его мы можем загрузить, чтобы проверить полезную информацию. Выполните следующую команду, чтобы загрузить файл журнала в рабочий каталог.
Открыв загруженный файл в текстовом редакторе, мы видим, что ищем файл журнала для балансировщика нагрузки, хотя идентификатор экземпляра отличается от балансировщика нагрузки, к которому у нас есть доступ. Проверка файла на полезную информацию приводит к появлению записи в журнале, которая показывает HTML-страницу, присутствующую в домене. На рисунке ниже показана запись журнала для HTML-страницы, которая может быть полезна.
Переход к точному URL-адресу в журнале ничего не дает - страница не загружается. Если вернуться к веб-странице программы Gold-Star Executive Interstellar Travel Rewards, которую мы обнаружили ранее, возможно, это часть «секретного» URL. Когда мы добавляем обнаруженную HTML-страницу к DNSName или общедоступному IP-адресу балансировщика нагрузки, который мы нашли ранее, мы видим следующую веб-страницу, которая выглядит как отличный кандидат для попытки введения команд.
Использование веб-приложения
Найдя веб-приложение, мы пробуем несколько команд и обнаруживаем, что оно уязвимо для удаленного выполнения команд
Затем мы можем запустить следующую команду, чтобы увидеть, кто является текущим пользователем.
К нашему восхищению (или ужасу), выполнение команды whoami показывает, что веб-приложение выполняется от имени пользователя root, поэтому каждая команда, которую мы запускаем через RCE, также запускается от имени пользователя root.
Используя следующую команду, мы можем увидеть общедоступный IP-адрес экземпляра, на котором запущено приложение.
Возвращаемый IP-адрес - это тот же IP, что и экземпляр EC2, который мы нашли ранее. Чтобы снова взглянуть на этот экземпляр, мы запускаем следующую команду.
Ниже показана запись «SecurityGroups» для экземпляра, показывающая, что он является членом группы «cg-ec2-ssh-cgid <uniqueID>». Это говорит нам о том, что доступ по SSH, скорее всего, включен.
Добавление открытого ключа SSH
Далее, мы хотим посмотреть, что произойдет, если мы просто добавим наш SSH-сертификат в файл авторизованные ключи. Для этого сначала нужно сгенерировать несколько ключей SSH. Выполнение следующей команды на вашем локальном компьютере сгенерирует открытые и закрытые ключи SSH.
Попытка SSH зайти в качестве пользователя root просто отображает сообщение, предлагающее использовать пользователя ubuntu. Итак, мы откроем public ключ, который мы только что сгенерировали, в файлом author_keys пользователя ubuntu, выполнив следующую команду через RCE.
На этом этапе мы кратко сместим фокус, чтобы охватить другой путь атаки в этом сценарии, McDuck. Lara и MsDuck начинаются в разных местах, но их пути сходятся в определенной точке, которую вы можете пропустить здесь .
McDuck Attack Path
Настройка пути атаки McDuck
В этом пошаговом руководстве будут использованы ключи McDuck, которые были сгенерированы при развертывании сценария. Выполните приведенную ниже команду и следуйте инструкциям, чтобы настроить профиль McDuck в интерфейсе командной строки AWS.
Обнаружение ключей SSH
Мы всегда хотим начать пентест, увидев, к чему у нас есть доступ. На пути атаки Lara было несколько корзин S3, которые оказались полезными, так что это, кажется, хорошим местом для начала.Следующая команда перечисляет сегменты S3, доступные для McDuck.
Как и в случае с Lara, мы можем перечислить 3 сегмента, но когда мы пытаемся просмотреть содержимое блоков «cg-logs» и «cg-secret», мы получаем сообщение «Отказано в доступе». Выполнение следующей команды выведет список содержимого корзины «cg-keystore».
На изображении ниже показан вывод предыдущей команды, показывающий, что является ключами SSH в корзине «cg-keystore».
Следующий шаг - загрузить эти файлы и посмотреть, что еще мы можем найти. Выполните следующие команды на локальном компьютере, чтобы создать каталог для файлов cloudgoat и cloudgoat.pub и загрузить их для последующего использования.
Теперь, когда мы посмотрели на S3, мы должны взглянуть на EC2. Запустите следующую команду, чтобы увидеть, есть ли экземпляры EC2, которые McDuck может перечислить.
Мы видим, что можем перечислить один экземпляр EC2, который имеет общедоступный IP-адрес и является членом группы, которая указывает, что доступ по SSH может быть возможен. На рисунке ниже показан раздел «Группы» экземпляра с записью для «cg-ec2-ssh-cgid <uniqueID>».
Финальная атака
Как указывалось ранее, пути атак Lara и McDuck сливаются здесь. Поэтому, используя либо закрытый ключ SSH, сгенерированный вами как Lara, либо закрытый ключ SSH, обнаруженный McDuck, попытайтесь подключиться к общедоступному IP-адресу экземпляров через SSH, передав файл личного ключа.
Использование экземпляра EC2
Теперь у нас есть удаленный root-доступ к экземпляру EC2. Немного осмотрев машину, я не вижу особого интереса на этом уровне. Следующим шагом было бы посмотреть, какой доступ имеет экземпляр EC2. Для этого нам нужно установить CLI AWS на экземпляр EC2, а затем повторить перечисление, которое мы делали ранее. Выполните следующую команду, чтобы установить интерфейс командной строки AWS.
В этом случае нам не нужно настраивать профиль, поскольку интерфейс командной строки AWS будет автоматически использовать ключи, предоставляемые службой метаданных EC2. Выполнение следующей команды покажет, к каким контейнерам может обращаться экземпляр EC2.
Мы видим те же сегменты, что и раньше, но на этот раз мы можем получить доступ к сегменту «cg-secret-s3». Выполните следующую команду, чтобы увидеть, что содержит корзина.
Скопируйте обнаруженный файл в рабочий каталог на экземпляре EC2 и проверьте его содержимое, выполнив следующую команду.
Это выводит учетные данные базы данных. Дааа! Следующий шаг - найти, где их использовать. Чтобы узнать, запущены ли у нас экземпляры БД, мы можем выполнить следующую команду.
Вывод этой команды изображен ниже.
Подключение к базе данных
После подтверждения местоположения базы данных RDS (которая, как оказалось, имеет то же имя MasterUser и DBName, что и наши обнаруженные учетные данные), мы пытаемся подключиться к базе данных. Выполнив следующую команду, чтобы сделать это:
Примечание: существует альтернативный путь для обнаружения экземпляра RDS. Простое использование curl для чтения user_data из метаданных экземпляра покажет местоположение экземпляра RDS и учетных данных.
Теперь, когда мы подключились к базе данных, последний шаг - перечислить таблицы и обнаружить флаг. Выполнение следующих команд в psql при подключении к экземпляру RDS выведет список таблиц, отобразит флаг и завершит этот сценарий.
«Super-secret-passcode» - это ваш флаг, как показано ниже. Поздравляем, вы завершили сценарий rce_web_app! Это был не простой сценарий, но мы это сделали.
Заключение
Это пошаговое руководство продемонстрировало пути атаки Lara и McDuck для сценария «rce_web_app». В обоих случаях рекурсивная разведка или пересмотр ваших разрешений и среды при достижении нового уровня доступа позволили получить полезную информацию, которая в конечном итоге привела к открытию флага. Злоумышленники, следуя пути Lara, использовали навыки тестирования веб-приложений, чтобы добавить себя в файл SSH «authorized_keys». После подключения к экземпляру EC2 злоумышленники повторно оценили разрешения для обнаружения новой информации в ранее недоступном сегменте S3 или запросили службу метаданных EC2 для обнаружения экземпляра RDS. Наконец, злоумышленники подключились к экземпляру RDS и обнаружили флаг.
Цель этих сообщений в блоге - продемонстрировать, как работает CloudGoat и как он может помочь пентестерам узнать о неправильно настроенных средах AWS. Мы также надеемся, что это поможет инженерам по безопасности AWS и разработчикам «синих» выявить некоторые распространенные ошибки конфигурации и помочь в создании защиты от них в производственных средах.
Мы будем выпускать официальные пошаговые руководства по всем сценариям CloudGoat, так что следите за обновлениями!
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://rhinosecuritylabs.com/aws/cloudgoat-walkthrough-rce_web_app/
Мы в Rhino Security Labs недавно выпустили следующее поколение нашего инструмента AWS, CloudGoat . Одним из самых больших изменений в этой новой версии является введение сценариев. В рамках нашей постоянной поддержки CloudGoat мы будем публиковать официальные пошаговые руководства по каждому сценарию, объясняя шаги по разведке и эксплуатации, необходимые для их завершения.
В этом первом официальном пошаговом руководстве рассматривается сценарий «rce_web_app» с использованием путей атаки «Lara» и «McDuck». Давайте начнем!
Начальная настройка
Следующее должно быть установлено перед продолжением этого пошагового руководства.
● Linux или MacOS. Windows официально не поддерживается.
○ Для завершения аргумента табуляции требуется bash 4.2+ (Linux или OSX с некоторыми трудностями).
● Python3.6.
● Terraform 0.12 установлен и находится в вашем $ PATH .
● CLI AWS установлен и находится в вашем $ PATH , и в учетной записи AWS с достаточными привилегиями для создания и уничтожения ресурсов.
Установка CloudGoat
CloudGoat можно найти здесь, на нашем Github. Чтобы установить его, вам нужно будет выполнить следующие команды.
Код:
$ git clone git@github.com:RhinoSecurityLabs/cloudgoat.git ./CloudGoat
$ cd CloudGoat
$ pip3 install -r ./core/python/requirements.txtСоздание пользователя IAM
Убедитесь, что вы следуете рекомендациям и используете пользователя IAM для настройки CloudGoat. Не развертывайте CloudGoat из под root (root keys).
Вам нужно будет перейти в раздел IAM консоли AWS и выбрать «Пользователи» в левом меню, затем выбрать «Добавить пользователя». На следующем экране введите имя пользователя для учетной записи и предоставьте учетной записи программный доступ, который сгенерирует ключи для пользователя. Мы будем использовать эти ключи для настройки профиля в интерфейсе командной строки AWS.
Следующим шагом является присоединение существующей политики непосредственно к новому пользователю. Выберите «прикрепить существующие политики напрямую» из трех приведенных вариантов. Появится список политик - CloudGoat требует административного доступа, поэтому выберите политику «AdministrativeAccess», которая находится вверху списка. Нажмите на раздел «Теги», так как мы не будем использовать его в этом пошаговом руководстве. Проверьте информацию, чтобы убедиться, что она правильная, затем нажмите последнюю кнопку «Создать пользователя». Появится сообщение «Success», и будут показаны ваши ключи AWS. Это единственный раз, когда вы можете получить ключ доступа AWS и секретный ключ AWS, поэтому важно сохранить их. Если они потеряны, вам нужно будет сгенерировать новый набор ключей.
Настройте интерфейс командной строки AWS для использования только что созданных ключей, выполнив приведенную ниже команду и следуя подсказкам.
aws configure --profile cloudgoatЗатем нам нужно настроить белый список IP-адресов, чтобы никто другой не мог получить доступ к преднамеренно уязвимой среде. Запустите следующую команду и выберите «Да» при появлении запроса.
./cloudgoat.py config whitelist --autoНастройка сценария веб-приложения
Последний шаг в настройке сценария - запустить команду «create» с настроенным нами профилем CLI AWS и указать, какой сценарий мы создаем. Хотя в одной учетной записи AWS можно создать несколько сценариев, команды создания должны выполняться отдельно. Выполните следующую команду, чтобы создать сценарий CloudGoat «rce_web_app».
./cloudgoat.py create rce_web_app --profile cloudgoatПуть атаки Lara
В этом сценарии есть два пути атаки: «Lara» и «McDuck». Два пути начинаются в разных местах, но сходятся в определенной точке. Мы начнем с пути Lara, но здесь вы можете пропустить путь «McDuck» .
Настройка пути атаки Lara
Когда сборка завершится, появится некоторая информация, с которой можно начать. Для сценария «rce_web_app» вам предоставляется два набора ключей. Создайте профили AWS CLI для данных ключей, используя приведенную ниже команду.
aws configure --profile LaraОбнаружение уязвимого веб-приложения
Первым шагом в любом пентесте является выяснение того, к чему у нас уже есть доступ - обычно путем подтверждения разрешений. К сожалению, Лара не авторизована для выполнения многих вызовов, обычно используемых для подтверждения разрешений. Из-за этого нам придется вручную осмотреться, чтобы найти то, к чему у нее есть доступ.
Поиск экземпляров EC2
Мы решили начать с выяснения, к каким экземплярам EC2 имеет доступ Лара, выполнив следующую команду.
aws ec2 describe-instances --profile LaraВыходные данные этой команды показывают, что Lara имеет доступ к экземпляру EC2 с открытым IP. Однако, когда мы пытаемся перейти к IP-адресу в браузере, мы получаем тайм-аут. Мы можем сделать вывод, что стоить взглянуть глубже, но сейчас мы продолжим осматриваться.
Нахождение балансировщиков нагрузки
Далее мы рассмотрим любые балансировщики нагрузки, к которым мы можем иметь доступ, выполнив следующую команду.
aws elbv2 describe-load-balancers --profile LaraМы видим общедоступный балансировщик нагрузки в выходных данных этой команды. Когда мы пытаемся перейти к нему в браузере, нас приветствует сообщение от «Gold-Star Executive Interstellar Travel Rewards», которое ссылается на «секретный» URL. Изображение ниже показывает эту страницу.
Обнаружение и перечисление S3 Buckets
Поскольку пока мы ничего не можем сделать с этим веб-приложением, перечисление сегментов S3 является хорошим шагом. Выполнение следующей команды показывает нам сегменты, которые мы можем перечислить.
aws s3 ls --profile LaraВывод этой команды показывает нам, что Lara может перечислить 3 сегмента, как показано ниже.
Запустив следующую команду, мы сможем определить, какие сегменты мы можем перечислить, и каково их содержимое.
aws s3 ls s3://<bucket> --recursive --profile LaraМы получили сообщение «Отказано в доступе» при запуске этой команды для двух блоков, но мы смогли получить список содержимого одного блока. Похоже, что эта корзина содержит журналы для балансировщика нагрузки, который мы обнаружили ранее, его мы можем загрузить, чтобы проверить полезную информацию. Выполните следующую команду, чтобы загрузить файл журнала в рабочий каталог.
Код:
aws s3 cp s3://<bucket>/cg-lb-logs/AWSLogs/793950739751/elasticloadbalancing/us-east-1/2019/06/19/555555555555_elasticloadbalancing_us-east-1_app.cg-lb-cgidp347lhz47g.d36d4f13b73c2fe7_20190618T2140Z_10.10.10.100_5m9btchz.log . --profile LaraОткрыв загруженный файл в текстовом редакторе, мы видим, что ищем файл журнала для балансировщика нагрузки, хотя идентификатор экземпляра отличается от балансировщика нагрузки, к которому у нас есть доступ. Проверка файла на полезную информацию приводит к появлению записи в журнале, которая показывает HTML-страницу, присутствующую в домене. На рисунке ниже показана запись журнала для HTML-страницы, которая может быть полезна.
Переход к точному URL-адресу в журнале ничего не дает - страница не загружается. Если вернуться к веб-странице программы Gold-Star Executive Interstellar Travel Rewards, которую мы обнаружили ранее, возможно, это часть «секретного» URL. Когда мы добавляем обнаруженную HTML-страницу к DNSName или общедоступному IP-адресу балансировщика нагрузки, который мы нашли ранее, мы видим следующую веб-страницу, которая выглядит как отличный кандидат для попытки введения команд.
Использование веб-приложения
Найдя веб-приложение, мы пробуем несколько команд и обнаруживаем, что оно уязвимо для удаленного выполнения команд
Затем мы можем запустить следующую команду, чтобы увидеть, кто является текущим пользователем.whoamiК нашему восхищению (или ужасу), выполнение команды whoami показывает, что веб-приложение выполняется от имени пользователя root, поэтому каждая команда, которую мы запускаем через RCE, также запускается от имени пользователя root.
Используя следующую команду, мы можем увидеть общедоступный IP-адрес экземпляра, на котором запущено приложение.
curl ifconfig.coВозвращаемый IP-адрес - это тот же IP, что и экземпляр EC2, который мы нашли ранее. Чтобы снова взглянуть на этот экземпляр, мы запускаем следующую команду.
aws ec2 describe-instances --profile LaraНиже показана запись «SecurityGroups» для экземпляра, показывающая, что он является членом группы «cg-ec2-ssh-cgid <uniqueID>». Это говорит нам о том, что доступ по SSH, скорее всего, включен.
Добавление открытого ключа SSH
Далее, мы хотим посмотреть, что произойдет, если мы просто добавим наш SSH-сертификат в файл авторизованные ключи. Для этого сначала нужно сгенерировать несколько ключей SSH. Выполнение следующей команды на вашем локальном компьютере сгенерирует открытые и закрытые ключи SSH.
ssh-keygenПопытка SSH зайти в качестве пользователя root просто отображает сообщение, предлагающее использовать пользователя ubuntu. Итак, мы откроем public ключ, который мы только что сгенерировали, в файлом author_keys пользователя ubuntu, выполнив следующую команду через RCE.
echo "<publicKey>" >> /home/ubuntu/.ssh/authorized_keysНа этом этапе мы кратко сместим фокус, чтобы охватить другой путь атаки в этом сценарии, McDuck. Lara и MsDuck начинаются в разных местах, но их пути сходятся в определенной точке, которую вы можете пропустить здесь .
McDuck Attack Path
Настройка пути атаки McDuck
В этом пошаговом руководстве будут использованы ключи McDuck, которые были сгенерированы при развертывании сценария. Выполните приведенную ниже команду и следуйте инструкциям, чтобы настроить профиль McDuck в интерфейсе командной строки AWS.
aws configure --profile McDuckОбнаружение ключей SSH
Мы всегда хотим начать пентест, увидев, к чему у нас есть доступ. На пути атаки Lara было несколько корзин S3, которые оказались полезными, так что это, кажется, хорошим местом для начала.Следующая команда перечисляет сегменты S3, доступные для McDuck.
aws s3 ls --profile McDuckКак и в случае с Lara, мы можем перечислить 3 сегмента, но когда мы пытаемся просмотреть содержимое блоков «cg-logs» и «cg-secret», мы получаем сообщение «Отказано в доступе». Выполнение следующей команды выведет список содержимого корзины «cg-keystore».
aws s3 ls s3://cg-logs-s3-bucket-cgid<uniqueID> --recursive --profile McDuckНа изображении ниже показан вывод предыдущей команды, показывающий, что является ключами SSH в корзине «cg-keystore».
Следующий шаг - загрузить эти файлы и посмотреть, что еще мы можем найти. Выполните следующие команды на локальном компьютере, чтобы создать каталог для файлов cloudgoat и cloudgoat.pub и загрузить их для последующего использования.
Код:
mkdir mcduck && cd mcduck
aws s3 cp s3://cg-keystore-s3-bucket-cgid<uniqueID>/cloudgoat . --profile McDuck
aws s3 cp s3://cg-keystore-s3-bucket-cgid<uniqueID>/cloudgoat.pub . --profile McDuckТеперь, когда мы посмотрели на S3, мы должны взглянуть на EC2. Запустите следующую команду, чтобы увидеть, есть ли экземпляры EC2, которые McDuck может перечислить.
aws ec2 describe-instances --profile McDuckМы видим, что можем перечислить один экземпляр EC2, который имеет общедоступный IP-адрес и является членом группы, которая указывает, что доступ по SSH может быть возможен. На рисунке ниже показан раздел «Группы» экземпляра с записью для «cg-ec2-ssh-cgid <uniqueID>».
Финальная атака
Как указывалось ранее, пути атак Lara и McDuck сливаются здесь. Поэтому, используя либо закрытый ключ SSH, сгенерированный вами как Lara, либо закрытый ключ SSH, обнаруженный McDuck, попытайтесь подключиться к общедоступному IP-адресу экземпляров через SSH, передав файл личного ключа.
ssh -i <private_key> ubuntu @ 107. 22,55 . 92Использование экземпляра EC2
Теперь у нас есть удаленный root-доступ к экземпляру EC2. Немного осмотрев машину, я не вижу особого интереса на этом уровне. Следующим шагом было бы посмотреть, какой доступ имеет экземпляр EC2. Для этого нам нужно установить CLI AWS на экземпляр EC2, а затем повторить перечисление, которое мы делали ранее. Выполните следующую команду, чтобы установить интерфейс командной строки AWS.
sudo apt-get install awscliВ этом случае нам не нужно настраивать профиль, поскольку интерфейс командной строки AWS будет автоматически использовать ключи, предоставляемые службой метаданных EC2. Выполнение следующей команды покажет, к каким контейнерам может обращаться экземпляр EC2.
aws s3 lsМы видим те же сегменты, что и раньше, но на этот раз мы можем получить доступ к сегменту «cg-secret-s3». Выполните следующую команду, чтобы увидеть, что содержит корзина.
aws s3 ls s3: // cg-secret-s3-bucket-cgid <uniqueID> --recursiveСкопируйте обнаруженный файл в рабочий каталог на экземпляре EC2 и проверьте его содержимое, выполнив следующую команду.
aws s3 cp s3: //cg-secret-s3-bucket-cgidzay5e3vg5r/db.txt. | cat db.txtЭто выводит учетные данные базы данных. Дааа! Следующий шаг - найти, где их использовать. Чтобы узнать, запущены ли у нас экземпляры БД, мы можем выполнить следующую команду.
aws rds describe-db-instances --region us-east-1Вывод этой команды изображен ниже.
Подключение к базе данных
После подтверждения местоположения базы данных RDS (которая, как оказалось, имеет то же имя MasterUser и DBName, что и наши обнаруженные учетные данные), мы пытаемся подключиться к базе данных. Выполнив следующую команду, чтобы сделать это:
psql postgresql: // cgadmin: Purplepwny2029 @ <rds-instance>: 5432 / cloudgoatПримечание: существует альтернативный путь для обнаружения экземпляра RDS. Простое использование curl для чтения user_data из метаданных экземпляра покажет местоположение экземпляра RDS и учетных данных.
curl http: //169.254.169.254/latest/user-dataТеперь, когда мы подключились к базе данных, последний шаг - перечислить таблицы и обнаружить флаг. Выполнение следующих команд в psql при подключении к экземпляру RDS выведет список таблиц, отобразит флаг и завершит этот сценарий.
\dtselect * from sensitive_information«Super-secret-passcode» - это ваш флаг, как показано ниже. Поздравляем, вы завершили сценарий rce_web_app! Это был не простой сценарий, но мы это сделали.
Заключение
Это пошаговое руководство продемонстрировало пути атаки Lara и McDuck для сценария «rce_web_app». В обоих случаях рекурсивная разведка или пересмотр ваших разрешений и среды при достижении нового уровня доступа позволили получить полезную информацию, которая в конечном итоге привела к открытию флага. Злоумышленники, следуя пути Lara, использовали навыки тестирования веб-приложений, чтобы добавить себя в файл SSH «authorized_keys». После подключения к экземпляру EC2 злоумышленники повторно оценили разрешения для обнаружения новой информации в ранее недоступном сегменте S3 или запросили службу метаданных EC2 для обнаружения экземпляра RDS. Наконец, злоумышленники подключились к экземпляру RDS и обнаружили флаг.
Цель этих сообщений в блоге - продемонстрировать, как работает CloudGoat и как он может помочь пентестерам узнать о неправильно настроенных средах AWS. Мы также надеемся, что это поможет инженерам по безопасности AWS и разработчикам «синих» выявить некоторые распространенные ошибки конфигурации и помочь в создании защиты от них в производственных средах.
Мы будем выпускать официальные пошаговые руководства по всем сценариям CloudGoat, так что следите за обновлениями!
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://rhinosecuritylabs.com/aws/cloudgoat-walkthrough-rce_web_app/
