Ющук Евгений Леонидович (yushchuk) wrote,
Ющук Евгений Леонидович
yushchuk

Category:

Программы для поиска на персональном компьютере как потенциальные шпионы. Результаты тестирования.

Статья представляет собой детальное описание эксперимента, в котором изучалась сетевая активность трех популярных программ по поиску информации на жестком диске локального компьютера - Google Desktop Search, Yandex Desktop и Copernic Desktop Search.

Исследователи искали и нашли ответ на вопрос, передают ли такие программы в Интернет информацию с компьютера без ведома пользователя.

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




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


Исторически сложилось так, что работа проводилась в два этапа.

Первый этап был выполнен лично Ющуком Евгением Леонидовичем с помощью общедоступного программного обеспечения. Результаты этой работы можно увидеть двумя способами. Первый способ – пройти по приведенным ссылкам на сайт it2b (для удобства размещения статья там представлена в виде трех частей, поэтому первому этапу эксперимента соответствуют ссылки на Часть 1 на it2b , Часть 2 на it2b , Часть 3 на it2b )

Второй способ – это скачать статью в виде файла Word размером около 1.12 МБ здесь: cкачать файл Word

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

Эту, четвертую, часть статьи мы приводим здесь полностью:

Программы для поиска на персональном компьютере как потенциальные шпионы. Часть четвертая. Идем вглубь.

Автор: Е. Л. Ющук, (автор книги «Конкурентная разведка: маркетинг рисков и возможностей», член SCIP)

27 января 2006г.


В предыдущей статье мы исследовали поведение поисковиков Google Desktop Search (далее по тексту - Гугл), Yandex Desktop (далее по тексту - Яндекс) и Copernic Desktop Search (далее по тексту - Коперник), с точки зрения передачи ими данных во внешнюю среду и приема оттуда. После этого нам стали поступать отзывы от читателей. Оказалось, что исследуемый вопрос вызывает интерес не только у рядовых пользователей, но и у серьезных специалистов по компьютерной безопасности.

Мы обратились за помощью к человеку, который профессионально занимается вопросами информационной безопасности.

Владимир Казеннов, как зовут нашего эксперта, не только помог нам советами, но и непосредственно проделал основную часть экспериментальной работы. Если читателям потребуется связаться с Владимиром, чтобы прояснить непонятные моменты, это можно сделать по электронной почте kentavr10@yandex.ru

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

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

Выводы:

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

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

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

И еще, установлено, что часть программного кода, применяемого Гуглом – в частности, java-скрипт может при определенных условиях быть вредоносной, так как использует технологию скрытого сбора информации и не требует получения разрешения от пользователя на ее отправку Google. Во всяком случае, такие java-скрипты не приветствуются в защищенных системах.

Правда, это именно так на момент проведения эксперимента. Что будет завтра, мы спрогнозировать не в состоянии.

Кроме того, подробно объяснено, почему loopback, так часто присутствующий при работе Гугла, Яндекса и многих других программ, безвреден в принципе, хотя и открывает порты на локальном компьютере.



Дополнительные термины, которые встречаются в этой статье.

Снифер - (вынюхиватель, в переводе с английского) – программа, которая позволяет не только зафиксировать факт передачи данных с одного адреса на другой, но и показывает, какие именно данные и в какой последовательности передавались. Его синонимом является термин «сетевой анализатор».

Прокси-сервер – компьютер, через которые несколько машин, объединенных в единую сеть, могут выходить в Интернет. Это своего рода ворота. Если установить программу на прокси-сервере, можно контролировать, а также разрешать или запрещать полностью или частично движение всех данных в сеть и из сети.

Куки (cookies) – небольшой текстовый файл, который сайт устанавливает на компьютер, зашедший на этот сайт. Куки сами по себе не вредят компьютеру и часто используются для организаций сессий с сайтом, так как обычно содержат в себе уникальный идентификатор пользователя по отношению к этому сайту в виде пары – имя параметра и его значение. Поэтому куки позволяют сайту, например, узнавать вас при последующем посещении. Если вы хотите увидеть Куки в своем браузере Mozilla Firefox, то щелкните следующие ссылки: Инструменты > Настройки > Приватность > Cookies > Просмотр Cookies.
Некоторые Куки воспринимаются антишпионскими программами как потенциально опасные, т.к. они позволяют путем идентификации пользователя при обращении его к сайтам и последующего анализа запросов пользователя по журналам сайтов (группировки их по уникальным значениям кук) выявить его предпочтения и нарушить таким образом отчасти неприкосновенность личной жизни (privacy).

