dxdt.blog: занимательный интернет-журнал

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

Скажем, приложение от поисковика умеет определять координаты пользователя по точкам доступа Wi-Fi. Соответствующий сервер геолокации – открыт и общедоступен. Поэтому всякий достаточно квалифицированный специалист может определить местоположение любого чужого компьютера, для которого известны MAC-адреса близлежащих точек Wi-Fi. Узнать MAC-адреса можно с помощью трояна, засланного на компьютер атакуемого пользователя. Для того, чтобы получить координаты, понятно, не нужно взламывать сервера геолокационного сервиса: достаточно взять подходящее приложение, – хоть бы вот мобильные “Яндекс.Карты”, – и подсунуть этому приложению нужные MAC-адреса, что можно сделать с помощью соответствующих SDK (инструментариев разработчика). В ответ – получить на экране примерное местоположение искомого компьютера, обозначенное на карте. Очень удобно. И не требуется GPS, поддержки которой может и не быть.

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

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

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

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

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

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

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

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

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

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

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

Кстати, успешный вброс истории о том, как браузер Chrome отсылает содержимое (да, именно, они так и написали) веб-страниц из закрытых интарнетов в Google для индексации, – см. например, бурное обсуждение на roem.ru, где активность поддержала редакция, – это неплохой задел в подготовке почвы для обоснования разработки “своего безопасного браузера”. То есть, потом, в рамках информационной кампании, можно ссылаться: были публикации в специализированной прессе, “продемонстрировавшие нам”, ну и так далее.

В общем, нужно последить за новостями. Это интересно.

Наверное, многие уже слышали про популярную сейчас охоту за утечками персональных данных в поисковиках. Тут очень весело читать, как следом за пресс-службой “Яндекса” в тематических СМИ поминают веб-мастерам файл robots.txt, обвиняя в том, что веб-мастера, дескать, не подготовили “правильное описание сайта”. Robots.txt никак не является инструментом для разграничения доступа на веб-сайте. И не может оправдать слишком любопытного бота, выкладывающего данные из закрытых разделов серверов в общий доступ.

Если посмотреть на ситуацию с технической стороны, то элементы URL-а (грубо говоря, вся часть после имени хоста) – это специальные параметры, предназначенные для изменения состояния веб-сервера. Веб-сервер – это программа, которая извлекает с диска некоторые файлы. Доступны ли эти файлы всем обратившимся на сервер, не доступны ли – регулируется это вовсе не неким robots.txt. В современной веб-разработке вполне себе нормальна передача секретных ключей доступа в параметрах URL-ов. Ну так вот сложилось. Например, так передают одноразовые ключи в системах восстановления паролей по e-mail. И это правильно, потому что является эффективным и безопасным методом, учитывающим подготовку и технические возможности среднего пользователя. Особенно актуально для сайтов, ориентированных на массового клиента.

Эти ключи в составе “адреса веб-страницы” – определяют уровень доступа к файлам или функциям сайта через веб-сервер. То есть, это команды не для “поискового паука”, а для веб-сервера. В современной технологической традиции команды эквивалентны вводу логина/пароля и полностью входят в состав секретного URL, который, впрочем, тоже можно “индексировать” поисковым роботом, предварительно стянув где-нибудь. А robots.txt тут ни при чём. Более того, довольно логично, что веб-мастер решает не указывать даже часть секретного адреса в этом общедоступном файле.

(Да, а ещё можно устроить робота-паука так, что он станет подбирать ключи в URI; надеемся, что “Яндекс” так не поступает.)

Поэтому, когда “Яндекс” или другой поисковик индексируют “секретные URL”, которые узнали тем или иным способом, – их действия, в общем-то, аналогичны ситуации, когда робот-паук передаёт веб-серверу с помощью метода POST логин и пароль. И не нужно тут пенять на веб-мастера, что он robots.txt не написал.

Кстати, поисковые машины, которые пытаются дотянуться до всего в Вебе, уже научились автоматически фильтровать и изменять собранный контент таким образом, чтобы не раскрывать личные данные тех или иных людей. Например, Google замазывает лица и автомобильные номера на панорамах улиц в Street View. Примерно то же можно сделать и с персональными данными, поиск утечек которых в “Яндексе” сейчас довольно популярное занятие, освещаемое СМИ.

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

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

