#71 Kali Linux для продвинутого тестирования на проникновение. Сканирование уязвимостей и эксплуатация приложений в EC2. Часть 2.
Здравствуйте, дорогие друзья.
Давайте продолжим и определим список экземпляров, доступных для профиля RCE, который мы создали, выполнив в терминале следующую команду:
1 |
sudo aws ec2 describe-instances --profile <Profile Name> |
Это должно предоставить детали экземпляра, как показано на рисунке ниже, с общедоступным и внутренним IP-адресом:
![Detailed IAM section within the Scout report](https://timcore.ru/wp-content/uploads/2023/04/295.png)
В деталях экземпляра (полный вывод не показан на рисунке выше) мы видим, что общедоступный IP-адрес настроен для определенных групп безопасности. Если Вы найдете «RootDeviceType» в выводе вышеуказанной команды, то она будет указывать на «ebs», что означает, что IP-адрес не общедоступен.
Следующий шаг — выяснить, какие балансировщики нагрузки настроены для этого устройства, запустив sudo aws elbv2 description-load-balancers --profile RCE
в терминале Kali Linux:
1 |
sudo aws elbv2 describe-load-balancers --profile <Profile Name> |
Вывод балансировщиков нагрузки EC2 возвращается с конкретным DNS-именем, как показано на рисунке ниже:
![Extracting elastic load balancer details](https://timcore.ru/wp-content/uploads/2023/04/296.png)
Наконец, теперь мы можем получить доступ к балансировщику нагрузки, как показано на рисунке ниже. Следующим шагом является определение того, что еще доступно:
![Accessing the elastic load balancer public DNS](https://timcore.ru/wp-content/uploads/2023/04/297.png)
Затем мы найдем разрешение нашего профиля в корзине S3, запустив sudo aws s3 ls - профиль RCE
в терминале. Этот профиль имеет доступ только к папке журналов в корзине S3. как показано на рисунке ниже:
![Accessing the S3 buckets with the RCE profile](https://timcore.ru/wp-content/uploads/2023/04/298.png)
Мы исследуем папку журналов, перечислив все каталоги в корзине S3, запустив sudo aws s3 ls s3://<bucket>/pathofthefile --profile --region us-east-1
и скопируем файл, запустив в терминале следующую команду, как показано на рисунке ниже:
1 |
sudo aws s3 cp s3://<bucket>/Path to the file>. --profile <Profile Name> --region us-east-1 |
![Copying the log file from the S3 bucket](https://timcore.ru/wp-content/uploads/2023/04/299.png)
Анализируя файл журнала, мы обнаруживаем, что есть несколько запросов, которые имеют 200 в качестве ответа HTTP сервера, и имеют связанный с ним уникальный HTML, как показано на рисунке ниже:
![Analyzing the log file and identifying the URI](https://timcore.ru/wp-content/uploads/2023/04/300.png)
Наконец, доступ к URL-адресу приводит нас к отправке формы, которая уязвима для выполнения удаленного кода, благодаря чему тестировщики теперь смогут запускать команды на сервере:
![Successfully executing the command on the server](https://timcore.ru/wp-content/uploads/2023/04/301.png)
Теперь мы воспользовались удаленным выполнением кода в веб-приложении, используя существующие разрешения на просмотр экземпляров, конфигурации балансировщика нагрузки и файлов, которые были доступны из корзины S3. Давайте попробуем другой профиль (mcduck), чтобы понять, как мы можем дальше взять на себя работающий инстанс EC2 на территории AWS. Чтобы просмотреть сведения об экземпляре, тестировщики могут запустить sudo aws ec2 description-instances --profile mcduck --region us-east-1
, как показано на рисунке ниже:
![Identifying instances using the mcduck profile](https://timcore.ru/wp-content/uploads/2023/04/302.png)
На этом все. Всем хорошего дня!
Полный цикл статей по Kali Linux для продвинутого тестирования на проникновение.