Пользователь
0,0
рейтинг
28 сентября 2011 в 12:22

Разработка → Я.Инцидент: Почему я читал ваши СМС?

Я.Инцедент

События прошедшего лета, связанные с утечками конфиденциальных данных в поисковые системы, прямо или косвенно коснулись каждого, кто следит за новостями, любезно предоставляемыми СМИ. Под «системный нож» попали поисковые роботы и персональные данные гражданина РФ. Копнем немного глубже и выясним, каким образом частная жизнь может оказаться «у всех на виду».

В самый разгар летнего периода СМИ наперебой делились новостью об утечке информации с веб-страниц, содержащих тексты СМС пользователей одного из крупнейших сотовых операторов. Среди множества хитрозакрученных и более-менее адекватных версий, касающихся причин данного факта, наконец-то всплыла мысль, которая была подкреплена результатами исследования. Участник форума rdot.org под псевдонимом «C3~RET» опубликовал небольшую исследовательскую работу, которой, тем самым, задал еще один, довольно хороший вектор для новых публикаций в средствах массовой информации.

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

1) персональных данных покупателей интим-магазинов;

2) документов, имеющих гриф «для служебного пользования»;

3) удаленных фотографий социальной сети «ВКонтакте»;

4) персональные данные покупателей РЖД-билетов.


Ситуация на поверхности


А был ли на самом деле инцидент? Прямое столкновение между веб-ресурсами и поисковой системой, красиво описанное «отделом пропаганды», на самом деле представляет собой лишь продемонстрированную широким массам технику «Google Hacking» только на примере другой поисковой системы.

Google Hacking

Остро стал освещаться всем известный факт: документированный функционал поискового робота запрещает ему индексировать страницы, не содержащиеся в специальном файле «robots.txt» в корневой веб-ресурса или же имеющий специальный HTML-тег «noindex», который, кстати говоря, предложен компанией Яндекс. Однако если бы только «козел отпущения» в лице Яндекса использовал исключительно документированные средства индексации, то, возможно, шумиха быстро прекратилась бы, и данный материал не вышел бы в свет…

В поисках истины


Ключевые выводы исследователей и предварительная версия причин инцидента, связанного прежде всего с утечкой СМС в кэш поисковой системы, формулируются примерно так: на стороне клиента шлюза отправки коротких сообщений установленное расширение к браузеру от компании-разработчика поисковой системы провоцировало передачу всех данных пользователя на сторону этой самой поисковой системы. Беглый осмотр исходного кода веб-страницы СМС-шлюза, которую любезно предоставил кэш Google’a после того, как сотовый оператор временно закрыл доступ к шлюзу, позволил убедиться, что на указанной странице, с которой проводилась отправка сообщений, содержался JavaScript-код, являющийся частью сервиса «Яндекс.Метрика», представляющий собой инструмент для веб-мастеров и предназначенный для формирования статистических данных о посетителях веб-страницы. Таким образом, перед нами появляется еще один потенциальный канал утечки конфиденциальной информации в кэш поисковой системы «Яндекс».

Знакомство с пользовательским соглашением окончательно высаживает параноика на измену в следующем пункте:

«8. … Функция записи Сессий посещений работает полностью в автоматическом режиме и не умеет анализировать содержание и смысл информации размещённой на страницах и вводимой третьими лицами (посетителями) в поля на страницах сайта Пользователя, а записывает её полностью независимо от содержания. ...»

Другими словами: пользователь понимает, что скрипт Яндекс.Метрики записывает все без разбора. Наша задача, определить конкретно, что именно.

Для проверки этой гипотезы были созданы три страницы, содержащие упомянутый JavaScript и уникальный текст с целью последующей их идентификации в поисковой выдаче. Первая страница вида defeсtech.ru/p4ste3stOfYa являлась открытой для поискового Yandex-робота. Другая — defectech.ru/4tom1cprOfit занесена в файл robots.txt. Адреса страниц исключают возможность подбора ссылок, если данный функционал имеется в наличии поискового бота (что позволит нам рассуждать о том, имело ли место так называемое интеллектуальное сканирование в рассматриваемом инциденте). С целью более оперативного уведомления бота о появившейся публичной странице (defectech.ru/p4ste3stOfYa) ссылка на нее разместилась на корневой странице (defectech.ru).

