Microsoft открывает антивирусную лабораторию в Мюнхене

Microsoft открывает антивирусную лабораторию в Мюнхене

...

Центр борьбы с вредоносным программным обеспечением - одно из структурных подразделений Microsoft - будет усилен еще одной исследовательской лабораторией, местом расположения которой станет немецкий город Мюнхен. Сферой ответственности ее сотрудников будет обнаружение новых угроз в регионе EMEA и надлежащее реагирование на них.


Выбор места аналитики Microsoft объясняют географически - это центр Европы, откуда они смогут более оперативно и эффективно реагировать на разнообразные угрозы, возникающие на территории как собственно Европы, так и Ближнего Востока вкупе с Африкой. Новая лаборатория будет функционировать в тесном взаимодействии с уже существующей аналогичной организацией в Дублине; руководить ими обеими будет один и тот же эксперт.

Всего у антивирусного центра Microsoft теперь пять лабораторий. Кроме двух уже упомянутых, работают подразделения непосредственно в Редмонде, а также в Мельбурне (Австралия) и Ванкувере (Канада). Исследовательские программы корпорации выполняются, помимо этого, в Нью-Йорке, Лос-Анджелесе и Пекине. Руководство Microsoft полагает, что распространение ее программных продуктов и сетевых сервисов по всему миру требует, помимо прочего, и ведения аналитической работы в сфере защиты от инфекций во всех основных макрорегионах планеты.

Центр борьбы с вредоносным ПО отвечает за развитие антивируса Microsoft Security Essentials, встроенного средства защиты последних выпусков популярной ОС редмондской корпорации - Windows Defender, а также семейства продуктов Microsoft Forefront. Региональный подход в противодействии инфекциям - разумное решение: известно, что спектр активных угроз порой существенно различается в зависимости от континента или даже конкретной страны. Посмотрим, удастся ли новой лаборатории повысить качество и эффективность защитных решений Microsoft.

Technet Blogs

Письмо автору

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