Tautulli - это инструмент на базе Python для мониторинга и отслеживания Plex Media Server. В Tautulli версии v2.15.3 и ранее атакующий с ад…
Tautulli - это инструмент на базе Python для мониторинга и отслеживания Plex Media Server. В Tautulli версии v2.15.3 и ранее атакующий с административным доступом может использовать конечную точку `pms_image_proxy` для записи произвольных Python-скриптов в файловую систему приложения. Это приводит к удалённому выполнению кода при совместном использовании с агентом уведомлений `Script`. Если атакующий с административным доступом изменит URL-адрес PMS на сервер, который он контролирует, он может злоупотребить `pms_image_proxy`, чтобы получить возможность записи в файловую систему приложения. Это можно сделать, выполнив запрос `pms_image_proxy` с URL-адресом в параметре `img` и желаемым именем файла в параметре `img_format`. Tautulli использует хэш необходимых метаданных вместе с `img_format` для построения пути к файлу. Поскольку атакующий контролирует `img_format`, который занимает конец пути к файлу, и `img_format` не проходит проверку, атакующий может использовать символы обхода пути, чтобы указать имя файла по своему выбору. Если указанный файл не существует, Tautulli попытается загрузить изображение из настроенного PMS. Поскольку атакующий контролирует PMS, он может вернуть произвольный контент в ответ на этот запрос, который затем будет записан в указанный файл. Атакующий может записать произвольный Python-скрипт в расположение на файловой системе приложения. Затем атакующий может использовать встроенный агент уведомлений `Script`, чтобы запустить локальный скрипт, получив удалённое выполнение кода на сервере приложения [1]. Пользователям следует обновиться до версии 2.16.0, чтобы получить исправление. Источники: - [1] https://github.com/Tautulli/Tautulli/security/advisories/GHSA-pxhr-29gv-4j8v - [2] https://github.com/Tautulli/Tautulli/commit/26e6b328112eb2cf35c164f981e0718f3a3d31a7
Программный продукт позволяет пользовательским входным данным управлять путями или именами файлов, используемыми в операциях с файловой системой, либо оказывать на них влияние.
https://cwe.mitre.org/data/definitions/73.html →Открыть в коллекции CWE →Злоумышленник прямо или косвенно изменяет переменные окружения, используемые целевым программным обеспечением или управляющие им. Цель злоумышленника состоит в том, чтобы заставить целевое программное обеспечение отклониться от ожидаемого поведения способом, выгодным злоумышленнику.
https://capec.mitre.org/data/definitions/13.html →Открыть в коллекции CAPEC →Данная атака использует кодирование URL в сочетании с кодированием символов слеша. Злоумышленник может воспользоваться множеством способов кодирования URL и злоупотребить его интерпретацией. URL может содержать специальные символы, требующие особой синтаксической обработки для правильной интерпретации. Специальные символы представляются с помощью символа процента, за которым следуют две цифры, обозначающие код октета исходного символа (%HEX-КОД). Например, пробел в US-ASCII представляется как %20. Это часто называют экранированием или процентным кодированием. Поскольку сервер декодирует URL из запросов, он может ограничивать доступ к некоторым путям URL, проверяя и отфильтровывая полученные URL-запросы. Злоумышленник попытается сформировать URL с последовательностью специальных символов, которая после интерпретации сервером окажется эквивалентна запрещённому URL. Защититься от данной атаки непросто, поскольку URL может содержать другие форматы кодирования, такие как UTF-8, Unicode и т. д.
https://capec.mitre.org/data/definitions/64.html →Открыть в коллекции CAPEC →Данная атака направлена на кодирование URL. Злоумышленник может воспользоваться множеством способов кодирования URL и злоупотребить его интерпретацией.
https://capec.mitre.org/data/definitions/72.html →Открыть в коллекции CAPEC →Злоумышленник манипулирует входными данными, которые целевое программное обеспечение передаёт в вызовы файловой системы операционной системы. Цель — получить доступ и, возможно, модифицировать области файловой системы, к которым целевое программное обеспечение не должно было предоставлять доступ.
https://capec.mitre.org/data/definitions/76.html →Открыть в коллекции CAPEC →Данная атака использует обратный слеш в альтернативных кодировках. Злоумышленник может использовать обратный слеш в качестве первого символа, вынуждая парсер считать следующий символ специальным. Это называется экранированием. Используя данный приём, злоумышленник пытается эксплуатировать альтернативные способы кодирования одного и того же символа, что создаёт проблемы для фильтров и открывает пути для атак.
https://capec.mitre.org/data/definitions/78.html →Открыть в коллекции CAPEC →Данная атака направлена на кодирование символов слеша. Злоумышленник пытается эксплуатировать распространённые проблемы фильтрации, связанные с использованием символов слеша, для получения доступа к ресурсам на целевом хосте. Системы на основе каталогов, такие как файловые системы и базы данных, как правило, используют символ слеша для обозначения перехода между каталогами или другими контейнерными компонентами. По неоднозначным историческим причинам ПК (и, как следствие, ОС Microsoft) используют обратный слеш, тогда как мир UNIX традиционно применяет прямой слеш. Шизофренический результат таков, что многие MS-системы обязаны понимать обе формы слеша. Это предоставляет злоумышленнику множество возможностей для обнаружения и использования распространённых проблем фильтрации. Цель данного шаблона — обнаружить серверное программное обеспечение, применяющее фильтры только к одному варианту, но не другому.
https://capec.mitre.org/data/definitions/79.html →Открыть в коллекции CAPEC →Данная атака является специфическим вариантом использования альтернативных кодировок для обхода логики проверки. Атака использует возможность кодирования потенциально опасного ввода в UTF-8 и передачи его приложениям, не ожидающим или неспособным эффективно проверять данный стандарт кодирования, что затрудняет фильтрацию ввода. UTF-8 (8-битный формат преобразования UCS/Unicode) — это кодировка переменной длины для Unicode. Корректные символы UTF-8 имеют длину от одного до четырёх байтов. Однако в ранних версиях спецификации UTF-8 содержались ошибки (в ряде случаев допускались расширенные символы). Кодировщики UTF-8 должны использовать «как можно более короткое» кодирование, однако наивные декодеры могут принимать кодирования длиннее необходимого. В соответствии с RFC 3629, особенно тонкая форма данной атаки может быть проведена против парсера, выполняющего критически важные для безопасности проверки корректности в отношении UTF-8-кодированного вида ввода, но интерпретирующего определённые недопустимые последовательности октетов как символы.
https://capec.mitre.org/data/definitions/80.html →Открыть в коллекции CAPEC →Злоумышленник эксплуатирует возможность кодирования потенциально опасных входных данных или содержимого, используемых приложениями, таким образом, что приложения оказываются не в состоянии проверять данное кодирование надлежащим образом.
https://capec.mitre.org/data/definitions/267.html →Открыть в коллекции CAPEC →