Архив за Сентябрь 2012

ПРОВЕРЯЕМ ВЕБ-СЕРВИСЫ НА СТОЙКОСТЬ

Четверг, 6 Сентябрь 2012

WS-Attacker — модульный фреймворк, написанный на Java, для проведения тестов на проникновение через веб-сервисы. Программа на вход запрашивает путь до WSDL IWeb Services Description Language! и извлекает из него всю полезную информацию для тестирования: методы с параметрами и так далее. Фреймворк является расширяемым с помощью плагинов и в своем составе по умолчанию имееттри плагина, реализующих следующие атаки:
• Signature Wrapping;
• SOAPAction Spoofing;
• WS-Addressing Spoofing.
По результатам работы плагинов программа сама отображает, какие методы и каким атакам подвержены. Помимо этого программа также способна в удобном виде отображать характеристики:
• интерфейсов;
• методов;
• запросов.
Программа позволяет автоматически и вручную (с нелегитимными данными) формировать запросы к веб-сервисам и просматривать ответы.

ЭКСПЛУАТАЦИЯ XSS ВМЕСТЕ С METASPLOIT

Четверг, 6 Сентябрь 2012

The Cross-Site Scripting Framework IXSSFI — инструмент для эксплуатации XSS-уязвимостей более легким способом. Проект XSSF призван продемонстрировать реальную опасность XSS-уязвимостей, упрощая их эксплуатацию до простого выбора модулей атак. XSSF позволяет создать канал связи с целевым браузером [от XSS-уязвимости) для выполнения дальнейших действий. Программа реализована в виде модуля для Metasploit и тесно интегрирована с ним, но помимо этого она имеет и собственный веб-интерфейс, где отображается информация о проэксплуатиро-ванных целях:
• IP-адрес;
• название браузера;
• версия браузера;
• наличие cookie.
Благодаря интеграции с Metasploit Framework возможно легко запускать брау-зерные эксплойты из его состава через XSS-уязвимости. Также благодаря создаваемому XSSF Tunnel возможно действовать от сессии жертвы. Для запуска модуля необходима команда:
load xssf

ВОССТАНАВЛИВАЕМ ТАБЛИЦУ ИМПОРТОВ

Четверг, 6 Сентябрь 2012

