Об устранённой в Windows 10 0-day Microsoft предупреждали два года назад

Об устранённой в Windows 10 0-day Microsoft предупреждали два года назад

Об устранённой в Windows 10 0-day Microsoft предупреждали два года назад

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

Уязвимости присвоили идентификатор CVE-2020-1464. Как объяснила сама Microsoft, проблема присутствует в механизме проверки подписи файлов.

Другими словами, атакующий мог обойти защитные функции Windows 10 и загрузить некорректно подписанные файлы.

Интересной информацией поделились специалисты компаний Zengo и SafeBreach Labs: об этом баге, на который Microsoft обратила внимание лишь в этом месяце, сообщали ещё в 2018 году. Более того, на тот момент корпорация из Редмонда отказывалась выпускать патч для CVE-2020-1464.

Бернардо Куинтеро из команды VirusTotal в январе 2019 года обратил внимание на вредоносный, но при этом подписанный исполняемый файл Java. После анализа файла с расширением .jar специалист понял, что на самом деле это MSI.

Операционная система Windows при этом принимала цифровую подпись, считая, что этот файл от Google, а значит, совершенно безобиден. Со сторонними защитными решениями происходила та же история.

Куинтеро сразу же сообщил о проблеме представителям Microsoft, однако последние заявили, что патчить дыру они не планируют.

Расширения 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