Опера не спешит закрывать уязвимость

Опера не спешит закрывать уязвимость

Если вы считаете, что знакомы с языком HTML и принципами работы браузеров, попробуйте прямо сейчас ответить для себя на вопрос — может ли картинка вставленная через тег IMG сделать редирект той странице, на которой она вставлена? Странный вопрос, скажете Вы. Тем не менее ответ на него не такой однозначный «нет», как кажется на первый взгляд.

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

В начале октября была обнаружена уязвимость в браузере Опера 12, которая позволяет через вставленную картинку и определенным образом отданные заголовки для нее перенаправлять посетителя на другой сайт. Атаке через эту уязвимость успели подвергунться крупнейшие сайты рунета, позволяющие вставлять картинки через УРЛ (например, rutracker — ссылка). Сайты, поддержкой которых занимаюсь я сам также были атакованы, пишет habrahabr.ru.

Как работает

Если в коде открываемой странице злоумышленник может разместить тэг вида:
<img src="http://evil.com/evil.png">
(где evil.com подконтрольный ему сервер)
и отдать при запросе http://evil.com/evil.png следующие заголовок:

Refresh: 0; url=data:application/internet-shortcut,[INTERNETSHORTCUT]%0D%0AURL=http://evil.com/

то браузер Опера не спросив и не предупредив пользователя, совершит переход по этому адресу.

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

Подвержены все сайты, которые позволяют пользователям вставлять свои картинки через УРЛ, а это возможно практически везде, начиная с форумов на phpbb, ЖЖ, Хабрахабра (!) и заканчивая письмами в mail.ru (где картинки в письме загружаются по умолчанию).

Официальный ответ Opera

В диалоге представителя Opera в России Ильи Шпанькова (shpankov) и администрации rutracker.org прозвучли следующие заявления:
«Как выяснилось, в Opera уязвимости нет и проблема не является результатом ошибок в браузере, но совместно с разработчиками Opera мы нашли решение, как избежать подобных проблем в дальнейшем, и это решение будет применено в ожидаемой скоро новой версии Opera 12.1»

А также привел слова технических специалистов Opera Software:
«У нас в Opera принято помогать сайтам, даже когда они делают что-то неправильно. Поэтому в Opera 12.10 мы отключим следование шорткатам в контенте, загружаемом внутри тега . Это именно то, что согласно ожиданиям веб-сайта должен делать браузер, хотя на самом деле такое поведение не описывается ни одним стандартом. Таким образом, мы сделаем то, что они хотят, очень скоро.»

Выводы

Представитель Опера, похоже, или совсем не понимает что такое безопасность браузера и не видит явной угрозы которую представляет данный баг. Или пытается сделать хорошую мину при плохой игре, т.к. лично от него врядли что-то зависит и ускорить исправление данного бага он не в силах, поэтому пытается сохранить лицо браузера в этой непростой ситуации.
Мне кажется, что человека, совсем уж ничего не понимающего в работе браузеров, не стали бы брать на такую должность, поэтому более чем уверен что его поведение идёт согласно второго сценария.

Что же касается ситуации в целом, то всё очень и очень грустно. Браузер Опера на данный момент занимает в РуНете порядка 15%, при этом открыто заявляется что «проблемы негров шерифа не волнуют» и переадресация сайтов черт знает куда без ведома пользователя «уязвимостью не является».
Явные же проблемы пользователей, разработчики почему то называют проблемами «владельцев сайтов». Хотя их продуктом пользуются не владельцы сайтов, а люди, чью личную информацию браузер Опера подвергает опасности.

Да, они заявляют что уязвимость исправлена в следующей версии браузера (12.10), но не называют даже примерных сроков ее релиза. А тем временем любой — даже не хакер — любой вообще человек, воспользовавшись информацией об этой уязвимости (опубликованной на днях на РуТрекере), может причинять реальные проблемы и страдания пользователям этого браузера.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

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

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

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

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