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

Теперь эти XML-документы могут содержать так называемые «сущности», определенные с помощью системного идентификатора и присутствующие в заголовке DOCTYPE. Эти объекты могут получать доступ к локальному или удаленному контенту. Например, ниже приведен пример XML-документа, содержащего объекты XML.

В приведенном выше коде внешний объект «entityex» объявлен со значением file:///etc/passwd. Во время синтаксического анализа XML этот объект будет заменен соответствующим значением. Использование ключевого слова «SYSTEM» указывает синтаксическому анализатору, что значение объекта должно быть прочитано из следующего за ним URI. Таким образом, когда значение объекта используется много раз, это может показаться очень полезным.

Для сущностей XML ключевое слово «СИСТЕМА» заставляет синтаксический анализатор XML считывать данные из URI и разрешает их замену в документе. Таким образом, злоумышленник может отправить через сущность свои собственные значения и заставить приложение отображать их. Проще говоря, злоумышленник заставляет анализатор XML получить доступ к указанному им ресурсу, который может быть файлом в системе или в любой удаленной системе. Например, приведенный ниже код извлечет папку/файл, присутствующий в этой системе, и отобразит его пользователю.

Прямой ответ на этот вопрос — определить те конечные точки, которые принимают XML в качестве входных данных. Но иногда вы будете сталкиваться с теми случаями, когда конечные точки, принимающие XML, могут быть не столь очевидны (например, те случаи, когда клиент использует только JSON для доступа к сервису). В этих случаях пентестер должен попробовать разные вещи, такие как изменение методов HTTP, Content-Type и т. д., чтобы увидеть, как реагирует приложение. Если приложение анализирует содержимое, то есть область для XXE.

Для демонстрации воспользуемся сайтом http://testhtml5.vulnweb.com/, поддерживаемым Acunetix. Это тестовый сайт, который можно использовать для проверки возможностей веб-сканера Acunetix. Посетите сайт http://testhtml5.vulnweb.com/ и нажмите ссылку «Забыли пароль» в разделе «Вход». Обратите внимание, что приложение передает данные с использованием XML, как показано ниже.

Запрос:

Ответ:

Глядя на приведенный выше запрос и ответ, мы можем понять, что приложение обрабатывает XML, получает определенные входные данные и отображает их обратно. Чтобы проверить, анализирует ли синтаксический анализатор XML отправленный нами XML, я отправил приведенный ниже запрос.

Модифицированный запрос и ответ:

Как видно из приведенного выше запроса, теперь мы ввели объект в запрос (myentity). Ответ ясно показывает, что синтаксический анализатор XML проанализировал все, что мы отправили, и, соответственно, вернул значение. Это подтверждает, что это приложение уязвимо для XXE-атак.

Следующие примеры кода можно использовать для эксплуатации уязвимости внешней сущности XML.

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

[скачать]Нажмите здесь[/скачать]

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

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

Основная проблема, о которой говорилось выше, заключается в том, что синтаксический анализатор XML анализирует ненадежные данные, отправленные пользователем. Однако может быть непросто или невозможно проверить только данные, присутствующие в системном идентификаторе в DTD. Большинство синтаксических анализаторов XML по умолчанию уязвимы для атак внешних сущностей XML (XXE). Следовательно, лучшим решением было бы настроить XML-процессор на использование локального статического DTD и запретить любые объявленные DTD, включенные в XML-документ.

Например, в Java (как показано в приведенном ниже коде), установив для соответствующих атрибутов значение false, можно предотвратить атаки внешних объектов. Таким образом, внешние сущности, сущности параметров и встроенные DTD устанавливаются в false, чтобы избежать атак на основе XXE.

Второй фрагмент кода см. в файле загрузки.

«ParseThru» — использование контрабанды HTTP-параметров в GolangОБНОВЛЕНИЕ 0096

10 октября 2022 г. —
CVE-2022-2880 был назначен этой уязвимости, и команда Golang исправила уязвимость в обновлении. Сотрудничество FTW!!

‍

‍

Исследовательская группа Oxeye по безопасности обнаружила уязвимость в безопасности приложений на базе Golang. При определенных условиях он позволяет злоумышленнику обходить проверки на основе параметров HTTP-запроса из-за использования небезопасного анализа URL-адресов.

Анализ URL-адресов 101

Каждый из них, представляющий интернет-адрес разрозненного веб-ресурса, имеет важное значение унифицированных указателей ресурсов (URL). Браузер инициирует HTTP-запрос для получения данного ресурса, идентифицированного его URL-адресом. Целевой веб-сервер переводит текстовый URL-адрес в понятный ему способ, называемый Анализ URL-адреса .

Этот процесс обычно выполняется в соответствии с RFC 3986, в котором содержатся инструкции по правильному анализу URL-адресов. Вот выдержка, иллюстрирующая компоненты URL:

Каждый язык имеет свою собственную реализацию этой логики. Например, в Python вы можете использовать модуль urllib.parse . В Golang это модуль net/url и так далее.

Разумно было бы предположить, что все реализации одинаковы, не так ли? Извините… на самом деле все они следуют одним и тем же правилам, но содержат небольшие различия. Это может привести к синтаксическому анализу несоответствий одного и того же ввода.

Golang + анализ URL = ?

Недавно основная команда Golang выпустила патч, который коренным образом меняет способ анализа URL-адресов этим языком. До версии 1.17 Golang считал точку с запятой в части запроса URL-адреса допустимым разделителем — подобно тому, как оценивается амперсанд. Это поведение происходит из метода parseQuery :

