Информационная безопасность
[RU] switch to English


Хакер-спец #9 20053APA3A

Утечка данных через служебную информацию и сетевой протокол в клиентском приложении.

Обмениваясь информацией вы всегда передаете данные. Однако, на разных уровнях (все помнят ISO/OSI?) к вашим данным добавляется служебная информация. Что это за информация, что она может сказать о вас и можно ли ее проанализировать? Давайте посмотрим на несколько простых примеров.
  1. Электронная почта

    Начнем мы, конечно же, с электронной почты, и рассмотрим какие данные утекают через 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 [email protected]; Mon, 11 Jul 2005 21:11:52 +0400
    Message-ID: <[email protected]>
    From: "Kris Kaspersky" <[email protected]>
    To: "3APA3A" <[email protected]>
    References: <[email protected]>
    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: <[email protected]>
    

    Содержит идентификатор (Message-ID) письма, на который идет ответ. Нас эта информация не интересует, поскольку это ответ на наше письмо, но по такому формату идентификатора легко узнается программа The Bat!.

    From: "Kris Kaspersky" <[email protected]>
    

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

    Message-ID: <[email protected]>
    

    Уникальный идентификатор письма. На ервый взгляд случайный. На второй - не очень. Чем больше неслучайных (а иногда и "случайных") циферок у нас есть, тем больше информации мы имеем. 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 [email protected]; 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. Протестировав различные модели подобных устройств (к сожалению у меня нет такой коллекции) можно хотя бы примерно установить семейство маршрутизатора, т.к. данная функция является весьма характерной.

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

  2. Утечка информации от HTTP клиента

    И этот течет.

    Дано: следующий заголовок HTTP запроса:

    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
    	application/vnd.ms-powerpoint, application/vnd.ms-excel, 
    	application/msword, */*
    Accept-Language: en-us
    Connection: Keep-Alive
    Host: www.security.nnov.ru
    Referer: http://www.security.nnov.ru/search/exploits.asp
    User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
    Via: 1.0 DOMSRV
    

    Находим, что:

    Система: Windows NT 4.0
    Браузер: Microsoft Internet Explorer 5.5
    Другие установленные приложения: Microsoft Office (не Professional версия)
    Используемый брандмауэр: Microsoft ISA Server
    Режим брандмауэра: HTTP прокси сервер указан в настройках Internet Explorer
    Язык пользователя: Английский

    Попробуйте сами определить откуда какие параметры взялись. Для решения задачи рекомендуется использовать Ethereal любой прокси-сервер, например 3proxy и Proxomitron или что-то похожее.

  3. Сокрытие информации как путь утечки информации

    Как правило, попытки скрыть информацию от пользовательского приложения приводят к утечке дополнительной информации. Например 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 он будет обрезан по фиксированной и достаточно типичной позиции. По запросу мы определим наличие проксомитрона.

  4. Утечка на уровнях отличных от прикладного

    Приложение - не единственная точка утечки данных. Данные могут "убегать" даже на канальном уровне (классический "Etherleak"). Есть и другие:

    PUSH - идентификация

    На уровне TCP, очень часто можно идентифицировать клиентское приложение или прокси по тому, какими кусками и как данные передаются в "провода" (по пакетам и флагам PUSH в TCP-потоке). То, как данные будут побиты на пакеты, и где будут распологаться флаги PUSH, зависит от того, сколько операций write/send и с какими задержками было использовано клиентским приложением для отправки данных.

    Поскольку логика работы с данными у каждого приложения своя, то и поток будет достаточно уникальным.

    Пассивное сканирование портов

    Как было наглядно продемонстрировано выше, даже информация о том, с какого порта клиента пришел запрос может оказаться довольно интересной. А что если таких запросов пришло очень много? Такое может случиться, если клиент, получает с сервера большое количество файлов по FTP или загружает Web-страничку с большим количеством картинок. Рано или поздно мы узнаем все динамические порты, которые может использовать клиентское приложения (правда только от 1024 и выше). Остальные порты, очевидно, открыты другими приложениями. Вот вам сканирование портов без сканирования портов, причем за фаерволом.

Заключение:

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

Перепечатка данной статьи невозможна без разрешения издательства Gameland

О сайте | Условия использования
© SecurityVulns, 3APA3A, Владимир Дубровин
Нижний Новгород