Привет, я Зак Фейзел, я буду говорить быстро, если будет слишком быстро, можете меня притормозить. Днём я пентестер, ночью диджей и фотограф, меня можно найти в «Твиттере» по нику @zfazel. Люди всегда спрашивают меня насчёт дипломов. Я не из тех людей, которые перечисляют кучу учёных степеней, поэтому лучше судите обо мне на основании этой презентации, а не по количеству имеющихся у меня сертификатов.
Беззастенчивый комментарий: у нас тут небольшая конкуренция, прямо сейчас парни из Чикаго выступают на 4 треке, мы все из Чикаго, быстро поднимите руки, кто здесь есть из Чикаго. Так, думаю, я проиграл пари. Сегодня вечером в бассейне я буду диджеем, так что если вы свободны, добро пожаловать на битву с Кейт Майерс, после этого я возвращаюсь в Чикаго на другую хакерскую конференцию. В прошлом году там присутствовало 500 человек, в этом году мы надеемся, что гостей будет побольше. Там также выступят мои ребята из команды 312, больше информации об этой конференции вы найдёте на thotcon.org.
Итак, чтобы не тратить даром время: мы будем говорить об альтернативе атаки Pass-the-hash под названием NTLM-Relay, о новом наборе инструментов для выполнения межпротокольной передачи Cross Protocol Relaying для запросов аутентификации NTLM, о новых методах автоматической аутентификации клиентов и о новых целях, в которых можно использовать Pass-the-hash.
Давайте начнём с NTLM, для тех, кто не знает, что такое NTLM 101, всю суть можно изложить меньше чем за 10 минут. Итак, что такое LM/NTLM? Это хранилище паролей и протокол сетевой аутентификации, разработанный Microsoft для использования в Windows. Чёрт, мои слайды не в порядке! Итак, LM-хеш – это формат хранения пользовательских паролей длиной менее 15 символов, пароль разделяется на 2 части по 7 байтов и приводится к верхнему регистру. Надеюсь, вы разглядите, как выглядят хеши LM и NTLM. Я не собираюсь тратить время, рассказывая, насколько плох и слаб LM, вы все это знаете, а если нет – гуглите.
NTLM-хеш обычно чувствителен к регистру, имеет неограниченную длину, не разбивается на группы символов и немного сильнее LM, но также не лишён проблем. Сейчас я о них расскажу. Первая уязвимость заключается в возможности атаки Pass-the-hash, что позволяет хакеру авторизоваться на удалённом сервере, который использует аутентификацию клиентов на основании протоколов NTLM/LM. Извините, ребята, я перепутал слайды, я сделал их 5 минут назад, короче, LM — это отстой.
Итак, что такое NTLM аутентификация? Это сетевая аутентификация для удаленных сервисов. Она нужна, чтобы доказать, что вы действительно являетесь тем, кем вы себя называете. Служба обычно работает на отдельном компьютере, где вы хотите получить доступ к ресурсам, предлагаемым службой, например, файловый сервер — это сервис, а файлы — ресурсы. Через минуту мы рассмотрим, что это за сервисы.
Мы можем запутаться, когда говорим о NTLM v1, v2, NTLM 2, подписанным или неподписанным, так что давайте быстро пробежимся по NTLM аутентификации. В процессе аутентификации отправляется 3 типа сообщений.
Тип 1 – это обращение клиента к серверу для установки контакта, что-то вроде «я хочу аутентифицироваться». Вы видите разобранный на части пакет, захваченный Wireshark, здесь имеются флаги для поддержки аутентификации, имя рабочей станции и принадлежащее ей доменное имя.
Сообщение Тип 2 – это ответ сервера. Если вы заметили, из сообщения Типа 1 мы ещё не знаем, кто этот пользователь, он просто обратился с просьбой подключиться к серверу и хочет узнать, поддерживается ли запрос.
Вы видите здесь ответ сервера NTML Challenge в виде набора цифр, который меняется каждый раз. На скриншоте видно статический ответ, который можно использовать для создания «радужных таблиц». Итак, сервер отвечает сообщением второго типа: «вот что я поддерживаю, вот моё доменное имя, вот моё имя сервера». Этот ответ используется для «соления» хеша вашего пароля, так что всякий раз получается уникальный ответ, и вы не можете повторять его снова и снова с одним и тем же запросом.
Сообщение Тип 3 – это и есть сообщение об аутентификации клиента.
Это ответ сервера, который хешируется с хешем пароля для хеша NTML вместе с именем пользователя, именем рабочей станции и именем принадлежащего ей домена и со сеансовым ключом, если вы подписываете сеанс.
Вот что представляет собой NTML версии 1. NTML версии 2 очень на него похож, но там добавлены дополнительные параметры в ответный пароль и вызов клиента с целью защиты от использования «радужных таблиц», то есть клиент использует против них элемент случайности.
Ещё одно, о чём мы должны поговорить – это встроенная аутентификация Windows. Она нужна для того, чтобы вам каждый раз не приходилось заново входить в систему с помощью пароля, чтобы пользоваться ресурсами и сервисами. Если вы подключились к доменному серверу или внутреннему веб-серверу, Windows не просит вас ввести пароль, она просто запрашивает API и получает от него информацию, что именно система должна использовать для аутентификации.
В контексте локальной безопасности HTTP защищает тем, что использует доверенные зоны безопасности, надёжные узлы или локальные сайты, проверяя лишь однословное имя домена. Я постараюсь быстро освежить вашу память. Однословный домен сначала выполняет поиск DNS-имени на DNS-серверах, затем проверяет его хост или имя DNS- хоста и передаёт его обратно. Он проверяет структуру вашего полного имени и затем выполняет NBNS, который является широковещательным запросом этого доменного имени. Фактически он спрашивает сеть: «эй, я ищу name, вы знаете кого-то с таким именем?», распространяя этот запрос по локальной сети в режиме широковещательной передачи мультимедийных данных MBNS.
Как я уже сказал, поскольку у нас везде используется протокол SMB, здесь нет никаких ограничений, у нас просто происходит автоматическая аутентификация с помощью SMB. Из-за этого возникают некоторые проблемы.
Рассмотрим метод Pass-the-hash. Из протоколов видно, что NTML для аутентификации не использует оригинальный пароль, поэтому всё что нам нужно – это сам NTML- хеш. Мы можем получить доступ к NTML-хешу с помощью различных инструментов Windows, то есть вытащить этот хеш из локального хранилища или из памяти. Всё это описывалось в других выступлениях, я просто быстро напомню вам суть вопроса, чтобы показать различия между двумя методами.
Дело в том, что обычно для этого Pass-the-hash требуется доступ на уровне локального администратора системы, потому что с гостевой учётной записью вы не получите доступ к локальному хранилищу или локальной памяти.
Итак, что такое NTLM Relaying и чем он отличается от метода Pass-the-hash? Мне постоянно говорят: «а, это вы рассказываете о Pass-the-hash!», а я отвечаю: «нет, я говорю о NTLM Relaying!». Разница в том, что NTLM Relaying не требует полномочий администратора для доступа к сети или к системе. Фактически вы изнутри или снаружи подключаетесь к сети и начинаете работать как гость. Нет никаких учётных данных, нет доступа к системе, происходит лишь аутентификация запроса, если вернуться к упомянутым выше типам сообщений 1,2,3. Нет никакой верификации, когда хост выдаёт ответ на ваш запрос и убеждается что вы – это вы.
Что мы делаем – это создаём мошеннический сервер, чтобы получить запросы проверки подлинности и затем ретранслировать их на целевой сервер.
Давайте выслушаем историю, чтобы вы поняли суть вопроса. Вернёмся в 1996 год, когда Доминик Брезинский обнаружил уязвимость процесса аутентификации с использованием протокола доступа CIFS, первой версии протокола SMB. После этого впервые заговорили о возможности использовать NTLM Relaying. В 2001 году NTLM удалось найти дыру в SMB. Сначала про это сообщил на одной из конференций DefCon сотрудник Veracode Кристиан Рю (a.k.a. Dildog), а затем хакер Джош Бушбиндер (a.k.a Sir Dystic) опубликовал код эксплойта, работающего с этой уязвимостью. При этом использовался протокол Telnet и уязвимость браузера IE, где вы могли просто набрать telnet://ip и автоматически пройти аутентификацию.
После этого метод NTLM Relaying стал использоваться для перенаправления SMB-запросов другим хостам или своему собственному хосту. Так продолжалось до ноября 2008 года, когда Microsoft Windows залатали дыры там, где смогли, предотвратив возможность обратного возврата запроса проверки подлинности NTLM патчем MS08-068.
Таким образом, мы лишились возможности возвращать запрос аутентификации своему хосту и могли только перенаправлять его другим хостам из-за особенностей дизайна протокола. В 2008 парень под ником Grutz выступил на DefCon с заявлением о смерти NTLM. Я думаю, что это было одно из лучших выступлений за последние годы, потому что оно оказало огромное влияние на корпоративную среду.
Он назвал свой инструмент именем покемона «Сквиртл», а технологию – «обезьяна посередине» по аналогии с «человеком посередине». Этот инструмент позволял исполнять NTLM Relaying через HTTP и также хорошо работал с SMB, получая запросы аутентификации.
Этот скриншот сделан два дня назад, и разработка его приложения Squirtle ещё продолжается. Я решил, что вы все знакомы с этими уязвимостями, о проблемах которых мы говорим снова и снова, потому что они никак не исправляются и повсюду себя проявляют. Я принадлежу к корпоративной среде, поэтому прекрасно знаю о проблеме, на которую постоянно жалуются – это то, что сайты не делают SSL-шифрования запросов аутентификации, так же, как не шифруют свои кукиз. В 2010 году вышло расширение браузера Firefox под названием Firesheep.
Вероятно, вы знакомы с этим инструментом для перехвата незашифрованных HTTP кукиз популярных веб-сайтов и чужих сессий работы с сайтами через Wi-Fi или сниффинг сетей, выдавая себя за других пользователей.
Я задал себе вопрос, откуда у людей тяга к созданию подобных инструментов. Оказывается, всё дело в простоте использования. Достаточно легко создать приложение, которое позволяет выдавать себя за кого-то другого. Поэтому я решил начать с того же и сделать приложение, которое позволило бы использовать метод NTLM Relaying, чтобы показать людям, что это так же просто, как Firesheep.
Я начал работать над NTLM Relaying, чтобы увидеть, насколько возможна его поддержка несколькими протоколами. Многие люди говорили о теоретической возможности такой поддержки, но никто не реализовал это на практике. Итак, моей целью стало создание Firesheep для NTLM.
Я решил начать изучать Ruby, потому что изначально собирался интегрировать свой эксплойт в Metasploit. В 2012 году я хотел выступить с этой темой на конференциях Black Hat и DefCon, однако мой доклад был отклонён. Мои выступления были не просто отвергнуты, я получил по электронной почте фальшивое сообщение о том, что DefCon принял мой доклад. Друг подумал, что будет очень смешно меня потроллить, такой вот он придурок. У него был здесь товарищ, выступление которого одобрили, и мой друг взял и переслал мне содержимое его электронного письма. Я не обратил внимание на заголовок, где значилось «От Никита» и запаниковал, поняв, что через полтора часа должен выступать на DefCon, но затем получил настоящее письмо с отказом.
Вы думаете, на этом история заканчивается? Нет, три недели спустя Никита говорит мне: «эй, у нас открытие в воскресенье, кто-то отказался участвовать, не хочешь ли ты выступить вместо него?». Я подумал – отлично, но потом спохватился, что у меня очень мало времени до выступления, и принялся кодить как ненормальный, пытаясь вовремя всё закончить.
Итак, в чём заключались мои проблемы? Во-первых, чужие инструменты не могли выполнить нужную мне работу пентестера, им катастрофически не хватало различных протоколов, которые могли бы возвращать обратно запросы аутентификации. Большинство протоколов относились к области использования SMB и HTTP и ни один не поддерживал LDAP для аутентификации MySQL или хотя бы тестирование удалённого рабочего стола, сетей VPN и тому подобное.
Другой проблемой было то, все они пересылали каждый запрос в одно и то же место назначения. То есть мы получали данные пользователей, учётные записи компьютеров и отправляли всю аутентификацию к одной цели, поэтому не могли определить пользователей до аутентификации, то есть до получения сообщения «Тип 3». Если вы помните эти сообщения типа 1,2,3, то сообщение Тип 2 представляет собой ответ сервера. Он уникален для каждой сессии, и я не знаю, кто эти пользователи, пока они не отправят последнее сообщение Тип 3, и я не знаю, какой ответ и от какого сервера относится к пользователю. Меня заинтересовало, почему нет инструментов, которые бы это делали, поэтому я внимательней присмотрелся к протоколам типа SMB и HTTP, позже мы поговорим об этом подробнее.
Windows 8 и Windows 2012 всё еще по умолчанию поддерживают NTLM. Это пугает, потому что мы знаем об уязвимости этих протоколов, однако NTLM никуда не делся. Поэтому мы, как пентестеры, сообщаем организациям, что они должны защищать себя сами от таких атак.
Итак, я захотел решить эту проблему и создал инструмент под названием ZackAttack. Я знаю, что оно смотрится уродливо, но мы перебрали целую кучу названий, лично мне больше всех понравилось последнее – «NTLMv2? Bitch Please…».
Что же содержится в этом инструменте? Я быстро пробегусь по этим слайдам, так как считаю, что уже достаточно вас развлек. ZackAttack состоит из нескольких различных компонентов, мы поговорим о каждом из них и о том, как они связаны друг с другом.
Прежде всего, здесь есть HTTP SMB сервер – это мошеннический сервер, который принимает запросы аутентификации. Так что клиенты нацеливаются на этот сервер, выполняют аутентификацию, и сервер удерживает их аутентифицированными. Далее у нас имеется набор правил для автоматической эксплуатации.
У нас есть клиенты для таких автоматических эксплойтов, так же, как и API, которые мы можем связать с любым посторонним приложением, выполняющим перенос запросов NTLM Relaying.
Наконец, у нас имеется поколение полезных нагрузок, заставляющих клиентов автоматически аутентифицироваться для нас.
Что представляют собой мошеннические серверы? Во-первых, они выполняют аутентификацию пользователей и сохраняют её для нас, позже я расскажу, как мы это используем.
Нам нужно, что бы все эти люди сохраняли своё состояние аутентификации. Существует множество инструментов, отключающих пользователей после первой успешной аутентификации, но наш инструмент ZackAttack удерживает пользователей аутентифицированными так долго, как только возможно. В Windows LAN для SMB это примерно 30 раз до того, как соединение будет разорвано. Итак, мы должны выяснить, кто этот пользователь, пока держим его аутентифицированным.
Первый запрос аутентификации представляет собой статический вызов типа 112233. Те из вас, кто занимается пентестингом, знают, что это своего рода задача для «радужных таблиц». Как я сказал, мы должны выяснить, кто этот пользователь, но не знаем этого, пока не дойдем до сообщения Тип 3, поэтому отправляем кучу вызовов. Я называю это «элементом Альцгеймера», когда система забывает, кто пользователь, и просит его аутентифицироваться каждый раз для подключения без закрытия сессии.
Причина, почему мы так делаем, состоит в том, что HTTP, WPAD и другие запросы не всегда поддерживают кукиз, кроме того, идентификация SMB через IP или порт источника Source Port не работает, если вы пытаетесь проделать её удалённо через интернет.
Поэтому для HTTP-сервера мы используем 302 редирект с параметром Keep-Alive, что позволяет держать сессию открытой, в то время как сокет закрывается, и после того как мы аутентифицировались, мы знаем, кто они, и мы знаем это до конца данной сессии.
С SMB было труднее, мне пришлось писать пользовательский SMB-сервер, он немного забагован, но всё равно работает. Я не собираюсь углубляться в механизм аутентификации протокола SMB, потому что это займёт пару часов, так что объясню кратко. После того, как сервер получает запрос аутентификации, он как бы забывает, кто этот пользователь, и говорит: «о, привет, приятно познакомиться!» — «круто, я хочу подсоединиться!» — «подождите, а кто вы такой?», и снова требует запрос аутентификации.
Итак, нам нужно получить запросы аутентификации, которые поступают на HTTP и SMB серверы. Многие люди спрашивают, как мы осуществляем атаку «человек посередине». Существует несколько различных способов, как заставить людей аутентифицироваться на нашем сервере, а затем послать их заниматься другими делами. Поэтому рассмотрим, что представляет собой полезная нагрузка, имеющаяся в нашем инструменте.
В первую очередь это WPAD – протокол автоматической настройки прокси, который позволяет определить место расположения конфигурационного файла. В Windows при попытке подключения, как вы знаете, появляется окно с маленькой галочкой «автоматически находить настройки моего соединения», которая активирует WPAD. Этот протокол отсылает запросы на проверку DNS и сетевого вещания, так что вы можете подделать эти запросы и ответить на них.
По умолчанию в Windows компьютер будет автоматически выполнять аутентификацию WPAD-сервера по HTTP с актуальными учётными данными пользователя.
18:00 мин
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
(KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до весны бесплатно при оплате на срок от полугода, заказать можно тут.
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Автор: ua-hosting