Scylla Imports Reconstruction — это утилита для восстановления таблицы импортов дампов. Инструмент из новых, но уже успел завоевать популярность. Как пишет сам автор, во всех программах для восстановления импорта [ImpRec, CHimpREC, Imports Fixer и так далее! есть недостатки, и он решил сделать свой инструмент, в котором их не будет. Особенности:
• встроенный дампер;
• редактирование РЕ-секций;
• редактирование кода;
• правка IAT и ОЕР;
• поддержка х86 и хб4;
• полная поддержка юникода;
• поддержка плагинов
(включая плагины от ImpRec, что особенно ценно];
• отлично работает нa Windows7.
Программа распространяется с открытыми исходными кодами. В качестве дизассемблера используется проект diStorm. Обрати внимание, что Windows XP хб4 имеет некоторые баги в API, так что под этой ОС полностью восстановить на 100% правильную таблицу импорта невозможно. Разработчик вообще всячески рекомендует использовать в качестве рабочей системы Windows хб4, под которой работает сам.

КАК ПРОХОДИЛ CTF?

Четверг, 6 Сентябрь 2012

Грандиозный CTF, проведенный в рамках PHDays, заслуживает отдельного слова. Площадка, на которой разместились 12 именитых команд, занимала львиную часть большого Progress-Bar’a, где на протяжении двух дней тусовалось огромное количество людей, связанных с информационной безопасностью. Как и в классическом CTF, основной задачей участников было выявить уязвимости в системах противников и получить доступ к секретным ключам, индивидуальным для каждой команды. Участники параллельно работали над поиском уязвимостей сразу в четырех сервисах, состояния которых, а следовательно, и их баги менялись каждые несколько часов. Основные очки участники получали за эксплуатацию найденных ими уязвимостей на серверах команд-соперников. Доказательством успешной эксплуатации являлся MD5-xeiu, после добавления которого в скоринг-систему команде начислялись баллы в зависимости от сложности задания, установленной организаторами. Если какой-либо из сервисов команд был недоступен более пяти минут, команде начислялись штрафные баллы. Все честно.
Заветные баллы команды могли получить и за решение заданий из зоны хак-квеста — отдельной сети, в которой находились серверы с уязвимыми сервисами. Эти задания участники могли решатьтолько методом черного ящика, то есть локального доступа к системам у них не было. Параллельно задания могли решать все желающие с любого конца света — для этого был построен VPN-канал до этой сети.
Чтобы участники не засиживались на месте, им предоставлялась возможность получить дополнительные баллы, занявшись так называемым dumpster diving,— короче говоря, поупражняться в добыче информации старым как мир путем. Для этого организаторы поставили по-настоящему огромный прозрачный бокс, заваленный распечатками на А4. Кроме листов с мусорной информацией, можно было найти и бумаги стеми самыми «флагами», за которые начислялись очки.
Забавным ответвлением основной легенды также было задание «Царь горы». Это максимально реалистичный конкурс для пентестеров: типовой периметр сети среднестатистической компании с уязвимыми веб-приложениями и различными сервисами, за всем этим скрывается Microsoft Active Directory. Задача участников — обнаружить уязвимости в системах;воспользоваться ими и максимально долго удерживать захваченные системы. Как? Дело в том, что после захвата системы одной из команд, цепочки уязвимостей перегенерируются, и у команды был выбор: либо пытаться захватить смежные системы, либо продолжить поиск уязвимостей в уже захваченной системе. К слову, время удержания Active Directory было самым дорогим. Оно и понятно, ведь для того, чтобы провести атаку на службу каталогов, требовалось удерживать системы, расположенные на первом уровне. Все как в жизни… (далее…)

PHDays 2012

Четверг, 6 Сентябрь 2012

Первое, что привлекало внимание каждого, кто появлялся на I площадке Positive Hack Days, — это огроменный аквариум,
заваленный распечатками А4. «Что это?» — спрашиваю я у организаторов, компании Positive Technologies. Это одно из заданий грандиозного CTF, в котором участникам нужно будет показать навыки олдскульного способа добычи полезной информации, копаясь в буквальном смысле в мусоре. Уже с этого момента становится ясно, что конференция будет гораздо большим, чем сессии докладов, параллельно идущих s нескольких залах. Это ощущение укрепляется, когда обходишь немаленькую территорию конференции, — кстати, все происходило в центре Москвы на одной из самых продвинутых площадок с символическим названием Digital October. Огромное количество декораций, стендов, затравок для конкурсов, атмосферный бар с бесплатным алкоголем, но главное… невероятное количество знакомых людей. Кажется, что собрать еще больше спецов из области ИБ под одной крышей невозможно. Ну или по крайней мере очень сложно. Простой пример: мы познакомились сразу с несколькими авторами ] [, которых раньше знали только виртуально. В итоге всю конференцию мы были в состоянии выбора: то ли пообщаться с интересными людьми, то ли бежать на доклад. Но если доклад, то какой? Часто интересные выступления были параллельно. Впрочем, была доступна прямая видеотрансляция, что решало проблему.

SQL, О ЧЕМ РЕЧЬ?

Четверг, 6 Сентябрь 2012

Класс атак,техника эксплуатации которых позволяет получить нам искомый выигрыш во времени, в англоязычном интернете обычно описывается как DNS Exfiltration. Изначально понятие «exfiltration» было военным термином, под которым подразумевалось возвращение агента разведки на родину. В Сети под этим словом в контексте ИБ обычно понимается незаконное извлечение данных из информационных систем. При использовании этой техники в контексте SQL-инъекций появляется способ извлечения данных через DNS, при котором возможно пренебречь ожиданием ответа от серверного приложения при эксплуатации слепых инъекций и получить результаты выполнения своих SQL-запросов (например, имена пользователей и пароли], отправляя на свой DNS-сервер DNS-запросы, содержащие данные из СУБД уязвимого приложения. Использование этой техники дает ряд неоспоримых преимуществ по сравнению с time-based или true/false техниками: во-первых, нам не требуется дожидаться ответа от веб-сервера, что существенно ускоряет процесс, во-вторых, за один запрос мы можем вытащить много больше данных. В-третьих, техника не накладывает ограничений на нестандартные типы данных, таблицы и названия столбцов.
DNS-запросы мы будем передавать по протоколу DNS, что неудивительно :) . Это относительно простой протокол. Запрос, выполняемый DNS-клиентом, и соответствующий ему ответ, предоставляемый DNS-сервером, используют один и тот же формат DNS-сообщений. За исключением трансферов зон, использующих для надежности протокол TCP. DNS-сообщения инкапсулированы в UDP-датаграммы — минимальные единицы информации в протоколе UDP для обмена информацией lbit.lv/MtolDxl на транспортном уровне модели OSI lbit.lv/qqHbREl. Для любого человека, осуществляющего мониторинг машины с помощью инструмента, подобного Wireshark, скрытый канал передачи данных, выполненный поверх DNS, будет выглядеть как небольшие серии всплеска DNS-трафика.
В основе работы такого неконтролируемого канала передачи данных лежит’процесс передачи DNS-запросов от безопасных систем (локальных компьютеров] к произвольным DNS-серверам, расположенным в интернете. Даже если предположить, что выход во внешнюю сеть запрещен, но целевая машина способна резолвить произвольные доменные имена, то передача данных возможна средствами отправляемых DNS-запросов.

