Положняк по AWS

D2

D2

Администратор
Регистрация
19 Фев 2025
Сообщения
4,380
Реакции
0
Автор qwerty1337
Статья написана для Конкурса статей #10


qwety.png



Эта статья призвана быть стартовым гайдом для новичков в пентесте aws и призывом к диалогу для седых мужчин . По сути, все нижеизложенное является common knowledge для понимающих , но я видел очень мало материала по теме на русском языке, и это хочется исправить и создать цикл статей, если эта зайдет . Спрашивается, зачем если есть документация? Вопрос правильный , поэтому мы рассмотрим реальный пример похека облочной инфры с которым я столкнулся совсем недавно . Я не буду переписывать документацию и выдавать это за статью , а постараюсь описать pentest flow на манер адшных майдмап. Важно понимать, что после получения ключей, пентест может закончится не начавшись , это не привычный нам AD , тут много случаев где мы, как тред актор можем сделать +- нихуя и это нормально. На самом деле, работа с ключами это не совсем пентест , а скорее аудит привилегий и тупых проебов кодеров, и девопсов (хотя
, это же и есть пентест???). С предисловием поконченно, начинаем с init access.

Initial access

Главный вопрос у каждого похекера , где размутить доступы (в нашем случае ключи доступа)?
Тут на самом деле все тривиально, и ничего нового тут вряд ли можно придумать, все сводится к человеческой ошибке (хардкод ключей в коде в паблик репе, забытый дебагер, .git , открыте бакеты со скриптами и т.д ). Каждый сам для себя должен разработать тактику добычи материала .Надо понимать только, что есть постоянные и временные ключи. Временные начинаются с "ASIA" и помимо ключа доступа, и секретного ключа, к ним обязательно прилагается токен. Постоянные начинаются с "AKIA" , так что грепайте Шура , они золотые.

API , CLI , регионы и тулы

Я не буду рассказывать как установить cli и как попадать ложкой в рот , кто умеет читать, тот должен справится. Скажу только, что aws разбит на регионы и большенство сервисов не являются кросcрегиональными. Это значит, что если вы размутите ключи и выставите в cli неверный регион в листинге, вы ничего не увидите. Для таких ситуаций есть инструмент pacu.PACU можно запулить сразу как докер образ , все ровно докер нам еще понадобится при работе с ECR. Вообще, по поводу pacu мне особо нечего сказать, он может ускорить enum, но мне привычнее делать все руками (кроме тупого перебора регионов). Для автоматизации работы с апи использовать питонячую либу boto3 и воять все самому. Так же есть aws-enumerator , это шумно и не особо информативно, но для начала поможет понять, какие сервисы вообще есть и зачем они нужны .Есть еще много гуевых тулов для aws'а, но это все для петухов и вайтхетов, т.к все знают, что тру 1337 black hat thread actor пишет на асме, причем все и всегда, и хлеб в ларьке берет за монеро. Если серьезно, то тулы реально очень много шумят, т.к по сути брутфорсят листинги всего, что можно на всех сервисах и GuardDuty (местный филиал SOCа) быстро словит знакомую сигнатуру последовательности api вызовов, даст пизды и ревокнет ключи. GuardDuty может быть и не настроен и админу будет похуй ,ему столько обычно не платят,и чтобы он девопсил днем, а ночью охраником в SOC подрабатывал. Так же не используйте cli на kali и прочих осях для похека. Это очередной средний детект.
# Главные сервисы и терминалогия

Этот хедер тезисно опишет главные понятия в контексте aws'а, некоторые привычные понятия попросту преименновыны, например ec2 instance == vps. Далее я буду пользоваться офицальной терминологией aws или использовать сокращения. Я опишу далеко не все ,а только то, что надо точно нам и пригодится в разборах инфры.

Ec2 - один из самых главных сервисов в клаудовой инфре , позволяет менеджить инстансы, на которых уже в свою очередь может крутиться что угодно
EKS - кубы (k8s) в облаке , ничего особенного кроме привязки системы кубов к юзерам aws, но об этом позже
S3 - бакеты , по сути просто файловая система для хранения чего угодно
ECR - система хранения докер образов
VPC - virtual private cloud , по сути просто сетка , по дефолту /16 , обычно такой и остается и никто не ебет себе голову сегментацией , но может быть настроена как угодно душе админа.
IAM - сервис, который позволяет контролировать кто (какие пользователи или системы) может выполнять какие действия с какими ресурсами в AWS.
Ключевые концепции IAM:

  • Пользователи (Users): Учетные записи для людей или приложений, которым нужен доступ к AWS.
  • Группы (Groups): Наборы пользователей с общими правами доступа.
  • Роли (Roles): Используются для временного доступа к ресурсам. Например, EC2-инстанс может получить доступ к S3 через роль.
  • Политики (Policies): JSON-документы, описывающие права доступа.
  • Principal: Объект, который запрашивает доступ (например, пользователь, роль или сервис).
