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

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

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

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

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

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

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

Внедряем в 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

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

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

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

Некоторые хакеры выставляют размеры картинки в 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-запрос, пойманный нашим веб-сервером

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

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

Попробуем разобраться в этом хозяйстве, попутно отметив, что 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). Что ж, неплохое начало!

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

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

Ага! Уже есть кое-что интересное! Адрес 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):

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

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

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

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-сервера, то есть пересылающие письма со своего доменного имени).