SQL-ИНЪЕКЦИИ ЧЕРЕЗ DNS

Четверг, 6 Сентябрь 2012

SQL-инъекции — одна из самых распространенных уязвимостей современных веб-приложений. Разработчики постоянно закрывают массу дырок, связанных с этой проблемой, но хакеры по-прежнему находят способы эксплуатации этой старой как мир уязвимости. Сегодня я расскажу тебе о не новой, но действительно крутой технике извлечения данных из SQL-баз с использованием DNS-запросов, которая в умелых руках может стать грозным оружием любого современного пентестера. Готов? Поехали!

Под SQL-инъекцией подразумевается внедрение произвольного SQL-кода в запрос к СУБД для получения доступа к данным таблиц. На практике это зачастую выглядит как специально сформированный запрос к странице вида http://target.com/get_data.asp7idH, где вместо 1 в параметре id хакер пытается «пропихнуть» серию из SQL-команд, которая позволяет получить доступ к содержимому базы данных.
В зависимости от логики работы уязвимого приложения, техники эксплуатации SQL-инъекций принято делить на три большие группы: классические, слепые и абсолютно слепые.
Одно из отличий слепых инъекций от классических состоит в том, что для эксплуатации они требуют очень много времени и большое количество запросов, ведь данные «вытягиваются» бит за битом. Поэтому атакующему обычно необходимо отправить десятки тысяч запросов, чтобы вытянуть содержимое таблички среднего размера, что можеТ’быть замечено бдительным администратором уязвимой системы.
Однако есть способы, позволяющие значительно увеличить скорость получения данных из СУДБ при эксплуатации слепых инъекций, при этом снизив количество  запросов к самой базе. Об одном из таких методов мы сегодня и поговорим.

ОРГАНИЗОВАТЬ ТУННЕЛЬ ЧЕРЕЗ XSS

Четверг, 6 Сентябрь 2012