GET / POST – обозначение типа запроса веб-браузера к сайту. При GET параметры запроса передаются прямо в теле URL и видны в браузере и истории посещения им страниц, а при POST – в поле данных запроса (и не видны поэтому).


Выполнение эксперимента.

Прежде, чем дать описание эксперимента, обращаем внимание читателей на то, что в тексте встретятся ссылки на подлинные файлы с полным описанием записи, которые появлялись в журнале снифера при появлении сетевой активности испытуемых программ. Основные параметры приведены в тексте и для большинства читателей их будет достаточно. Если кто-то захочет подробно познакомиться с файлами журнала, то его можно скачать в виде архива размером около 250кБ здесь: Скачать архив файлов


В ходе эксперимента на компьютере с установленной Windows XP (SP2) была запущена так называемая виртуальная машина. Этот прием позволяет проводить чистые эксперименты и создавать такую тестовую среду, в которой на компьютере работает только тестируемая программа, и работа других программ не оказывает влияния на результат эксперимента.

Для непосредственного анализа сетевой активности приложений использовались программы - SmSniff и Ethereal.

SmSniff представляет собой бесплатный снифер, который позволяет для каждого отдельного сетевого соединения собрать вместе прикладные данные без служебных заголовков пакетов, передаваемые в обе стороны, сохранить потом эти данные в отдельный текстовый файл и обеспечить, таким образом, легкость их анализа (что важно особенно для HTTP-соединений). Скачать эту программу можно по адресу: http://www.nirsoft.net/utils/smsniff.html Снимок экрана программы приведен на рисунке:



Сразу поясним, что на этом рисунке видно.

Применительно к выделенной строке, снифер сообщает, что идет передача данных по Интернет-протоколу HTTP (это протокол, которым пользуются браузеры, просматривающие страницы Интернета). Данные передаются с компьютера пользователя, имеющего ip-адрес 192.168.0.5 на адрес 216.136.131.30, принадлежащий поисковой машине Yahoo!. Конкретно, передача идет с порта 1088 на порт 80. Передано 6 пакетов общим объемом 826 байт.

В нижнем окне на рисунке показано, что в поисковую машину Yahoo! сделан поисковый запрос по слову nirsoft .

Чтобы убедиться в этом, мы самостоятельно сделали этот запрос. Вот строка, которая была сгенерирована в окне URL, когда Yahoo! Выдал ответ по запросу:

http://ru.search.yahoo.com/search?p=nirsoft&sm=%D0%9D%D0%B0%D0%B9%D1%82%D0%B8&fr=FP-tab-web-t&ei=UTF-8&vc=

Как видите, эта строка почти совпадает с той, что приведена в снимке экрана. Кроме того, на снимке видно, что запрос сделан с из браузера Mozilla/4.0, а также что компьютером воспринимаются английский язык в американской версии. Там же показано, что соединение прошло с компьютером по адресу pa.yahoo.com

