Утечка данных

ЗАРАЗА

Спецвыпуск: Хакер, номер #058, стр. 058-062-3

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

Как правило, попытки скрыть информацию от пользовательского приложения приводят к дополнительной утечке дополнительной информации. Например, Norton Internet Security заменяет заголовок Referer на что-то типа "Weferer: EJGDGVCJVTLBXFGGMEP...". Outpost (в зависимости от версии) на Field blocked by Outpost Firewall или Field blocked by Outpost. Это позволяет определить не только средство защиты, используемое пользователем, но и его версию.

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

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

Дано:

Браузер: Microsoft Internet Explorer (можно взять и другой), возможно, с нестандартными настройками.

Прокси-сервер: Proxomitron в абсолютно прозрачном режиме (без замены каких-либо заголовков запроса или с их заменой).

Надо:

Написать web-страничку для определения не просто наличия прокси-сервера (это часть задания 1), а того, что прокси-сервером является именно Proxomitron.

Можно ли решить это нерешаемое задание? Оказывается, не очень сложно, и способов довольно много. Например, поймаем Proxomitron на какой-нибудь граничной ситуации, такой как длинный запрос. Как поведет себя "голый" Internet Explorer или IE с проксомитроном на запросе типа www.server.domen/[1024x’A’], например, при перенаправлении? Оказывается, в Internet Explorer такой запрос пройдет без каких-либо проблем. Однако в Proxomitron он будет обрезан по фиксированной и достаточно типичной позиции. По запросу мы определим наличие проксомитрона.

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

Приложение – не единственная точка утечки данных. Данные могут "убегать" даже на канальном уровне (классический "Etherleak" - www.security.nnov.ru/news2523.html).

PUSH - идентификация (на уровне TCP)

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

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

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