Облака под угрозой. Как пентестить инфру в AWS. Часть 1

MichelleVermishelle

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

Сна­чала рас­смот­рим «базу» — перечис­ление и повыше­ние при­виле­гий в IAM и EC2. В даль­нейшем мы научим­ся зак­реплять­ся в этих сер­висах, оку­нем­ся в вол­шебс­тво Lambda и SecretManager, най­дем пароль в S3, выберем­ся из кон­тей­нера, вытащим дан­ные из EBS, RDS и даже проб­росим­ся в дру­гой VPC!

ТЕОРИЯ

Amazon Web Services — облачное решение, пре­дос­тавля­ющее сво­им кли­ентам мно­жес­тво полез­ных сер­висов. Их мож­но раз­делить на три типа.

• IAS (infrastructure as a service) — к этой катего­рии отно­сит­ся толь­ко сер­вис Virtual Private Cloud, который дает воз­можность поль­зовате­лю соз­давать при­ват­ные изо­лиро­ван­ные сети пря­мо в обла­ке.
• PAS (platform as a service) поз­воля­ет арен­довать один вир­туаль­ный сер­вер (инстанс).
• SAS (software as a service) — пре­дос­тавле­ние ПО и услуг.

СЕРВИСЫ

Identity and access management (IAM) — один из осно­вопо­лага­ющих сер­висов облачной инфраструк­туры Amazon. Он поз­воля­ет управлять дос­тупом к ресур­сам AWS. Адми­нис­три­руют поль­зовате­лей, груп­пы, роли и их дос­туп имен­но здесь. Струк­тура это­го сер­виса показа­на на сле­дующей иллюс­тра­ции.

Политика

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

Внут­ри полити­ки — три важ­ных ком­понен­та:

1. Effect — исполь­зует­ся для пре­дос­тавле­ния дос­тупа или отка­за в нем.
2. Action — вклю­чает спи­сок дей­ствий, которые полити­ка раз­реша­ет или зап­реща­ет.
3. Resource — спи­сок ресур­сов, к которым при­меня­ется полити­ка.

Пользователь

Поль­зователь IAM — сущ­ность, которая соз­дает­ся в AWS для пред­став­ления исполь­зующе­го его челове­ка либо при­ложе­ния. У поль­зовате­лей есть так называ­емое User ARN (Amazon resource name), выг­лядит оно сле­дующим обра­зом:

arn:partition:service:region:account:resource

где

• arn — иден­тифика­тор стро­ки;
• partition иден­тифици­рует раз­дел для ресур­са. Для стан­дар­тных реги­онов AWS исполь­зует­ся раз­дел aws. Для Пекина, допус­тим, будет aws-cn;
• service иден­тифици­рует про­дукт AWS. Ресур­сы IAM всег­да исполь­зуют iam;
• region опре­деля­ет реги­он ресур­са. Для ресур­сов IAM это поле всег­да оста­ется пус­тым;
• account ука­зыва­ет иден­тифика­тор учет­ной записи AWS без дефисов;
• resource иден­тифици­рует кон­крет­ный ресурс по име­ни.

Вот некото­рые при­меры ARN:

arn:aws:iam::123456789012:root

arn:aws:iam::123456789012:user/JohnDoe

arn:aws:iam::123456789012:user/division_abc/subdivision_xyz/JaneDoe

arn:aws:iam::123456789012:group/Developers

arn:aws:iam::123456789012:group/division_abc/subdivision_xyz/product_A/Developers

arn:aws:iam::123456789012:role/S3Access

Группа

Груп­па IAM — это совокуп­ность поль­зовате­лей. Груп­пы облегча­ют управле­ние ими. Груп­па может содер­жать мно­жес­тво поль­зовате­лей, а поль­зователь может при­над­лежать к нес­коль­ким груп­пам. Кро­ме того, груп­пы не могут быть вло­жен­ными: они дол­жны содер­жать толь­ко поль­зовате­лей, но не дру­гие груп­пы.

Роль

Роль IAM — это сущ­ность, которая опре­деля­ет набор раз­решений для выпол­нения зап­росов к сер­висам AWS. Исполь­зование ролей — безопас­ный спо­соб пре­дос­тавить раз­решения опре­делен­ным объ­ектам. Так, пен­тестер может поп­робовать взять на себя опре­делен­ную роль, если у него есть на это пра­ва, и получить при­виле­гии этой роли.

