Привет, я Зак Фейзел, я буду говорить быстро, если слишком быстро, вы можете меня замедлить.
Днем я пентестер, ночью диджей и фотограф, меня можно найти в Твиттере под ником @zfazel. Люди всегда спрашивают меня о дипломах.
Я не из тех людей, которые перечисляют кучу степеней, поэтому судите обо мне по этой презентации, а не по количеству имеющихся у меня сертификатов.
Бесстыдный комментарий: у нас здесь небольшая конкуренция, прямо сейчас ребята из Чикаго на 4-м треке, мы все из Чикаго, быстрое поднятие рук, кто здесь из Чикаго.
Ладно, думаю, я проиграл пари.
Сегодня вечером я буду диджеить в бассейне, так что, если вы свободны, можете сразиться с Кейт Майерс, а потом я возвращаюсь в Чикаго на очередную хакерскую конференцию.
В прошлом году там было 500 человек, в этом, надеемся, гостей будет больше.
Там же выступят мои ребята из Team 312, дополнительную информацию об этой конференции можно найти на сайте thotcon.org. Итак, чтобы сэкономить время, мы поговорим об альтернативе атаке Pass-the-hash под названием NTLM-Relay, новом наборе инструментов для выполнения межпротокольной ретрансляции для запросов аутентификации 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, который представляет собой широковещательный запрос для этого доменного имени.
По сути, это вопрос сети: «Эй, я ищу имя , вы знаете кого-нибудь с таким именемЭ», распространяя этот запрос по локальной сети в режиме медиатрансляции MBNS. Как я уже говорил, поскольку мы везде используем протокол SMB, то никаких ограничений здесь нет, у нас просто автоматическая аутентификация с использованием SMB. Это вызывает некоторые проблемы.
Давайте посмотрим на метод Pass-the-hash. Из протоколов ясно, что NTML не использует исходный пароль для аутентификации, поэтому все, что нам нужно, — это сам NTML-хеш.
Мы можем получить доступ к хешу NTML с помощью различных инструментов Windows, то есть получить этот хэш из локального хранилища или из памяти.
Все это обсуждалось в других докладах, я просто быстро напомню вам об этом, чтобы показать различия между двумя методами.
Дело в том, что обычно для этого Pass-the-hash требуется доступ на уровне локального системного администратора, поскольку с гостевой учетной записью вы не получите доступ к локальному хранилищу или локальной памяти.
Итак, что такое ретрансляция NTLM и чем она отличается от метода передачи хэша? Мне всегда говорят: «ой, ты про Pass-the-hash!», а я отвечаю: «нет, я про NTLM Relaying!» Разница в том, что ретрансляция NTLM не требует прав администратора для доступа к сети или системе.
Фактически вы подключаетесь к сети изнутри или снаружи и начинаете работать в качестве гостя.
Никаких учетных данных, никакого доступа к системе, происходит только аутентификация по запросу, если вернуться к упомянутым выше типам сообщений 1,2,3. Нет проверки, когда хост выдает ответ на ваш запрос и убеждается, что вы — это вы.
Что мы делаем, так это создаем мошеннический сервер для получения запросов аутентификации и затем ретранслируем их на целевой сервер.
Давайте послушаем историю, чтобы вы поняли суть вопроса.
Давайте вернемся в 1996 год, когда Доминик Брезински обнаружил уязвимость в процессе аутентификации с использованием протокола доступа CIFS, первой версии протокола SMB. После этого впервые заговорили о возможности использования NTLM Relaying. В 2001 году NTLM удалось найти дыру в SMB. Сначала об этом сообщил на одной из конференций DefCon сотрудник Veracode Кристиан Рю (он же Dildog), а затем хакер Джош Бушбиндер (он же Sir Dystic) опубликовал код эксплойта, работающий с этой уязвимостью.
При этом использовался протокол Telnet и уязвимость в браузере IE, где можно было просто ввести телнет://ip и автоматически аутентифицироваться.
После этого метод NTLM Relaying использовался для перенаправления SMB-запросов на другие хосты или на свой собственный хост. Так продолжалось до ноября 2008 года, когда Microsoft Windows заделала дыры там, где могла, предотвратив возврат запроса на аутентификацию NTLM с помощью патча MS08-068.
Таким образом, мы потеряли возможность возвращать запрос аутентификации на наш хост и могли только пересылать его другим хостам из-за особенностей протокола.
В 2008 году на DefCon выступил парень под ником Grutz с заявлением о смерти NTLM. Я считаю, что это было одно из лучших выступлений за последние годы, поскольку оно оказало огромное влияние на корпоративную среду.
Свой инструмент он назвал в честь покемона «Сквиртл», а технологию «обезьяна посередине» по аналогии с «человеком посередине».
Этот инструмент позволял осуществлять ретрансляцию NTLM через HTTP, а также хорошо работал с SMB для получения запросов аутентификации.
Этот скриншот был сделан два дня назад, а его приложение Squirtle все еще находится в разработке.
Я решил, что вы все знакомы с этими уязвимостями, о проблемах которых мы говорим снова и снова, поскольку они никак не устраняются и проявляются повсеместно.
Я работаю в корпоративном мире, поэтому мне хорошо известна проблема, на которую постоянно жалуются люди: сайты не шифруют запросы аутентификации SSL, точно так же, как они не шифруют свои файлы cookie. В 2010 году было выпущено расширение для браузера Firefox под названием Firesheep. Вы, вероятно, знакомы с этим инструментом для перехвата незашифрованных файлов cookie HTTP популярных веб-сайтов и сеансов просмотра других людей через Wi-Fi или перехват сети, выдавая себя за других пользователей.
Я спросил себя, почему у людей возникает желание создавать такие инструменты.
Оказывается, все дело в простоте использования.
Создать приложение, позволяющее выдавать себя за другого человека, довольно легко.
Поэтому я решил начать с того же места и сделать приложение, которое позволило бы использовать метод NTLM Relaying, чтобы показать людям, что это так же просто, как Firesheep. 
Я начал работать над ретрансляцией NTLM, чтобы проверить, поддерживается ли она несколькими протоколами.
О теоретической возможности такой поддержки говорили многие, но на практике никто ее не реализовал.
Итак, моей целью было создать 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? Сука, пожалуйста.
" 
Что содержит этот инструмент? Я быстро пройдусь по этим слайдам, потому что думаю, что уже достаточно вас развлек.
ZackAttack состоит из нескольких различных компонентов, мы поговорим о каждом из них и о том, как они связаны друг с другом.
Прежде всего, есть HTTP SMB-сервер — это мошеннический сервер, принимающий запросы на аутентификацию.
Таким образом, клиенты нацеливаются на этот сервер, проходят аутентификацию, а сервер поддерживает их аутентификацию.
Далее у нас есть набор правил для автоматической работы.
У нас есть клиенты для этих автоматических эксплойтов, а также API, которые мы можем связать с любым сторонним приложением, выполняющим запросы ретрансляции NTLM. 
Наконец, у нас есть поколение полезных данных, которые заставляют клиентов автоматически аутентифицироваться для нас.
Что такое мошеннические серверы? Во-первых, они аутентифицируют пользователей и сохраняют это для нас, о том, как мы этим воспользуемся, я расскажу позже.
Нам нужно, чтобы все эти люди сохраняли свое состояние аутентификации.
Существует множество инструментов, которые отключают пользователей после первой успешной аутентификации, но наш инструмент ZackAttack сохраняет аутентификацию пользователей как можно дольше.
В локальной сети Windows для SMB соединение разрывается примерно 30 раз.
Поэтому нам нужно выяснить, кто этот пользователь, пока мы сохраняем его аутентификацию.
Первый запрос аутентификации представляет собой статический вызов, например 112233. Те из вас, кто занимается пентестированием, знают, что это своего рода вызов радужной таблицы.
Как я уже сказал, нам нужно выяснить, кто этот пользователь, но мы не узнаем этого, пока не доберемся до сообщения типа 3, поэтому рассылаем кучу вызовов.
Я называю это «элементом Альцгеймера», когда система забывает, кто пользователь, и каждый раз просит его пройти аутентификацию для подключения, не закрывая сеанс.
Причина, по которой мы это делаем, заключается в том, что HTTP, WPAD и другие запросы не всегда поддерживают файлы cookie, а аутентификация SMB через IP или исходный порт не работает, если вы пытаетесь сделать это удаленно через Интернет. Итак, для HTTP-сервера мы используем перенаправление 302 с опцией Keep-Alive, которая позволяет нам сохранять сеанс открытым, пока сокет закрыт, и как только мы прошли аутентификацию, мы знаем, кто они, и мы знаем, что для остальных этой сессии.
С SMB было сложнее, пришлось писать собственный SMB сервер, он немного глючный, но все равно работает. Я не буду углубляться в механизм аутентификации протокола SMB, поскольку это займет пару часов, поэтому я буду краток.
После того, как сервер получает запрос на аутентификацию, он как бы забывает, кто этот пользователь, и говорит: «О, привет, приятно познакомиться!» - «круто, хочу подключиться!» — «подожди, ты ктоЭ», и снова требует запрос на аутентификацию.
Итак, нам необходимо получать запросы аутентификации, которые приходят на HTTP и SMB-серверы.
Многие люди спрашивают, как мы проводим атаку «человек посередине».
Есть несколько разных способов заставить людей пройти аутентификацию на нашем сервере, а затем отправить их на другие дела.
Поэтому давайте посмотрим, какая полезная нагрузка доступна в нашем инструменте.
Прежде всего, это WPAD — протокол автоматической настройки прокси, позволяющий определить местонахождение файла конфигурации.
В Windows при попытке подключения, как известно, появляется окно с небольшой галочкой «автоматически найти мои настройки подключения», которое активирует WPAD. Этот протокол отправляет DNS-запросы и запросы сетевого вещания, поэтому вы можете подделать эти запросы и ответить на них.
По умолчанию в Windows компьютер автоматически аутентифицирует сервер WPAD через HTTP с использованием текущих учетных данных пользователя.
18:00 мин.
Конференция DEFCON 20. Захват за 60 секунд: от гостевой учетной записи до администратора домена Windows. Часть 2 Спасибо, что остаетесь с нами.
Вам нравятся наши статьи? Хотите увидеть больше интересных материалов? Поддержите нас, разместив заказ или порекомендовав друзьям, Скидка 30% для пользователей Хабра на уникальный аналог серверов начального уровня, который мы придумали для вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от 20$ или как правильно расшарить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40 ГБ DDR4).
VPS (KVM) E5-2650 v4 (6 ядер) 10 ГБ DDR4 240 ГБ SSD 1 Гбит/с бесплатно до весны при оплате на срок от шести месяцев и более вы можете заказать здесь .
Dell R730xd в 2 раза дешевле? Только здесь 2 x Intel Dodeca-Core Xeon E5-2650v4 128 ГБ DDR4 6x480 ГБ SSD 1 Гбит/с 100 ТВ от 249 долларов США в Нидерландах и США! Прочтите об этом Как построить корпоративную инфраструктуру класса, используя серверы Dell R730xd E5-2650 v4 стоимостью 9000 евро за копейки? Теги: #информационная безопасность #программирование #ИТ-инфраструктура #Конференции #Захват аккаунтов #Захват аккаунтов #Передать хеш #Передать хеш
-
Google Сообщил Людям
19 Oct, 24 -
Пока Все Едут На Запад, Я Переехал В Армению
19 Oct, 24 -
Эскроу (Эскроу) Исходного Кода
19 Oct, 24 -
Яндекс Пробки
19 Oct, 24 -
Оптимизация Затрат На Sms
19 Oct, 24
