Уязвимость в нескольких продуктах Atlassian позволяет удаленному не прошедшему проверку подлинности злоумышленнику обходить фильтры сервлет…
Уязвимость в нескольких продуктах Atlassian позволяет удаленному не прошедшему проверку подлинности злоумышленнику обходить фильтры сервлетов, используемые собственными и сторонними приложениями. Воздействие зависит от того, какие фильтры используются каждым приложением и как эти фильтры используются. Эта уязвимость может привести к обходу аутентификации и межсайтовому скриптингу. Atlassian выпустила обновления, устраняющие основную причину этой уязвимости, но не перечислила исчерпывающим образом все потенциальные последствия этой уязвимости. Версии Atlassian Bamboo затронуты до 8.0.9, с 8.1.0 до 8.1.8 и с 8.2.0 до 8.2.4. Версии Atlassian Bitbucket затронуты до 7.6.16, с 7.7.0 до 7.17.8, с 7.18.0 до 7.19.5, с 7.20.0 до 7.20.2, с 7.21.0 до 7.21.2 и версии 8.0.0 и 8.1.0. Версии Atlassian Confluence затронуты до 7.4.17, с 7.5.0 до 7.13.7, с 7.14.0 до 7.14.3, с 7.15.0 до 7.15.2, с 7.16.0 до 7.16.4, с 7.17.0 до 7.17.4 и версия 7.21.0. Версии Atlassian Crowd затронуты до 4.3.8, с 4.4.0 до 4.4.2 и версия 5.0.0. Версии Atlassian Fisheye и Crucible до 4.8.10 затронуты. Версии Atlassian Jira затронуты до 8.13.22, с 8.14.0 до 8.20.10 и с 8.21.0 до 8.22.4. Версии Atlassian Jira Service Management затронуты до 4.13.22, с 4.14.0 до 4.20.10 и с 4.21.0 до 4.22.4.
Продукт проверяет входные данные до их канонизации, что не позволяет обнаружить данные, становящиеся недопустимыми после шага канонизации.
https://cwe.mitre.org/data/definitions/180.html →Открыть в коллекции CWE →Некоторые API удаляют определённые ведущие символы из строки параметров. Злоумышленник может намеренно вставлять ведущие «фантомные» символы (дополнительные символы, не влияющие на корректность запроса на уровне API), которые позволяют входным данным пройти фильтры и тем самым обрабатываются API целевого ресурса. Это происходит, когда целевой API принимает входные данные в нескольких синтаксических формах и интерпретирует их семантически одинаково, тогда как фильтр не учитывает полный спектр синтаксических форм, допустимых для целевого API.
https://capec.mitre.org/data/definitions/3.html →Открыть в коллекции CAPEC →Злоумышленник может передавать Unicode-строку компоненту системы, не поддерживающему Unicode, и использовать её для обхода фильтра или сбоя классифицирующего механизма при правильной интерпретации запроса. Это может позволить злоумышленнику передать вредоносные данные через фильтр содержимого и/или вызвать некорректную маршрутизацию запроса приложением.
https://capec.mitre.org/data/definitions/71.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 →| Продукт | Вендор | Статус |
|---|---|---|
| bamboo | * | Отслеживается |
| bitbucket | * | Отслеживается |
| confluence_data_center | * | Отслеживается |
| confluence_server | * | Отслеживается |
| crowd | * | Отслеживается |
| crucible | * | Отслеживается |
| fisheye | * | Отслеживается |
| jira_data_center | * | Отслеживается |
| jira_server | * | Отслеживается |
| jira_service_desk | * | Отслеживается |
| jira_service_management | * | Отслеживается |