книги хакеры / журнал хакер / 205_Optimized

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

Автор опубликовал отчет и видео, где показано, как использовать эту уязви-

-x cha

мость.

TARGETS

phpBB < 3.1.7-PL1.

SOLUTION

Производитель выпустил исправление.

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

to

w Click

m

w

w

o

ЭКСПЛУАТИРУЕМ УТЕЧКУ ИНФОРМАЦИИ В ЯДРЕ LINUX,

.

.c

p

g

df

n

e

-xcha

ЧТОБЫ ОБОЙТИ KASLR

CVSSv2:

N/A

Дата релиза: 24 января 2016 года

Автор:

Marco Grassi

CVE:

N/A

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

Многие из читателей знают про механизм ASLR (Address Space Layout Randomization) — рандомизацию адресного пространства. Менее известный kASLR — это то же самое, но для ядра (k — kernel). Пока что kASLR не включен по умолчанию в популярных дистрибутивах, но это не делает их менее безопасными. И вот почему.

Некоторое время назад исследователь Марко Грасси изучал каталог /proc в Android, и его внимание привлекло поле WCHAN. Это канал ожидания (wait channel), там содержится адрес события, которое ожидает конкретный процесс. Увидеть его можно при запуске команды ps с опцией -l.

Узнать значение wchan ты можешь из пространства пользователя, прочитав /proc/pid_of_interest/stat. И это довольно странно. Что, если наш процесс находится в пространстве ядра? Тогда мы получим адрес ядра? После некоторых проверок автор получил положительный ответ.

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

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

Значение 18446744071579755915 — это, очевидно, место расположения кода ядра, и в hex выглядит следующим образом:

>>> hex(18446744071579755915)

‘0xffffffff810de58bL’

В качестве тестовой ОС автор выбрал Ubuntu 14.04, но, так как kASLR там не включен по умолчанию, для успешного воспроизведения следующего примера нужно будет его включить.

EXPLOIT

Тестовый скрипт очень прост и быстр. Как сказано ранее, в /proc/pid/stat лежит код ожидания из пространства ядра, поэтому мы можем:

1.Зафиксировать это место ожидания.

2.Получить с помощью WCHAN значение ASLR.

3.Сравнить утекшее значение с известным «случайным» значением.

4.Вывести смещение.

Для первого пункта мы можем воспользоваться следующим трюком: если форкнуть процесс и перевести его в режим сна, то после этого мы сможем прочитать его /proc/sleeping-pid/stat, и, пока процесс спит, это будет стабильным значением.

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

Пример получения адресов на языке Python.

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

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

Вот как будет выглядеть результат работы.

marco@marco-l:~/Documents$ python infoleak.py

Leaking kernel pointers...

leak: 0xffffffffb70de58b 18446744072485725579

kASLR slide: 0x36000000

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

TARGETS

Системы с включенным kASLR и без указанного ниже патча.

SOLUTION

Производитель выпустил исправление.

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

to

w Click

m

w

w

o

УДАЛЕННОЕ ВЫПОЛНЕНИЕ КОДА

.

.c

p

g

df

n

e

-xcha

В RUBY ON RAILS

CVSSv2:

N/A

Дата релиза: 25 января 2016 года

Автор:

John Poulin

CVE:

CVE-2016-0752

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

