Easy Наск

xml-digital-signature

В прошлый раз я рассказал о том, что такое ХМL Digital Signature и что за атака XML Signature wrapping (XSW). Сегодня мы продолжим тему, но уже в практическом ключе.
Кратко напомню о технологии. XML DSig позволяет создать электронную подпись части или «целого» XML-документа. При подписи XML-документа в его начало добавляется заголовок, содержащий подпись. Проблема заключается в том, что заголовок с подписью использует для ссылки на ту часть, которая подписана, технологию XPointer (или аналогичную, например XPath), а она, в свою очередь, не позволяет достоверно определить расположение подписанного элемента в теле всего документа.
Таким образом, XSW-атака в простейшем виде требует того, чтобы атакующий переместил подписанный кусок XML в заголовок, а на его место подставил бы другой, интересующий его. Получив такой документ, XML-пapcep возьмет подпись из заголовка, а также подписанный кусок, и тоже из заголовка, и в итоге подпись сойдется. Но, что хуже, в дальнейшую обработку пойдут данные от злоумышленника, так как они находятся в теле, а не в заголовке. Надеюсь, что ты вспомнил.
Конечно, звучит это все очень просто и легко. На практике возникает приличная проблема. Хотя сама по себе она типична: несмотря на то, что ХМL DSIG и ХМL вполне точные стандарты, различных парсеров (на разных уровнях) много. К тому же здесь еще есть зависимость от работы самого приложения. Это все приводит к тому, что вариантов перестановок очень много. Например, возможно, «не прокатит» перенос легального тела в заголовок, а надо сделать два последовательно идущих тела, причем в правильной последовательности. Или надо для XSW перенести легальное тело в тело интересующего нас… То есть вариантов много-много, и все необходимо тестировать.
И вот потому прошу устремить твое внимание к чудесному «фреймворку». Название его — WS-Attacker (goo.gl/qQ3WS), автор — Кристиан Майнка (Christian Mainka).
Несмотря на свою фреймворковость, тулза эта умеет делать пока только три вещи. Итак, пробегусь по модулям:
Атака SOAP Action Spoofing. Основывается на том, что SOAP позволяет задать Action (то есть какая операция должна проводиться в приложении), как с помощью указания в Body, так и с помощью заголовка (пример есть ниже в задачке про VMware). Но последнее опционально.
Атака же состоит в том, чтобы нарушить процесс авторизации за счет указания какого-то другого Action в заголовке. Наши права проверятся по команде из Body, а фактическое действие производится из заголовка. Хотя, признаюсь, на практике я такого не встречал.
WS-Addressing Spoofing. Эта атака основывается на технологии WS-Addressing. Она позволяет задавать «маршруты» для передаваемого XML-документа. То есть мы можем указать, какому XML-сервису адресован документ, куда отсылать ответ, куда отсылать сообщения об ошибках. Задаются маршруты простым добавлением URL’oв. Так что это проще сделать ручками.
XSW. С помощью этого модуля мы почти полностью автоматизировано можем определить вектор для XSW-атаки. И это очень круто! Но так как модуль несколько не юзер-френдли, то я позволю себе расписать последовательность действий, необходимых для настройки XSW-модуля.
1. WSDL Loader — Указываем URL до атакуемого сервиса»LOAD.
2. Expert View — вставляем украденный XML-документ с валидной подписью (даже если время жизни, так называемый Timestamp, уже просрочено).
3. В Test Request надо послать тестовый запрос к Plugin Config — » Signature Wrapping.
5. WS-Attacker анализирует введенный XML-документ и определяет все подписанные части. Чаще всего это Body и Timestamp.
С последним WS-Attacker и сам знает, что делать. Но если нужно, в Show можно указать, какая часть документа будет меняться.
6. Далее самое главное — Reference Element. Здесь мы должны указать итоговый XML-документ, который нам необходимо внедрить, то есть нагрузку. Рекомендуется выбрать такой, чтобы было понятно, что атака прошла, но при этом чтобы все не сломать. Цель ведь — определить «магическую» последовательность данных. Это обязательный этап.
7. Иногда веб-сервис не плюется ошибками в случае некорректных запросов, а отображает ответ на изначальные (не подмененные данные). Так, например, ведет себя фреймворк для веб-сервисов CXF. И WS-Attacker по ошибке считает атаку успешной. Чтобы такого не происходило, необходимо указать в Search уникальный текст, который должен быть возвращен только при успешной атаке.
8. Attack Overview — »Start.
9. В поле Content отобразится итоговый запрос для проведения XSW-атаки.
Кстати, у WS-Attacker версии 1.1 была проблема: в итогах выводился запрос для проведения атак, но без использованных схем, что очень удручало. Нормальный запрос можно было выискать, лишь только немного покопавшись в логах. Так что качай последнюю версию — 1.2.
Еще из косяков стоит отметить то, что тулза за один запуск может быть натравлена только против одного веб-сервиса. Если указать ей другой, то она начинает подглючивать. А в общем — незаменимая тулза получилась.