Жучки в электронных письмах::Журнал СА 4.2008
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Архив номеров
Контакты
   

  Опросы
  Статьи

Разбор полетов  

Ошибок опыт трудный

Как часто мы легко повторяем, что не надо бояться совершать ошибки, мол,

 Читать далее...

Принципы проектирования  

Dependency Inversion Principle. Принцип инверсии зависимостей в разработке

Мы подошли к последнему принципу проектирования приложений из серии SOLID – Dependency

 Читать далее...

Рынок труда  

Вакансия: Администратор 1С

Администратор 1С – это специалист, который необходим любой организации, где установлены программы

 Читать далее...

Книжная полка  

Книги для профессионалов, студентов и пользователей

Книги издательства «БХВ» вышли книги для тех, кто хочет овладеть самыми востребованными

 Читать далее...

Принципы проектирования  

Interface Segregation Principle. Принцип разделения интерфейсов в проектировании приложений

Эта статья из серии «SOLID» посвящена четвертому принципу проектирования приложений – Interface

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 10304
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 8494
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 8589
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5478
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 6158
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

Друзья сайта  

 Жучки в электронных письмах

Архив номеров / 2008 / Выпуск №4 (65) / Жучки в электронных письмах

Рубрика: Безопасность /  Безопасность

КРИС КАСПЕРСКИ

Жучки в электронных письмах

Электронная почта была и остается одним из основных инструментов хакера (достаточно вспомнить письма с зловредными вложениями или эксплуатацию «дыр» популярных почтовых клиентов). Атакующие применяют все более и более изощренные приемы, зачастую неизвестные широкой аудитории администраторов и специалистов по безопасности. Сегодня мы поговорим о… ссылках на картинки и покажем, на что они способны, а способы они на многое!

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

Неожиданным хакерским подспорьем оказалась… электронная почта. Отвечая на хакерское письмо (вполне безобидное со всех точек зрения), жертва, сама того не подозревая, включает в заголовок ответа не только данные об установленном программном обеспечении, но и более «тонкую» информацию (например, номера локальных портов, по стратегии назначения которых при длительной переписке можно выявить наличие транслятора сетевых адресов или сделать вывод о степени загруженности узла).

Руководящая идея

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

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

Начнем со спам-фильтров, обрабатывающих графические изображения (а с учетом популярности графического спама такие фильтры получают все большее и большее распространение). Очевидно, чтобы отделить зерна от плевел, фильтр должен загрузить картинку, следуя указанной ссылке. Если фильтр установлен непосредственно на почтовом сервере жертвы (или перед ним), хакерский веб-сервер «поймает» GET-запрос сразу же после отправки письма (или спустя короткое время с учетом очереди обработки писем), даже если жертва спит мертвым сном и не заботится о проверке почты. Как вариант спам-фильтр может быть установлен на локальной машине (интегрирован в почтовый клиент), работающей на «автопилоте» (то есть остающейся включенной на ночь) и загружающей письма по POP3-протоколу каждые 3-5 минут. Может ли хакер различить две эти ситуации? Конечно же, может! Внешний спам-фильтр имеет свой собственный IP, отличающийся от IP-адреса клиента, что выдает его с головой!

Поскольку последнее время обнаружено огромное количество «дыр» в графических библиотеках, то антивирусы, установленные на почтовых серверах, осуществляют автоматический поиск вирусов в изображениях, формируя GET-запрос на хакерский сервер, причем этот GET-запрос очень характерный. Для экономии трафика антивирусы (как правило) загружают только заголовок (где, собственно говоря, и находятся искаженные поля, приводящие к переполнению буфера). Остальное содержимое файла их не интересует, в результате чего мы получаем очень характерный GET-запрос, более того – уникальный для каждого типа антивируса. Поскольку длина заголовка большинства графических файлов варьируется в очень широких пределах, размер запрашиваемого блока у всех антивирусов различен, что позволяет отличить NOD32 от KAV (например). То же самое относится к системам обнаружения вторжений и многим брандмауэрам, «скрещенным» с антивирусами. Мода пихать в один продукт кучу функционала хакерам только на руку.

Так же можно выявить и наличие proxy-сервера, GET-запрос которого отличается от GET-запроса «чистого» почтового клиента. «Хорошие» (в хакерском смысле этого слова) proxy-серверы даже сообщают внутренний IP-адрес жертвы. Красота! А если у жертвы на локальном компьютере установлены «баннерорезалки» (обычно работающие как локальные Proxy-серверы), они также будут обнаружены, поскольку их GET-запросы отличается от GET-запросов почтовых клиентов.

