Содержание статьи
Автоматизация обхода проверки подписи в XML (XML Signature Wrapping)
Решение: В прошлый раз я расписал большую задачку про то, что такое XML Digital Signature и что за атака XML Signature wrapping (XSW). Сегодня мы продолжим ее, но чисто в практическом ключе.
Кратко напомню о технологии. XML DSig позволяет нам создать электронную подпись части или «целого» XML-документа. При подписи XML-документа в его начало добавляется заголовок, содержащий подпись. Проблема заключается в том, что заголовок с подписью использует для ссылки на ту часть, которая подписана, технологию XPointer (или аналогичную, например XPath), а она, в свою очередь, не позволяет достоверно определить расположение подписанного элемента в теле всего документа.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.Таким образом, XSW-атака в простейшем виде требует того, чтобы атакующий переместил подписанный кусок XML в заголовок, а на его место подставил бы другой, интересующий его. Получив такой документ, XML-парсер возьмет подпись из заголовка, а также подписанный кусок, и тоже из заголовка, и в итоге подпись сойдется. Но, что хуже, в дальнейшую обработку пойдут данные от злоумышленника, так как они находятся в теле, а не в заголовке (см. рис. 1). Надеюсь, что ты вспомнил.
Конечно, звучит это все очень просто и легко. На практике возникает приличная проблема. Хотя сама по себе она типична: несмотря на то что XML DSIG и XML вполне точные стандарты, различных парсеров (на разных уровнях) много. К тому же здесь еще есть зависимость от работы самого приложения. Это все приводит к тому, что вариантов перестановок очень много. Например, возможно, «не прокатит» перенос легального тела в заголовок, а надо сделать два последовательно идущих тела, причем в правильной последовательности. Или надо для XSW перенести легальное тело в тело интересующего нас… То есть вариантов много-много, и все необходимо тестировать.
И вот потому прошу обратить твое внимание к чудесному «фреймворку». Название его —WS-Attacker, автор — Кристиан Майнка (Christian Mainka).
Несмотря на свою фреймворковость, тулза эта умеет делать пока только три вещи. Итак, пробегусь по модулям:
Атака SOAPAction Spoofing. Основывается на том, что SOAP позволяет задать Action (то есть какая операция должна проводиться в приложении), как с помощью указания в Body, так и с помощью заголовка (пример есть ниже в задачке про VMware). Но последнее опционально.
Атака же состоит в том, чтобы нарушить процесс авторизации за счет указания какого-то другого Action в заголовке. Наши права проверятся по команде из Body, а фактическое действие производится из заголовка. Хотя, признаюсь, на практике я такого не встречал.
WS-Addressing Spoofing. Эта атака основывается на технологии WS-Addressing. Она позволяет задавать «маршруты» для передаваемого XML-документа. То есть мы можем указать, какому XML-сервису адресован документ, куда отсылать ответ, куда отсылать сообщения об ошибках. Задаются маршруты простым добавлением URL’ов. Так что это проще сделать ручками.
XSW. С помощью этого модуля мы почти полностью автоматизировано можем определить вектор для XSW-атаки. И это очень круто! Но так как модуль несколько не юзер-френдли, то я позволю себе расписать последовательность действий, необходимых для настройки XSW-модуля.
- WSDL Loader -> Указываем URL до атакуемого сервиса -> LOAD;
- Expert View — вставляем украденный XML-документ с валидной подписью (даже если время жизни, так называемый Timestamp, уже просрочено);
- в Test Request надо послать тестовый запрос;
- Plugin Config -> Signature Wrapping;
- WS-attacker анализирует введенный XML-документ и определяет все подписанные части. Чаще всего это Body и Timestamp. С последним WS-Attacker сам уже знает, что делать. Но если есть желание, в Show можно указать, какая часть документа будет меняться;
- далее самое главное — Reference Element. Здесь мы должны указать итоговый XML-документ, который нам необходимо внедрить, то есть нагрузку. Рекомендуется выбрать такой, чтобы было понятно, что атака прошла, но при этом чтобы все не сломать. Цель ведь — определить «магическую» последовательность данных. Это обязательный этап;
- иногда веб-сервис не плюется ошибками в случае некорректных запросов, а отображает ответ на изначальные (не подмененные данные). Так, например, ведет себя фреймворк для веб-сервисов CXF. И WS-Attacker по ошибке считает атаку успешной. Чтобы такого не происходило, необходимо указать в Search уникальный текст, который должен быть возвращен, только при успешной атаке;
- Attack Overview -> Start;
- в поле Content отобразится итоговый запрос для проведения XSW-атаки.
Кстати, у WS-Attacker версии 1.1 была проблема: в итогах выводился запрос для проведения атак, но без использованных схем, что очень удручало. Нормальный запрос можно было выискать, только покопавшись в логах. Так что качай последнюю версию — 1.2.
Еще из косяков стоит отметить то, что тулза за один запуск может быть натравлена только против одного веб-сервиса. Если указать ей другой, то она начинает подглючивать. А в общем — незаменимая тулза получилась.
Удаленно включить компьютер
Решение: Ты, наверное, знаешь такую штуку, как Wake-on-LAN. Это бородатая технология, которая позволяет удаленно включить какой-то компьютер, отправив по сети специальный пакет. Вот такое простое решение :).
Оно нам может пригодиться, чтобы расширить скоуп того, что можно поломать в какой-то локальной сети. Подключились мы удаленно к корпоративной сети в выходные дни, а большинство хостов юзеров отключено. И тут мы возьмем и включим их, и похакаем всех :).
Теперь поподробнее о технологии. Суть ее заключается в том, что комп в выключенном состоянии продолжает питать сетевую карту. А та, в свою очередь, просматривает трафик в желании отыскать специальный пакет (magic packet). При этом стоит отметить, что сетевая карта не разбирает входящие пакеты по стеку TCP/IP, а просто ищет последовательность (magic packet). То есть она может быть инкапсулирована в любой протокол сетевого или транспортного уровня. Хотя чаще всего в качестве основы используется протокол UDP и порт 9 (иногда 7).
Важно еще и то, что сетевая карта в таком состоянии не имеет выделенного адреса и в качестве IP в UDP-пакете используются широковещательные адреса. И как следствие, без специальной маршрутизации на сетевом оборудовании мы можем посылать WOL-пакеты только в сегмент, к которому подключены. Если же говорить о самом Magic Packet, то он вполне прост:
- шесть байт со значением «FF», как некий заголовок;
- шестнадцатикратное повторение MAC-адреса сетевой карты «получателя». Пример для хоста с MAC 01:02:03:04:05:06 — на рисунке. Вдобавок к этому на некоторых девайсах, поддерживающих WOL, имеется возможность добавить пароль (длиной до шести байт).
Теперь поговорим об «атаке». Все, что нам нужно для включения хоста, — знать его MAC (и иногда пароль). Если мы знаем производителя сетевухи, то мы уже имеем на руках первые три байта и можно попытаться перебрать остальные три. Но все-таки лучше эти данные получить из других мест. Например, заранее просканировав по ARP или поснифав трафик. Из последнего метода мы также можем вытащить и пароль, так как он передается в открытом виде.
Для отсылки WOL-пакетов есть целый ряд всяких тулз. Но WOL-Explorer (авторства Натаниэля Карью — Nathaniel Carew) имеет ряд допфишечек и к тому же входит в BackTrack 5 (/pentest/enumeration/wol-e). А потому пара-тройка примеров с ней:
1. Запуск одного хоста:
wol-e.py -m 01:02:03:04:05:06 -b 192.168.1.255 –p 9 –k
2. Брутфорс MAC-адресов
wol-e.py -a
Первые байты MAC-адреса берутся из файла bfmac.lst
3. Сниф трафика (-s) в сети на WOL-пакеты и WOL-пароли
wol-e.py -s -i eth0
4. ARP-скан подсетки и определение Apple-девайсов
wol-e.py -f
Если же говорить о распространенности технологии, то она, ИМХО, очень даже распространена. Думаю, что все современные стационарные компы поддерживают ее (точнее, поддержка нужна со стороны блока питания и мамки). Вопрос в том, разрешена ли она в БИОСе изначально… По слухам, во многих Apple-продуктах включена.
Обойти аутентификацию или авторизацию (Verb Tampering)
Решение: Многие веб-серверы имеют встроенные возможности разграничения доступа. Простейший пример — это ограничить доступ админке (к директории admin). А при обращении к ней требовать от пользователя аутентифицироваться, используя Basic-аутентификацию. Большой плюс в том, что разграничение доступа реализуется только за счет возможностей веб-сервера. И не надо париться со скриптами, писать код какой-то…
Кроме этого, опять-таки большинство браузеров позволяют еще внедрять контроль HTTP-методов (они же verb). То есть можно ограничить доступ к какому-то объекту только по методу GET, а POST — разрешить. Это добавляет еще больше возможностей с точки зрения конфигурации. Но, как это часто и бывает, порождает целую прослойку конфигурационных уязвимостей. Что интересно, проблемы с настройкой несколько варьируются в зависимости от веб-сервера, и потому несколько классических примеров.
Есть сервер приложений J2EE, а в нем — web.xml со следующим содержанием:
<security-constraint>
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Здесь все просто. Мы указываем, что доступ к директории admin разрешен только админам (о чем нам и сообщает указанная роль).
Проблема, я думаю, ясна. Здесь также перечислены методы, которые запрещены (то есть используются blacklist-правила). И заметно, что методов «не хватает». Как минимум, админчик позабыл метод HEAD (см. рис. 1). Это метод, по сути, эквивалент GET’а. С той лишь разницей, что сервер отвечает на него по-другому. Обрабатывает, но в ответ не посылает тело, только заголовок.
Таким образом, мы имеем возможность обойти проверку веб-сервера и обращаться к сервлетам, используя метод HEAD. Конечно, нам еще требуется, чтобы в этой директории мы могли сделать что-то «страшное», используя только HEAD, но это уже совсем зависит от конкретного приложения. К тому же на нашей стороне еще и тот факт, что в яве ОЧЕНЬ часто сервлеты не различают GET и POST.
Пример номер два. Apache + PHP. В нем валяется файл .htaccess с вроде бы нормальным ограничением на доступ только с определенного IP (предположим, что это админский IP). Остальные доступ получить не могут (см. пункт deny from all).
<Limit GET POST>
order deny,allow
deny from all
allow from 192.168.0.1
</Limit>
Конечно, ты можешь тут сразу отметить, что отсутствует метод HEAD. Но нет, это здесь не сработает, так как Apache по умолчанию блокирует HEAD, если GET запрещен.
Зато другие особенности нам помогут. Во-первых, Apache, когда используется директива Limit, обрабатывает только известные ему методы запросов (GET, HEAD, POST, TRACE, PUT и так далее полный список смотри здесь. Неизвестные методы он переправляет на уровень выше — приложению, обрабатывающему запрашиваемый файл (например, PHP).
Таким образом ограничения не действуют на эти кастомные методы. Но еще интересней второе. По умолчанию PHP, когда видит неизвестный ему метод, воспринимает и обрабатывает его как GET.
Обобщая сказанное, мы видим, что Apache и PHP создают смесь, которая дает нам простую возможность обойти ограничения апача. Все, что требуется, так это обращаться напрямую к PHP-скриптам, используя нестандартный HTTP-метод (см. рис. 2). Webscarab или Burp отлично подойдут для автоматической подмены метода.
Логичный DoS
Решение: Маленькая задачка про атаку «из дедушкиного сундука». Она сверхпроста, но прикольна в своей идее — для обучения правильному ходу мышления. Название атаки — Land.
Суть ее в том, чтобы указать один и тот же адрес и порт (IP нашей жертвы) в пакете. Таким образом, когда данный пакет попадет к жертве, она на него ответит, но при этом ответит сама себе. Итог — пакеты, которые так и не могут обработаться сетевым стеком, приводят к DoS’у всего хоста.
Некогда эта проблема была во многих ОС и девайсах, включая Windows XP и продукты Cisco. Хотя и сейчас, я думаю, можно найти такие косяки в каких-нибудь embeded-устройствах или промышленных контроллерах…
Повышение привилегий в Windows
Решение: Повысить свои привилегии в Windows, и просто, и не очень. Все зависит от того, как много и какое ПО стоит на хосте. То есть Windows из коробки, не считая каких-то программных уязвимостей, достаточно хорошо защищена. Но все мы живем и должны пользоваться софтом. Это и порождает проблемы конфигурационного плана. Об этом я сегодня и поговорю.
Каждое ПО, когда устанавливается, вносит какие-то коррективы в ОС. И как ни странно, очень часто страдает безопасность, так как многих производителей ПО этот вопрос не очень волнует.
Итак, что нам требуется для повышения привилегий? Найти места, через которые это можно сделать :). Можно пойти двумя путями: либо искать ПО и сервисы, которые имеют более высокие привилегии (то есть цели), либо сначала получить список всего, что нам вообще доступно (а точнее, его отличия от стандартной конфигурации). И тот, и другой способ имеют свои плюсы и минусы, как ты понимаешь.
Несколько трудно, обобщать но искать надо примерно следующее. Места запуска привилегированных процессов (сервисов) и процессов других пользователей; директории, которые доступны на чтение и запись; конфигурационные файлы, реестр — то есть все места, где возможно на что-то повлиять. Плюс не забываем про уязвимости, типа DLL-Hijacking (но об этом я уже писал).
В любом случае одним из главных наших инструментов будет тулза от Марка Руссиновича —accesschk. Она умеет отображать права для всех объектов в Windows и при этом фильтровать только интересующие нас группы и юзеров. А это как раз то, что нам необходимо. Пример.
accesschk -wsu “user” “C:\Program Files\”
где
- w — искать только доступ на запись;
- s — включить рекурсию;
- u — отключить вывод ошибок (удобно, когда у нас не на все есть права);
- User — имя пользователя или группы, для которой будут проверяться права; “C:\Program Files\” — путь к директории, откуда начнется проверка. Также тут можно указать ключ реестра, PID процесса (или *), имя объекта или сервиса.
Так, следующие параметры должны тебе пригодиться:
- c — проверять права к сервисам (* — для всех);
- k — для поиска по ветвям реестра (название ветвей сокращенное, типа hklm);
- p — проверять процессы (* — для всех);
- o — проверять объекты;
- v — вывод полной информации прав для конкретного юзера/группы.
Попробуй просканировать свою ОС, и я уверен, что результаты покажутся тебе очень интересными.
Стоит также отметить, что программа плоховато работает с русскими названиями групп.
Захватить контроль над VMware vCenter (NTLM relay)
Решение: Пару номеров назад я описывал в EasyHack новый модель для Metasploit’a — универсальный NTLM relay от Webstersprodigy. Такого модуля давно не хватало MSF. NTLM relay (SMB relay) как тип атаки — ого-го! И мощна, и гибка. А вот тулзы для юзания всей мощи не было. Теперь же в наших руках мощное оружие. Ну да ладно с похвалой…
Как я и писал в прошлый раз, проблема кроется в самой NTLM-аутентификации, а потому уязвимыми продуктами являются все, что используют ее (и не используют каких-то дополнительных средств для своей защиты). И в подтверждение тех слов — данная задачка.
Есть такая вещь, как VMware vCenter — система централизованного управления ESXi-серверами и виртуалками на них. Поломать ее — лакомое дело, ведь мы можем «выдрать» из нее привилегированные доменные креды и получить привилегированный доступ ко всем виртуалкам. То есть в общем случае поовнить vCenter равняется поовнить всю корпоративную сеть. Алексей Синцов в одном из номеров писал о нашем опыте, о том, как это можно сделать на основе найденных им уязвимостей. Он, конечно, маг и волшебник в поиске уязвимостей :).
Но сейчас немного о другом, о «неисправимом». Вообще, и vCenter, и ESXi серверы (и, вероятно, другие) построены в своей основе на одной платформе. Для общения с ними (не считая веба) нужно использовать специальный vSphere Client. Но если посмотреть на передаваемые данные, то мы увидим, что по сути это обычный веб-сервис, использующий в качестве основы SOAP. То есть можно написать и свой клиент для управления. Во-вторых, у продуктов VMware по умолчанию имеется поддержка Windows-аутентификации. А это в простейшем и основном случае стандартная NTLM-аутентификация. Но и это еще не все. VCenter под виндой в качестве основы для разделения прав использует доменных пользователей. Это все ведет к тому, что мы можем очень просто и легко проводить атаку типа NTLM relay.
И для этого дела я написал NTLM relay модуль для MSF под VMware vCenter — приводящий или к обходу аутентификации (если повезло админу), или к полной компрометации всей инфраструктуры.
Не могу не описать самой атаки в простейшем виде.
Итак, у нас есть: жертва-админ, мы — хакеры и vCenter-сервер. Мы находимся в локальной сети с жертвой.
- Мы заставляем браузер жертвы (IE, например) зайти на наш веб-сервер — модуль MSF.
- Наш модуль требует у браузера аутентифицироваться по NTLM. Так как мы находимся в одной сети, то жертва может обратиться к нам по короткому доменному имени (типа http://hacker/lalala) и потому IE автоматом попробует аутентифицироваться по NTLM, «не теребя» жертву вопросами.
- IE посылает первый NTLM-пакет с именем жертвы и общей инфой (все в Base64).
- Мы его пихаем в тело SOAP-запроса и отправляем на vCenter.
- Сервер возвращает на SOAP ответ с challenge (рандомная строчка) для NTLM и куки — vmwaresoapsession.
- Мы пересылаем NTLM-пакет с challeng’eм нашей жертве.
- Жертва хеширует свой хеш и challenge и отправляет нам его.
- Мы это переправляем на сервер.
- Сервер нам говорит, что все ОK и мы аутентифицированы!
Все просто, как видишь. Здесь главное — чтобы у админчика были права в vCenter.
Но что дальше? Да, мы аутентифицированы. А точнее, аутентифицированы куки, которые нам сервер назначил при подключении. Но мы же не можем выполнять операции!
Дальше есть два варианта. Первый — воспользоваться модулем vmwaresessionridder, который входит в комплект VASTO. Этот модуль — прокси для vSphere Client. Если указать vSphere Client подключиться к этому модулю (он открывает порт), а в качестве входных параметров этому модулю — аутентифицированные куки и адрес vCenter сервера, то vmwaresessionridder будет проксировать запросы от vSphere Client и подменять на лету значения куки. Таким образом, с его помощью мы сможем получить стандартный доступ к vCenter. Очень круто. Минусы у этого варианта в том, что, во-первых, из-за проксирования vSphere Client работает прилично медленней, а во-вторых, в том, что нельзя полностью автоматизировать процесс (в смысле по-простому нельзя). То есть, поставив «ловушку» первым модулем, мы будем ждать, когда админ на нее зайдет. Но, как только он зайдет и сервер аутентифицирует наши куки, у нас будет не очень много времени (время жизни сессии вроде десять минут), чтобы скопировать их из одного модуля в другой и запустить vSphere Client. Именно из-за этих минусов я добавил в модуль возможность добавлять любого доменного пользователя в админы vCenter. По сути, это один SOAP-запрос с именем юзера, которому надо выставить админские права. После этого можно входить обычным vSphere Client. Конечно, минус тут в том, что надо иметь учетку хотя бы от одного доменного юзера.
Практика. Запускаем NTLM Relay:
- Скинуть VASTO и мой модуль в “auxiliary/server/” в MSF
- use auxiliary/server/vmauth_ntlmrelay
- set RHOST 192.168.0.1 (IP-адрес vCenter)
- set SRVPORT 80 (порт, на котором будет поднят веб-сервер для запроса NTLM-аутентификации)
- set URIPATH / (URL, для запроса NTLM-аутентификации)
- set USERNAME corp/hacker (имя пользователя, которому будут даны права Administrator. Опционально)
- run
Ждем админа. Когда все будет успешно сделано, нам отобразятся куки vmwaresoapsession, они же SOAPID (см. рис. 2).
Далее:
- use use auxiliary/server/vmwaresessionrider
- set RHOST 192.168.0.1 (IP адрес vCenter)
- set SRVPORT 9999 (локальный порт, на котором прокси будет ждать подключения vSphere Client)
- set SOAPID vmwaresoapsession (вставляем куки из предыдущего модуля)
- run
- Запускаем vSphere Client:
- хост: localhost:9999
- пароль и логин — bypassme
Радуемся победе!
Хотелось бы отметить, что мой модуль vmauth_ntlmrelay еще нужно подретушировать, хотя функции он свои уже выполняет. К сожалению, не уверен, войдет ли он в официальную поставку MSF, или, как VASTO, надо будет качать ручками.
Вот и все. Надеюсь, было интересно :).
Кстати, если хочешь что-нибудь поресерчить или думаешь стать пентестером, но не знаешь как и что — напиши мне, и я постараюсь тебе помочь 🙂 И успешных познаний нового!
