Атака «Браузер в браузере» (BITB): ложь, обман и CSS

Почти незаметная фишинговая атака теперь распространяется по Интернету со скоростью лесного пожара.

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

Повторяю заявление об отказе от ответственности, упомянутое в репозитории mr.d0x: использование этих шаблонов для атаки целей без предварительного согласия является незаконным. Ответственность за соблюдение всех применимых законов лежит на конечном пользователе. Разработчик не несет ответственности за неправильное использование этих шаблонов.

«Остерегайтесь мартовских ид», — говорят они; и мы должны по уважительной причине.

15 марта исследователь безопасности по имени mr.d0x опубликовал статью о почти необнаружимой фишинговой атаке, которую большинство пользователей быстро проигнорируют как легитимный признак. в диалоге. Эта форма фишинга, известная как атака Браузер в браузере, серьезно усложняет растущую зависимость Интернета от SSO и диалогов OAuth для авторизации и аутентификации пользователей в онлайн-сервисах, таких как социальные сети, облачное хранилище, и другие платформы, которые могут хранить конфиденциальную информацию о пользователях. Типичными примерами этого, которые мы видим сегодня, является вход в другие службы с нашей учетной записью Google, учетной записью Microsoft и т. д., которым мы автоматически доверяем из-за репутации.

Эта атака использует доверие пользователей, созданное с помощью этих процессов входа, для кражи учетных данных путем репликации поддельного модального окна OAuth с использованием старого простого HTML, CSS и JS.

Истоки

Хотя эта атака сегодня попадает в заголовки, это разновидность того, что существовало с конца 2000-х годов. Когда доля Windows XP на рынке составляла более 80%, а Internet Explorer был самым популярным браузером в мире, поддельные онлайн-антивирусные сканеры начали появляться в каждом уголке Интернета. Поскольку Windows не была известна своими выдающимися функциями безопасности, продажа поддельных и вредоносных вредоносных программ, замаскированных под антивирусы, была очень прибыльным бизнесом: 3 компании за время своего существования заработали в общей сложности 130 миллионов долларов.

Цель этих поддельных антивирусных сканеров состояла в том, чтобы напугать пользователей, чтобы они купили их «антивирус», поскольку однажды их компьютер был магическим образом заражен. Эти фишинговые сайты заполонили ваши экраны окнами Windows XP или 7, состоящими из мигающего красного текста, большого списка вирусов и гигантских призывов к действию, заставляющих вас зарегистрировать продукт, чтобы спасти ваш компьютер от неминуемой гибели. Для Windows XP вы увидите что-то вроде этого.

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

Запаниковавший пользователь послушно следовал подсказкам и загружал scareware, запускающую поддельный антивирус с «пробным» периодом. По истечении этого периода он снизит производительность хост-компьютера или заполнит его большим количеством вредоносных программ, чтобы убедить пользователя приобрести официальную лицензию для удаления всего рекламного, шпионского и другого дерьма, которое он установил на ваш компьютер. Как только жертва покупает программное обеспечение, злоумышленник получает ваше имя, платежный адрес и информацию о кредитной карте, чтобы выполнить любую транзакцию, которую он хочет.

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

Атака

Доказательство концепции mr.d0x — это эволюция того, что мы видели с поддельными окнами антивирусного сканирования. Вместо отображения страницы сканирования с подробностями, связанными с системой, этот фишинг для подтверждения концепции использует вредоносный диалог OAuth, похожий на регистрацию в онлайн-сервисе с использованием сторонней учетной записи. Если вам это не кажется знакомым, то GIF ниже может быть более знакомым.

Пример диалогового окна OAuth из JavaScript SDK Facebook.

Первая часть этой атаки требует, чтобы жертва посетила скомпрометированный домен, где злоумышленник установил ловушку. Это можно сделать либо с помощью Гомографов IDN, либо с помощью Отравления/спуфинга DNS. Эту часть атаки, вероятно, сложнее всего реализовать и убедить пользователей посетить сайт по причинам, описанным ниже. Наиболее убедительным подходом является использование отравления DNS, но это само по себе сложнее в настройке.

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

Код

Созданная демо mr.d0x содержит шаблоны для создания поддельных всплывающих окон для нескольких популярных операционных систем и их вариантов. В каждой папке для каждой ОС есть эти файлы:

├───Windows-Chrome-LightMode
│       index.html
│       logo.svg
│       script.js
│       ssl.svg
│       style.css

index.html — это просто тестовая страница, содержащая файл <iframe>.
logo.svg — это фавикон, используемый поддельным окном.
script.js содержит логику перетаскивания окна, анимации кнопок и т.д.
ssl.svg — это значок замка, который вы увидите в адресной строке всплывающего окна.
style.css содержит стили, используемые на странице.

Код окна довольно прост, а инструкции по настройке можно найти в README. Это должно работать так, как показано на GIF ниже.

Gif из репозитория BITB mr.d0x, демонстрирующий, как это работает.

Улучшения в форке

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

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

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

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

Следующее, что я сделал, это сделал само окно изменяемым по размеру. Пользователь должен иметь возможность перетаскивать окно во всех направлениях, как настоящее. Это привело к некоторым проблемам, которые были решены с помощью некоторых хитрых трюков CSS во время перетаскивания, а не перетаскивания.