Итак, опять представим себе ситуацию. Есть сервер с административным веб-интерфейсом, есть админ и есть мы, а хотим мы поовнить данный сервачок. Предположим, что каких-то сверхкритичных уязвимостей на вебе найдено не было, а только, скажем, XSS’Ka. И вроде бы все отлично: хватай ХББ’кой куки, и вперед! Но как бы не так.Как минимум,проблемой может стать установленный сервером для кукисов флаг HTTPOnly, который не даст нам возможность вынуть их из браузера админа. Другой проблемой может стать фильтрация по IP доступа к веб-серверу или к самой админке. И что же тогда делать? Организовать туннель через XSS. Что бы там ни говорилось о продвинутом использовании XSS’ok, но самым мощным payload’oM, я думаю, является как раз XSS-туннель. Зачем нам аутентификационные куки, когда мы можем напрямую выполнять какие-то действия на сайте от имени нашей жертвы?
Но постой. Давай посмотрим, что же такое XSS-туннелинг. Если говорить в общем, то это специальный JavaScript, который подгружается ХББ’кой нашей жертве. Далее этот JS открывает какую-нибудь страницу на атакуемом сайте и полностью ее нам пересылает. Мы видим ее в своем браузере, кликаем, куда нужно, но наши действия не выполняются браузером, а передаются обратно в этот JS, который и произведет необходимые действия на атакуемом сайте, но от имени жертвы. Причем жертва об этом не будет догадываться.
Описание, конечно, очень общее, для понимания идеи. На практике все происходит несколько сложнее,количество элементов несколько больше, и это мы сейчас рассмотрим на примере BeEF.
BeEF — это специальный фреймворк для проведения мощных и глубоких атак на браузеры с использованием XSS’ok. На самом деле, может быть, не очень хорошо получается, что описывать такую прекрасную вещь, как BeEF, мне приходится в несколько строк, ведь она заслуживает отдельной статьи. Но я думаю, что в следующих выпусках мы это поправим.
Итак, BeEF представляет собой трехкомпонентную систему: 1. Браузеры жертв — hoocked browsers. Браузеры, в которые нам удалось подгрузитьсвой, аточнее BeEF’a, JavaScript-код. Ядро BeEF’a — главное связующее и всеобрабатывающее звено. Интерфейс BeEF’a, к которому атакующий подключается, используя свой браузер, и через который он может«управлять» жертвами. На самом деле не совсем управлять, а скорее за пускать те или иные атакующие модули.
Если посмотреть на это в процессе, то атакующий с помощью XSS’ok или просто заманив жертву себе на сайт, подгружает ей в браузер JS BeEF’a. Данный JS «устанавливает соединение»  с ядром фреймворка и ждет от него команд [систематически стучится]. Атакующий через интерфейс может указать действие для какого-нибудь из браузеров жертв, выполнить сканирование портов например. Ядро, получив от атакующего команду, переправит к жертве еще дополнительный кусок JS, который исполнит указанную команду (то есть сканирование портов], а результат отправится обратно в ядро. Кроме сканирования портов, можно в любой момент подгрузить какой-нибудь эксплойт, например, и захватить контроль над тачкой. На самом деле это очень мощная штука. Получается, что люди как бы садятся на крючок…