Ро­ли соз­дают­ся для того, что­бы не приш­лось регис­три­ровать допол­нитель­ную учет­ную запись ради каких?нибудь авто­мати­чес­ких задач. Роль зачас­тую при­вязы­вает­ся к какому?либо сер­вису.

EC2

Он же Elastic Compute Cloud. Это вир­туаль­ный сер­вер (инстанс), на котором поль­зователь может запус­кать любые при­ложе­ния, что­бы решать собс­твен­ные задачи. Инстанс сос­тоит из сле­дующих ком­понен­тов.

Рас­смот­рим все эти сос­тавля­ющие по поряд­ку.

1. Опе­раци­онная сис­тема — на EC2 мож­но уста­новить прак­тичес­ки любую ОС.
2. Дос­туп — спо­собы, с помощью которых мож­но получить дос­туп к EC2 через интернет.
3. Ад­рес — IP-адрес, по которо­му откли­кает­ся инстанс.
4. Хра­нили­ще — мес­то, где хра­нят­ся дан­ные инстан­са.
5. Груп­пы безопас­ности — набор пра­вил, которые при­меня­ются к EC2, они поз­воля­ют кон­тро­лиро­вать вхо­дящий и исхо­дящий тра­фик.
6. VPC (virtual private cloud) — изо­лиро­ван­ная облачная сеть, в которой может находить­ся наш инстанс.

INITIAL ACCESS

Есть мно­жес­тво спо­собов про­ник­нуть в обла­ко заказ­чика пен­теста. Мы будем дей­ство­вать через AWS CLI — коман­дную стро­ку для работы с AWS. Нам пот­ребу­ются спе­циаль­ный иден­тифика­тор сек­ретно­го клю­ча и сам сек­ретный ключ, пос­ле пре­дос­тавле­ния которых мы получим воз­можность работать с обла­ком. В качес­тве точ­ки вхо­да будем исполь­зовать IAM и EC2.

Сбор информации

На компь­юте­рах, вза­имо­дей­ству­ющих с облачны­ми сер­висами Amazon, обыч­но при­сутс­тву­ет файл credentials, в котором находит­ся иден­тифика­тор сек­ретно­го клю­ча дос­тупа и сам этот ключ. Стан­дар­тные пути рас­положе­ния фай­ла сле­дующие. В Linux:

/root/.aws/credentials

/home/user/.aws/credentials

В Windows:

%userprofile%.awscredentials

Иден­тифика­тор сек­ретно­го клю­ча и сам сек­ретный ключ мож­но обна­ружить в пуб­личных репози­тори­ях.

Очень час­то нуж­ные нам клю­чи могут лежать в перемен­ных окру­жения. Обя­затель­но про­веряй и их:

set

dir env:

Get-ChildItem Env: | ft Key,Value

Воз­можно, у тебя не получит­ся обна­ружить столь чувс­тви­тель­ные дан­ные такими прос­тыми метода­ми. Перед тес­тирова­нием ты, ско­рее все­го, успел обна­ружить при­над­лежащие заказ­чику под­домены, репози­тории, фай­лы. В таком слу­чае поп­робуй поис­кать во всех этих источни­ках сле­дующие харак­терные стро­ки:

aws_access_key_id

aws_secret_access_key

aws_session_token

bucket_name

aws_access_key

aws_secret_key

S3_BUCKET

S3_ACCESS_KEY_ID

S3_SECRET_ACCESS_KEY

S3_SECRET_KEY

S3_ENDPOINT

list_aws_accounts

metadata_service_timeout

metadata_service_num_attempts

ПОДКЛЮЧЕНИЕ

Пос­ле того как ты нашел иден­тифика­тор и сам сек­ретный ключ, нас­тало вре­мя под­клю­чать­ся к AWS CLI. Для это­го исполь­зуем PowerShell:

aws configure

Что­бы узнать, под какой учет­ной записью ты под­клю­чил­ся к сис­теме, в Linux исполь­зует­ся коман­да whoami, но в AWS такой коман­ды нет. Что­бы узнать свое имя поль­зовате­ля, нуж­но ввес­ти в кон­соль PowerShell сле­дующую коман­ду:

aws sts get-caller-identity

