Oracle Access Manager затронула серьезная уязвимость аутентификации

Oracle Access Manager затронула серьезная уязвимость аутентификации

Oracle Access Manager затронула серьезная уязвимость аутентификации

Недавно пропатченная Oracle уязвимость нарушала основные функции Oracle Access Manager (OAM), предназначенные для предоставления доступа к защищенным данным предприятия только авторизованным пользователям.

OAM предоставляет функцию аутентификации для веб-приложений на основе Oracle Fusion Middleware. Возможности этого решении также позволяют блокировать доступ к внешним мобильным и облачным приложениям.

Однако специалисты австралийской компании SEC-Consult обнаружили недостаток в реализации криптографического алгоритма, позволяющего создавать токены сеанса для любого пользователя. Злоумышленники могут использовать этот баг, выдав себя за легитимного пользователя, тем самым получив доступ к веб-приложениям, которые OAM должен защищать.

Как пояснили эксперты, проблема кроется в компоненте аутентификации Oracle WebGate.

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

Однако недостаток позволил исследователю SEC-Consult расшифровать токен аутентификации.

«Используя эту уязвимость, мы смогли создать токен сеанса. WebGate принимает такой токен за легитимный и предоставляет доступ к защищенным ресурсам», — объясняет эксперт — «Более того, можно также создать специальный cookie-файл для произвольного имени пользователя, что позволит выдать себя за любого пользователя».

Подпишитесь на новости

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

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

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru