О причинах утечки информации через поисковые системы

information-leakage.jpg

Компания Positive Technologies провела вебинар на тему "Почему случился Russian.Leaks?", посвященный случаям масштабных утечках конфиденциальной информации через поисковые системы. В ходе мероприятия представители компании объяснили, что послужило причиной последних утечек, и рассказали о мерах предотвращения подобных инцидентов.

В 2011 году в Рунете случился целый ряд утечек конфиденциальной информации через поисковые системы. Обсуждение данной темы началось с утечки информации с портала wiki.yandex-team.ru, произошедшей в марте этого года: сеть внутренней вики-документации для служебного пользования сотрудников "Яндекса" была проиндексирована поисковым роботом Google. Самый громкий скандал связан с утечкой SMS-сообщений абонентов "МегаФон", отправленных с сайта оператора, о чем стало известно 18 июля (об итогах и причнах сбоя - см. новость раздела МегаФон SMS-утечка от 26 июля 2011 г.). В это же день в блогах широко обсуждалась аналогичная утечка с сайта sms.prm.ru, где успели отметиться абоненты МТС, "ВымпелКома" ("Билайн") и "МегаФона". Затем, 25 июля, появилась информация о заказах в интернет-магазинах, а на следующий день - о заказах железнодорожных и авиабилетов.

Как отметил докладчик - технический директор компании Positive Technologies Сергей Гордейчик, данное явление не ново: техника поиска конфиденциальной информации в поисковых машинах и веб-архивах известна давно. Известным является термин Google Hacking Database - это сборник приемов, с помощью которых из поисковых машин можно извлекать конфиденциальную информацию, искать уязвимые сервисы и т. д. В целом, было отмечено, что утечки через поисковые системы случаются по всему миру, однако в указанных выше случаях есть несколько интересных моментов.

Традиционно утечки связаны с простейшими ошибками в реализации веб-сайтов. Это недостаточная аутентификация, когда страницы веб-сервера, которые должны быть защищены от дистанционного просмотра, не проводят авторизацию пользователя; веб-сайты, которые разрешают индексацию каталогов; неверные разрешения файловой системы сайтов, и небезопасная индексация, когда через локальные формы поиска можно получить конфиденциальную информацию с сайта. К таким традиционным утечкам докладчик отнес несколько случаев, имевших место быть в рамках обсуждаемой волны. Так, в фотоальбомах streamphoto.ru опубликованная пользователем ссылка на закрытый впоследствии альбом оставалась доступна в кэше. В социальной сети "В Контакте" скрытые фотографии и ссылки на них не удалялись даже после удаления учетной записи. 27 июля было зафиксировано, что Google проиндексировал открытый файловый архив, содержащий документы под грифом "Для служебного пользования" в доменах *.gov.ru. В связи с этим Сергей Гордейчик привел "интернет-правило Миранды", сформулированное экспертом по вопросам информационной безопасности Михаилом Емельянниковым на Positive Hack Days 2011: "Все, что вы указали о себе в социальной сети, блоге, форуме, чате, любом общедоступном сервисе, будет храниться там вечно и всегда может быть использовано против вас".

Более сложные уязвимости традиционно эксплуатируются вручную в рамках конкурентной разведки. Это может быть подбор файлов и ссылок - Brute Force, подбор простых имен пользователей и паролей к FTP- и файловым хранилищам и другие методы извлечения информации без взлома ресурсов. Но в рамках последних утечек в кэш поисковой машины попали данные, которые до этого могли быть доступны только квалифицированному хакеру. Поясняя, как это могло произойти, Сергей Гордейчик рассказал, что после отправки веб-формы, будь-то SMS или заказ, сайты возвращали пользователю страницу статуса, которая содержала детальную информацию о переданных данных, например, номер телефона и текст сообщения или наименование заказа, его стоимость и имя заказчика. Эта страница идентифицировалась уникальным значением вида http: //site/script/?id=, зная которое можно было просмотреть страницу.
Дополнительная проверка запроса по cookie или IP не выполнялась, то есть для получения доступа к странице было достаточно знать это случайное значение. Предотвращать появление конфиденциальной информации в поисковых машинах должно использование уникального значения в адресе и ограничение времени жизни страницы, то есть поисковики просто не должны были знать о существовании такой ссылки.