Последним шагом было создание образца фишинговой страницы с кнопкой входа SSO и создание модифицированной версии страницы входа в Google, похожей на то, что мы видим сегодня. Единственное, что я добавил, это новое поле пароля (которое отображается, когда мы нажимаем «Далее», но это было довольно сложно воспроизвести) и пользовательскую функцию, когда пользователь нажимает «Ввод»/«Далее». Любой опытный пользователь сможет сказать, что Google больше не размещает поле пароля под полем электронной почты в последней версии диалогового окна входа.

Для фишинговой страницы, которая запускает поддельный диалог OAuth, мы можем сделать вещи более убедительными, установив href на реальный URL-адрес входа в Google и используя функцию onclick, которая возвращает false. Таким образом, браузер проигнорирует href и вместо этого запустит вашу функцию JavaScript.

<a
    href="https://accounts.google.com/o/oauth2/auth/identifier?response_type=code&client_id=1083004"
    onclick="return loadWindow()"
    class="clickme u-flex text-gray-800 font-normal"
    id="clickme"
>
    <div class="icon">
        <img class="icon-svg" src="https://upload.wikimedia.org/wikipedia/commons/5/53/Google_%22G%22_Logo.svg" />
    </div>
    <p class="btn-text m-0 u-flex u-items-center"><b>Sign in with Google</b></p>
</a>
function loadWindow() {
    setTimeout(() => {
        $('#window').toggleClass('visible');
        $('#content')[0].src = "phish.html";
    }, 100 + Math.floor(Math.random() * 500));
    return false;
}

После этих изменений конечный результат выглядит так:

Дальнейшие улучшения

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

@media (prefers-color-scheme: dark) {
  /* Dark theme styles go here */
}
@media (prefers-color-scheme: light) {
  /* Light theme styles go here */
}

Еще одним улучшением будет добавление состояний окна для имитации того, когда окно находится в фокусе и не в фокусе.

Почему это эффективно

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

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

Одним из проектов, направленных на решение этой проблемы путем оповещения каждого iframe (включая законный контент), является odacavo/enhanced-iframe-protection. Это хороший первый шаг к решению этой проблемы, но он оказывается очень громоздким, так как вам нужно будет самостоятельно разрешить список всех фреймов.

Почему это не эффективно

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

Отображение фишинговых предупреждений для подозреваемых фишинговых сайтов.
Подсветка домена в адресной строке.

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

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

Отсутствует поведение окна, например изменение размера.
Странное обрезание адреса в адресной строке с правой стороны.
Мгновенная загрузка окна (добавлены ложные задержки).

Даже с учетом улучшений фишинговая атака все еще имеет множество уязвимостей. Первая вопиющая проблема заключается в том, чтобы выяснить, как обрабатывать оконные рамы всех существующих операционных систем? Конечно, мы можем использовать дизайн окон Windows и Mac OS, чтобы обмануть большинство пользователей, но даже эти распространенные операционные системы также имеют разные варианты и оттенки. Проектировать кучу Windows для соответствия всем этим вариациям — огромная трата времени. Не говоря уже о всех различных комбинациях, которые поставляются с разными дистрибутивами Linux. Я имею в виду, что видеть рамку Windows в Mac OS просто небрежно и смущающе.

Вторая проблема заключается в том, что поддельное диалоговое окно OAuth нельзя переместить за пределы браузера. Вы заметите, что попытка перетащить его за пределы браузера просто приведет к тому, что он застрянет на краю страницы. Сворачивание браузера также скроет с ним окно. Его нет на панели задач, и он не будет отображаться в представлении задач для Windows или в Mission Control в Mac OS.

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

Смягчения

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

Проверьте всплывающее окно и сравните его с элементами управления окнами вашей ОС. Если он выглядит иначе, то вас фишят.
Попробуйте переместить поддельное всплывающее окно за пределы браузера, проверить, отображается ли оно как окно на панели задач, развернуть, свернуть и т. д. Если оно не работает должным образом, то это фишинговая атака.
Если ваш менеджер паролей не заполняет данные автоматически, значит, вы находитесь на фишинговом сайте.
Настройте 2FA/MFA в своих онлайн-сервисах, чтобы добавить дополнительную защиту от любых скомпрометированных учетных данных.
Установите NoScript. Крайний способ смягчить эту проблему, но он сработает на 100%.
Подделка вашего пользовательского агента. Любое возможное обнаружение пользовательского агента фишинговым сайтом для отображения правильного окна не будет работать правильно.

Заключение

Новая или старая, я должен сказать, атака браузер в браузере (BitB) может вернуться в 2020-х — на этот раз в виде мошеннических всплывающих окон OAuth. Хотя этот метод фишинга кажется большинству убедительным, современные браузеры предлагают большую степень защиты от фишинговых сайтов, которая уже останавливает пользователей еще до того, как они попадут на фишинговый сайт. Множество проблем уже делает эту атаку менее эффективной, чем она могла бы быть. Однако его летальность исходит из того, что браузеры не могут заблокировать фишинговый сайт. Внешний вид диалогового окна входа дает большинству пользователей ложное чувство безопасности, заставляя пользователя вводить свои учетные данные.

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

Спасибо за прочтение!

💎 Спасибо, что нашли время, чтобы проверить этот пост. Чтобы узнать больше подобного контента, перейдите в мой настоящий блог. Не стесняйтесь обращаться ко мне в LinkedIn и подписывайтесь на меня в Github.