Кэширующие proxy-серверы распознаются вообще элементарно. Если мы отправили письмо по нескольким адресам, принадлежащим одной фирме, а картинка с хакерского сервера оказалась загружена лишь однажды, то либо остальные письма не были открыты, либо же картинка была скэширована. Кстати, далеко не все сотрудники компании проверяют корреспонденцию со своего рабочего места. Многие из них используют альтернативные каналы выхода в Сеть, да и сама локальная сеть компании зачастую разбита на несколько независимых сегментов, и хакер без труда выяснит, что это за сегменты! Впрочем, на практике обычно достаточно найти хотя бы одно слабое звено – сотрудника, проверяющего корпоративный ящик со своего домашнего компьютера (естественно, незащищенного). Зная его IP и версию операционной системы, хакер запросто забросит туда зловредную программу, заражающую другие приложения (и сменные носители типа флеш-карт), в конечном счете проникающие на рабочую станцию, подключенную к корпоративной локальной сети.

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

Кстати, Outlook Express (и другие популярные почтовые клиенты/браузеры) по умолчанию загружают только по три картинки за раз, и следующие GET-запросы формируют только после получения ответа от веб-сервера. Любое другое поведение указывает на то, что картинки загружаются не почтовым клиентом и не браузером, а каким-то программным комплексом, расположенным между ними, тип которого можно выявить по характеру и содержимому GET-запросов.

Кстати, о браузерах и веб-почте. Поразительно, какое количество информации браузеры передают в GET-запросе! Часто поле Referrer содержит все необходимые данные для несанкционированного входа в чужую текущую почтовую сессию – хакер может открыть почтовый ящик жертвы как свой собственный и делать все, что ему заблагорассудится (конечно, одновременная работа с двух разных IP, как правило, блокируется, но если жертва выходит из ящика, не сделав Logout, то сессия еще будет некоторое время удерживаться, позволяя хакеру дорваться до почты).

Выявить наличие трансляторов сетевых адресов несколько сложнее, но все-таки возможно. Для этого необходимо проследить за номерами локальных портов, характер назначения которых позволяет выявить не только наличие транслятора, но также его тип и загруженность узла (т.е. сколько других TCP/IP-соединений осуществляется за единицу времени). Впрочем, техника выявления NAT – это отдельная большая тема.

А вот еще один интересный факт. Операционные системы семейства Windows имеют довольно слабый DNS stub (не путать с DNS-клиентом, который вообще может быть отключен). Генерируя довольно предсказуемые номера UDP-портов и идентификаторов (при активном DNS-клиенте, который в Windows 2000 и выше включен по умолчанию, UDP-порт вообще постоянен), они допускают возможность «подмятия» DNS. Хакер генерирует подложный ответ, который тем не менее воспринимается системой как правильный и… последствия не заставляют себя ждать. Единственная проблема в том, что в отличие от DNS-серверов рабочие станции не генерируют большое количество DNS-запросов в единицу времени, и послать подложный ответ, опередив настоящий DNS, достаточно трудно. Если только… не напичкать письмо кучей ссылок на картинки! Тогда… а вот тогда… даже страшно сказать, что произойдет. Ну если жертва выходит в Сеть со своего домашнего ПК, то атака провалится, даже не начавшись, поскольку штатные клиенты генерируют не более трех GET-запросов одновременно. И хакеру будет очень трудно успеть послать подложный запрос. А вот если это корпоративная сеть с кэширующим proxy или антиспам-фильтром, то картинки загружаются общим скопом, и вероятность того, что поддельный DNS-отклик будет воспринят как правильный, значительно повышается (естественно, все картинки должны быть расположены на разных узлах).

Допустим, хакер подделал DNS-отклик. Что тогда? А то, что антивирус загрузит совсем не ту картинку, на которую указывает ссылка. И если исходная картинка содержит в себе вирус, антивирус его не поймает, зато его поймает жертва, открывающая письмо!

Обращаю внимание читателя, что во всех вышеописанных случаях ответа получателя на хакерское письмо не требуется!

Рисунок 1. Внешний вид «жучка» и фрагмент HTML-кода с внешней ссылкой на картинку

Рисунок 1. Внешний вид «жучка» и фрагмент HTML-кода с внешней ссылкой на картинку

От идеи до модели, или Лабораторная работа №1