Программа Ethereal (http://www.ethereal.com/) позволяет записывать в один файл специального формата данные о всех сетевых взаимодействиях. Она предназначена для решения широкого класса задач, но, к сожалению, не содержит удобных встроенных средств сбора только прикладных данных, поэтому и использовалась в качестве резервной. С другой стороны она имеет богатые возможности выборочного перехвата пакетов и анализа служебных заголовков пакетов (что невозможно с помощью SmSniff), дополняя, таким образом, ее.

Мы не будем приводить здесь снимки экрана этой программы, т.к. они лишены каких бы то ни было украшений и представляют собой просто строки, идущие друг за другом. Желающие могут увидеть их на сайте программы.

В нашем эксперименте были последовательно установлены все три поисковика - Copernic Desktop Search, Google Desktop и Yandex Desktop, в каждом из них после установки делался запрос на поиск информации на локальном компьютере, после чего поисковик удалялся с компьютера и заменялся следующим.
Эксперимент проводился 26.01.2006г., эту дату можно видеть в файлах отчетов снифера.
Как было показано в предыдущих частях статьи, Google и Yandex использовали веб-интерфейс для организации взаимодействия с пользователем локальной программы поиска. Для этого они и открывали на порту 4664 (Google) и на порту 9375 (Yandex) так называемые локальные веб-серверы, которые обеспечивают передачу данных между ними и веб-браузером, запущенным пользователем программы поиска. Данные, передаваемые в ходе такого взамодействия, не выходят за пределы локального компьютера. Убедиться в том, что процесс носит именно локальный характер, можно, посмотрев адрес URLа, который показывается в консоли пользователя при открытии браузера (в качестве имени хоста указан localhost или 127.0.0.1).
Опишем теперь то, что осталось за кадром в предыдущей статье, а именно – куда и какую конкретно информацию передали поисковики, а также, что они получили взамен и откуда.
В журналах есть указание на порт 3128. Для тех, кто обратит на это внимание, поясним, что этот порт, как и адрес прокси-сервера, появились в журналах потому, что тестовая машины для контроля за взаимодействиями была подключена к Интернет через прокси-сервер и именно через прокси-сервер выполнялись все описанные ниже соединения с Интернетом.


1)Поведение Коперника
После установки, как и было показано ранее, Коперник попытался получить обновления. В подробностях это выглядело как обращение по адресу:

http://updates.copernic.com/softwareupdates/desktopsearchupdateinfo.scuf
и загрузка закодированного файла с информацией об обновлениях (подлинник этой записи со всеми подробностями можно увидеть в файле cop1.txt)
Затем Коперник самостоятельно запустил веб-браузер и перешел в нем на главную страницу сайта программы Коперник:

http://www.copernic.com/go/?dest=cds16welcomepage&l=ENG&e=
(подлинник этих записей со всеми подробностями можно увидеть в файлах cop2.txt - cop6.txt). Столь большое количество файлов обусловлено тем, что на загружаемых страницах содержится много изображений и каждое изображение требует отдельной загрузки, для чего веб-браузером устанавливается новое соединение с веб-сервером. Дальше мы увидим, что другие сайты позволяют в рамках одного соединения передавать несколько запросов и получать, соответственно, несколько ответов (поэтому приложенные файлы надо просматривать до конца, чтобы увидеть их).
Анализ служебных заголовков запросов не выявил ничего подозрительного. Для специалистов конкретизируем, что все запросы имели тип GET, а куков и дополнительных служебных полей в заголовках не было.


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

GET http://desktop.google.com/firstuse?version=121205-233423&id=1f931c38a13d4f3aea604e92f4741fbc&brand=GGLD&hl=ru , где произвел регистрацию нового клиента (подлинник этой записи со всеми подробностями можно увидеть в файле google1.txt).

Затем Гугл проверил наличие обновлений, что отразилось снифером в записи:
GET http://desktop.google.com/updatecheck?id=1f931c38a13d4f3aea604e92f4741fbc&hl=ru&rb=0&version=121205-233423&brand=GGLD (подлинник этой записи со всеми подробностями можно увидеть в файле google2.txt).
Далее для того, чтобы использовать ближайший к пользователю национальный сервер. Гугл получает список национальных серверов:

GET http://www.google.com/supported_domains
При этом на компьютер пользователя устанавливается кука:

Set-Cookie: PREF=ID=ef3b95f5a20cf20e:TM=1138265002:LM=1138265002:S=fvXZjDP_wxOkqB7z; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
(подлинник этой записи со всеми подробностями можно увидеть в файле google3.txt)



Затем на компьютере пользователя запускается локальный веб-сервер и веб-браузер, настроенный на него, и браузер обращается к сайту Google (это видно по полю Referer – указанию предыдущей ссылки, с которой произошел переход на текущую ссылку):

GET http://www.google.com/
В ответ на это обращение, на компьютер пользователя устанавливается еще одна Кука:

Set-Cookie: PREF=ID=5e3dceb7857639a7:TM=1138265032:LM=1138265032:S=ZdB1kWwm_Z7yh2dk; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com

После этого происходит переключение на национальный сервер - www.google.ru и снова следует установка куки на компьютер пользователя:

Set-Cookie: PREF=ID=482df878e3ab6188:TM=1138265032:LM=1138265032:S=oskcMsWN9YUq6YNg; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.ru

(подлинник этой записи со всеми подробностями можно увидеть в файле google4.txt)