IAM вообще самая важная концепция вокруг которой и рабтают все остальные сервисы , поэтому нам важно понимать, какие политики относятся к нашему юзеру напрямую или косвенно. По сути, все похеки происходят из-за ошибок настройки политик доступа IAM (и проебанных ключей конечно). Все , перестаю грузить духотой , настало время примеров .
# Prod

Начнем с легкого случая , где по сути похека не потребуется (если работу с aws'ом вообще можно назвать похеком). Мы добыли ключи , поставили aws cli , указали верный регион (все это за кадром) . Что дальше? Мы помним, что автоматические тулы для петухов ~~или вайтхетов~~, поэтому никаких скаутсьютов и энумераторов. Постараемся понять кто мы вообще по жизни при помощи дефолтного cli.

aws sts get-caller-identity //whoami местного разлива
output:
Код: Скопировать в буфер обмена
Код: 
{
    "UserId": "AIDADMMYNJJU3EUS7ZHF6",
    "Account": "09513371337",
    "Arn": "arn:aws:iam::095313371337:user/boris.elcin"
}
Первый шаг сделан , у нас тепеть есть ARN и юзернейм . Arn это универсальный айдишник который есть +- у всех объектов в AWS, он нам еще не раз пригодиться. Теперь надо проверить политики, которые относятся напрсямую к нашему юзеру.

Command:

aws iam list-attached-user-policies --user-name boris.elcin

output:

Код: Скопировать в буфер обмена
Код: 
{
    "AttachedPolicies": [
        {
            "PolicyName": "AmazonS3FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3FullAccess"
        }
    ]
}

Уже неплохо, у нас есть полный доступ к бакетам, это очевидно из названия. Вообще есть дефолтные и кастомные политики, конкретно эта политика дефолтная и легко гуглится https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FullAccess.html .
Политики описываются в json policy document , для AmazonS3FullAccess он выглядит вот так:
Код: Скопировать в буфер обмена
Код: 
[CODE]{
  "Version" : "2012-10-17",
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "s3:*",
        "s3-object-lambda:*"
      ],
      "Resource" : "*"
    }
  ]
}

Я думаю, тут все интуитивно понятно . Вместо гугла можно в cli дернуть эту последовательность комманд что бы получить этот документ (более актуально для кастомных политик):

1. aws iam get-policy --policy-arn <arn> // to get version of policy
2. aws iam get-policy-version --policy-arn <arn> --version-id <policy-version> // to get policy json


Всегда стоит проверять бакеты на предмет бекапов и логов Cloudtrail (что-то типо журнала ивентов в винде), если у нас есть доступ к s3. Так же на бакетах можно найти скрипты с хардкод кредами, что может привести к компрометации хостов на внешнем периметре. Залистим бакеты `aws s3 ls`
output:
Код: Скопировать в буфер обмена
Код: 
2024-11-16 02:26:03 app.infra
2024-11-08 22:08:49 app.test
2024-11-12 02:38:03 aws-cloudtrail-logs-133713371337-13371337
Понятно, что тут настроенны логи. Это значит, что каждый наш шаг будет виден админу (при усовии, что он будет туда смотреть). Идея подтереть за собой логи- хорошая , но надо быть осторожным , .к на удаление логов может быть настроенна двухфакторка. Но это совсем другая история.

Юзер так же может состоять в группах. Проверить в каких можно этой коммандой:

`aws iam list-groups-for-user --user-name boris.elcin

output:

Код: Скопировать в буфер обмена
Код: 
{
    "Groups": [
        {
            "Path": "/",
            "GroupName": "FullAccess",
            "GroupId": "AGPARMMKNJJU3UYBADOHD",
            "Arn": "arn:aws:iam::133713371337:group/FullAccess",
            "CreateDate": "2018-06-07T01:21:26Z"
        }
    ]
}


We happy Vincent?

`aws iam list-attached-group-policies --group-name FullAccess`

Oh yea ,we happy! :

Код: Скопировать в буфер обмена
Код: 
{
    "AttachedPolicies": [
        {
            "PolicyName": "AdministratorAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
        }
    ]
}

Проверим, что же мы имеем из инстансов:
`aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" --query "Reservations[].Instances[?NetworkInterfaces[].Association.PublicIp!=null].[InstanceId, Tags[?Key=='Name'].Value | [0]]" --output table`

output (not full):

[/CODE]
-----------------------------------------------------------------------------
| DescribeInstances |
+----------------------+----------------------------------------------------+
| i-053cc558feda06f27 | app billing |
| i-00a09cd16ab7d381c | v2-collector |
| i-0bce944c32768ef35 | v2-shareurl-web |
| i-0c1d6edf320a075e8 | RabbitMQ |
| i-0bc7616ef101ad7be | app-reserve-consumer |
| i-025f6d50b5f652024 | v2-reverse-proxy |
| i-0dde86b3cc4cd4842 | v2-cli |
| i-0decad5df497eff1a | v2-registar-new |
| i-07d00c53c43519a7e | v2-redis-cache-server |
| i-0ba39153388f78ee3 | v2-payment |

