Электронная почта
Начнем мы, конечно же, с электронной почты, и рассмотрим какие данные утекают через SMTP (RFC 821) и служебную информацию письма (RFC 822) т.к. единственное письмо может нам дать просто огромное количество информации. Проведем эксперимент на Крисе (ни один мыщъх в ходе эксперимента не пострадал, т.к. помогал собирать данные абсолютно добровольно). Пошлем его письмом, получим ответ и вглядимся в заголовки
Received: from [83.239.x.y] (port=41101 helo=kpnc)
by mx2.mail.ru with smtp
id 1Ds1ou-0002q6-00
for 3APA3A@SECURITY.NNOV.RU; Mon, 11 Jul 2005 21:11:52 +0400
Message-ID: <00a401c5863b$f05f7f70$0100a8c0@kpnc>
From: "Kris Kaspersky" <kpnc@somebox.ru>
To: "3APA3A" <3APA3A@SECURITY.NNOV.RU>
References: <1985289168.20050711205823@SECURITY.NNOV.RU>
Subject: =?koi8-r?B?UmU6IOvMycXO1NPLycUg0NLP1M/Lz8zZ?=
Date: Mon, 11 Jul 2005 21:14:03 +0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Начнем с конца:
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Используется Microsoft Outlook Express, это в пояснении не нуждается. Сверившись по своему богатому почтовому архиву, я обнаруживаю следующие факты:
Этот Outlook Express установлен на машине с Windows 2000 SP4 (об этом говорит 2800 в номере версии) с патчами от июля 2004 года. Зная, что последний патч к Outlook Express выходил в июне 2005 и вошел в накопительное обновление Windows 2000, можно предположить что как минимум с июня 2005 года машина не обновлялась и накопительное обновление не стоит. Чуть выше идет несколько не очень информативных заголовков, т.к. они подставляются любым почтовым клиентом, однако и в них есть определенная информация - взаимное расположение заголовков, капитализация символов, способ переноса строк - которая помогла бы нам определить почтового клиента даже если бы поля X-Mailer и X-MimeOLE кем-то фильтровались.
Date: Mon, 11 Jul 2005 21:14:03 +0400
Если мы сравним дату письма с временной отметкой сервера, то обнаружим, что часы компьютера спешат чуть более чем на 2 минуты. В данном случае (Windows 2000) это говорит о легкой творческой небрежности владельца: А вот в случае с Windows XP, в котором синхронзация времени включена изначально, это могло бы нам поведать о том, что доступ в сеть происходит через прокси-сервер или сильно ограничивающий фаервол. В случае точной синхронизации часов на достаточно большом письме мы смогли бы просчитать производительность канала, через которое письмо отправлялось.
References: <1985289168.20050711205823@SECURITY.NNOV.RU>
Содержит идентификатор (Message-ID) письма, на который идет ответ. Нас эта информация не интересует, поскольку это ответ на наше письмо, но по такому формату идентификатора легко узнается программа The Bat!.
From: "Kris Kaspersky" <kpnc@somebox.ru>
Мы знаем от кого мы получили ответ. Наверное. Т.к. эта информация в заголовке письма легко подделывается. Требуйте электронной подписи.
Message-ID: <00a401c5863b$f05f7f70$0100a8c0@kpnc>
Уникальный идентификатор письма. На ервый взгляд случайный. На второй - не очень. Чем больше неслучайных (а иногда и "случайных") циферок у нас есть, тем больше информации мы имеем. 00a401c5863b - дата/время создания письма в "файловом" формате. Сравнив ее с полем Date мы можем узнать не является ли данное письмо попыткой "подделаться" под почтовую программу. Kpnc - имя компьютера. Отсутствие в имени точек говорит о том, что компьютер не является частью домена. 0100a8c0 - IP адрес компьютера (в little endian). Т.е. 192.168.0.1. Этот адрес определен RFC 1918 для внутреннего использования, т.е. компьютер выходит во внешнюю сеть через NAT или прокси а следовательно, с большой долей вероятности, не по коммутируемому каналу. Адрес 127.0.0.1 мог бы говорить о наличии локального почтового шдюза, который раньше любили устанавливать различные антивирусы, например старая версия Symantec. Сейчас их поймать несколько сложнее, т.к. почтовый трафик проверяется путем привязки антивируса к LSP незаметно для почтового приложения. Или легче, если добродушный антивирус о себе сообщает.
Received: from [83.239.x.y] (port=41101 helo=kpnc)
by mx2.mail.ru with smtp
id 1Ds1ou-0002q6-00
for 3APA3A@SECURITY.NNOV.RU; Mon, 11 Jul 2005 21:11:52 +0400
Мы еще раз видим имя компьютера (в SMTP команде HELO, что лишний раз подтверждает что это Outlook Express). 83.239.x.y - реальный IP адрес устройства, выполняющего трансляция адреса или проброс порта. Может насторожить номер клиентского порта (41101). Он необычно высокий. Если порты назначаются с 1024 по порядку, то либо прошло очень большое количество соединений, либо мы имеем не совсем стандартное поведение. Чтобы выяснить это затянем переписку, получим еще несколько писем и посмотрим что делается с данным полем во времени:
Received: from [83.239.x.y] (port=41101 helo=kpnc)
Mon, 11 Jul 2005 21:11:52 +0400
Received: from [83.239.x.y] (port=18294 helo=kpnc)
Mon, 11 Jul 2005 21:31:46 +0400
Received: from [83.239.x.y] (port=25896 helo=kpnc)
Mon, 11 Jul 2005 23:48:02 +0400
Received: from [83.239.x.y] (port=52180 helo=kpnc)
Tue, 12 Jul 2005 00:21:52 +0400
<перерыв>
Received: from [83.239.x.y] (port=37530 helo=kpnc)
Tue, 12 Jul 2005 23:58:15 +0400
Received: from [83.239.x.y] (port=38040 helo=kpnc)
Tue, 12 Jul 2005 23:58:22 +0400
<Тут поменялись сутки>
Received: from [83.239.x.y] (port=47946 helo=kpnc)
Wed, 13 Jul 2005 00:14:59 +0400
Received: from [83.239.x.y] (port=37167 helo=kpnc)
Wed, 13 Jul 2005 00:27:48 +0400
Received: from [83.239.x.y] (port=34185 helo=kpnc)
Wed, 13 Jul 2005 02:43:57 +0400
<перерыв>
Received: from [83.239.x.y] (port=45881 helo=kpnc)
Thu, 14 Jul 2005 16:46:43 +0400
Received: from [83.239.x.y] (port=47538 helo=kpnc)
Thu, 14 Jul 2005 16:46:54 +0400
Received: from [83.239.x.y] (port=51689 helo=kpnc)
Thu, 14 Jul 2005 16:53:45 +0400
Хорошо видно, что клиентские порты явно идут не подряд, но в то же время их последовательность не случайна, а является некоей функцией от текущего времени суток (после перехода за 24 часа приращение становится отрицательным) и, возможно, числа соединений. Такое поведение почти наверняка свидетельствует о трансляции адресов и портов (NAT/PAT) на каком-нибудь аппаратном маршрутизаторе, типа D-Link. Протестировав различные модели подобных устройств (к сожалению у меня нет такой коллекции) можно хотя бы примерно установить семейство маршрутизатора, т.к. данная функция является весьма характерной.
Таким образом не анализируя содержимое самого письма, а пользуясь только "протокольными" данными мы можем установить ОС, наличие последних обновлений, иногда наличие брандмауэра, способ подключение к сети, топологию сети и оборудование маршрутизатора.
Сокрытие информации как путь утечки информации
Как правило, попытки скрыть информацию от пользовательского приложения приводят к утечке дополнительной информации. Например Norton Internet Security заменяет заголовок Referer на что-то типа
Weferer: EJGDGVCJVTLBXFGGMEP:.
Outpost (в зависимости от версии) на Field blocked by Outpost Firewall или Field blocked by Outpost.
Это дает возможность определить не только средство защиты используемое пользователем, но и его версию.
Любая странность в поведении клиентского приложения может быть интерпретирована и из нее могут быть сделаны выводы. Надо эту странность найти, а она есть при любой нестандартной конфигурации. Очень часто для сокрытия информации или используются специальные приложения, заменяющие или просто фильтрующие служебные заголовки. В общем-то это почти бесполезная вещь - клиентское приложение, и даже его версию, всегда можно определить - именно по тому, что отличает одну версию от другой. Не будем рассматривать идентификацию приложения по поведению, это слишком обширный вопрос, кроме того можно получить по шапке от кликеров или тех, кто с ними борется. Но попробуем определить фильтрующее приложение. Такое, как например Proxomitron. Казалось бы, такое приложение не добавляет никаких своих данных, а значит идентифицировать его, и, соответственно, сокрытие или подмену информации не возможно.
Дано:
Браузер: Microsoft Internet Explorer (можно взять и другой), возможно с нестандартными настройками.
Прокси-сервер: Proxomitron в абсолютно прозрачном режиме (без замены каких-либо заголовков запроса или с их заменой).
Надо:
Написать веб-страничку для определения не просто наличия прокси-сервера (это часть задания 1), а того, что прокси-сервером является именно Proxomitron.
Можно ли решить это нерешаемое задание? Оказывается, даже не очень сложно и способов можно найти довольно много. Например, поймаем Proxomitron на какой-нибудь граничной ситуации, такой как длинный запрос. Как поведет себя "голый" Internet Explorer или Internet Explorer с проксомитроном на запросе типа
http://www.server.domen/[1024x'A'], например при перенаправлении? Оказывается в Internet Explorer такой запрос пройдет без каких либо проблем. Однако в Proxomitron он будет обрезан по фиксированной и достаточно типичной позиции. По запросу мы определим наличие проксомитрона.
Утечка на уровнях отличных от прикладного
Приложение - не единственная точка утечки данных. Данные могут "убегать" даже на канальном уровне (классический "Etherleak"). Есть и другие:
PUSH - идентификация
На уровне TCP, очень часто можно идентифицировать клиентское приложение или прокси по тому, какими кусками и как данные передаются в "провода" (по пакетам и флагам PUSH в TCP-потоке). То, как данные будут побиты на пакеты, и где будут распологаться флаги PUSH, зависит от того, сколько операций write/send и с какими задержками было использовано клиентским приложением для отправки данных.
Поскольку логика работы с данными у каждого приложения своя, то и поток будет достаточно уникальным.
Пассивное сканирование портов
Как было наглядно продемонстрировано выше, даже информация о том, с какого порта клиента пришел запрос может оказаться довольно интересной. А что если таких запросов пришло очень много? Такое может случиться, если клиент, получает с сервера большое количество файлов по FTP или загружает Web-страничку с большим количеством картинок. Рано или поздно мы узнаем все динамические порты, которые может использовать клиентское приложения (правда только от 1024 и выше). Остальные порты, очевидно, открыты другими приложениями. Вот вам сканирование портов без сканирования портов, причем за фаерволом.
