Продолжаем наш рассказ
об изучении работы эксплоита.
Анализируем пакеты WEB-PHP
Посмотрим теперь на пакет, который вызвал
тревогу. Несмотря на то, что snortsnarf точно
указывает нам на пакет, я предлагаю окинуть
взглядом всю цепочку пакетов, найдя нужный.
Содержимое пакета должно нам объяснить что
же вызвало тревогу. Обратите внимание на
выделенные фрагменты (содержимое его
обрезано для экономии места).
После изучения информации о тревоге на
сайте Snort можно понять, что срабатывание
было ложным, так как в пакете нет полной
сигнатуры, а лишь ее часть. К тому же
дальнейшее изучение данного пакета и
следующего за ним наводит на мысль, что
ничего сверхъестественного не происходит.
Внутри я не вижу ничего необычного,
ведь часто разработчики эксплоитов
оставляют заметные следы, например
неизменяемый TCP sequence number или некоторые
другие заметные вещи. Следующий мой шаг -
построение следующего фильтра для
обнаружения второй аномальной активности,
однако тут мы видим пакет с адреса 67.18.39.58. Я
назвал выходной файл web_php2 для простоты -
опять мы видим сигнатуру viewtopic.php:
Очевидно, что мы имеем два ложных
срабатывания сигнала "WEB-PHP viewtopic.php access",
так что мы можем продолжить наше
исследование дальше.
Анализ NETBIOS DCERPC ISystemActivator bind attempt
Пришла пора взяться за второе
предупреждение, выданное Snort-ом. Первое, что
стоит сделать так это кликнуть на метку [sid]
рядом с предупреждением - посмотреть на
сайте его описание (из работы Snort ясно, что в
предупреждении есть один адрес источника и
один адрес назначения). Осознав серьезность
происходящего снова строим bpf фильтр для
выделения всего трафика между хостами. И
хотя я знаю, что атакующий использовал TCP, в
фильтр я включаю и IP пакеты, так как не хочу
пропустить возможный ICMP или UDP трафик. Можно
создать и самый широкий фильтр сужая его
потом до приемлемых пределов, в этом случае
больше вероятность не пропустить важную
информацию.
C:\ windump.exe -r log_file -nXvSs 0 ip and host 192.168.1.100 and host
192.168.1.101 > dcerpc
Если вкратце, то windump читает из бинарного
файла log_file пакеты с нужным IP адресом в
заголовке и содержащие второй адрес. Ну и
все найденное дампится в decrpc. В случае
отсутствия времени можно указать windump
выдать только PSH/ACK пакеты, это предоставит
нам действительно нужные пакеты, что
быстрее приведет к обнаружению работы
эксплоита. Сделать это нужно так:
C:\ windump.exe -4 log_file -nXvSs 0 ip and host 1921.68.1.100 and host
192.168.1.101 and tcp[13] = 24 > dcerpc_pshack
В нашем случае я этого не делал, поэтому
выходной файл получится несколько больше.
Открываем файл и ищем в нем описание с сайта
Snort - A001 0000 0000 0000 C000 0000. Находим такое:
Видим лишь частичное совпадение сигнатур.
Учитывая, что риск предупреждения высок -
делаем дополнительные исследования.
Просматривая пакет видим дальше строки "F.X.N.B.F.X"
и "MEOW MARB port 135" - ищем их в Google. Одна из
найденных ссылок указывает на DShield
и становится понятно, что пакет
действительно свидетельствует о нападении.
Мораль - некто получил полный доступ к
компьютеру 192.168.1.101. Вероятно это же причина
срабатывания остальных сигналов тревоги.
Тут я бы хотел остановится и еще раз
указать как важно для борца со взломщиками
тестировать эксплоиты в домашних условиях
для того, что бы знать как они на самом деле
выглядят. Я знаю как выглядит работа
эксплоита, приведенного в этой статье и с
уверенностью могу сказать, что это
действительно пример RPC DCOM эксплоита.
Конечно, невозможно знать в лицо все
эксплоиты, но необходимо все время учиться
и совершенствоваться!
Анализ "TFTP Get"
Продолжаем изучать предупреждения и
теперь мы дошли до следующего пункта - TFTP Get.
Кроме анализа необходимо так же выяснить,
связано ли возникновение этой ошибки с
предыдущей - NETBIOS DCERPC? Еще до начала можно
предсказать, что сигнал действительно
свидетельствует о возникновении
нестандартной ситуации. Почему? Можно
предсказать, что TFTP использовался для
передачи или скачки файлов с уязвимой
машины нападающим. ОС Windows имеют встроенный
TFTP клиент и вероятно именно он
использовался хакером, по целому ряду
причин.
Посмотрим на пакет, вызвавший появление
алярма. TFTP использует для передачи данных
протокол UDP, что позволит нам построить
более точный bpf фильтр. Можно указать windump
выдирать только пакеты с правильный UDP
заголовками:
c:\ windump.exe -r log_file -nXvSs 0 udp and host 192.168.1.100 and host
192.168.1.101 > tftp
Вот пример найденного пакета:
Видно, что 192.168.1.101 запросил файл evil_file1 с
машины хакера 192.168.1.100. Передача его
выглядит так
На самом деле файл может содержать все что
угодно, ибо что передается по сети к
взломанной машине зависит только от
кривизны рук хакера (это может быть и руткит,
и вирус, и любое другое программное
обеспечение) и того, что он планирует дальше
творить в сети.
(Продолжение следует)