# Дополнительно можно указать конфигурационный профиль (если, допустим, получили данные не от профиля default)

aws sts get-caller-identity --profile demo

ENUMERATION

В начале любого тес­тирова­ния на про­ник­новение сле­дует хорошень­ко осмотреть­ся и понять, нас­коль­ко боль­шое обла­ко пред­сто­ит про­пен­тестить. Сна­чала столь скру­пулез­ная раз­ведка может показать­ся бес­полез­ной, но, перехо­дя к сле­дующим эта­пам, мы уже будем рас­полагать дос­таточ­ным объ­емом информа­ции. В начале каж­дого раз­дела я ука­зал, для чего нам пот­ребу­ются те или иные дан­ные.

Не пережи­вай, механизм работы с полити­ками и ролями будет понача­лу не сов­сем ясен. Пос­тарай­ся удер­жать в голове коман­ды. Ког­да дой­дем до эта­па повыше­ния при­виле­гий, все вста­нет на свои мес­та само собой.

IAM

Пользователи

Поль­зовате­ли — самая популяр­ная точ­ка вхо­да в обла­ко AWS. Имен­но поль­зователь­скую учет­ную запись мож­но обна­ружить в фай­ле .aws/credentials, а так­же в пуб­личных репози­тори­ях.

Сна­чала сто­ит най­ти всех зарегис­три­рован­ных в обла­ке поль­зовате­лей:

aws iam list-users

Вы­вод коман­ды показы­вает наличие двух поль­зовате­лей: mishaadmin и Bob, которые в даль­нейшем могут сыг­рать важ­ную роль в тес­тирова­нии обла­ка на про­ник­новение.

Юзе­ры могут сос­тоять в груп­пах, а к этим груп­пам могут быть при­вяза­ны кри­во скон­фигури­рован­ные полити­ки. Сле­дующей коман­дой мы опре­делим, в каких груп­пах сос­тоит каж­дый поль­зователь:

aws iam list-groups-for-user --user-name <username>

Кро­ме групп, полити­ки могут быть так­же при­вяза­ны непос­редс­твен­но к поль­зовате­лю. Про­верим, есть ли в нашем слу­чае такая при­вяз­ка:

# Управляемые

aws iam list-attached-user-policies --user-name <username>

# Встроенные

aws iam list-user-policies --user-name <username>

Группы

К груп­пам тоже могут быть при­вяза­ны полити­ки, спо­соб­ные помочь нам на эта­пе повыше­ния при­виле­гий. Что­бы уви­деть все IAM-груп­пы, набери в кон­соли PowerShell сле­дующее:

aws iam list-groups

Най­ти при­меня­емые к груп­пе полити­ки помога­ют сле­дующие коман­ды. Для управля­емых политик:

aws iam list-attached-group-policies --group-name <group-name>

Нап­ример:

aws iam list-attached-group-policies --group-name demogroup

И для встро­енных:

aws iam list-group-policies --group-name <group-name>

Нап­ример:

aws iam list-group-policies --group-name demogroup

Роли

Ро­ли инте­ресу­ют нас по тем же при­чинам, что и груп­пы. Роли мы можем исполь­зовать в сво­их инте­ресах, если у нас есть при­виле­гия iam:PassRole, о которой мы погово­рим чуть поз­же.

Уви­деть все роли IAM мож­но при помощи сле­дующей коман­ды:

aws iam list-roles

Вы­вод коман­ды показы­вает, что в нашем обла­ке есть роль Example1, которая может быть исполь­зована на сер­вере ec2.amazonaws.com.

Что­бы най­ти полити­ки, при­вязан­ные к этой роли, вос­поль­зуем­ся сле­дующи­ми коман­дами. Для управля­емых политик:

aws iam list-attached-role-policies --role-name <role-name>

Нап­ример, так:

aws iam list-attached-role-policies --role-name Example1

Для встро­енных:

aws iam list-role-policies --role-name <role-name>

При­мер исполь­зования:

aws iam list-role-policies --role-name Example1

Политики

Имен­но в полити­ках содер­жится информа­ция о пре­дос­тавля­емых поль­зовате­лю при­виле­гиях. Есть очень полез­ный сайт policysim.aws.amazon.com, на который мож­но заг­рузить получен­ную полити­ку и удоб­но работать с ней, при­менять филь­тры.

