Главная > Uncategorized > Термины, XXE, SSRF и все-все-все

Термины, XXE, SSRF и все-все-все

Написать пост меня сподвиг вот этот диалог, приключившийся в твиттере третьего дня.

Преамбула: в терминологии и в классификациях в нашей области полная разруха.

Во-первых, почти все называют уязвимости по названиям атак (см. SQLi/XSS). A side note: кстати, если вы не читали пост Владимира Кочеткова про XSS, вы просто обязаны это сделать!.

Во-вторых, умудряются классифицировать недостатки по типам атак, которые, в свою очередь, определяют вперемешку то по цели воздействия, то по способу воздействия. Пример классификации, которую я видел лично: есть класс «DoS» (цель), следом идет класс «Input Validation» (причина) и рядом же — класс «Parameter Tampering» (способ). Как будто не может быть недостатка, связанного с некорректной обработкой входных данных, благодаря которому можно устроить DoS, но только через «Parameter Tampering». Пример — DROP всего через SQLi через HPP в значении hidden-поля.

Амбула: препарируем SSRF :)

SSRF = Server-Side Request Forgery. Кто-то, возможно, посчитает, что термин классический. Лично для меня он прост и понятен — его уже который год вокруг употребляют то Владимир Воронцов [тыц], то Александр Поляков [тыц].
С другой стороны, если погуглить «Server-Side Request Forgery», окажется, что упоминаний термина не очень-то и много. Кроме того, «пацаны, оказывается, не в курсе»: один исследователь известную всем нам идею обозвал собственноручно придуманным именем — XSPA, а Дж. Гроссман вообще подумал про свое-другое

Так вот, с моей точки зрения, XXE — это, конечно, свойство приложения. Свойство заключается в том, что парсер приложения небезопасно разрешает XML-сущности, определенные клиентом. Обычно каждый недостаток можно использовать в различных целях и различными способами: отличный пример тот же SQLi в целях считывания базы и в целях обхода аутентификации в форме логина.
Так вот, XXE — enabling свойство для таких действий удаленного клиента, как чтение локальных файлов или запрос сетевого ресурса по URI. Как не всякий недостаток является уязвимостью, так же и не всякая новая возможность дополнительных действий удаленного пользователя в отношении веб-приложения является атакой.

На мой взгляд, в правильно сконфигурированной системе возможность делать сетевые запросы по URI через XXE не должна давать удаленному пользователю дополнительные бонусы. Правильно сконфигурированная система — это система, в которой выполняется принцип ограниченности потенциального ущерба (и, как следствие, принцип наименьших привилегий). В такой системе будут запрещены лишние сетевые соединения с сервера приложений к другим узлам в DMZ, а необходимые соединения будут устанавливаться только после взаимной аутентификации и авторизации сторон. Мне представляется, что в такой системе SSRF — всего лишь недокументированная фича приложения, не позволяющая сделать ничего нового.

Соответственно, если принцип ограниченности потенциального ущерба не выполняется, то можно говорить о том, что с помощью SSRF мы злоупотребляем отношением доверия между внутренними сервисами. И тогда эта техника уже является слагаемым известного класса атак под названием Exploitation of Trust. И тогда еще одной причиной атаки можно называть небезопасную конфигурацию или даже кривой проект взаимодействия систем! Как вам такая софистика?