Затем производится автоматическая регистрация установки поисковика Гугл на локальном компьютере и указывается полученный ранее идентификатор пользователя программы поиска:

GET http://desktop.google.com/installer?action=install&version=121205-233423&ec=0&id=1f931c38a13d4f3aea604e92f4741fbc&brand=GGLD&hl=ru

И снова на локальный компьютер устанавливается кука c помощью поля Set-Cookie:
PREF=ID=ef3b95f5a20cf20e:TM=1138265002:LM=1138265002:S=fvXZjDP_wxOkqB7z


Интересно, что никаких данных локальный компьютер обратно не получает. Это может быть связано с тем, что описанные действия Гугл проводит просто для производится регистрации запроса на установку программы поиска.
(подлинник этой записи со всеми подробностями можно увидеть в файле google5.txt)

Затем происходит новое получение неизвестных данных на компьютер пользователя (и данные передавались именно с сервера на компьютер пользователя). Выяснить, что это за данные, наше оборудование не позволило, т.к. они передавались по защищенному от перехвата протоколу SSL. Это может быть какая-то компонента программы поиска. Однако, поскольку мы не знаем, что передано в этом пакете, мы не можем и сделать вывод о том, зачем его надо было зашифровывать.
(подлинник этой записи со всеми подробностями можно увидеть в файле google6.txt)

После этого на локальный компьютер передается страница с новостями (это хорошо видно в файле с подлинной записью. Там можно увидеть, например, такой текст, рассказывающий о взаимоотношениях Малазийского производителя автомобилей Протона с германским Фольксвагеном: «Malaysia's largest car maker, Proton, remains keen to team up with Volkswagen AG despite the German firm's sudden pull-out fr...». По окончании установки программа Google открывает много панелей и, помимо, собственно поиска навязывает использование ряда других сервисов):

GET http://desktop.google.com/dsnews?i=1f931c38a13d4f3aea604e92f4741fbc&k=20&r=0&hl=ru&ed=ru&t=4031830140:19;&s=&a=
(подлинник этой записи со всеми подробностями можно увидеть в файле google7.txt).

Сразу после этого на локальный компьютер загружается карта:

GET http://desktop.google.com/maps.xml

При этом клиент начинает представляться как User-Agent: Mozilla/4.0 (compatible; Google Desktop)
(подлинник этой записи со всеми подробностями можно увидеть в файле google8.txt).


Далее Гугл начинает проверять дату и время большой группы каких-то файлов с помощью команды HEAD (с ее помощью получается информация о дате-времени последнего обновления файла, но сам файл не скачивается), чтобы выяснить необходимость их загрузки в-дальнейшем (и не загружать понапрасну те файлы, которые не обновлялись). Каких именно, мы выяснять не стали. Желающим сделать эту проверку рекомендуется посмотреть на все панели, которые Гугл разворачивает и вычислить, для какой из них он это делает (судя по данным о расширении, это какой-то файл с картинкой) на сайте mt.google.com (чтобы принять решение, грузить его или нет):
HEAD http://mt.google.com/mt?v=w2%2E5&hl=ru&x=736&y=1589&zoom=5

(подлинник этой записи со всеми подробностями можно увидеть в файле google9.txt).

Затем Гугл получает список стран:


GET http://www.google.com/ig/countries?output=xml&hl=ru
(подлинник этой записи со всеми подробностями можно увидеть в файле google10.txt)

Потом Гугл получает список блогов (еще один навязанный сервис) размером 30Кб:

GET http://googleblog.blogspot.com/atom.xml
(подлинник этой записи со всеми подробностями можно увидеть в файле google11.txt)