Заканчиваем с теорией и вплотную переходим к практическим экспериментам. Мы будем использовать почтовые программы Outlook Express и The Bat. К сожалению, штатным образом ни одна из них не позволяет вставлять ссылки на картинки без присоединения самой картинки к письму (что, естественно, не входит в наши планы). Отсутствие встроенного HTML-редактора препятствует элементарной правке полей, однако… не нужно быть гением, чтобы обойти все эти ограничения.

Хорошо, берем Outlook Express, создаем новое письмо в HTML-формате и вставляем гиперссылку в текст сообщения (именно гиперссылку, а не картинку!). Сохраняем его на диск через меню «Файл -> Сохранить как…» и получаем вполне текстовой .eml, который можно править в текстовом редакторе.

Листинг 1. Письмо, созданное Outlook Express, сохраненное на диск и открытое в текстовом редакторе (все e-mail-адреса в заголовке — недействительные)

From: "Kris Kaspersky" <kpnc@sendmail.ru>

To: <kpnc@aport.ru>

Subject: test 666

Date: Sat, 26 Apr 2008 03:00:58 +0400

MIME-Version: 1.0

X-Priority: 3

X-MSMail-Priority: Normal

X-Unsent: 1

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506

 

------=_NextPart_000_025C_01C8A749.C39D0D40

Content-Type: text/html;

    charset="koi8-r"

Content-Transfer-Encoding: quoted-printable

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">

<META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR>

<STYLE></STYLE>

</HEAD>

<BODY bgColor=3D#ffffff>

<A=20 href=3D"http://nezumi.org.ru/souriz/temp/love.gif">

http://nezumi.org.ru/souriz/temp/love.gif</A>

</FONT></DIV></BODY></HTML>

 

------=_NextPart_000_025C_01C8A749.C39D0D40--

Находим строку (выделена желтым цветом):

<A=20href=3D"http://nezumi.org.ru/souriz/temp/love.gif">

http://nezumi.org.ru/souriz/temp/love.gif</A>

и переписываем ее следующим образом:

<IMG SRC=3D"http://nezumi.org.ru/souriz/temp/love.gif"/>

Некоторые хакеры выставляют размеры картинки в 0x0 пикселей, чтобы она не была видна, но это не есть хорошо и слишком подозрительно. Лучше вставить обычную картинку, например, свой логотип или что-то еще.

Естественно, вместо адреса http://nezumi.org.ru вы должны указать что-то свое, воздвигнув собственный веб-сервер (рекомендую бесплатный SMALL HTTP – smallsrv.com) с доменным именем, которое можно зарегистрировать, даже имея в своем распоряжении всего лишь динамический IP с хлипким каналом (большая пропускная способность нам не понадобится, мы же не спамом занимаемся).

Открываем модифицированный файл в Outlook Express (для этого достаточно дважды щелкнуть по нему мышкой в Проводнике) и отправляем его адресату. Смотрим на консоль нашего веб-сервера, отображающую текущие запросы (или пытаем лог).

Поскольку в данном случае мы отсылаем файл самому себе, то в момент просмотра полученного письма в логе сервера тут же появляется новая запись с нашим IP-адресом и прочими параметрами. Кстати, обратите внимание, что почтовые службы mail.ru и gmail.com не осуществляют проверку внешних картинок ни при отправке, ни при приеме письма. А еще говорят, что они защищают нас от спама! Выходит, что вся защита сводится к ведению black-листов IP-адресов (ну и, может быть, фильтрации текстового содержимого).

Если же картинка загружается с внешнего ресурса, спамерам достаточно менять IP-адреса (для чего идеально подходит boot-net, то есть подконтрольная хакеру сеть машин с внедренным back-door) и спам свободно пройдет сквозь фильтры, правда, нагрузка на наш веб-сервер существенно возрастет, но исходящий трафик обычно либо очень дешев или вообще бесплатен, а объем входящих GET-запросов не так уж и велик.

Ладно, а как осуществить то же самое при помощи The Bat? В меню «Tools» выбираем «Import messages -> From .MSG/.EML-flies», и наше письмо появляется в папке входящих, откуда мы копируем его в исходящие и говорим «Send Queued Mail».

Как и в предыдущем случае, смотрим в лог веб-сервера и делаем соответствующие выводы.

Практический пример атаки

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