Реклама
Метки:
  1. 09.11.2012 в 01:59

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

    Если же говорить вообще, то в области ИБ никогде не было внятной логичной терминологии и всеми разделяемого понятийного аппарата на любом из уровней — начиная от общих понятий вроде уязвимости, атаки, недостатка, заканчивая низкоуровневыми техническими вещами.
    Я уж не говорю про таксономию этого дела.

    • 09.11.2012 в 02:02

      >На разнице этой суперпозиции и своих прав всегда может сыграть злоумышленник, эксплуатирующий XXE.

      Приведи, пожалуйста, пример, если не трудно. Где именно SSRF будет способом проведения атаки, а все внутренние сервисы будут проводить взаимную аутентификацию.

      • 09.11.2012 в 02:06

        (из башки): Database credentials из конфига читай @ на базу через gopher набегай

      • 09.11.2012 в 02:19

        Если запретить LFR, то придумывается такой пример (воображаемый):
        Допустим общение с бэкенд-базой происходит по мифическому протоколу ololo, с использованием CRUD-интерфейса в духе ololo://my_database/my_table/delete/where 1=1/
        Для того, чтобы это плавно работало, в веб-приложении зарегистрирован protocol-handler протокола ololo.
        В настройках protocol-handler’а указываются учетные данные для базы.
        Соответственно в xxe мы можем использовать URL’ы этого протокола. => Профит

        Этот пример — частный случай любого использования ambient credentials. В каком-то смысле аналогично CSRF.
        Я правда не могу привести пример из жизни, но думаю, сценарий не слишком невероятный.

  2. 09.11.2012 в 02:07

    George Noseevich (@webpentest) :

    (из башки): Database credentials из конфига читай @ на базу через gopher набегай

    Еще раз: только SSRF

    • 09.11.2012 в 02:36

      Кстати, если говорить про SSRF вообще (на самом высоком уровне абстракции), то SQLi — тоже SSRF. Тогда мой пример можно еще больше упростить — любая эксплуатация SQLi (даже при работающей авторизации с БД) будет приводить к нарушению access control пользователей веб-приложения. Все те же ambient credentials.

  3. 09.11.2012 в 02:41

    George Noseevich (@webpentest) :

    Если запретить LFR, то придумывается такой пример (воображаемый):
    Допустим общение с бэкенд-базой происходит по мифическому протоколу ololo, с использованием CRUD-интерфейса в духе ololo://my_database/my_table/delete/where 1=1/
    Для того, чтобы это плавно работало, в веб-приложении зарегистрирован protocol-handler протокола ololo.
    В настройках protocol-handler’а указываются учетные данные для базы.
    Соответственно в xxe мы можем использовать URL’ы этого протокола. => Профит

    Этот пример – частный случай любого использования ambient credentials. В каком-то смысле аналогично CSRF.
    Я правда не могу привести пример из жизни, но думаю, сценарий не слишком невероятный.

    Но тут встает весь такой в белом принцип наименьших привилегий, который должен по моим требованиям выполняться…

  4. qqlan
    09.11.2012 в 06:30

    +1 общую идею и +1 про SQLi (http://www.securiteam.com/tools/5FP0F20FPK.html). Метод атаки годный, но городить за него терминологический огород — перебор

  5. 09.11.2012 в 07:30

    Во многом согласен но. 1) SSRF как я себе вижу и описываю это связка из 2х или более проблем одна из которых это возможность слать чтото кудато причём без разницы через уязвимость типа XXE,sqli rfi, xml sighature reference и пр или через функционал системы как то UTL_HTTP в оракле к примеру. Вторая это собсно уязвимость которую мы эксплуатируем на другом хосте или на том же или в клиентском приложении которое собсно делает запросы на удалённый хост (аля Counter-attack SSRF см. новую презентацию http://goo.gl/GyhS3). Наличие этих 2х багов или ещё других в связке и называется SSRF.
    2) Exploitation of trust хороший термин но тут вопрос в детализации вед все инъекции это по сути Input validation но всёравно каждая имеет свой термин. Так и здесь SSRF более конкретное описание куска Exploitation of trust кмк. 3) есть много приложений у которых SSRF делается нетипично и не эксплуатирует текущие уязвимости типа XXE типа возможность портскана и такого рода баги тоже неплохо кудато отнести и сгруппировать и я считаю данный термин наиболее подходит для их группировки.

  6. 09.11.2012 в 12:39

    SSRF — просто баззворд обозначающий тунелирование. Не суть XXE, SQLi и т.п.. Можно и RFI в PHP обозвать SSRF, если эксплуатировать уязвимость стороннего сервера. Равно как и любую RCE вообще, да и всю работу при пентесте.тоже.

    Сейчас термин активно форсится, приживётся или нет — посмотрим. Тут как с «облачными технологиями».

  7. 09.11.2012 в 14:07

    Хмм ну и как тогда назвать уязвимость из первоисточника ? http%3A%2F%2Fwww.shmoocon.org%2F2008%2Fpresentations%2FWeb%2520portals%2C%2520gateway%2520to%2520information.ppt просто Information Disclose?

  8. No
    09.11.2012 в 14:30

    Exploitation of trust. А почему нет, в чем проблема?

    • 09.11.2012 в 17:16

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

      • 10.11.2012 в 00:54

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

  9. 09.11.2012 в 16:12

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

    С другой стороны, тот же WASC-05 WASC-33 и проч. требуют для реализации атаки не только самой уязвимости, называемой RFI или Path Traversal, но и настроек системы и прав файловой системы.

    Для себя я определил, что есть атаки, одноименные с уязвимостями, например RFI, в ряде случаев, через уязвимость атаку реализовать нельзя (писал выше почему), тогда это потенциальная уязвимость.

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

    • 09.11.2012 в 16:17

      В принципе, согласен с Владимиром и Александром, что давать собственное название (SSRF) описанному вами комбо — вполне резонно. Ну и правильно там коллеги указали, что Exploitation of Trust — это очень общий класс. Так что это название тупо не удобно употреблять для быстрой коммуникации идеи в разговорах ;)

      Но обсуждение знатное вышло!

  10. 09.11.2012 в 16:23

    Вообще я предлагаю сделать альтернативный классификатор более иерархичной структуры. Верхний уровень — первопричина, input validation или аналог, затем ниже уязвимость, затем атаки. Ну и связи.

    Просто это нам уже сейчас не понятно, то скоро (лет 10) уже черт нгу сломит.

    Возьмем, например, WASC-24: «HTTP Request Splitting is an attack that enables forcing the browser to send arbitrary HTTP requests». Какого, спрашивается, хрена, надо было писать «browser» и ограничивать это клиентской стороной? Ну и так далее

  11. 09.11.2012 в 16:36

    Володь, уже сейчас это неподъёмная задача) тотже CAPEC там тысяча багов и не сказал бы что они уж так уж отличаются ) если делать то майндмепом ибо простой иерархии не получится. Я лично собираюсь сдалать wiki по SSRF из серии откуда через что и куда можно атаковать и в последнем докладе собственно представил те наработки что сейчас нашёл, такчто буду рад любой помощи ) Кстати, можно поподробенее про «Можно и RFI в PHP обозвать SSRF, если эксплуатировать уязвимость стороннего сервера» не совcем ясно почему это SSRF?

  12. 09.11.2012 в 16:37

    Vladimir Vorontsov (@d0znpp) :

    Вообще я предлагаю сделать альтернативный классификатор более иерархичной структуры. Верхний уровень – первопричина, input validation или аналог, затем ниже уязвимость, затем атаки. Ну и связи.

    Ммм… Ты же должен знать про CWE и CAPEC? Это оно и есть ;)
    CWE — иерархия недостатков, CAPEC — атак. Между иерархиями проставлены связи.

  13. 09.11.2012 в 16:39

    Alexander Polyakov (@sh2kerr) :

    Кстати, можно поподробенее про “Можно и RFI в PHP обозвать SSRF, если эксплуатировать уязвимость стороннего сервера” не совcем ясно почему это SSRF?

    Выступлю в роли К.О. RFI = включение удаленного файла. Например, по HTTP. Вот тебе возможность сделать HTTP-запрос к внутреннему серверу. А там может быть phpMySQLAdmin дырявый…
    Вов, ты это имел в виду?

  14. 09.11.2012 в 16:46

    Просто RFI в том виде когда делаеш инклуд это всёже атака на тот же сервис а не проксирование атаки, я к этому. Но на самом деле все очень разиыто и о терминологии можно спорить сколько угодно. Мне вот сейчас интересно больше куда пойдет обсуждение XSPA ))

  15. 09.11.2012 в 17:04

    я, кажется, познал DAO CAPEC+CWE, с помощью Андрея.
    Не надо спорить, надо просто юзать всем одни справочники и проблем не будет

  16. 09.11.2012 в 17:14

    Andrew Petukhov :

    Vladimir Vorontsov (@d0znpp) :
    Вообще я предлагаю сделать альтернативный классификатор более иерархичной структуры. Верхний уровень – первопричина, input validation или аналог, затем ниже уязвимость, затем атаки. Ну и связи.

    Ммм… Ты же должен знать про CWE и CAPEC? Это оно и есть ;)
    CWE – иерархия недостатков, CAPEC – атак. Между иерархиями проставлены связи.

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

    Alas.

    • 09.11.2012 в 19:12

      и это правда, и поэтому мысть начать для веба деревья на основе CAPEC+CWE меня не оставляет. Хотя бы просто подчистить

      • 09.11.2012 в 19:31

        Один вопрос — а зачем? Люди и так все понимают, что есть что, в разговоре редко бывают фейлы и недопонимания. Гроссман не в счет, он просто аббревиатуру не так понял. Только если для красоты и точности.

      • 09.11.2012 в 22:25

        Создать правильную формальную таксономию в нашей области — достаточно неподъемная, а главное (как верно заметили ниже) — вполне бессмысленная задача. Вот начни — поймешь.
        Для начала, например, придется как минимум запилить годную математическую модель. Она либо будет чересчур подробная и специализированная, что ограничит её обобщающую способность, либо, наоборот, слишком общая, что сделает её бессмысленной для практического использования (см. Белла с Ла-Падулой, noninterference, тысячи их).

  17. 12.11.2012 в 13:13

    Alexey Sintsov (@asintsov) :
    Один вопрос – а зачем? Люди и так все понимают, что есть что, в разговоре редко бывают фейлы и недопонимания.

    Ура!

  18. 15.11.2012 в 12:36

    Имея удобную классификацию, всегда проще выявлять закономерности и тем самым получать новые знания. В случае использования неудобных классификаций этот процесс также реализуем, но с б`ольшими затратами времени и труда. Очевидно, что если бы удобная классификация имело место быть, этой классификацией, конечно, активно пользовались бы, и, конечно, меньше времени уходило бы на обсуждение необходимости ее наличия, что, само по себе, тоже неплохо. Это одна позиция. Можно, конечно, занять позицию даосиста и руководствоваться постулатом «Отсутствие желания приносит покой, и тогда порядок в стране сам собой установится». Это еще одна позиция, не слишком подходящая для целей научного познания. В случае, если процесс деятельности не сводится к чисто «найти клеви баги» или «сделать ?серьезное и полезное? исследование» (с кучей новых аббревиатур и далекое от реальности), без удобной классификации, которой приятно пользоваться не обойтись. Тем более людям, которым приходится представлять результаты труда не только подкованным в теме людям. Без красивой классификации вполне могут работать хакеры, всем лигал-исследователям в своей работе без нее не обойтись.

    • 20.11.2012 в 22:01

      Вы не учитываете затраты на создание такой классификации и поддержку её постоянно в актуальном состоянии.

      У нас область не формализована (точнее, все формальные модели бесконечно далеки от реальности, кроме разве что rbac’а и дискреционной модели), поэтому любая новая/красивая таксономия быстро превратится в сборник кейсов из жизни (как, собственно, и происходит в случае с CWE). При этом количество холиваров только увеличится.

      Мое мнение — там, где это абсолютно необходимо, надо продолжать использовать стандартные вещи типа CWE и CAPEC, не особо беспокоясь по поводу их кривости.
      Во всех остальных случаях два человека, имеющие мозг, смогут друг друга понять.

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: