Join
William Cross
@papioss
October 11, 2023

Назад к основам: обход каталогов

Назад к основам: обход каталогов

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

Что такое обход каталога?

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

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

Обход каталога, позволяющий читать произвольные файлы

Рассмотрим приложение, которое позволяет пользователю хранить фотографии, а затем получать их с помощью запроса GET, используя параметр имени файла, чтобы указать, какой файл нужно получить. Если приложение не включает защиту от обхода каталогов и создает путь к файлу, используя предоставленный параметр имени файла, можно получить произвольные файлы с базового веб-сервера. На рисунке 1 показана эта последовательность на практике:

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

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

Обход каталога, позволяющий произвольную запись в файл

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

Хотя это может показаться безобидным, поскольку это всего лишь сохранение фотографии, существуют способы дальнейшего использования. Если тип файла не проверен (например, JPEG, PNG), злоумышленник может загрузить файл любого типа, что приводит к нескольким различным сценариям использования. Некоторые возможные примеры эксплуатации в этом сценарии:

  • Добавление открытого ключа злоумышленника в файл авторизованных_ключей пользователя (например, /root/.ssh/authorized_keys) для получения постоянного доступа.
  • Перезапись файлов приложения для изменения поведения приложения.
  • Загрузка веб-оболочки в корневой каталог веб-сайта
  • Вызов отказа в обслуживании путем перезаписи необходимых системных файлов.
  • Загрузка исполняемых файлов (например, вредоносных программ, программ-вымогателей)

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

Обход каталогов в дикой природе

CVE-2023-2825: обход каталогов в Gitlab

В Gitlab версии 16.0.0 существует уязвимость обхода каталогов, которая позволяет читать произвольные файлы. Загрузка файла в качестве вложения к задаче в установке Gitlab по умолчанию приводит к тому, что Gitlab сохраняет файл в 10 каталогах в глубину по шаблону, как показано ниже:

/var/opt/gitlab/gitlab-rails/uploads/@hashed/<directory>/<directory>/<directory>/<directory>/<filename>

После загрузки Gitlab также предоставляет конечную точку для получения загруженного файла по адресу.

/<repo-name>/uploads/<file-id>/<filename>

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

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

GET /Group-1/Group-2/Group-3/Group-4/Group-5/Group-6/Group-7/Group-8/Group-9/Group-10/Group-11/<repo-name>/uploads/<file id>/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd

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

CVE-2022-48362: обход каталогов в ManageEngine Desktop Central.

В сборках ManageEngine Desktop Central до версии 10.1.2127.1, обход каталога в функции загрузки файлов позволял производить произвольную запись файлов путем манипулирования параметром «имя_компьютера» (или несколькими другими) для включения последовательностей обхода.

На момент обнаружения эта уязвимость активно эксплуатировалась и сочеталась с обходом аутентификации (CVE-2021-44515) для обеспечения возможности удаленного выполнения кода. Для краткости мы сосредоточимся только на части атаки, связанной с обходом каталога, поскольку она позволяет записывать файлы и обходит свободную проверку.

В функции с именем «doPost» Desktop Central обрабатывает несколько параметров в рамках загрузки файла этой функцией, включая «имя компьютера», «имя файла» и другие параметры. Есть две проблемы, которые приводят к успешному обходу каталога, обеспечивающему запись файлов:

  1. Для последовательностей обхода проверяется только параметр имени файла. Другие параметры, такие как «domainName», «computerName» или «customerId», используются для построения абсолютного пути к файлу, но не проверяются на предмет последовательностей обхода. «Имя_компьютера» — это последний параметр, используемый в объединенной строке, поэтому это идеальное место для ввода последовательности обхода.
  2. Загрузка файлов позволяет использовать файлы с расширениями zip, 7z и gz. На первый взгляд, возможно, это кажется безопасным. Однако поскольку Desktop Central является приложением Java, а файлы JAR созданы в формате zip, это позволяет удаленно выполнять код. Загрузив zip-файл в C:\Program Files\DesktopCentral_Server\libкаталог и принудительно перезапустив его, опытный злоумышленник может перезаписать файлы классов в приложении, включив в него свой собственный код и добиться выполнения кода.

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

Обход каталога с точки зрения WAF

Обход каталогов — один из наиболее часто наблюдаемых методов атак, который мы описали в нашем отчете об угрозах сетевого эффекта за второй квартал 2023 года.

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

../../../../../../../../../etc/passwd../../../../../../../../etc/passwd../../../../../../../etc/passwd../../../../../../etc/passwd../../../../../etc/passwd../../../../etc/passwd../../../etc/passwd

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

Другие типы атак, такие как межсайтовый скриптинг (XSS), могут использовать полиглоты полезной нагрузки, которые объединяют несколько методов в одну полезную нагрузку. Это приводит к тому, что злоумышленники и сканеры отправляют гораздо больше полезных данных для проверки на обход, чем при тестировании на XSS. Наш файл примера из PayloadsAllTheThings содержит 140 полезных данных по сравнению с их файлом XSS_Polyglots , в котором их 16. Самый большой файл полезных данных для обхода в PayloadsAllTheThings содержит более 21 000 записей , по сравнению с самым большим для XSS - более 600 , SQLi - более 400 (хотя следует предположить, что на практике это будет больше, если тип базы данных неизвестен, поскольку потребуется протестировать несколько типов), и более 400 для внедрения команд ОС .

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

Предотвращение уязвимостей обхода каталогов

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

Запретить создание путей к файлам с помощью пользовательского ввода

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

Строгая проверка ввода пользователя

Строгая проверка отличается от санитарной обработки. Вместо того, чтобы пытаться удалить последовательности обхода (например, ../), которые можно обойти бесчисленными способами, убедитесь, что в вводимые пользователем данные входит только ожидаемый контент, и отклоните все, что не проходит строгую проверку. Примеры проверки, которые могут помочь предотвратить обход каталогов:

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

Используйте функции языка канонизации путей для строгой проверки.

Канонизация пути по существу сокращает путь к файлу до его фактического пути, эффективно удаляя символические ссылки, последовательности ../ и другой символический контент. Получив канонический путь, вы можете убедиться, что он по-прежнему начинается с ожидаемого базового каталога (например, uploads/photos/). Некоторые примеры функций для получения канонического пути:

  • Java: getCanonicalPath
  • PHP: реальный путь
  • C: реальный путь
  • ASP.NET: GetFullPath

Ограничить доступ к приложению

Как правило, приложение должно иметь доступ только к файлам и каталогам, доступ к которым ему необходим для правильной работы. В некоторых случаях обхода каталогов это помогает, ограничивая влияние уязвимости в случае ее обнаружения. Например, веб-приложение никогда не должно запускаться от имени пользователя root, а в идеале оно должно быть ограничено доступом только к тем файлам, которые необходимы для обслуживания приложения.

Ссылки и дополнительная литература

William Cross
October 11, 2023, 11:08
0 views
0 reactions