Разберем уязвимость в фреймворке Ruby on Rails, которая в определенных условиях позволяет атакующему выполнить удаленно произвольный код. Если исследуемое приложение использует динамический рендеринг путей (к примеру, render params:id(), то оно уязвимо.

Контроллеры RoR по умолчанию полностью рендерят отображаемый файл, который соответствует вызываемым методам. К примеру, метод контроллера show полностью сгенерирует файл show.html.erb, если не получит других точных параметров рендеринга.

Однако во многих случаях разработчики решают, как рендерить, на основе формата, то есть результат будет разным в зависимости от того, что должно быть на выходе — HTML, JSON, XML или другой формат. В указанном выше случае используется языковой шаблон (ERB, HAML и так далее). Есть несколько методов, которые можно использовать, чтобы повлиять на отображение содержимого. Для наших целей мы сфокусируемся на методе рендеринга. В документации Rails описано несколько способов вызывать такой метод, включая возможность явно указать путь к содержимому с помощью опции ile:.

Рассмотрим небольшой код.

На первый взгляд он очень прост, и можно сразу предположить, что контроллер хочет отобразить шаблон с помощью параметра template. Но неясно, откуда он его будет подгружать. Из основной директории или откуда-то еще? Будет ли это полный путь до файла или просто его имя? Разберемся с механизмом чуть подробнее. Это яркий пример функции, которая пытается выполнить слишком много всего. В ней-то и кроется проблема.

Предположим, мы ждем, что функция отрендерит файл app/views/ user/#{params[:template]}. Другими словами, если значение параметра шаблона будет равно dashboard, то будет выполнена попытка загрузить файл app/views/user/dashboard.{ext}, где ext — это любое из разрешенных расширений: .html, .haml, .html.erb и так далее.

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

Пример загрузки шаблона dashboard

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

Но что будет, если мы попытаемся загрузить шаблон из другого пути —

../admin/dashboard?

Попытка загрузки шаблона из ../admin/ dashboard

После небольшого анализа ошибки стало понятно, что приложение пытается найти шаблон по нескольким путям, включая RAILS_ROOT/app/views, RAILS_ ROOT и корневую директорию системы. Первым делом, конечно, хочется проверить доступность файла /etc/passwd, что и сделал автор эксплоита.

Читаем файл /etc/ passwd

Если мы можем читать файлы системы, то, может, получится узнать содержимое исходников приложения и его настройки? Например, conig/initializers/ secrettoken.rb.

Содержимое файла config/initializers/secrettoken.rb_ file

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

Сделать все это позволил код, который использовал динамический рендеринг

-x cha

путей внутри приложения. И к сожалению, это не самое худшее.

EXPLOIT

Исследователь Джефф Джармок описал в своей статье «The Anatomy of a Rails Vulnerability — CVE-2014-0130: From Directory Traversal to Shell» возможность получения шелла в приложениях Rails, если будет найдена уязвимость обхода путей. Он как раз описывает схожую ошибку, скрытую в механизме рендеринга. В нашем же случае была найдена уязвимость типа LFI, а она имеет другую особенность. Мы загружаем, интерпретируем и выполняем файл как код (ERB). Обычная уязвимость обхода путей возвращает неисполняемый контент (к примеру, файл CSV). Мы же не только можем прочитать исходники приложения и другие доступные для чтения файлы в системе, но и выполнить Ruby-код с правами веб-сервера.

Для проведения атаки воспользуемся техникой «загрязнения» логов, которую мы уже не раз описывали. Ruby on Rails спроектирован так, что записывает все запросы, включая параметры, в файл с логами окружения (к примеру, development.log).

Отправим запрос на правильную страницу, но с поддельным параметром и URL-кодированным значением.

Проверим содержимое лога.

Полученноесодержимоефайла development.log

И попытаемся обратиться к обновленному development.log.

Результат выполнения команды ls

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

Наша небольшая полезная нагрузка была выполнена и заменена на результат

-x cha

работы команды ls.

Автором был написан модуль для Metasploit, который автоматизирует атаку.

Примеруспешной

эксплуатацииуязви-

мостиCVE-2016-0752

Оригинальную статью ты можешь прочитать в блоге компании автора. В ней же он приводит и пример патча к фреймворку, если ты по тем или иным причинам не можешь обновить RoR.

TARGETS

Ruby on Rails без патча от 25 января 2016 года.

SOLUTION

Производитель выпустил исправление.

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

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

СОВРЕМЕННЫЙ

ХЕШКРЕКИНГ

ВЗГЛЯД НА ВЗЛОМ ХЕШЕЙ ИЗНУТРИ

InsidePro Software

www.insidepro.com

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o		Часто хакер проделывает огромную работу
	.							.c
		p					g
			df			n		e
				-xcha

для проникновения в систему, и от получения к ней полного доступа его отделяет всего один шаг — подбор пароля к хешу (зашифрованному паролю администратора или нужного пользователя). На словах звучит просто, а как на деле? И что нужно знать и уметь, чтобы успешно восстанавливать даже самые стойкие пароли? А может, лучше сразу обратиться к тем, кто профессионально занимается хешкрекингом многие годы?

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

ЧТО ТАКОЕ ХЕШКРЕКИНГ?

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

При этом настоящий хешкрекер часто полностью изолирован от этапов извлечения хешей и применения сломанных паролей для доступа к чужим аккаунтам. Более того — ему это неинтересно, он же не хакер. На всех хешкрекерских форумах публикуются только хеши (или списки хешей) для расшифровки. Эти списки не содержат ни имени ресурса, ни имен пользователей, ни почтовых ящиков, ни IP-адресов, никакой другой приватной информации. Поэтому, даже сломав пароль, хешкрекер никогда его не применит, так как просто не знает — откуда он. А если б и знал — все равно не применит, так как его цель — сам процесс хешкрекинга, ведь для него это почти искусство.

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