Кстати, аналогичная техника используется корпорацией Intel в ее почтовой рассылке – все картинки там представлены в виде ссылок на внешний HTTP-сервер. Возможно, это сделано с целью уменьшения объема рассылаемых писем, возможно, для слежения за подписчиками. Кто знает? Но никто же не пытается засудить Intel, поскольку никакого состава преступления в ее действиях нет. Вот так же и с нами.

Объектом исследований выступит популярная антивирусная служба www.virustotal.com, внизу главной страницы которой мы видим адрес info@virustotal.com. Вот на него мы и отправим письмо, созданное по вышеописанной методике, только вместо <kpnc@aport.ru> поставим <info@virustotal.com>. Обратный адрес может быть любым, это не суть важно. Главное, чтобы он не был в black-листе и сервер-отправитель не относился к категории заблокированных. Лучше всего использовать свой собственный SMTP-сервер, кстати говоря, в состав SMALL HTTP-сервера входит замечательный SMTP!

Через несколько секунд после отправки письма с жучком мы ловим первый GET-запрос (см. листинг 2).

Листинг 2. Первый GET-запрос, пойманный нашим веб-сервером

!->25/04 13:34:43 [81.26.151.146:2785>80] (t1 547)

GET /souriz/temp/love.gif HTTP/1.0

User-Agent: Mozilla/4.0 (compatible; Lotus-Notes/6.0; Windows-NT)

Accept-Language: ru

Host: nezumi.org.ru

Accept: text/html

Accept: text/x-html

Accept: application/html

Accept: application/x-html

Accept: text/plain

Accept: image/gif

Accept: image/jpeg

Accept: multipart/*

Accept: application/x-x509-user-cert

Accept: application/x-x509-ca-cert

Accept: */*

 

!->25/04 13:34:43 [81.26.151.146:2785>80] (t1 548)

!->HTTP  in:408 out:8735 /souriz/ Time:130

А спустя короткое время (около двух минут) наш веб-сервер ловит еще один GET-запрос (см. листинг 3):

Листинг 3. Второй GET-запрос, пойманный нашим веб-сервером

!->25/04 13:36:55 [85.62.90.20:54329>80] (t1 549)

GET /souriz/temp/love.gif HTTP/1.0

Host: nezumi.org.ru

Accept-Language: es

Accept: */*

User-Agent: Mozilla/4.0 (compatible; MSIE.6.0; Windows NT 5.1)

Via: 1.1 noname:8888 (squid/2.6.STABLE17)

Cache-Control: max-age=259200

Connection: keep-alive

 

!->25/04 13:36:55 [85.62.90.20:54329>80] (t1 550)

!->HTTP  in:255 out:8735 /souriz/ Time:10

Попробуем разобраться в этом хозяйстве, попутно отметив, что IP-адрес самого virustotal равен 74.53.201.162, а также приведем несколько вполне типичных GET-запросов от известных агентов (см. листинги 4-6). Первый запрос (см. листинг 2) совершенно нетипичен ни для браузеров, ни для почтовых клиентов, ни для proxy-серверов, что наводит на мысль – а не является ли это спам-фильтром? Поскольку запрашивается вся картинка целиком (размер out совпадает до последнего байта), то это скорее именно спам-фильтр, а не антивирус.

Второй GET-запрос (см. листинг 3) – типичный кэширующий proxy (сравните его с листингом 6). Кстати, первый запрос не мог принадлежать кэширующему proxy, иначе бы второй запрос уже бы не появился. Не мог первый запрос быть и просто от proxy-сервера, ибо разница во времени (примерно 2 минуты) слишком велика для «проксирования», но вполне типична для спам-фильтра/антивируса на довольно загруженном узле.

Оба GET-запроса достаточно характерны и позволяют выявить версию программного обеспечения, для чего достаточно запустить какой-нибудь сетевой сканер, например, X?Spider, сообщающий нам, что узел 85.62.90.20 не отвечает на запросы, а 81.26.151.146 работает под управлением UNIX, имеет кучу открытых портов (53, 80, 123, 443, 993, 2222) и содержит уязвимость в OpenSSH, приводящую к возможности выполнения произвольного кода (см. рис. 2). Что ж, неплохое начало!

Листинг 4. GET-запрос FireFox

!->25/04 11:05:02 [83.239.33.46:3338>80] (t1 9199)

GET /souriz/temp/love.gif HTTP/1.1

Host: nezumi.org.ru

User-Agent: Mozilla/5.0 (Windows; Windows NT 5.0; en-US; rv:1.8) Gecko Firefox/1.5

Accept: text/xml,application/xml,application/xhtml+xml,text/html; image/png,*/*

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip, deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

 Листинг 5. GET-запрос Outlook Express

 !->25/04 11:30:17 [83.239.33.46:3415>80] (t1 174)