Далее Гугл проверяет данные о группе других файлов-картинок на mt.google.com c URL’ами аналогичного вида.
Эта деятельность отражена в файлах(google12.txt - google47.txt c несколькими пропусками – параллельно идет загрузка данных для других панелей – см. ниже). Проверка эта происходит не всегда удачно (иногда возвращается код 404 - страница не найдена, что вообщем-то непонятно).
Затем Гугл получает список городов в России (файл google48.txt:
GET http://www.google.com/ig/cities?output=xml&hl=ru&country=RU

После этого он получает информацию о текущей погоде в России (еще навязанный сервис)(файл google49.txt):
GET http://www.google.com/ig/api?hl=ru&weather=,,,55750000,37630001

Параллельно вышеописанному опросу Гугл начинает обращаться к страницам, на которые заходил недавно пользователь (google18.txt, google27.txt, google33.txt, google50.txt - google58.txt). Скорее всего, таким образом Гугл либо кэширует данные (сохраняет в памяти), либо хочет отслеживать обновления этих страниц(возможно, Гугл так предпочтения пользователя как раз и узнает. Он же любит настраивать персонализированный поиск и делает это своим приоритетным направлением) В любом случае происходит целенаправленный сбор данных о поведении пользователя компьютера в Интернете (но отправки информации об это обратно на Google явно зафиксировано не было – разве, что с помощью SSL).
После этого сбора данных Гугл опять скачивает какие-то данные на компьютер по протоколу SSL с www.google.ru (файл google43.txt). Как и в предыдущем случае, мы не имеем возможности узнать, что это за данные, т.к. они защищены от перехвата.

Наконец, Гугл отправляет обратно POST-запросом информацию о своем состоянии (файл google59.txt):

POST http://desktop.google.com/status

ВНИМАНИЕ!
Ниже приведены данные (размером 2Кб), где по именам параметров видно, насколько разнообразную статистическую информацию и информацию о своих собственных параметрах отправляет поисковая программа Гугл на свой сервер.

version=121205-233423&v=7&brand=GGLD&id=1f931c38a13d4f3aea604e92f4741fbc&uninstall=1&itime=1137228183&htime=10&uptime=0&num_indexed=2340&avg_indexing_time=6&num_queries=1&avg_query_time=20&num_commits=1&avg_commit_time=111&num_db_updates=7411&avg_db_update_time=1&num_db_lookups=0&avg_db_lookup_time=29666&num_events=2465&num_docs=2460&av_event_size=241&avg_doc_size=259&num_events_added=2465&num_docs_added=2480&ev_of=0.011&doc_of=0.012&db_size=56557893&index_size=28311655&repo_size=49283278&events_51=2500&dups_51=231&invalid_51=0&exp_search=1&search_all=1&time_slp=639&exp_search_slp=1&search_all_slp=1&hypr_stky=0&hypr_dflt_srch=0&hypr_indx_sz=20971635&hypr_num=6&hypr_ft_on=1&nuicls=4&af=1&gmail=0&blist=0&ccrawl=0&sb_size=153&sb_curr_pl=8&sb_past_pl=1&{ECCB44957F5B4B4EA8877A66BE948AC1}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,188&{FBA13A6FE59548B7AB732630042A4E93}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,188&{65E256ACB33540048C6A5A7F986CD0A4}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,36&{4516155CB94E43348D26D4BF0932581C}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,115&{3C66FE034FB7497C850F60265842D043}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,120&{50EDABE0140C406DA8B932652145560A}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,45&{A5B8FE6AE3E140F38189630E37C2AA47}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,0&{3872340B239E4C1CA7830E2A5E28383B}=1,0,0,0,0,0,0,0,0,0,0,0,0,0,36&{18F55B95159A4982A1377FB2193AB210}=0,0&disp_mode=1&sb_days=0&default=6&talk=0&fti_mode=3&hyper_mode=2&hl=ru&user_feeds=0&feeds=1&active_feeds=1&auto_rem_feeds=0&feeds_w_clks=0&stocks=0&zip=0&zip_good=0&mem_load=84&fr_phys_mem=61534208&tl_phys_mem=402112512&fr_page_mem=878628864&tl_page_mem=1168248832&fr_vir_mem=2087309312&tl_vir_mem=2147352576&min_ws=204800&max_ws=1413120&sx=1280&sy=960&nmon=1&wx=1127&wy=930&fh=11&bw=771&bh=453&free_disk=5267787776&total_disk=8578932736&w2k=0&efs=0&fs=NTFS&fsf=700FF&news_len=0&4024883069=1&1381391883=6&873245=1&outlook-1=1&outlook_addin=1&search_DOC_0=1&search_XLS_0=1&search_PPT_0=1&search_PDF_0=1&search_HWP_0=1&search_TXT_4=1&search_MEDIA_5=1&search_HTTPS_0=0&search_EMAIL_1=1&search_WEB_2=1&search_CONTACT_9=1&search_CALENDAR_0=1&search_TASK_1=1&search_NOTE_2=1&search_JOURNAL_3=1&search_AIM_3=0&search_AIM_6=0&search_SECUREOFFICE_0=0&blacklist_used=1&integration=1&admin=1


Затем Гугл скачивает данные для локального показа карты (файл google60.txt):

GET http://www.google.com/maps?file=desktop&sourceid=gd

Далее Гугл скачивает картинки для этой карты (файлы google61.txt - google64.txt) с идентификатором клиента:

GET http://kh.google.com/kh?&v=3&hl=ru&t=tsrrtrsqqrsqq&cookie=fzwq1JGYLAs0UddQlbttf5nVBnKzeMp-p1wxwA

При удалении программы происходят следующие явления:
Сначала скачивается страница с формой-анкетой:


GET http://desktop.google.com/uninstall-feedback.html?hl=ru
(файл google65.txt)

Затем регистрируется удаление программы (файл google66.txt):

GET http://desktop.google.com/installer?action=uninstall&version=121205-233423&ec=0&id=1f931c38a13d4f3aea604e92f4741fbc&brand=GGLD&hl=ru&itime=10&htime=10

После этого скачивается javascript-часть к форме-анкете (файл google67.txt):
GET http://www.google-analytics.com/urchin.js

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

И еще странный запрос ниже(файл google68.txt). Необычно и непонятно, почему в запросе, который похож на GIF, содержится так много параметров для его получения (обычно GIF-файл является статическим и его получение не требует указания в URL каких-либо параметров. Скорее наличие параметров говорит о том, что вызывается какой-то скрипт, вызов которого маскируется под получение GIF-файла. Причем, такой способ маскировки удобен тем, что не требует привлечения пользователя для его вызова и сбор статистики может быть осуществлен автоматически. Этот запрос является результатом работы скрипта, показанного в файле google67.txt, судя по результатам анализа программы, находящейся в нем). Связь при этом установлена с адресом на www.google-analytics.com :

GET http://www.google-analytics.com/__utm.gif?utmwv=1&utmn=1742479550&utmsr=1280x960&utmsc=32-bit&utmul=en-us&utmje=1&utmfl=6.0&utmcn=1&utmdt=%u0421%u043F%u0440%u0430%u0432%u043E%u0447%u043D%u044B%u0439%20%u0446%u0435%u043D%u0442%u0440&utmhn=desktop.google.com&utmr=-&utmp=/support/bin/request.py?contact_type=uninstall&hl=ru&utmac=UA-18007-2&utmcc=__utma%3D171019829.1742479550.1137228847.1137228847.1137228847.1%3B+__utmb%3D171019829%3B+__utmc%3D171019829%3B+__utmz%3D171019829.1137228847.1.1.utmccn%3D%28direct%29%7Cutmcsr%3D%28direct%29%7Cutmcmd%3D%28none%29%3B


Напоследок - прощальное обращение Гугла на страницу поддержки:
GET http://desktop.google.com/support (файл g69.txt)




3) Поведение Яндекса.
На фоне Гугла Яндекс ведет себя как спокойный Удав Каа по сравнению с непоседливой Пеппи-Длинный Чулок.
После установки Яндекс получает RSS-файл (это XML-файл с информацией о параметрах Яндекса. Просмотр не выявил в нем ничего подозрительного).

