Задача: Спрятать присутствие шелла на веб-сервере
Решение
На недавно прошедшем Hack In The Box 2010 Dubai крутой спец в области ИБ, Laurent Oudot, представил интересную презентацию на тему повышения скрытности при взломе через web. Материалы можешь найти тут – conference.hitb.org/hitbsecconf2010dxb/materials. Ничего чрезвычайно нового и революционного он вроде не рассказал, но приятно обобщил информацию с кучкой подробностей и хитростей, которые теперь можно опробовать на практике. Так что если ты фанатик web-hack'а, то обязательно посмотри ее. Но, с учетом общего интереса к этой тематике, я позволю себе обобщить и выделить основные вкусности.
Для начала рассмотрим проведение самой атаки и исследование скриптов на уязвимости. Конечно, самое скрытное – это узнать максимальную информацию о жертве (заюзав всевидящий Гугл, например), сконфигурить аналогичный сервак и отработать взлом на нем. Минимизировать при этом возможные появления в логах и, если что, знать, где подчистить. В итоге должна получиться почти 100% атака с минимумом лишних действий. Но чаще всего бывает лень это все делать, поэтому можно, например, скрыть реальный вектор атаки в куче ложных атак. А главное, чтобы быть менее заметным в логах, все атаки выполняй методом POST (если, конечно, ситуация позволяет), так как он там отмечается лишь как обращение к странице, без указания параметров, как это происходит с GET-запросом. То есть наши попытки проинжектить какую-нибудь БД будут не столь успешны 
.
Далее, как спрятать «общение» с шеллом. Во-первых, добавить бытовой информации, то есть в запросах указывать нормальные значения для User-Agent и Referer, чтобы смешаться с другими записями в логах. Кстати, их, наряду с проксями, желательно систематически менять, чтобы затруднить прослеживание последовательности наших действий. Во-вторых, для передачи команд шеллу и получению ответов от него можно юзать куки, например. Тогда твои обращения к шеллу будут выглядеть как GET-запросы к странице без параметров, раскрывающих его, то есть совсем без палева. В-третьих, кодируем команды и ответы в base64, например, или что-нибудь позлее, чтобы не засекли в момент обмена данными, но это в основном при условии использования на сервере какой-нибудь IDS. В-четвертых, прячем шелл в самых глубоких местах, о коих не раз было рассказано в этой рубрике, не забывая обфускировать его разными методами, дабы спрятаться от антивиреподобного ПО. К тому же желательно спрятать несколько шеллов, причем разных, чтобы и по массовому обращению к одному скрипту не засекли, да и вообще, хорошо это.
В общем, отличная основа, чтобы переписать какой-нибудь классический web-шелл.
Задача: «Вживую» проанализировать pcap-трафик
Решение
Есть целая группа программ, которая работает с «живыми» данными, то есть с потоком данных, приходящим на какой-то сетевой интерфейс. Например, всевозможные снифферы паролей, детекторы ОС, сервисов, определители структуры сети и т.д. Многие из них позволяют подгружать данные из файла лога трафика – pcap, но не все. Как раз в таких случаях нам поможет tcpreplay. Эта программа (точнее набор программ) читает pcap-файл и прогоняет его на сетевом интерфейсе, меняя какие-то значения в пакетах данных, если это необходимо. Взять ее можно с tcpreplay.synfin.net/wiki/Download, но обычно она уже есть в *nix-системах. Для Win есть только кривенький релиз, который можно взять там же.
Приведу простенький пример. Предположим, мы имеем файл test.pcap с трафиком из какой-то подсети, и нужно определить ее структуру:
Запускаем lanmap на интерфейсе eth0. Эта тулза анализирует трафик прослушиваемой сети и рисует ее структуру в файл lanmap.png. Не самая лучшая, но все же входит в состав BackTrack.
Далее запускаем tcpreplay для «повтора» пакетов из pcap-файла на том же интерфейсе.
В итоге мы получим структуру подсети из pcap-файла. Только проследи, чтобы на eth0 не приходило никаких данных из реально подключенной сети, чтобы не исказить результат. Хотя легче зареплеить на lo. Ну да ладно.
Кроме всего прочего, есть возможности изменения данных pcap-файла. Например, можно изменить IP и MAC-адреса, заголовки пакетов, эмулировать клиент-серверное общение. Можно разогнать поток данных...
Область применения данного ПО конкретно велика, так что о нем при необходимости стоит вспоминать.
Задача: Создать поддельные cookie на основе статистических данных
Решение
Общеизвестно, что для идентификации пользователей веб-сервером очень часто используются куки, поэтому украсть их – благое дело. Пихнув эти куки в наш браузер, мы автоматически аутентифицируемся под нашей жертвой. Но иногда этого не хватает, так как в кукисах может храниться какая-нибудь дополнительная переменная, привязанная ко времени (или еще как-то). К тому же, красть куки не всегда обязательно. Можно их полностью подделать, определив алгоритм формирования переменных и подставив нужные нам значения. В общем, мы заходим несколько раз на атакуемый сервер и смотрим генерируемые куки. Статические, временные поля будут сразу заметны. С динамическими же все чуть сложнее, но не намного. Для понимания их работы нам поможет набор скриптов с open-labs.org/ob-session04.tar.gz (прилагается на диске).
Итак, запускаем:
Где getcookie.pl – скрипт для получения значений из переменной в кукисах; http://example.com – полный путь до страницы на атакуемом веб-сервере; USERID – имя переменной в кукисах, откуда берем значения и файл test1.txt, куда сохраняем их; 100 – количество запросов к серверу для формирования необходимой базы и определения зависимостей.
Далее запускаем скрипт для анализа полученных данных:
В итоге мы получаем статистические данные об изменяемых и постоянных позициях, наборе символов, возможности перебора и т.д.
На основе этих данных, используя какой-либо fuzzer, мы сможем методом тыка подобрать необходимые значения для кукисов и таким образом аутентифицироваться на сервере.
Кстати, ob-session.pl работает с простыми текстовыми строками, так что можно использовать этот скрипт и для анализа других последовательностей.
Задача: Забэкдорить клиентскую машину
Решение
Здесь под «клиентской машиной» понимается комп обычного юзера. То есть какая-нибудь версия Windows, файервольчик, возможно антивирь – никаких лишних сервисов наружу не торчит, а единственные программы, которыми пользуется юзер – это браузер да, может быть, почтовый клиент. Но все решаемо. Воспользуемся функционалом Metasploit'а.
Первая трудность – достать пользователя. В данной ситуации, если мы находимся «далеко» от пользователя, то мы можем либо с помощью социальной инженерии, либо благодаря уязвимостям сайтов, которые пользователь посещает, заставить зайти его на наш «специально оформленный» сайт. Если же мы находимся в одной сети с ним, то проблема решается проще, ведь мы можем заставить его зайти на наш сервер. В этом нам поможет dns-spoofing. Суть заключается в подделке ответов DNS-сервера. Иными словами, браузер нашей жертвы при путешествиях по сайтам делает запросы к DNS-серверу, чтобы перевести названия посещаемых сайтов в IP-адреса. Мы же перехватываем их и отвечаем с подмененным IP-адресом нашего сервера.
В зависимости от ситуации может потребоваться применение arp-spoofing, чтобы перенаправить трафик через нас, чтобы мы могли «видеть» DNS-запросы. Я писал про arp-spoofing в прошлом номере, потому не буду подробно останавливаться на описании.
где 192.168.0.1 – IP шлюза, чей MAC мы подменяем своим.
Форвардинг всего приходящего трафика.
Далее DNS-spoofing. В Metasploit’е есть модуль fake dns, как раз для этих целей, но я воспользуюсь модулем от Digininja, который скачать можно здесь: digininja.org/metasploit/dns_dhcp.php (либо с диска). Главное отличие последнего в том, что поддельные ответы он посылает только для имен, хранящихся в файле dns.txt, остальные пересылаются на реальный DNS. Это позволяет избавиться от некоторых «глюков» и сконцентрировать атаку.
Устанавливаем модуль:
Качаем и разархивируем
Папку dns_mitm кидаем в auxiliary/server в metasploit’e
Папка lib из архива нужна для модуля dhcp_exhaustion, то есть нам не нужна. Заходим в msfconsole.
Здесь мы подгрузили модуль, указали необходимые переменные среды: путь до файла dns.txt и IP настоящего DNS-сервера и запустили его. Кстати, путь под Windows нужно указывать не полный, а относительно папки с Metaspoit’ом, так как MSF исполняется в Cygwin'e. Иначе говоря, нельзя кинуть файлик на диск C и прописать путь к нему.
Файл dns.txt содержит записи вида:
где 192.168.0.1 – IP нашего сайта с начинкой, а google.com – сайт, куда юзер попытается зайти, но попадет к нам. Список можно пополнять во время действия модуля, подгружая по мере необходимости. Делается это за счет отправки специального DNS-запроса на наш фейковый сервер. Можно локально, пишем в консоли:
где 192.168.0.101 – IP поддельного DNS, digininja.reload – «указание» обновить dns.txt (можно поменять в переменной RELOAD в MSF).
Далее. Создаем сайт с начинкой. Эксплойт подбираем под браузер жертвы. Начинка – meterpreter. Тема заезжена, потому кратко. Юзаем Аврору.
В общем-то, все. При попытке жертвы зайти на google.ru, она попадет к нам и… шелл получен.
Задача: Задетектить использование Google-хаков и сканирование директорий веб-сервера
Решение
Google (и аналогичные поисковики) имеют гигантские базы проиндексированных, закэшированных страниц, очень часто хранящих важную с точки зрения безопасности информацию. С помощью специальных запросов можно достаточно просто выискать сервера с уязвимым ПО. Потому хакеры очень часто прибегают к гуглохакам и сканерам для выявления слабых мест в защите сервера.
Для того, чтобы определить такие действия, можно создать хонипот. На ghh.sourceforge.net можно скачать хонипоты, заточенные под гуглохаки, плюс почерпнуть информацию по этой теме. Итак, для хонника, выложенного на диске:
Разархивируем хонипот;
Файл config.php и файл логов кидаем в папку, недоступную для просмотра, то есть не в htdocs (для Apache);
Остальные файлы, кроме readme.txt, кидаем куда-нибудь в htdocs;
В config.php указываешь путь до файла логов и тип логов;
Отключаем RegisterGlobals в php.ini, если оно вообще нужно;
На какой-нибудь из страниц нашего сайта делаем скрытую для глаза ссылку, например, так: <a href=http://example.com/honeypot.php>.</a>, и указав цвет точки под цвет фона сайта;
В index.php нашего пота указываем путь до config.php и адрес страницы, откуда идет ссылка на наш хонник.
Все. После этого ждем пока поисковики проиндексируют наш хонипот.
Обо всех заходах на хонипот, будь то поисковый паук, сканер или какой-нибудь человек, ты сможешь узнать из файла логов. Конечно, вычислить человека ты вряд ли сможешь, но выделить хотя бы какую-то информацию для того, чтобы покопаться потом в логах апача и понять общее развитие атаки – это можно.
Кроме обычных текстовых логов, можно использовать MySQL или XMLRPC, что явно повышает возможности по реагированию.
Кстати, если есть желание повысить свой уровень юзания Гугла для поиска либо уязвимых сайтов, либо другой информации, то можешь заглянуть на hackersforcharity.org/ghdb/. Здесь содержится самая большая база для поиска ПО, стандартных ошибок и т.д. Почерпнуть опыта также можно, найдя книжку «Google Hacking for Penetration Testers by Johnny Long».
Задача: Анонимно сграбить заголовки сервисов на сервере
Решение
Способов масса, но есть один – грубоватый, но забавный. Для нашей цели можно воспользоваться плохо настроенными анонимайзерами. Фишка в том, что php’шные glype-проксики позволяют при определенных условиях коннектиться к любым портам серверов и, к тому же, возвращать заголовки ответов сервисов. Все, что нам требуется, это указать номер порта после имени сервера вида example.com:22, где 22 – номер порта. И, если порт закрыт, нам покажут ошибку «couldn't connect to host», а если открыт, то заголовок сервиса. Для примера, можно побаловаться на www2.de.com/index.php.
В «промышленных масштабах» технология, вероятно, не самая лучшая, но в ограниченных условиях – очень даже. Более того, есть даже концепт-скрипт для автоматизации сканирования, который и на диске есть, и скачать можно с sensepost.co.za/labs/tools/pentest/glype. К тому же, количество общедоступных glype-анонимазиров очень велико, даже пунктик есть в GHDB.
Решение
В последних номерах Х публиковалось много материала о написании эксплойтов. Примеры приводились в основном в Olly Debugger’е и большая часть действий производилась вручную. Как ни странно, существуют более заточенные вещи с учетом специфики эксплойтописания. Для начала – Immunity Debugger. Это, в хорошем смысле, клон Ollydbg версии 1.10. Из основного – приделанная поддержка Python’a для написания дополнений, коих создано уже очень много. Последняя рабочая версия – 1.73 выложена на диске (с 1.74 что-то не срослось из-за количества глюков в ней). Кстати, программа вряд ли будет нормально работать, если установить ее или Python в какое-нибудь нестандартное место. Теперь к главному. Широкоизвестный в узких кругах Peter Van Eeckhoutte aka corelanc0d3r выпустил отличный плагин к ImmunityDbg – pvefindaddr.
Сам проект достаточно быстро развивается, так что лучше скачать последнюю версию с
. На диске выложена версия 1.32. Для установки дополнения требуется:
Скачать pvefindaddr.py;
В папке ImmunityDbg’ра кинуть его PyCommands;
Проверить работоспособность можно через командную строку ImmunityDbg. Вводим !pvefindaddr, и в окне (L)og’a появится описание плагина.
Плагин содержит в себе очень много всяких фишек, которые помогают в эксплойтописании и избавляют от рутинных дел. Приведу несколько примеров.
Находим джампы на регистры:
В результате плагин покажет нам в логе все jmp, call, push+ret и т.д. для указателя на вершину стэка для библиотеки user32.dll и сохранит итог в j.txt.
Поиск offset'ов при переполнении буфера. Для примера возьмем статью Алексея Синцова «Глумимся над объектами ActiveX» из апрельского номера Х. Используем плагин вместо написания скрипта в ComRaider'е.
Создаем паттерн в стиле Metasploit’а.
Копируем его в аргумент в скрипте запуска уязвимой функции SubmintToExpress
Запускаем скрипт в дебаггере. Смотрим ESI – 37694136, SEH – 6B41316B. Пишем:
ESI начинается с 260 байта, SEH с 304.
Ищем модули для обхода ASLR и DEP’a:
Плагин выведет список dll’ок, к которым можно привязаться, так как они скомпилированы без поддержки рандомизации адресного пространства.