GET /souriz/temp/love.gif HTTP/1.1

Accept: */*

Accept-Language: ru,ja;q=0.5

Accept-Encoding: gzip, deflate

If-Modified-Since: Mon, 21 Nov 200518:06:17 GMT

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Host: nezumi.org.ru

Connection: Keep-Alive

 Листинг 6. GET-запрос proxy-сервера (SMALL-HTTP)

!-<25/04 12:40:53 [74.53.201.162:80<4008] (t1 388)

Date: Fri, 25 Apr 2008 08:16:15 GMT

Server: Apache

Last-Modified: Tue, 19 Jun 2007 11:32:26 GMT

ETag: "519b2-15df-43340aaf5c680"

Accept-Ranges: bytes

Content-Length: 5599

Cache-Control: max-age=604800

Expires: Fri, 02 May 200808:16

!->25/04 12:40:54 [127.0.0.1:4005>3127] (t1 389) >Proxy in:6049 out:333

Рисунок 2. Данные сканирования узла 81.26.151.146

Рисунок 2. Данные сканирования узла 81.26.151.146

Теперь попробуем выяснить, кому какие IP-адреса принадлежат, и как они распределены в пространстве на поверхности планеты Земля. В этом нам поможет одна из множества on-line служб, например http://www.leader.ru. Открыв ее в браузере, видим в правом верхнем углу окошко whois, вводим туда «www.virustotal.com» и получаем следующую информацию (см. листинг 7):

Листинг 7. Информация об имени www.virustotal.com

Hostname:        www.virustotal.com

IP:              74.53.201.162

Reverse name:    viruskill2.hispasec.com

Preferable MX:   mail.hispasec.com

 

Owner:                  ThePlanet.com Internet Services, Inc.

Location:               Capitol, City: Houston, PostalCode: 77002, Country: US

Contact Information:    74.52.0.0 - 74.55.255.255

CIDR:                   74.52.0.0/14,

NetType:                Direct Allocation,

NameServer:             NS1.THEPLANET.COM, NameServer: NS2.THEPLANET.COM,

 

Domain Information:     VIRUSTOTAL.COM

Owner:                  Hispasec Sistemas

Location:               Edificio Bic Euronova, Parque Tecnologico Andalucia, ES

Contact Information:    Hispasec Sistemas bernardo@hispasec.com, Network Solutions, LLC.

Name Servers:           DNS.HISPASEC.COM, DNS.HISPASECSISTEMAS.COM

 Теперь испытаем IP-адрес 85.62.90.20 (второй GET-запрос нашего «жучка»), пойманным веб-сервером (см. листинг 8):

Листинг 8. Информация об узле 85.62.90.20

Hostname:        Cannot be resolved

IP:              85.62.90.20

Preferable MX:   inc.wanadoo.es

 

Network Information:    UNI2-NET

Network Range:          85.62.0.0 - 85.62.255.255

Owner:                  Addresses IP for corporate ABI clients, France Telecom Espaa

Location:               Parque Empresarial La Finca, Edificio 9,  Madrid, Spain

 Ага! Уже есть кое-что интересное! Адрес 85.62.90.20 никак не связан с узлом www.virustotal.com и входит в совершенно другую подсеть, впрочем, также принадлежащую испанскому провайдеру. Учитывая тот факт, что 85.62.90.20 не отвечает на запросы, не имеет доменного имени и в качестве почтового сервера использует внешнюю почтовую службу inc.wanadoo.es, мы с 99% вероятностью можем предположить, что это proxy-сервер (squid/2.6.STABLE17) организации, обслуживающей www.virustotal.com.

А что на счет адреса 81.26.151.146? И вот тут нас ждет неожиданный, но очень приятный сюрприз (см. листинг 9):

Листинг 9. Информация об узле 81.26.151.146

Hostname:        msk-gw.drweb.com

IP:              81.26.151.146

Preferable MX:   mx.drweb.com

 

Network Information:    NAUKANET

Network Range:          81.26.151.0 - 81.26.151.255

Owner:                  Moscow

Location:               OOO Nauka-Svyaz,3ya ulitsa Yamskogo Polia,125124 Moscow, Russia

Contact Information:    Vadim Vakhrushin, noc@naukanet.ru,

                        +7 495 5029092, +7 495 9373412, Vladimir Schedrin,

                        noc@naukanet.ru, +7 495 5029092, +7 495 9373412

 Выходит, что сотрудники virustotal используют Dr.Web в качестве «магистрального» почтового сервера, точнее, его использует их провайдер, чем и объясняется столь длительное время проверки такого короткого письма (узлы провайдера обычно довольно сильно загружены). Как уже говорилось выше, данный узел содержит уязвимость, приводящую к возможности выполнения удаленного кода, а значит, мы можем захватить контроль не только над перепиской компании-разработчика virustotal, но и многих других фирм. И все это мы выяснили всего за несколько минут, обладая минимальными познаниями и хакерскими навыками!

Рисунок 3. Кто есть кто в Интернете

Рисунок 3. Кто есть кто в Интернете

Заключение

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

Если же вы все-таки хотите заблокировать жучков, достаточно установить пакетный фильтр, анализирующий поступающую корреспонденцию и «выкусывающий» все ссылки на внешние картинки.

Приложение

Сокрушая барьеры, или HTML во вложениях

Outlook Express (и некоторые другие почтовые клиенты), обрабатывают HTML-содержимое электронных писем весьма специфическим образом, помещая их в «песочницу» с минимальными привилегиями, которые в лучшем (для хакера) случае совпадают с привилегиями удаленных интернет-узлов, то есть сценарий JavaScript не имеет доступа ни к каким локальным файлам и далеко не во всех случаях может устанавливать соединение даже с тем сервером, откуда он был загружен, что существенно затрудняет атаку.

HTML-вложения – в этом смысле идеальный вариант. Чтобы просмотреть содержимое вложения, его необходимо открыть, а при этом всегда происходит копирование на диск. Даже если жертва не выбирает опцию «сохранить», почтовый клиент копирует HTML-вложение во временный файл, передавая его браузеру со всеми вытекающими отсюда последствиями. Как защититься от атак подобного типа? Очень просто – ассоциировать HTML/HTM-расширения со специальным браузером, в настройках которого отключить поддержку скриптов, ActiveX-компонентов и всего-всего-всего. Или же (если браузер поддерживает различные зоны безопасности, как, например, IE) «урезать» права локальной зоны.

Дыры в обработчиках изображений

Листая Security Focus, не устаешь поражаться, как много дыр содержится в обработчиках графических изображений. В настоящий момент уязвимы практически все форматы графических изображений: wmf, bmp, pic, gif, png, jpg, swf… И хотя большинство ошибок уже исправлено, далеко не все пользователи установили заплатки, что делает их уязвимыми для удаленных атак.

Практика показывает, что локальные антивирусы (DrWeb, KAV, NOD32) обращают внимание лишь на вложения, но пропускают ссылки на внешние ресурсы. Антивирусы, установленные на «магистральных» каналах, проверяют и то и другое, однако исследование, проведенное мною, показало, что таких антивирусов – раз два и обчелся, и потому ссылки на зловредные картинки работают превосходно, а вот вложения давятся локальными вирусами весьма эффективно.

Почтовые ресурсы с жучками

Существует большое количество вполне легальных служб, предоставляющих услуги внедрения жучков в письма с целью определения точного времени открытия письма абонентом (не говоря уже о подтверждении факта успешной доставки). Как вы понимаете, эта техника радикальным образом отличается от стандартной процедуры запроса на получение – по умолчанию почтовые клиенты выводят диалоговое окно на экран, позволяя пользователю либо подтвердить получение письма, либо сделать вид, что оно до него не дошло. Вот пара ссылок на подобные ресурсы: http://www.didtheyreadit.com и http://www.msgtag.com/home (между прочим, бесплатные и работающие по принципу proxy-сервера, то есть пересылающие письма со своего доменного имени).

Какую информацию может собрать img-жучок

  • подтвердить открытие письма жертвой;
  • установить точное время открытия письма;
  • определить наличие proxy-сервера у жертвы;
  • выявить наличие трансляторов сетевых адресов;
  • определить наличие кэширующего proxy-сервера у провайдера жертвы;
  • определить используемое программное обеспечение с точностью до версии;
  • определить наличие спам-фильтров и/или антивирусов (а иногда и их версию);
  • определить IP-адрес жертвы (чаще – внешний, реже – внутренний и внешний);
  • выявить «баннерорезалки», аннонимайзеры, контентные фильтры и другие локальные утилиты.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru