Проблема обнаружения прокси сервера в корпаративных ланах на самом деле является довольно актуальной - ведь если вам удалось занести свой back-connect бэкдор в сеть, то ещё нет гарантии что он сможет совершить этот самый коннект (почитайте статью PoiZon'а в этом выпуске). Основными помехами в данном случае будут наличие корпоративного firewall'a и/или прокси сервера. А как же антивирусы и персональные фаеры ? А на самом деле никак =) Корпаративные пользователи (естесвенно что в общем случае лучшие мишени для атак - это отдел кадров или бухгалтерия) обычно настолько неосведомленны, а администраторы настолько ленивы что бы расказать им что либо - что при внедрении библиотеки (даже если покажется алярм) они просто нажму Ок, незадумываясь. Так же не стоит забывать что мы лезем в корпаративный лан - а значит вероятность наткнуться на локального админа на компе сравнительна невилека - поэтому про модные руткит способы приходится забыть. Ну а про способности обнаружения неизвестных бэкдоров антивирусами можно просто промолчать ;)

Так что для начала рассмотрим корпаративный фаер. Даже если он есть - это ещё ничего не значит .... Очень много фаеров (из тех что мне попадали) работали в простом режиме - блокировка всего снаружи, а из нутри всё можно. (а про то сколько валяется статей по настройке фаеров для новичков с опцией default to accept я промолчу) Однако мы будем считать что всё таки наш противник посерёзнее и фаер более менее настроен. В таком случае наибольшая вероятность открытия следующих портов для вылазки наружу:

  • HTTP - 80
  • HTTPS - 443
  • SMTP - 25
  • POP3 - 110
  • IMAP - 143
  • FTP - 21
Наибольшую вероятность вылазки наружу мы имеем через http/https порты - ведь почтовые порты могут быть разрешенны только до почтовика (если почтовый сервер находится снаружи) или в противном случае для обычных пользователей запрещенны вовсе. FTP так же является неплохим выбором - однако он может быть открыт только с администраторских машин (ведь обычным пользователям вовсе незачем лазить куда попало=)

Хотя если нет другого выбора - то вполне можно написать работающего поверх stmp/pop3 (пароли и настройки ессно мы получаем с машины пользователя) - другое дело что у него будет довольно большое время реагирования на команды и он будет хорошо сорить в логах - но если это не критично - то пожалуй "туннель" поверх smtp/pop3 довольно неплохая идея ( учитывая что почтой сейчас пользуются все компании (даже состоящие из нескольких человек)). Однако темой данной статьи всё же является определение прокси сервера, а не троян over smtp - так что вернёмся к хттп.

Естественно что в доступе по HTTP ественной преградой может являться корпаративный прокси сервер - ведь если он используется, то на фаере будут стоять настройки на пропуск HTTP только через прокси сервер. В этом случае нам необходимо определить этот самый прокси сервер. Это можно сделать довольно большим числом способов (в этом числе использую эврестические методы). Рассмотрим наиболее известные методы определния прокси, если известно каким браузером пользуются в компани:

  • В самом простом случае пользователи используют IE в качестве браузера - в этом случае настройки прокси можно получить через WinInet Функцию - InternetQueryOption с параметром INTERNET_OPTION_PROXY
  • В случае посложнее - они могут пользоваться альтернативными браузерами - если браузер известен - тогда легко узнать где лежат его настройки - например для Opera прокси можно узнать из файла:
    Disk:\Documents and Settings\Curent user\Application Data\Opera\[различается в зависимости от версии - но обычно просто Opera]\profile\opera6.ini
    Раздел [Proxy]
Всё это конечно легко - однако если вам ничего неизвестно про устройство лана, а бэкдор установить удалось - то надо как то получить данные о его работе. Тут нам помогут эврестические методы, которые довольно просты в реализации. Основной компонент такой программы это сканер портов (или даже сканер прокси - который может определить висит на данном порту прокси сервер или нет). Далее будет описанна серия тестов для поиска прокси сервера.

  1. Самый простой вариант - это когда прокси сервер находится на одной машине со шлюзом в инет (такая схема часто применяется в маленьких сетях для экономии на железе). В данном случае получаем настройки сети через IpHelper функцию GetAdapterInfo и в параметре GatewayList получим список шлюзов (В случае если мы на nix машине - можно использовать вывод ifconfig'а). Теперь надо простучать основные возможные для прокси порты (80, 3128, 8080, 1080 ... etc) возможно где-то там скрылся прокси

  2. Так же довольно просто - мы получаем имя хоста, на котором оказались (в Win через GetNetworkParams, в nix опять же через ifconfig) - оно будет иметь вид типа user_bla_bla_bla.company.com - соотвевенно попробуем заресолвить адрес proxy.company.com - если выйдет - опять идёт скан

  3. Более сложный вариант - получаем список текущих соединений (GetTcpTable в Win или netstat в nix) и, зная свой IP адрес (GetAdapterInfo/ifconfig) и маску сети, определяем какие соединения идут наружу и на какие порты - в этом случае мы забиваем на прокси и пытаемся напрямую простучаться по ним (в этом случае основной проблемой опять является корпоративный фаер - правила могут позволить соединения только на определённые IP адреса (например для бухгалтерии это доступ к банковским серверам)

  4. Модифицируем предыдущий способ - получив данные можно поискать среди них соединения в локальную сеть на порты для прокси серверов ( в этом случае поиск надо повторять некоторое время (например в течении 2-х часов) в дневное рабочее время - что бы быть уверенным что кто-то серфит веб - ведь http соединения довольно кратковременны).

    Кроме того можно простукивать все порты на которые когда-либо были сделаны соединения.

  5. Более сложный способ - необходимо помимо прокси опеределить клиента (этот случай более актуален для win - когда необходимо внедрить свою библиотеку/код в разрешённое приложение) - в данном случае можно воспользоваться либо недокументированной AllocateAndGetTcpExTableFromStack/
    AllocateAndGetUdpExTableFromStack из библиотеки iphlpapi.dll для получения данных о том какое соединение принадлежит какому процессу - однако это работает только для WinXP+, так что для получения списка соединений в Win2k придётся получать используя \Device\Tcp
Другой проблемой может стать то что прокси сервер может так же разрешать (но всё же разрешать) доступ не по всем портам... Однако это уже проблема стороны принимающей back-connect - для этого используйте сниффер, построенный на Raw сокетах - для определения первой попытки коннекта, далее следует нормалаьно открыть нужный порт - соответсвенно бэкдор должен повторять попытки соединения через определённые промежутки времени.

В завершении статьи хочется привести примеры, демонстрирующие использование функций, описанных в статье - при желании часть можно найти в msdn, а часть в google

Содержание архива (авторы программ указанны в комментах):

  • IpConfig.cpp - демонстрирует работу GetNetworkParams, для получения данных о сети
  • IpStat.cpp и IpStat.h - демострирует работу GetTcpTable, для получения даных о текущих соединениях
  • PortProcess.cpp - использование AllocateAndGetTcpExTableFromStack
 
     
     
Назад
by said
Вперед