Паленый сервис
Взлом proxy-сервиса для прослушивания
неприятельского трафика Иногда бывает необходимо
последить за человеком. Узнать, какие сайты он посещает,
с кем ведет переписку, на каких форумах общается, о чем
трепется в icq и какой его пароль к таинственному
web-ресурсу. Для этого совсем необязательно прослушивать
телефон или ставить видеокамеры в квартире. Достаточно
лишь отсниффать его трафик. Обычно подобраться к
маршрутизатору жертвы невозможно. Однако довольно часто
объекты слежки для анонимности пользуются различными
сетевыми сервисами, которые едва ли добавляют
безопасности.
[печальная преамбула]
Как-то давно я искал хороший прокси-сервис. Теряясь в
догадках, я серфил много интересных сайтов, читал форумы
и отзывы клиентов. И вот мой браузер занесло на сайт
proxy4you.net. На этом интересном проекте предлагалось
купить проксики по довольно низкой цене. И я, быть
может, даже и купил, если бы не увидел ссылку на форум
phpBB 2.0.6. Учитывая то, что ситуация происходила
где-то с полгода назад, я совсем не удивился :). Бережно
выполняя одну команду за другой, я по обкатанному
сценарию залил на сервер connback-шелл и вошел в
систему. Вот только продержаться мне там не удалось. В
этот день я толком ничего не посмотрел, а на следующий
обнаружил пропажу не только шелла, но и всего форума :).
Видимо, админ каким-то образом обнаружил взлом и снес
борду. Про этот «минивзлом» я никогда бы не написал в
журнал, если бы не продолжение истории, случившейся
недавно.
[охота на уток]
В один чудный вечер я сидел дома и не знал, чем бы
себя занять. Мой хороший знакомый, с которым мы давно
перетираем «заказные» спецзадания, поделился со мной
одной интересной информацией. Он очень давно охотился за
человеком, который промышлял не совсем честными делами.
Не могу утверждать, но, по-моему, злобный чувак просто
кинул моего приятеля, что и побудило последнего
преследовать сетевого негодяя, желая вернуть свои
деньги. На одном из форумов, где мой кореш скорефанился
с администрацией, ему удалось запалить IP-адрес негодяя.
Судя по всему, айпишник принадлежал какому-то хостингу -
на это указывал вывод whois'а, который мне скинул мой
напарник. Описание хостинга выглядело примерно, как
uaonline-hqhost-cluster. Эта надпись показалась мне до
боли знакомой и через некоторое время я вспомнил почему.
Как оказалось, я сам пробивал по хуизу адрес
proxy4you.net, и тот оказался в той же подсети, что и
последний адрес. Все это косвенно указывало на то, что
жертва пользуется услугами proxy-сервиса. Я поделился
размышлениями с другом и потом пожалел об этом. Сразу же
посыпались просьбы попробовать внедриться в этот ресурс
и поснифать трафик с этого айпишника. Я согласился.
Атака началась со стандартных вещей. Перво-наперво я
занялся сканированием. Сканить решил всю подсеть с
помощью старого доброго LANGuard Scanner. Ни к чему
хорошему это не привело, потому как хост proxy4you.net
вообще оказался недоступным для этой программы, а
остальные узлы, по-видимому, выступали в роли
дополнительных IP, на которых вообще не светились
никакие порты. Но я-то знал, что ЛАНГуард определяет
живучесть хоста при помощи ICMP-запроса. Логичным
заключением можно было назвать тот факт, что
установленный на машине файрвол просто резал весь
ICMP-трафик. |
Запустив nmap с опцией -P0, я получил список
открытых портов: 22, 25, 80, 1723, 5000 и 6709.
Воспользовавшись телнетом, я узнал, что за цифрой 6709
скрывается обычный проксик типа Squid. Оставалось
определить, что за сервис находится под 5000 портом. Все
стало ясно после того, как я зашел на сайт конторы: эти
ребята предоставляли не только proxy, но и vpn-сервис.
Так что под этим портом скрывался OpenVPN - это я
выяснил по характерным иероглифам, которые выдавались
после соединения. Однако все эти исследования не
сдвинули дело с мертвой точки. Необходимо было хоть
каким-то образом проникнуть на машину. Сканирование
скриптов на traversal, sql-injection и прочие баги не
привели к большому успеху, поэтому я стал просто тупо
ходить по ссылкам и... нашел кое-что интересное. Нет, я
не обнаружил невидимый phpmyadmin или web-шелл, как ты
мог предположить. Я наткнулся на страницу, где в
картинках описывалась настройка VPN-соединения. И один
из скриншотов меня очень насторожил. На нем отображался
последний шаг настройки VPN, вот только логин был не
очень стандартный. Вместо каких-то тривиальных имен типа
demo, test и т.п. использовался логин michael. В
качестве пароля отображались пять звездочек. Может быть,
это было случайно придуманное имя, однако дальнейший шаг
доказал, что это было неспроста. Я решил попробовать
отправить тестовое письмо пользователю michael через их
SMTP-сервер. Думаю, понятно, на что я рассчитывал - если
системного имени не существует, мне вернется ответ
демона о некорректном имени пользователя. Но такого
ответа не вернулось, следовательно, логин Майкла
существует и, по-видимому, активно используется.
[активная атака]
Дальнейшая логика моих действий была следующей: мне
ничего не оставалось, как запустить процесс перебора
пароля на сервис PPTP VPN с быстрого шелла. Для
эффективного брутфорса я отфильтровал все пятизначные
пароли из большого словаря. Действительно, если имя
совпало, то, скорее всего, совпадет и длина пароля. По
крайней мере, я на это искренне надеялся.
И я не прогадал (я вообще редко когда пользуюсь
брутфорсерами, если не уверен в победе). PPTP-Bruter,
про особенности которого я уже писал в моих статьях,
справился с задачей «на ура». Спустя полчаса брутер
ответил, что успешно подобрал пароль к учетной записи.
Сразу после этого было принято решение попробовать
полученную комбинацию l/p для входа по SSH. И опять
успех - michael имел доступ к машине по ssh. Для пущей
маскировки я залогинился с ключиком -T, чтобы не
подвязывать к себе псевдотерминал и не палиться в
журналах /var/log/wtmp и /var/run/utmp. В консоли на тот
момент никого не было, поэтому можно было без палева
изучать удаленный сервак. Первым делом я посмотрел
процессы - стандартный набор: pptpd, openvpn, squid,
sendmail, exim и еще несколько сервисов. На первый
взгляд - ничего необычного - простая Linux-станция.
Насторожило лишь одно: то, что админы повесили Web-сайт
на рабочий proxy- и vpn-сервер. Обычно под это дело
выделяется отдельная тачка, хотя бы ради безопасности. К
несчастью, мне не хватило прав не только на просмотр
учетных записей proxy и vpn, но и на чтение каталога /usr/service,
содержащий всю интересную информацию. Поэтому мне нужно
было приложить все усилия и повысить свои права до
нулевого уровня. |
[операция «Захват-110»] Не найдя ничего
подходящего в папках, которые были мне доступны и
перечитав все логи и истории вводимых команд, я не
добился никаких успехов. Ядро в системе было 2.4.27
версии, и я также попробовал его взломать. Стандартные
эксплойты выдавали какую-то ерунду, а самый последний я
не решился испытывать, так как завалил им множество
систем (на 99% атака просто бы парализовала сервер).
Полностью отчаявшись, я скачал старый добрый сценарий
check.sh (http://kamensk.net.ru/forb/1/x/check.sh)
и запустил его на сервере. Для незнающих напомню, что
этот чекер проверяет все suid/sgid/nogroup-файлы на
сервере, а также выдает полную информацию об
операционной системе. После детального отчета, я выудил
несколько suid-файликов и принялся их изучать. С виду
это был стандартный набор приложений: ping, traceroute,
su, sudo, exim и еще несколько бинарников. Первым делом
я скачал эксплойт для sudo и попытался его запустить,
однако ни к чему хорошему это не привело: то ли версия
была новой, то ли эксплойт был кривоват. Тут я вспомнил,
что и для exim имеется сплоит (www.xakep.ru/post/27010/exploit.txt),
который работает только локально и переполняет буфер у
почтового сервиса. Скомпилировав и запустив его, я
убедился, что iDEFENCE пишут реальные вещи - эксплойт
сработал как часы и предоставил рутовый шелл. Мысленно
передав привет админу, который засуидил демон, я
продолжил мониторинг за сервером.
По старинке, я создал suid-бэкдор и положил его в
неприметное место (на всякий случай) и стал жадно шарить
по жесткому диску. В заветной папке /usr/service
находилась структура каталогов для сервисов squid и
openvpn. В одном из каталогов я нашел готовые скрипты
для запуска openvpn на клиентской стороне, а также лист
учетных записей в открытом виде. Первое, что я хотел
сделать, - определить логин нашей жертвы. Быть может он
как-то связан с его ником или e-mail'ом. Но логины
выбирались «от фонаря», поэтому удача мне не улыбнулась
:). Но мне посчастливилось найти файл clients.xls. Его
вес достигал 800кб и наверняка он содержал в себе всю
информацию о клиентах сервиса. Использовав scp, я
скопировал этот файл на свой доверенный шелл, а затем -
на комп. Но при открытии с меня потребовали пароль ;).
Конечно, можно было убить полдня на перебор комбинаций,
или сгрузить с www.passwords.ru программу-брутфорс, но
мне просто не хотелось этим заниматься. Я предпочел
вернуться в консоль и добить сервер до конца.
[слушаем линию]
Пообщавшись с приятелем, мы решили поставить тачку на
прослушку. Причем загвоздка заключалась в том, что нужно
снифать все 80 интерфейсов, которые были активны, потому
как ip-адрес, выдаваемый клиенту, выделяется совершенно
случайно (по протоколу DHCP), а squid использует всего 3
айпишника, которые находятся в другой подсети. Из этого
можно сделать разумный вывод: наша жертва использует не
proxy, а vpn-подключение. Но сути вопроса это не меняло,
так как VPN-трафик шифруется только на участке «клиентgt;
сервер», а затем перебрасывается в чистом виде на
выходной интерфейс. Наша задача была - прослушать этот
интерфейс и собрать компромат на жертву. Однако за
незнанием определенного номера интерфейса, пришлось
ставить на прослушку весь внешний трафик. |
Дело оставалось за малым - нам нужно было
определиться с хорошим снифером, который отлавливал
только пароли. Посмотрев список, я остановился на
софтине PHoss (www.phenoelit.de/phoss/PHossS.gz). По
словам разработчиков, этот снифер умеет отлавливать
пароли по протоколам POP3, IMAP, FTP, TELNET, LDAP и VNC.
Короче, то, что доктор прописал. Я закачал этот нюхач
на сервер, затем распаковал и был приятно удивлен:
снифер состоял всего из одного прекомпиленного файла.
Сначала у меня были некоторые сомнения, что это чудо
природы вообще запустится. Но после команды ./PHossS --help
все стало ясно. Софтина доказала свою профпригодность: в
параметрах можно было указывать конкретный интерфейс,
осуществлять фильтрацию и включать буферизацию. В общем,
минимум возможностей, с которыми можно жить.
Итак, прежде чем запускать снифер, я внимательно
ознакомился с процессами. Среди них было несколько
потоков httpd и программы для авторизации squid под
названием nsca_auth. Я решил замаскировать нюхач под эту
прогу, однако мне нужно было каким-то образом скрыть
редирект, который бы отображался в процесс-листе. Здесь
можно было поступить двумя способами: либо вызвать
функцию execl() в специальном приложении, где можно
оговорить параметр, поступающий в процесс-лист. Либо
поступить более хитро, как сделал я. Сперва я переместил
PHossS в /usr/bin и назвал его nsca_auth. Затем с
помощью гениального приложения nohup запустил снифер.
Появилось оповещение, что весь вывод приложения будет
записываться в nohup.out. В общем, строка запуска
выглядела так: «nohup nsca_auth &». Проверив
процесс-лист, я убедился, что подложный процесс
практически никак себя не выдает. А тем временем в файле
nohup.out стала накапливаться конфиденциальная
информация.
[разбор полетов]
Через пару дней активного снифинга, я выключил
анализатор пакетов и слил логи себе на комп. Удалось
поймать порядка 10 мегов информации. Теперь нам
предстояла сложная задача по отделению мух от котлет,
чем мы и стали заниматься. Примечательно, что мой
товарищ знал провайдера, к которому подключена жертва.
Это и явилось ключевым фильтром. Пробив по WHOIS
диапазон адресов московского прова, мы быстро
отфильтровали несколько учетных записей на FTP- и
POP3-протоколы. Среди них большинство, действительно,
принадлежало нашему неприятелю, по крайней мере, так
сказал мой корефан. Через некоторое время выяснилось,
что жертва промышляла фишингом: нам удалось достать
пароли на FTP-серверы с логами от разных богатых персон. |
(Администратор не несет ответственности (Автор Денис
Евгеньевич)
|