Например, следующий URL дает два параметра запроса, имя и компания , а не одно имя параметр:

Golang изменил это поведение, начиная с версии 1.17. Теперь его метод parseQuery возвращает ошибку, если URL-запрос содержит точку с запятой:

Хотя метод parseQuery был исправлен, чтобы правильно возвращать ошибку, когда ввод содержит точку с запятой, один из методов, отвечающих за беспечное получение проанализированной строки запроса игнорирует возвращенную ошибку:

Более того, Golang предлагает встроенную функцию для проксирования HTTP-трафика с использованием своих 9Модуль 0005 httputil/reverseproxy.go . Чтобы создать новый обратный прокси-сервер, он предоставляет метод NewSingleHostReverseProxy :

Он берет необработанную строку запроса из запроса, а не проанализированную. Но вместо того, чтобы анализировать его, он отправляет его как есть.

Теперь вы видели разницу в поведении между версиями Golang, но как точки соединяются?

Объединяем все вместе

Рассмотрим следующие два сервиса на основе Golang. Первое — это пользовательское приложение, работающее в версии 1.17 или более поздней, а второе, серверная служба, работает в более ранней версии.

Пользователь отправляет HTTP-запрос к первой службе, указав параметр запроса name . Эта первая служба решает, передавать ли запрос на основе предоставленного параметра.

Предположим, пользователь добавляет точку с запятой к параметру name при разборе строки запроса. В этом случае первая служба игнорирует свое существование; вместо того, чтобы принимать логическое решение на его основе, запрос перенаправляется во вторую (внутреннюю) службу. Последний получает транзакцию и обрабатывает параметр без точки с запятой.

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

Практический пример Harbour

С официального веб-сайта Harbour: «Harbour — это реестр с открытым исходным кодом, который защищает артефакты с помощью политик и управления доступом на основе ролей… Harbour, дипломированный проект CNCF, обеспечивает соответствие требованиям, производительность и совместимость, чтобы помочь вам последовательно и безопасно управляйте артефактами на облачных вычислительных платформах, таких как Kubernetes и Docker».

Другими словами, Harbour позволяет вам управлять артефактами вашего приложения. Одной из его многочисленных особенностей является то, что вы можете централизовать несколько реестров изображений под одной крышей.

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

Harbour использует реестр контейнеров дистрибутива для хранения образов Docker и управления ими.

При чтении API V2 реестра Docker мы обнаружили конечную точку, которая позволяет монтировать BLOB-объекты между репозиториями . Эта функция экономит дисковое пространство и пропускную способность сети при сохранении/загрузке образов Docker, указывающих на одни и те же слои файловой системы.

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

Чтобы смонтировать большой двоичный объект из внешнего репозитория, конечная точка ожидает получить один параметр пути URL — имя (с указанием целевого репозитория) — и два параметра запроса:

• mount (хеш-дайджест слоя, который нужно смонтировать)
• from (имя внешнего репозитория, который уже содержит указанный слой)

Когда Harbour получает такой запрос, он пытается выполнить два разрешения валидации:

1. Проверяет, есть ли у пользователя доступ к репозиторию, указанному в параметре URL < имя >
2. Проверяет, есть ли у пользователя доступ по запросу из репозитория, указанного в параметре запроса < из >

Oxeye искал развертывания Harbour, которые имеют это несоответствие версии Golang. Мы обнаружили, что Bitnami (компания, приобретенная VMWare, которая хранит диаграммы Helm и образы Docker для различных проектов) имеет именно эту настройку. Его основной микросервис Harbour работает на Golang 1.17, а микросервис реестра Docker — на версии 1.15.

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

‍ Исходный запрос — заблокирован из-за проверок авторизации Harbor:

Модифицированный запрос — обход проверок авторизации Harbor, ответ подтверждает, что большой двоичный объект (полученный из реестра) успешно смонтирован:

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

Дополнительные тематические исследования

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

Traefik

Traefik — это современный обратный HTTP-прокси и балансировщик нагрузки, упрощающий развертывание микросервисов. Одна функция позволяет блокировать определенные запросы на основе параметров запроса. Например, следующая конфигурация не пересылает запросы с параметром foo :

В фоновом режиме Traefik использует метод разбора уязвимой строки запроса. Проксирование запроса на внутренний сервер передает как исходный запрос, так и строку запроса. Запрос с Параметр foo , содержащий точку с запятой, будет обходить этот сопоставитель правил.

Skipper

Skipper — это HTTP-маршрутизатор и обратный прокси-сервер для составления сервисов, который также использует анализ уязвимых запросов. Например, запросы с параметром foo будут отклонены при использовании следующей конфигурации:

Запрос с параметром foo и завершающей точкой с запятой будет обходить средство сопоставления правил, в результате чего Skipper не отклонит этот запрос.

Исправление

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

Если вы все еще хотите использовать уязвимый метод, рассмотрите возможность очистки необработанного запроса таким образом, чтобы входные данные, содержащие точку с запятой, отклонялись до вызова метода (хотя есть и другие способы маскировки ввода, например, кодирование URL).

Чтобы помочь сообществу найти такие уязвимости, Oxeye написал правило Semgrep, которое предупреждает вас, если ваша кодовая база использует уязвимый метод. Он предлагает автоматическое исправление с использованием более безопасного метода:

‍

https://semgrep.dev/s/daniel-abeles:golang-http-parameter-smuggling-assignment

Раскрытие информации об уязвимостях

Все упомянутые выше уязвимости были раскрыты соответствующим поставщикам и исправлены в последние версии.