С другой стороны, уже есть и DNSSEC, и HTTPS, и надёжные обратные зоны в .arpa – так что, во-первых, можно сделать “безопасной” любую доменную зону, хоть третьего уровня; во-вторых, можно обеспечить идентификацию хостов + идентификацию пользователей (обратная зона+электронные подписи в прямой DNS+связанный с тем же субъектом сертификат для доступа к веб-сайтам). Решит ли это проблему? Вряд ли. Потому что нужно как-то донести информацию о преимуществах до конечного пользователя, чтобы он надавил на провайдеров и они сподобились поддерживать новые технологии. Сделать это сложно. Пользователи могут не понимать, чего от них хотят.

Если же просто ввести тот или иной .secure, то может так получиться, что пользователи воспримут именно это текстовое окончание .secure в адресной строке как гарантию безопасности. Как обычно. Ну и злоумышленники кинутся подделывать адреса соответствующим образом, ведь, ни DNSSEC, ни даже https, для массового пользователя всё ещё не работают на практике. (Если с https ситуация ещё более или менее движется в сторону положительной, то с DNSSEC совсем худо.)

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

Интересно, что не выйдет использовать один стандартный и распространённый профиль-отпечаток, скопированный с какой-нибудь типичной рабочей станции под управлением Windows: ведь если такой профиль существует и не обладает высокой степенью уникальности, то это просто означает, что системы идентификации не работают. Ну а тогда, спрашивается, зачем огород городить? Более того, нельзя использовать искусственно созданный стандартный “отпечаток”, тиражируя его по всем пользователям вашего защитного ПО. Во-первых, такой отпечаток будет являться отличным демаскирующим признаком; во-вторых, число пользователей ПО должно быть изначально очень велико, иначе различить их можно будет очень просто, всего лишь добавив какой-нибудь один сетевой признак (например, данные геолокации IP-адреса). Да, конечно, можно использовать TOR для доступа к Сети, и такой комплект обеспечит хорошую защиту от идентификации, но это не тот случай – слишком медленно, слишком сложно для обычного пользователя.

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

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

Кстати, всё больше появляется громко анонсируемых сервисов, предлагающих идентификацию пользовательских устройств, подключенных к Интернету. (Например, сейчас пишут про некий проект BlueCava, который предлагает подобную идентификацию.) Речь, конечно, не о банальной записи IP-адресов и куки-файлов, а о некоторых более развитых технологиях, позволяющих отличить один компьютер от другого.

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

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

Для уточнения нужно двигаться дальше. Точнее – глубже. Можно попытаться использовать параметры, привязанные к оборудованию. Скажем, как уже предлагалось, “дрейф” системных часов, в компьютерах, которые не синхронизируются по времени. Можно попытаться определить тип процессора и характеристики производительности. Как? Например, замеряя скорость выполнения функций, написанных на том же Javascript (скорость существенно зависит от браузера, впрочем) или внутри Flash. Кстати, наверняка широкое поле деятельности тут предложит HTML5.

Понятно, что даже если IP-адреса устройства меняются, то оно всё равно соединяется с веб-сайтом по TCP – поэтому особенности реализации этого протокола, которые можно измерить со стороны сервера, тоже нужно положить в копилку источников информации.

Современные смартфоны содержат набор дополнительных сервисных устройств, информация от которых также может поступать через браузер на удалённый сервер. Например, GPS. Особенности конкретных реализаций интерфейсов вполне себе могут дать дополнительные биты информации для уточнения уникальности устройства.

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

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

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

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

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

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

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

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

Интересно, что есть довольно старая (более десяти лет ей, думаю) идея, сходного направления: можно ли массово и скрытно установив простые датчики или программные закладки в компьютеры и офисную технику, находящуюся в эксплуатации на территории другой страны, определить, что там начались некоторые значительные события в офлайне? Ну, грубо говоря: вот начали срочные приказы набирать в текстовом редакторе, нервничают, много опечаток, мышка дёргается – всё это мониторит логическая закладка в операционной системе, и передаёт некий простой сигнал в центр. Закладка при этом не читает ключевые слова (в отличие от монитора сообщений в Twitter’е), чтобы не выдать себя при анализе кода, а вот просто фиксирует побочные параметры. Центр, суммируя показатели, определяет, что да – началось, пора действовать.

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