Два дня спустя. Утешительные для нас результаты: размещение JS-кода никоим образом не отразилось на индексации закрытых для поисковых ботов страниц. Более того, индексация публичных страниц также не выполнена, что может говорить исключительно о крайне малых сроках присутствия тестовых страниц в периметре Всемирной Паутины, что не позволило поисковому роботу дотянуться до уникальных данных. Тем не менее, сам код аналитической системы для веб-разработчика не спровоцировал индексацию страниц, а значит, как минимум, на данном этапе он не может являться каналом утечки данных в поисковую систему. Согласно заявлению представителей Яндекс после выявления факта утечки в «Яндекс.Метрику» внесены соответствующие исправления (http://bit.ly/qFtSs5 — комментарии представителей поисковой системы). Детали не уточняются. Двигаемся дальше.

Не одним Яндексом полнится множество поисковых систем, по этой причине было принято решение о поверхностном осмотре действий аналогичного JS-кода от Google. Беглый осмотр логов снифера показал результаты активности данного скрипта, которая заключается в передачи на сервис Google Analytics статистической информации о действиях пользователя. Среди этой информации находится и адрес страницы, на которой размещен код, а это означает, что Google, как минимум «знает» о наличии данной страницы (код используется для формирования статистики, отображаемой Гуглом на веб-панели администратора ресурса, но кто знает, куда еще уходят данные).

Эффект газового разряда


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

Иллюстрация утечки обезличенных данных

Рассмотрим подробнее каналы утечки данных, которые открывают указанные выше расширения для пользовательских браузеров от разработчиков поисковых систем на примере «Яндекс.Бар» и «Google.Toolbar».

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

Фоновая активность Google Toolbar.
Фоновая активность Google Toolbar.

Яндекс.Бар параллельно передает данные по HTTP несмотря на передачу данных по HTTPS-соединению.
Яндекс.Бар параллельно передает данные по HTTP несмотря на передачу данных по HTTPS-соединению.

Переключаем свое внимание на аналогичный продукт от Яндекса. Чтобы результаты исследования были «погорячее», рассмотрим поведение плагина в боевых условиях: совершим платежную операцию в распространенной системе интернет банкинга «HandyBank», установленной у одного из крупных российских банков.

Классика жанра: плагин передает адрес страницы на сервис поисковой системы. Вводим детали платежной операции и жмем «Далее». Скрипт системы интернет-банкинга передает всю введенную информацию в GET-запросе и это провоцирует передачу конфиденциальной информации на сервис Яндекса. Косяк… Причем, со стороны вендора системы.

Демонстрация передачи платежных данных в параметрах URL на сервис Яндекса.

«Яндекс.Бар» помимо быстрого поиска предоставляет возможность проверки орфографии данных, введенных пользователем на текущей странице. Активируем данную опцию и что мы видим: плагин передает всю информацию о деталях платежной операции в специально составленном XML-файле на сервис проверки орфографии от Яндекса (структура этого файла хорошо видна на соответствующем скриншоте). И все это Я.Бар передает на свои сервера в обход HTTPS-соединения по незащищенному протоколу HTTP.

Опция Проверка орфографии Я.Бара провоцирует передачу платежных данных на сервис Яндекса.

Глазами аналитика


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

Особое внимание к новости, которая послужила отправной точкой для наблюдения за деятельностью поисковых систем, вполне возможно косвенным образом вызвано событиями, развернувшимися вокруг ФЗ-152, изменения которого пошатнули российскую индустрию ИБ. Обнародованная СМС-переписка и поставленный в угол «Мегафон» — яркая демонстрация якобы плохой защищенности персональных данных, к которым, согласно обновленному определению, теперь относится почти любая информация, созданная существом человекоподобным. Но это уже другая история.
Denis Makrushin @Difezza
карма
25,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (45)

  • +14
    Черт, пора переходить на текстовый браузер без поддержки client-side скриптов, а после использования интернета уничтожать одноразовый компьютер.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вирус может в БИОС пролезть.
        • –1
          ходить в инет из-под виртуалки :)
        • 0
          А за что минус?
          Вот же: habrahabr.ru/blogs/virus/128570/, натуральный BIOS-руткит.
  • +80
    Ух ты, картинки в bmp.
    • +5
      Так вот почему, сидя с телефона, к концу прочтения статьи я их так и не увидел.
    • 0
      Большое спасибо! Поправил.
      • +21
        Отлично поправили, однако. Всё с текстом в jpg, единственная картинка без него — в png. На xkcd сами сходите?
        • +7
          Вы имеете в виду знаменитый комикс «PNG vs JPEG»? Считаю необходимым указать, что он располагается не на xkcd.
      • +1
        JPEG в отдельных случаях еще хуже, чем даже BMP (ведь BMP бывает индексированный). Но PNG, конечно, еще лучше индексированного BMP.
  • +5
    Автор считает, что если через два после публикации страница не попала в поисковую выдачу, то всё ок?
    • 0
      Автор посчитал, что данный вектор утечки на момент исследования является менее приоритетным по указанным в статье причинам (комментарии разработчиков Яндекса и отсутствие результатов за длительный временной промежуток).
      Уверяю Вас, что даже на текущий момент страницы, содержащие скрипт Я.Метрики не попали в поисковую выдачу.
      • +1
        Не могли бы вы привести рабочие ссылки на обсуждаемые страницы?
      • +2
        С другой стороны не зря же после «Я.Инцидента» Яндекс добавил опцию «Запрет отправки страниц на индексацию» в настройка счетчика Яндекс.Метрики. (http://help.yandex.ru/metrika/?id=1120714)
        • +1
          Судя по тому, что эта опция требует явного включения (более того — не особо простого; например, на многих сайтах код прописывается в шаблонах страниц, и не меняется от страницы к странице, а здесь именно это и требуется), а не явного отключения — я бы сказал, что опция сделана в изрядной степени для того, чтобы можно было при случае прессе показать на нее, мол, сами владельцы сайта не воспользовались официально предложенной им возможностью.

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

          На фоне обычно декларируемой заботы о пользователях и веб-мастерах такой подход не особо приятен.
          • 0
            Я ничего не говорил об удобности использования этой опции и о декларациях/заботе/подходах Яндекса.

            Я лишь хотел сказать, что Яндекс не сосвсем «не-при-делах», что косвенно доказывается фактом добавления этой опции именно после описанных в статье событий.

            Это был лишь аргумент автору комментария, который соглашался с автором статьи, что вектор утечки через Яндекс наименее приоритетный, и утверждал, что «даже на текущий момент страницы, содержащие скрипт Я.Метрики не попали в поисковую выдачу».
      • +3
        люди неделями ждут индексации засвеченных где угодно страниц… Раньше чем через 2 недели нет смысла говорить о корректной\некорректной индексацией яндексом.
        • +1
          Я 9 месяцев ждал :)
  • +14
    Круто! Пойду порадую всех своих знакомых — любителей десятка тулбаров с «очень важной информацией» от погоды в столице Зимбабве, до курса юаня к тэньге.
  • +7
    А я вот все давно хотел спросить, да боялся засмеют…
    Вот захожу я в панель вебмастера Яндекс, смотрю: документов загружено роботом 100, в поиске 80, исключенные страницы 20.
    По подробной ссылке на исключенные смотрю причину — ага, запрещено в роботс.ткст.
    Причем выдает список всех исключенных страниц, даже тех, которые в роботсе регулярными выражениями запрещаются.
    Но страницы то ЗАГРУЖЕНЫ! Робот вообще же не должен на них ходить и анализировать.
    Так вот — а разве эти загруженные страницы не могут непосредственно из Яндекса всплывать?
    • 0
      Не обязательно загружены. Может просто ссылки нашлись, но паук по ним пошел, т.к. они в robots.txt-list запрещены. Нужно потестировать — написать скрипт который все заголовки сохраняет — тогда станет понятно стукается ли в них паук или нет
      • +1
        Вполне возможно…
        Однако в вебмастере на главной странице так и написано (цитирую заголовки колонок): Сайт \ ТИЦ \ ЗАГРУЖЕНО РОБОТОМ \ Страниц в поиске.

        Далее, если кликнуть по цифре, отраженной в «Загружено роботом» попадаем в раздел (опять же дословно): «Структура сайта с точки зрения робота Яндекса. Показаны подразделы, содержащие более 10 страниц и занимающие более 1% от общего числа загруженных страниц.»
        С заголовками колонок: Загружено страниц, доля %.

        Ну, а если пройти в «Исключенные страницы \ По типу» видим, что они «запрещены в роботсе».

        в таком контексте логично предположить, что он их все же «грузит» и страницы Яндексу известны, но в выдачу он их не пускает… (или с учетом возможных глюков все же может пустить)…
        • +1
          Было бы здорово, если бы ребята с Яндекса прокомментировали.

          Просто я в своих предположениях отталкиваюсь от первоначального предназначение robots.txt как средства контролировать ботов, чтобы не создавать нагрузку. Если Яндекс тупо на них забивает, то следовательно, нужно его по заголовкам банить… А что если какой-нибудь публичный сервис без авторизации, но с запретом всем ботам делает тяжелые операции… Ну например, PDF быстрообновляющегося контента позволяет делать — то его такой «непослушный» бот может запросто прибить.

          Поэтому хочется верить, что это просто ребята неправильно подписи сделали
  • +7
    чем дальше читал про бары, тем больше расширялись глаза, особенно про http в обход https. сам бары не использую и категорически избегаю, поэтому не задавался вопросами защищенности соединений или какие данные передаются. Но людей, который любят ставить бары, либо тупо ставят все подряд, не задаваясь вопросом, почему сегодня одним баром стало больше знаю, и таких много.
    По статье не понял только. Так кто виноват?
    • +1
      Ой да ладно, приватбанк использует га и гуглдокс на внутренних страницах своего банкинга.
      Я им об это написал — мне ответили, что никакой проблемы в этом нет.
      • +3
        это отображает крайнюю заботу банка о своих клиентах, а также профессионализм людей, предоставляющих эти услуги.
  • +3
    Уважаемый автор так увлёкся срывом покровов, что забыл ответить на вопрос почему же он читал смс.

    Кроме того, не понятно, что он хотел сказать фразой
    >которая по каналам утечки попадает в различные уголки сети
    Бары собирают данные и раскладывают их по пиринговым сетям?

    >Скрипт системы интернет-банкинга передает всю введенную информацию в GET-запросе и это провоцирует передачу конфиденциальной информации на сервис Яндекса. Косяк… Причем, со стороны вендора системы.

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

    Ну и отдельно доставляет стилистика первого абзаца в разделе «Глазами аналитика».

    Но в целом статья понравилась — даёт исчерпывающе представление об уровне «экспертов ИБ».

    PS
    Было бы круто приложить к посту лупу для изучения скриншотов.

    • 0
      >Но в целом статья понравилась — даёт исчерпывающе представление об уровне «экспертов ИБ».

      И каков же он, этот уровень?
    • 0
      Извините, а как, если не гет?
    • 0
      Автор привел результаты исследований, но предоставляет читателю возможность ответить на вопрос в заголовке статьи самостоятельно.

      > Бары собирают данные и раскладывают их по пиринговым сетям?

      Не совсем. Рассмотренные каналы утечки: 1) Я.Метрика/GoogleAnalytics — скрипты сервиса для веб-мастеров 2) Я.Бар/GoogleToolbar — расширения для браузеров. Каждый из указанных каналов передает информацию поисковой системе, таким образом в кэш попадают фрагменты конфиденциальных данных.

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

      Автор искал банк для совершения платежной операции, а уязвимая (на тот момент) система интернет-банкинга нашла его сама.

      Спасибо!
      • 0
        >Каждый из указанных каналов передает информацию поисковой системе, таким образом в кэш попадают фрагменты конфиденциальных данных.

        Объясните пожалуйста подробней, как из одного следует другое?

        >Рассмотренные каналы утечки: 1) Я.Метрика/GoogleAnalytics — скрипты сервиса для веб-мастеров

        Вы же в статье пишите, что

        >Тем не менее, сам код аналитической системы для веб-разработчика не спровоцировал индексацию страниц, а значит, как минимум, на данном этапе он не может являться каналом утечки данных в поисковую систему
        • 0
          > Объясните пожалуйста подробней, как из одного следует другое?

          Пользователь вводит информацию в браузере с установленным плагином от ПС => определенная информация попадает в кэш. Пользователь посещает страницу с установленным скриптом статистики => определенная информация попадает в кэш. Пользователь использует браузер fx.yandex.ru/ => определенная информация попадает в кэш. Таким образом: определенная информация от различных источников в сумме может образовать конфиденциальную информацию.

          >Вы же в статье пишите, что

          В статье я описываю результаты исключительно своего эксперимента. В моем случае он ничего не спровоцировал, но в СМИ была опубликована информация о том, что именно Я.Метрика послужила причиной утечки.
          • 0
            Под кешем в данном контексте имеется ввиду индекс, правильно?

            >установленным плагином от ПС => определенная информация попадает в кэш
            какая информация? урлы?

            То есть по Вашей логике получается, что все урлы по которым ходит пользователь должны быть проиндексированы и должны быть доступны по запросу. почему этого не происходит?
    • 0
      > почему же он читал смс

      Всегда поражали такого рода подходы: «если ты хороший, не тронь плохое». В ответ напомню знаменитое «All that is necessary for the triumph of evil is that good men do nothing» ©, надо не глаза закрывать, а реагировать.
  • +9
    Такое ощущение, что автор решил применить «защиту Чубакки»

    image
  • +5
    >… И все это Я.Бар передает на свои сервера в обход HTTPS-соединения по незащищенному протоколу HTTP…

    От же яка подлюка! :( Это теперь мне объяснило чью активность по http я наблюдал при проведении операций в интернет-банке
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Участник форума rdot.org под псевдонимом «C3~RET» опубликовал небольшую исследовательскую работу

    На самом деле, автором данной „исследовательской работы” является Дмитрий Евтеев: Яндекс.Бар – Большой брат следит за тобой
    • 0
      Кто сказал, что два исследователя не могут обнаружить аналогичные результаты в один и тот же промежуток времени?
      • 0
        Я такого не сказал.
        Возможно вы правы, но, во-первых я заметил две практически одинаковых статьи.

        А во-вторых:
        … задал еще один, довольно хороший вектор для новых публикаций в средствах массовой информации.
        Речь идёт всё-таки о Дмитрии Евтеев (например).
  • НЛО прилетело и опубликовало эту надпись здесь
  • –8
    хуй

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