```

Это, явно, прод во всей красе :) Что по кубам?

aws eks list-clusters
output:
Код: Скопировать в буфер обмена
Код: 
{
    "clusters": [
        "prd"
    ]
}

Опять прод? Хм, видимо на кубах рабоатет старая версия приложения (исходя из тегов ec2 инстансов). Забратся в кластер и потыкать в него палкой можно так:
1) aws eks update-kubeconfig --name prd-eks //создаст конфиг для подключения к kubeapi в хомяке
2) kubectl get pods --all-namespaces

Но при попытке залистить поды, мы получаем :

`error: You must be logged in to the server (Unauthorized)
`
Доступ к кубовым кластерам это крайне ебнутая штука. Доступ к eks кластеру в aws, по дефолту, имеет только создатель кластера, как-то понять (нормальными способами) кто является создателем тоже нельзя. При этом, может случиться ситуация потери доступа к своему же кластеру, при удалении юзера, который создал кластер. Поэтому, если попадете в ситуацию, когда вы aws админ, но kubeapi не пускает вас, придется выпускать дополнительные ключи для каждого юзера для доступа к кластеру. К счастью, с помощью команды aws eks describe-cluster --name <cluster-name> можно понять, когда кластер был создан и сузить круг поисков . Иногда еще одним косвенным признаком может послужить политики и группы, отсылающие так или иначе к кубам, но раз на раз не приходится. Так же можно найти запись о создании кластера в логах Cloudtrail, но по дефолту они хранятся, вроде, 3 месяца. Поэтому, этот способ тоже работает далеко не всегда. Административый доступ дает нам возможность выпускать дополнительные ключи доступа каждому юзеру. По итогу, перебрав половину пользаков, я нашел создателя, и кубы поддались и пустили меня внутрь.
Вообще, есть человеческий способ через sts, но он менее понятен с первого взгляда и описан тут.
Кусочек листинга :
Код: Скопировать в буфер обмена
Код: 
kube-system   kube-proxy-1337                                         1/1     Running   0              108d
kube-system   kube-proxy-1337                                         1/1     Running   0              37d
kube-system   metrics-server-1337133797-1337                          1/1     Running   0              108d
prometheus    alertmanager-prometheus-kube-prometheus-alertmanager-0   2/2     Running   0              108d
prometheus    prometheus-grafana-1337133775-13372                      3/3     Running   0              108d

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

На этом моменте, белая шляпа получил бы свои знаменитые 300$ баунти и пошел жаловатся в чатики. Для ровного пацана веселье начинается сейчас, но аудит политик закончен. Теперь время разбиратся в инфре. ~~Повышать энтропию на бэкапах или ставить прослушку на проде для странных цифр за которые деньги почему-то платят~~. Со всем этим не должно возникнуть проблем . Самый полезный сервис для постэксплотации это SSM. По сути, это aws агент, который ставится на ec2 инстансы. Он умеет исполнять команды от рута на тачке, где он стоит. Так же, можно запустить на всех тачках сразу и установить им всем сразу полезный софт :) Чекнуть где есть ssm агент : aws ssm describe-instance-information --query "InstanceInformationList[*].[InstanceId, PingStatus]" --output table
Есть еще вариант с импортом ssh ключей, но, как по мне ,это более палевный метод. Советую использовать --query и не листать огромные простыни json'а . Для более быстрых реквестов и автоматизации, я использую LLM, чтобы не приходилось искать что там куда вложенно.

Для быстрого развертывания sql баз данных в aws, используют сервис RDS. Если вам вдруг сдумается слить базу данных, то помните, что они по дефолту шифруются и вам надо будет найти ключ которым пошифрованы базы, чтобы сделать ее экспорт на s3. Ключи хранятся в сервисе KMS и ключ должен быть кастомным (не пренадлежать aws по дефолту). Не сложная вещь, но в первый раз при дампе меня немного смутила.
Конец?

Фух, начало положенно. Надеюсь, кто-нибудь узнал что-то новое и в след. раз вам будет легче при работе с AWS. В этот раз до повышений привилегий как-то не дошло (кроме eks) , но это явление не частое в облаках, да и еще не вечер, верно? Это моя первая статья, так что судите строго, кидайтесь говном, хвалите. Главное дайте фидбек и тогда я еще напишу о своих облачных похождениях. В качестве затравки, могу сказать, что ecr:* может привести к пиздатой суплай чейн атаке :) А пока снимаю шляпу и удачной охоты.
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу