Баг WhatsApp допускает изменение текста сообщений и личности отправителя

Баг WhatsApp допускает изменение текста сообщений и личности отправителя

Баг WhatsApp допускает изменение текста сообщений и личности отправителя

В ходе конференции по безопасности Black Hat эксперты компании Check Point рассказали о способе взлома WhatsApp, благодаря которому злоумышленник может изменить текст сообщения или личность отправителя этого сообщения.

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

Исследование Check Point под названием «Reverse Engineering WhatsApp Encryption for Chat Manipulation and More» раскрывает детали эксплуатации проблем безопасности в WhatsApp.

Все началось в 2018 году, когда специалисты Роман Заикин и Одед Вануну провели обратный инжиниринг исходного кода и смогли расшифровать трафик WhatsApp. Тогда эксперты и обнаружили уязвимости в сервисе обмена сообщениями.

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

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

Специалисты Check Point даже создали специальный инструмент, с помощью которого можно успешно эксплуатировать вышеозначенные проблемы безопасности. Но даже это не привлекло должного внимания со стороны головной компании — Facebook.

В заявлении интернет-гиганта утверждается, что описанные Check Point проблемы не имеют ничего общего с уязвимостями в сквозном шифровании.

Меж тем команда Check Point опубликовала видео, в котором демонстрируется эксплуатация описанных проблем безопасности:

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