Сейчас есть официальный ответ "Яндекса", где представитель информационной безопасности компании Владимир Иванов сообщает: "Мы изучили ситуацию и выяснили, что адреса страниц с некоторых хостов стали известны Яндексу через установленную на сайтах Метрику. А поскольку в robots.txt этих сайтов запрета на индексацию страниц не содержалось, они стали находиться в Яндексе. Особо хотим отметить, что посещение пользователем страницы с помощью браузера с установленным Яндекс.Баром не приводило и не приводит к ее индексации". "Яндекс.Метрика" является сервисом, позволяющим собирать статистику посещения сайта. При установке на сайте счетчика данного сервиса адреса страниц, включая уникальные значения, передаются в "Яндекс", который индексирует и кэширует их. В итоге, даже если на основном сайте страницы удалялись, их содержимое оставалось в кэше "Яндекса". Сергей Гордейчик добавил, что в настоящее время "Яндекс" изменил поведение "Метрики", снизив вероятность индексации подобных страниц.

В официальном ответе Владимир Иванов упомянул панель инструментов "Яндекс.Бар". Как пояснил докладчик, данный сервис был под подозрением, потому что он передает адреса посещаемых страниц на сайты bar- navig.yandex.ru и backup-bar-navig.yandex.ru, и было высказано предположение, что эти адреса также могут быть использованы поисковой машиной. По неофициальным заявлениям "Яндекса", передаваемые UPL не участвуют в индексации, а используются только для определения тематического индекса цитирования. Однако при дальнейшем анализе "Яндекс.Бара" возникло несколько вопросов, на которые Сергей Гордейчик дал ответы. Первый вопрос заключается в том, что будет при использовании панели инструментов "Яндекс", если при работе с банком через Интернет все запросы передаются по HTTPS. В данном случае "ЯндексБар" будет передавать информацию о зашифрованных страницах в открытом виде. Казалось бы то, что в сети будет доступен адрес интернет-банка, не играет роли. Однако здесь возникает другой вопрос: будет ли в этом случае передаваться конфиденциальная информация в открытом виде? Ответ на этот вопрос положительный в том случае, если служба дистанционного банковского обслуживания передает значения в параметрах URL-запроса. Также докладчик упомянул о том, что конфиденциальная информация в открытом виде может быть передана в случае использования функции "Проверка орфографии" в "Яндекс.Бар". Также Сергей Гордейчик обратил внимание на технологию "Вебвизор" в сервисе "Яндекс.Метрика", которая позволяет записывать действия посетителей сайтов, будь то заполнение форм на страницах или просто движения мыши. В данном случае также вся введенная информация будет сохраняться в базах данных "Яндекса".

В заключении вебинара Сергей Гордейчик дал несколько советов, как предотвратить утечку информации через поисковые системы. Администраторам веб-сайтов, как и вообще всем пользователям, рекомендуется внимательно читать лицензионные соглашения, "искать себя" в поисковых машинах и тестировать сайт с помощью автоматических утилит, аккуратно относиться к внешним компонентам, устанавливаемым на сайт, и следить за связанными с ними уязвимостями, это касается, в том числе, баннерных сетей, а также использовать передовой опыт в области безопасности. Корпоративным администраторам, которые хотят, чтобы информация с внутреннего сайта не попадала в Интернет по незащищенным каналам, докладчик порекомендовал фильтровать на межсетевых экранах различные счетчики, трафик "баров" и аналогичных приложений. Интернет-пользователям также рекомендуется внимательно читать лицензионное соглашение и фильтровать различные счетчики с помощью надстроек, таких как NoScript, AdBlock, либо встроенных возможностей браузера.

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

spbIT