При этом полити­ки могут быть как встро­енны­ми (inline), так и управля­емы­ми (managed). Они реали­зуют одни и те же фун­кции: пре­дос­тавля­ют пра­ва либо отка­зыва­ют в них. Отли­чие встро­енной полити­ки зак­люча­ется в том, что она дей­стви­тель­но встро­ена в груп­пу, поль­зовате­ля или роль, к которым при­меня­ется. Появ­ляет­ся стро­гая связь: одна полити­ка — один объ­ект. При уда­лении поль­зовате­ля, груп­пы или роли эта полити­ка так­же будет уда­лена. Чаще все­го встро­енные полити­ки при­меня­ют, что­бы гаран­тирован­но не пре­дос­тавить слу­чай­но пра­ва какому?либо дру­гому объ­екту. Тем не менее Amazon рекомен­дует исполь­зовать управля­емые полити­ки вмес­то встро­енных.

Уп­равля­емые полити­ки чуть более удоб­ны. Самое важ­ное — их мож­но при­вязать к нес­коль­ким объ­ектам сра­зу. В свою оче­редь, управля­емые полити­ки делят­ся на два типа: managed policy и customer managed policy. Пер­вые избавля­ют нас от необ­ходимос­ти писать полити­ку самос­тоятель­но, AWS сам позабо­тил­ся об этом и пре­дос­тавил некото­рые вари­анты для самых рас­простра­нен­ных слу­чаев, нап­ример AmazonDynamoDBFullAccess, AWSCodeCommitPowerUser и тому подоб­ные. При этом стан­дар­тные полити­ки managed policy нель­зя редак­тировать. Вто­рой тип — customer managed policy — исполь­зует­ся, если тре­бует­ся чуть более тон­кая нас­трой­ка при­виле­гий. В таком слу­чае при­дет­ся соз­давать полити­ку самос­тоятель­но.

Уви­деть спи­сок политик IAM мож­но с помощью сле­дующей коман­ды:

aws iam list-policies

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

aws iam get-policy --policy-arn <policy-arn>

Нап­ример, так:

aws iam get-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Ско­рее все­го, в выводе пер­вой или вто­рой коман­ды ты обра­тил вни­мание на параметр DefaultVersionId. В AWS могут одновре­мен­но сущес­тво­вать нес­коль­ко отли­чающих­ся друг от дру­га вер­сий одной и той же полити­ки. Допус­тим, полити­ка пер­вой вер­сии пре­дос­тавля­ла пол­ный дос­туп к любым ресур­сам, а полити­ка вто­рой вер­сии уже огра­ничи­вала нас в чем?то. С этим свя­зан один из век­торов повыше­ния при­виле­гий, который мы тоже рас­смот­рим. Обя­затель­но обра­ти вни­мание на параметр IsAttachable, воз­можно, что полити­ка «мер­твая» и ее нель­зя ни к чему при­вязать.

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

aws iam list-policy-versions --policy-arn <policy-arn>

Нап­ример, так:

aws iam list-policy-versions --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

По­лучить информа­цию об опре­делен­ной вер­сии ука­зан­ной полити­ки мож­но таким обра­зом:

aws iam get-policy-version --policy-arn <policy-arn> --version-id <version-id>

При­мер исполь­зования этой коман­ды:

aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --version-id v1

Эта полити­ка пре­дос­тавля­ет воз­можность любых дей­ствий на любых ресур­сах (Action: *, Resource: *, Effect: Allow). Так­же мы можем уви­деть, какие пра­ва дает кон­крет­ному объ­екту ука­зан­ная полити­ка:

aws iam get-user-policy --user-name <user-name> --policy-name <policy-name>

При­мер исполь­зования коман­ды:

aws iam get-user-policy --user-name mishaadmin --policy-name AdministratorAccess

Для груп­повой полити­ки исполь­зует­ся сле­дующий син­таксис:

aws iam get-group-policy --group-name <group-name> --policy-name <policy-name

Нап­ример, так:

aws iam get-role-policy --role-name <role-name> --policy-name <policy-name>

Как видим, наш мно­гоува­жаемый адми­нис­тра­тор обла­ка mishaadmin име­ет неог­раничен­ные воз­можнос­ти.

 Читайте ещё больше платных статей бесплатно: https://t.me/xakep_1