Браузер-шпион: технические особенности

В продолжение темы про Chrome, который, якобы, переправляет в Google контент закрытых страниц из корпоративных интранетов: интересно подумать, как можно было бы устроить подобный шпионский браузер. Понятно, что едва ли Google что-то подобное делает, потому что не ясны стратегические выгоды: ну чего там интересного для массового пользователя можно найти в интранетах? Тем более, что и ссылку-то не покажешь: сервер же закрыт. В исходном вбросе, направленном на тематические СМИ, по той или иной причине не разработан технический аспект: то есть нет легенды, как именно Chrome “сливает инфу”. А ведь это был бы самый занимательный кусочек истории.

Что можно придумать? Понятно, что простое зеркалирование забранных с “секретного” сайта страниц на сервер Google – это неинтересный вариант. Хотя бы потому, что он обнаруживается совсем уж элементарно, с помощью систем мониторинга трафика. Использование зашифрованных каналов тут не поможет, потому что само наличие канала с трафиком демаскирует “шпиона”. Однако, можно “размазать” собранную информацию по многим транзакциям, передавая внутри каждой лишь небольшой фрагмент. Получается такой медленный и малозаметный канал.

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

Возникает вопрос: где хранить тексты страниц, если мы растянули передачу и для того, чтобы утекло десять килобайт текста, требуется несколько сеансов работы браузера и большой “легитимный” трафик для прикрытия? Действительно, пользователь почитал страницу и закрыл её, а браузеру ещё передавать и передавать. Ответ: есть кэш, читать текст страницы нужно из него. Обычно браузерный кэш включен. Да, страницы, полученные по https, не должны бы сохраняться в кэше, но ведь наш шпионский браузер может сделать исключение. Тем более, не обязательно кэшировать текст страницы в открытом виде, можно преобразовать его в некоторый “служебный файл”, – попутно сжав, да, – и сохранить так.

Другой вопрос: что взять за основу для построения канала утечки? А тут годятся любые сервисы, принимающие некие персонализированные настройки (например, проверка посещаемых URL на “фишинговость и вредоносность”). Сжатый текст будем передавать так: небольшие блоки подмешиваются в токены, которые браузер генерирует при формировании запроса на сервер. Пусть токен содержит 64 байта. Предположим, что 16 из них – это данные утечки. Тридцать запросов с токенами (не много) – 480 байт. Хорошим кодированием можно ужать сюда примерно 2500 знаков текста (можно и заметно больше). Необязательно поддерживать канал открытым, пока не передан весь собранный текст (см. ниже). Вообще, нет никакой необходимости, создавая такой браузер, встраивать в него излишнюю надёжность. Механизмы обеспечения такой надёжности только выдадут затею. Центр посеял много браузеров в окружающее киберпространство. Какие-то из них что-то приносят, какие-то – нет, они сломались. Нестрашно, многочисленность источников компенсирует (для центра) ненадёжность каждого из них.

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

В комментариях к предыдущей заметке высказали ещё несколько идей. Jno предлагает использовать DNS для передачи части собранной информации (как известно, DNS-трафик хорошо преодолевает всякие корпоративные брандмауэры и редко мониторится на предмет утечек). А Vlad пишет, что не обязательно передавать все “внутренние” страницы подряд. Сперва можно посчитать статистику текста по ключевым словам и спросить центр, нужна ли такая страница. Правда, это подразумевает развитую обратную связь, что может демаскировать канал утечки. Кстати, браузеру хорошо бы спрашивать, есть ли уже найденная только что страница в базе, например, передавая хеш её текста.

Вообще, задача определения “секретных” страниц – тоже интересная (особенно, если нет связи с центром). И её что-то упустили из вида при обсуждении вброса на тему Chrome.

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

(Продолжение про риски и политику.)

()

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 7

  • 1. 2nd August 2011, 19:19 // Читатель aa написал:

    > Хотя бы потому, что он обнаруживается совсем уж элементарно, с помощью систем мониторинга трафика.

    Он (Хром) вполне честно предупреждает, что отсылает данные http://www.google.com/chrome/intl/en/privacy.html

    autofill, включен после установки

    > If you enable the optional AutoFill feature, … will send Google limited information about the structure of pages that have web forms and information such as the arrangement of the form

    suggest, шпионит за клавиатурой и адресной строкой. Включен, если при установке выбрать Google search

    > When you type URLs or queries in the address bar, the letters you type are sent to your default search engine

    location, следит за ip-адресами и видимыми wi-fi сетями и сливает в гугл:

    > Google Chrome will send local network information to Google Location Services .. includes, depending on the capabilities of your device, information about the wifi routers closest to you, cell ids of the cell towers closest to you, the strength of your wifi or cell signal, and information about your device such as your device?s IP address.

    Про тексты страниц пишут только, что все тексты сохраняются локально ;)

    > Google Chrome records useful information about your browsing history on your own computer. …
    > Basic browsing history information: the URLs of pages that you visit, a cache file of text from those pages, and a list of some IP addresses linked from pages that you visit.

    Плюс в локальном индексе оседает практически полный текст (дополнительно к кешу, статистика по словам – в комплекте)

    > A searchable index of most pages you visit

    Кстати, удобное место для троянов, которые могут сразу получить доступ к страницам, посещенные за последние несколько месяцев.

  • 2. 2nd August 2011, 19:33 // Читатель sarin написал:

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

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

  • 3. 2nd August 2011, 22:54 // Читатель jno написал:

    Ресурсы? Кто ж ему даст?! :)
    Если заметно отъест, то его просто сроют под корень и вернутся к тормозилле :)

  • 4. 3rd August 2011, 01:30 // Читатель DarthBender написал:

    Интереснее оказывается, когда пользователи сами засылают данные. Например, небезызвестный Google Translate честно в соглашении говорит, что весь текст введенный для перевода отсылается на сервер. Зачем скрываться, и пытаться что-то зашифровать или спрятать, если при грамотном подходе пользователь сам все отдаст? :)

    Ну а с Хромом все более менее ясно – качай исходники и ковыряй, при желании. Безусловно, различия между Хромом и Хромиумом будут, но не настолько значительные.

    По личным наблюдениям полугодичной давности (правда под Дебианом), у Хрома и Хромиуима сетевая активность совпадает практически полностью. Ну а в разницу ничего стоящего засунуть точно не выйдет.

  • 5. 3rd August 2011, 12:10 // Читатель sarin написал:

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

  • 6. 3rd August 2011, 16:33 // Читатель jno написал:

    Да, сами отсылают почём зря.

    Мой работодатель даже покупает сотрудникам лицензии на офлайновые переводчики (ХЗ какие именно – форточные они) и предупреждает об ответственности за использование подобных ресурсов для перевода конфиденциальных документов.

  • 7. 3rd August 2011, 21:30 // Читатель kaschey написал:

    Пока Opera включена, даже в режиме просмотра, когда уже ничего не должно грузится минут 10-20 постоянно что-то передаётся туда сюда (на быстром соединении, на медленном, вроде, не хулиганит).