Но вернемся к туннелю. Одним из атакующих модулей BeEF’a является Tunnel Proxy (aka XSS-туннель].
Для того чтобы сделать XSS-туннель, нам потребуется прописать в нашем браузере специальный прокси-сервер от BeEF’a (по умолчанию 127.0.0.1, порт 6789). После этого все клики в нашем браузере (то есть HTTP-запросы! будут обрабатываться этим прокси. Данный прокси, получая запрос от атакующего, модифицирует его специальным образом и переправляет JS модулю BeEF’a в браузере жертвы. Этот модуль выполняет запрос на атакуемый сервер, но от имени заХЗБ’енной жертвы. Результаты запроса (HTML-страничка! получаются этим JS-модулем BeEF’a и переправляются обратно в ядро BeEF’a. Оттуда данные конвертируются и передаются на BeEF-прокси, который, в свою очередь, отображает страницу для браузера атакующего. То есть фактически атакующий видитто, что «видит» жертва. Далее атакующий может выполнить еще какое-то действие, например ввести какую-нибудь форму и отправить ее. Все эта операция повторится, JS BeEF’a отправит от имени жертвы данный запрос, и результаты его попадут обратно атакующему.

ПОЛУЧИТЬ ЛОГИН И ПАРОЛЬ ОТ SSH

Четверг, 6 Сентябрь 2012

Взаимодействия в Сети, является одним из главных админских интерфейсов. И если атаки на другие интерфейсы (Web, SSL, RDPl мы уже разбирали в Easy Hack, то SSH почему-то обошли стороной. Что ж, исправляемся.
Итак, давай представим простую ситуацию: есть сетка, есть админ, есть сервер с открытым SSH, которым активно пользуется админ для удаленного администрирования. Нам же необходимо получить доступ к данному серваку. И как же это сделать? Ответ: сейчас чаще всего — никак. Ну, в смысле не совсем никак, но точно не через SSH. Здесь слабое звено стоит искать либо в других сервисах’сервера, либо в самом админе… Причины — высокая защищенность последней версии SSH на уровне протокола и малое количество эксплойтов под ПО… Хотя я, наверное, перегибаю палку, говоря «никак». Все же пути есть.
Конечно, первое, что приходит на ум, — bruteforce. Тогда ТНС Hydra нам в руки и в бой! Но возможно, это и не потребуется, если нам повезет. А наше везение во многом зависит оттого, насколько стар атакуемый сервер.
Наш шанс в том, что он будет поддерживать SSH версии 1. Эта версия протокола SSH имеет серьезную проблему, которая позволяет нам, атакующим, провести классическую man-in-the-middle атаку и в итоге видеть незашифрованный трафик. В общем виде атака представляет собой следующий процесс:
1. Мы проводим ARP-спуфинг между админом и сервером и таким образом контролируем передаваемый трафик.
2. Админ коннектится на сервер noSSH.
3. Серверотправляетсвой открытый ключ клиенту.
4. Мы подменяем этотключик на свой.
5. КлиентЭБИ админа выбираетшифрование, генеритсессионный ключ, шифрует его открытым ключом сервера и отправляет его.

6. Та к ка к клиентзашифровал сессионный ключ нашим открытым ключом, то мы его расшифровываем и передаем дальше серверу.
7. Зашифрованное соединение на основе сессионного ключа установлено. Но мы знаем этот ключ, а потому можем расшифровывать проходящий через нас трафик.
Этот процесс и показан на рисунке. Фактически данную атаку можно реализовать с помощью Ettercap или Cain.
Теперь же самое важное — как много осталось серверов, которые поддерживают SSH v1? Точно я не скажу, но во время проведения пентестов они систематически попадаются. Сама атака стала общеизвестна году так в 2000-2001-м. А потому почти все новые серваки и железки поставляются уже с правильной версией SSH. Но в то же время всякое пятилетнее оборудование может быть уязвимо. Особенно это относится к сетевому оборудованию и всевозможным нестандартным железкам (например, контроллерам], безопасностью которых производители плохо занимаются.

ПРОВЕРИТЬ УСТОЙЧИВОСТЬ ВЕБ-СЕРВЕРА К SLOW POST

Четверг, 6 Сентябрь 2012

В прошлый раз мы начали разбирать классические и не очень классические DoS-атаки на веб-серверы. Сегодня продолжим, поэтому я опускаю вводную часть.
Итак, позвольте рассказать про атаку slow HTTP POST DoS. Название ее определенно говорящее. Идея атаки в том, чтобы уложить HTTP-сервер за счет использования «медленных» P0ST-запросов на сервер. Так, в заголовке POST-запроса клиент передает серверу Content-Length большого значения, а после удачного запроса начинает очень медленно передавать данные. Веб-сервер получаеттакой POST-запрос, видит в нем Content-Length и ждет соответствующее значение данных в теле запроса, но, как я уже сказал, данные приходят к нему медленно, по чуть-чуть.
Таким образом, атакующий, имея под своим контролем небольшое количество хостов (возможно, даже один], может создавать такие «висящие коннекты» и израсходовать ресурсы сервера, так что тот не сможет отвечать легитимным клиентам. Исчерпавшиеся ресурсы могут быть различны. Например, можно занять все потоки или занять ими всю память.

Как видно, данная атака основывается на «уязвимостях» самого протокола HTTP. Ведь мы не вылезаем за рамки протокола, а эмулируем множественное подключение медленных клиентов. То есть с точки зрения логов, если все настроить правильно, жертва может долго не догадываться о причинах падения ее сервака. Такая «нормальность» атаки рождает достаточно неприятную проблему — от нее непросто защититься.

Если посмотреть более общим взглядом, то можно заметить, что данная атака во многом похожа на описанный в прошлом номере Slowloris. Да и вообще вспоминаются разнообразные олдскульные атаки, типа SYN-flood’a, — история повторяется на новом уровне. Но даже с учетом большого сходства Slowloris и Slow POST’a они достаточно различны с точки зрения атакующего потенциала. Как минимум если, используя Slowloris, можно завалить в основном Apache-подобные веб-серверы, то slow POST’y подвержены почти все основные серверы. Это и тот же Apache, и все версии IIS, и что-то альтернативное вроде lighttpd. Что касается nginx, то ситуация с ним не совсем ясна. Чисто теоретически он не должен быть подвержен такой атаке, но фактически, с учетом тех или иных настроек его самого и ОС, на которой он крутится, иногда получается его завалить.

Архивы

Вы сейчас просматриваете архивы сайта Бизнес и финансы за Сен 2012.

КартаКарта