Локальное нападение

Докучаев Дмитрий aka Forb

Хакер, номер #071, стр. 071-056-1

(forb@real.xakep.ru)

Правильный выбор убойного эксплойта

Ежедневно публичные источники пополняются свежими локальными эксплойтами для различных багов. К сожалению, далеко не каждый из них способен завоевать рутовые права. Как правило, это обусловлено «защитой от дурака» – автор намеренно допускает ошибки в коде и недоработки в синтаксисе. Чтобы каждый твой удаленный взлом поощрялся блестящей локальной атакой, необходимо научиться грамотно искать и юзать эксплойты.

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

Slackware 9.0 & 2.4.20

Однажды я наткнулся на очень интересную дыру в Web-скрипте одного раскрученного портала. Дырка позволяла выполнять системные команды. Отдав приказ консольному wget, я залил бэкдор, запустил его и прицепился к хакерскому порту с забугорного шелла. Взлом получился очень легким, но меня смущали слишком низкие права. Мой бэкдор запустился с привилегиями nobody под уидом 65535. Узрев версию ядра, я убедился, что попал по адресу - кернел был стареньким (2.4.20), хотя система носила гордое название SlackWare. В этот момент я знал, какой эксплойт буду использовать для получения нулевого идентификатора. Мой выбор остановился на файле isec-ptrace.c, который эксплуатировал уязвимую ядерную функцию. Стянув исходник с доверенной машины, я скомпилил и запустил хакерское творение. Тут же я получил абсолютные права, после чего стал старательно вычищать логи.

Некролог:

Ptrace-kmod-эксплойт применяется для повышения прав в Linux c ядрами 2.2.х, 2.4.22 и ниже. Он не работает, если на ядро наложен патч grsecurity и другие ptrace-заплатки. Эксплойт не привязывается к псевдоустройству, посему может работать и в интерактивном шелле. Если по какой-то причине на машине отсутствует компилятор или эксплойт не желает собираться, его можно без проблем портировать, собрав на машине с похожей конфигурацией. Ссылка на эксплойт: http://packetstormsecurity.nl/0304-exploits/ptrace-kmod.c.

RedHat 8.0 & 2.4.24

Глубокой ночью я залогинился на недавно порутанный маршрутизатор, чтобы заценить журнал локального снифера. Нюхач встраивался в клиент ssh и записывал все введенные пароли в файл /usr/share/locale/ne/1.lc. Я ждал целую неделю, пока какой-нибудь юзер не захочет порулить локальной машиной. И дождался! Этим роковым днем администратор зацепился на DNS-сервер ns.host.ru. Заценив его длинный пароль, я дождался, пока сисадмин свалит спать, а затем воспользовался его учетной записью в своих грязных целях. Как оказалось, ns-сервер крутился на продвинутом дистрибутиве RedHat 8.0. Посмотрев на версию ядра, я понял, что isec’овский ptrace здесь бессилен. Но это не говорило о неприменимости других хакерских творений. Если ты знаешь, полгода назад в публичных источниках появился эксплойт к ядерной функции mremap(), который мог получить рута на ядрах 2.4.26 и ниже. Первая версия эксплойта трудилась более 4 часов и в итоге могла не дать видимых результатов. Чуть позже хакеры выложили быстрый сплойт, который за пару секунд запускал рутовый шелл. Я поспешно стянул mremap.c и запустил его на удаленной машине. И действительно, через пару секунд мой UID стал нулевым!