GET http://desktop.yandex.ru/version.rss?appid={C975C436-D0C3-46C3-BC71-60371B395405}&ver=0.9.8.310

При этом на компьютер устанавливается Кука:
yandexuid=6745512991138264648; expires=Tue, 19 Jan 2038 03:14:07 GMT; path=/; domain=.yandex.ru

И агенту явно присваивается уникальный идентификатор (appid). Вероятная цель этих действий - идентификация компьютера (или инсталлированной версии программы поиска).
(подлинник этой записи со всеми подробностями можно увидеть в файле yand1.txt).
Затем, вероятно, обновляется счетчик использования программы поиска на сайте Яндекса при каждом запросе к программе поиска(файлы yand2.txt - yand4.txt):

GET http://export.yandex.ru/counters-js
Это видно по полю Referer - Referer: http://127.0.0.1:9375/
При этом от клиента передается кука, установленная ранее. Собственно тело содержит один Javascript-оператор, присваивающий счетчику нулевое значение.

Можно констатировать, что реализованы следующие параметры:
• идентификация клиента в целом (с помощью кук),
• идентификация фактов использования клиентом программы и выдаваемых им поисковых запросов (так как в локальном интерфейсе запрос программе поиска передается с помощью GET-запроса, в поле Referer он виден - например, тестовый запрос "aaaa" привел к появлению вызова счетчика с полем Referer - Referer: http://127.0.0.1:9375/?dtype=0&ls=1&text=aaaa )
Правда, эксперты считают, что скорее всего, это незапланированный побочный эффект (им надо было использовать POST-запрос, а не GET), так как, по мнению экспертов, Yandex – добропорядочная компания, и если бы захотела собирать информацию об использовании, предупредила бы пользователей об этом и реализовала бы ее сбор совершенно по-другому (например, как Google – с помощью отдельного запроса), но, как говорится, "кто предупрежден, тот вооружен".


В заключение – несколько слов о том, почему безвреден loopback , несмотря на то, что порты открываются.
Loopback абсолютно безвреден потому, что он не доступен извне. Порты, открытые на этом адресе, не могут быть использованы злоумышленниками для организации «черного входа» на компьютер.
Дело в том, что ip-адрес, который имеет этот процесс, означает, что пакет можно послать только с этого компьютера на этот же компьютер, т.е. – самому себе и никак иначе.
Loopback на самом деле - это IP-адрес с DNS-именем localhost (не путать с localhost - это условное имя локального компьютера в Outpost) (127.0.0.1). Нас интересует именно IP-адрес, так как для успешного взаимодействия с компьютером, нужно его знать и этот адрес должен быть маршрутизируемым (т.е. компьютер-отправитель пакета и промежуточные компьютеры между ним и компьютером-получателем пакета должны знать, куда его послать). Адрес 127.0.0.1 - это локальный адрес, соответсвующий этому компьютеру. При попытке послать пакет на этот адрес, компьютер будет посылать его сам себе. И как, спрашивается, компьютер сможет обратиться по этому IP-адресу к другому компьютеру?


Когда вы видите, что программа открыла сетевой порт больше 1024 и локальный порт показан как localhost:any, то это чаще всего означает лишь, что программа недавно взаимодействовала с удаленным хостом и использовала этот временный (и случайным образом назначенный) номер локального порта для исходящих соединений, а не для того чтобы принимать запросы от удаленных компьютеров. Стек протоколов TCP/IP устроен так, что какое-то время после завершения передачи данных порт показывается как открытый.
Проверить, что порт не используется, можно очень просто - можно в журнале файрволла Agnitum Outpost посмотреть, не было ли исходящих соединений от этой программы (чаще всего оказывается, что для якобы открытых портов UDP посылались DNS-запросы, а для TCP - организовывались исходящие соединения). Гораздо более объективную информацию можно получить с помощью программы Secheck ( http://www.mynetwatchman.com/downloads/seccheck.exe ). Она заслуживает отдельной статьи, если по-хорошему, так как дает очень полную и объективную картину о системе и в большом числе случаев помогла легко вычислить троянские программы у пользователей. Поэтому для комплексного анализа программ на шпионские функции эксперты рекомендуют использовать три программы - Agnitum Outpost, Smsniffer и Secheck.

А для тех, кто на самом деле, анализирует внутреннее содержимое обнаруженных шпионских программ, есть Malcode Analyst Pack ( http://labs.idefense.com/labs-software.php?show=8 ). С его помощью можно активно вмешиваться и перехватывать все запросы шпиона (там тоже есть сниферы. Может быть, он помог бы перехватить незашифрованный текст того, что посылается с помощью SSL Google-овской программой…

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

 

 

Статья Google без секретов (операторы Гугла в практических примерах)

Статья «Кадровая дилемма в конкурентной разведке: «Маркетологи» или «Безопасники»

На главную страницу сайта "Конкурентная разведка для работающих в российском бизнесе"


Открытый мастер-класс Ющука Евгения Леонидовича. Ющук Евгений Леонидович
"Конкурентная разведка против PR в живом эфире". В порядке ответа на
"Черный список", автор которого Кузнецов Сергей Валентинович



Кузнецов Сергей Валентинович

Tags: Бизнес-разведка, Евгений Ющук, Конкурентная разведка, Маркетинг, Ющук Евгений Леонидович
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 12 comments