Во второй части мы узнаем, кто пользовался компьютером Джо Чмо, пока он был в отпуске. Мы продолжим расследование, проведя тщательный анализ Интернет активности других браузеров, имеющихся на жестком диске компьютера Джо.
Авторы Keith J. Jones и Rohyt Belani
Обзор первой части
Это вторая часть серии статей об экспертизе web-браузеров. В первой части мы начали расследование несанкционированного доступа на файловый сервер юридической фирмы, работающий на основе Docustodian. Мы доказали, что к серверу получил доступ хакер, или группа хакеров, которые использовали его в качестве хранилища MP3-музыки, MPEG-фильмов и пиратского программного обеспечения.
Также мы проанализировали файлы, хранящие историю активности главного подозреваемого, системного администратора Джо Чмо. Анализ активности показал, что Джо искал материалы по сетевому взлому, а также способы обхода лицензионной политики Docustodian. Однако все эти действия были совершены, пока Джо отдыхал во Флориде со своей семьей.
Во второй части мы узнаем, кто пользовался компьютером Джо, пока он был в отпуске. Мы продолжим расследование, проведя тщательный анализ Интернет активности других браузеров, имеющихся на жестком диске компьютера Джо.
Расследование
Дальнейшее расследование показало, что единственным браузером, кроме Internet Explorer, расположенным на компьютере Джо, оказался Mozilla Firefox. Просмотр файлов истории активности Mozilla Firefox нельзя сделать с помощью одного клика мышки как у IE. В основном это связано с нехваткой инструментов, позволяющих легко воссоздать действия пользователя. Как мы уже обсуждали в первой части, большинство подобных инструментов, типа FTK, IE History, и Web Historian, способны восстанавливать файлы истории для Mozilla Firefox, но они не ассоциируют локальные кэшированные файлы с Интернет активностью. Это подразумевает, что мы имеем даты и время посещения сайтов, но не можем просмотреть их содержимое.
Давайте начнем расследование с рассмотрения кэшированных файлов Firefox’a, расположенных на компьютере Джо. Они находятся в следующей папке:
\Documents and Settings\<user name>\Application Data\Mozilla\Firefox\Profiles\<random text>\Cache
Внутри этой директории находятся файлы, прямо относящиеся к нашему расследованию. На Рис. 1 можно увидеть содержимое этой директории:
Рис. 1: Директория с кэшированными файлами браузера Mozilla Firefox.В этой директории находятся 3 типа файлов:
Файл, отображающий структуру кэша
Файл, отображающий структуру кэша, называется _CACHE_MAP_ и является главным помощником при восстановлении кэшированных данных Firefox’a. Структура самого файла довольно простая. Есть заголовок, за которым следуют области памяти (buckets), отображающие местонахождение кэшированных данных, как показано на Рис. 2:
Рис. 2: Структура файла _CACHE_MAP_.
В этом файле 32 области памяти. В каждой области 256 записей. Это значит, что мы имеем 8,192 записей в файле.
Каждая запись содержит информацию по одному событию в истории активности. Запись содержит четыре 32-битных числа:
Firefox использует два способа хранения данных. Он либо сохраняет данные в блоковом файле, либо создает новый файл. Hash-идентификатор используется в качестве имени нового файла, если данные были сохранены в новый файл. Поля «Расположение данных» и «Расположение метаданных» понадобятся нам для восстановления истории активности. Каждая запись в кэшэ имеет информацию в виде метаданных и описание содержимого.
Если вы возьмете поле «Расположение метаданных» и прооперируете её с помощью «bitwise AND 0x30000000», а затем сместите результат на 28 битов влево, вы получите число между нулем и тройкой. Если результат получился 0, то метаданные сохраняются в отдельном файле. Если результат 1, 2 или 3, то метаданные записываются блоковый файл. Этот же алгоритм использует «Расположение данных» для вывода информации по содержимому кэша.
Блоковые файлы
Есть три блоковых файла, отображающих блоки кэша, которые называются “_CACHE_00N_”, где N – число от 1 до 3. Блоковые файлы содержат описание данных кэша и информацию в виде метаданных для каждой записи в кэшэ. Эта структура блоковых файлов создает проблемы для большинства инструментов, восстанавливающих историю активности. Но мы в курсе этих проблем, и извлечем данные, чтобы продолжить наше расследование.
После определения нужного блокового файла, требуется определить расположение данных. Начальный блок определяется с помощью «bitwise AND 0x00FFFFFF» расположения данных/метаданных. Далее следует определить количество смежных блоков, составляющих кэшированные данные/метаданные. Количество определяется с помощью «bitwise AND 0x03000000» расположения данных/метаданных и смещением результата на 24 бита вправо. Теперь нужно определить размер блоков в нужном нам блоковом файле. Браузеры Mozilla определяют размер блока смещением влево числа 256 на следующее число битов: вычесть единицу из номера блокового файла и умножить результат на два. Таким образом, когда N=1 – размер 256, N=2 – 512, N=3 – 1,024 байт.
Напоследок нужно учесть побитовый заголовок блоковом файле. Этот заголовок определен в 4,096 байт. Блоки начинаются сразу после этого заголовка. Используя вышеописанные алгоритмы, мы можем извлечь кэшированные данные и метаданные для каждой записи, описанной в файле _CACHE_MAP_.
Отдельные файлы с кэшированными данными
Если кэшированные данные или метаданные слишком велики для размещения в блоковых файлах, то данные сохраняются в отдельные файлы. Названия файлов определяются следующим образом:
<HASH-ИДЕНТИФИКАТОР><ТИП><СГЕНЕРИРОВАННОЕ ЧИСЛО>
Hash-идентификатор берется из файла _CACHE_MAP_. «Тип» либо “d” для кэшированных данных, либо “m” для метаданных. «Сгенерированное число» - число, определяемое с помощью «bitwise AND 0x000000FF» расположения данных/метаданных.
Восстановление кэшированных данных
Хорошим инструментом для восстановления кэшированных данных Mozilla Firefox является Cache View. Cache View позволяет просматривать кэшированные данные нескольких браузеров, включая Firefox. Для каждой кэшированной страницы, Cache View предоставляет URL посещенной страницы, имя локального кэшированного файла, размер файла, тип файла, время последнего изменения и другое. Эта информация является теми метаданными, которые мы обсуждали ранее. Пример работы Cache View показан на Рис. 3:
По умолчанию, Cache View обрабатывает кэшированные файлы браузеров, расположенных на локальной системе. В нашем случае, как и во многих других, обработка информации ведется на рабочей станции следователя, стоящей отдельно от системы с настоящими уликами. Таким образом, нам требуется импортировать кэшированные файлы браузеров с оригинала на нашу рабочую станцию. В случае с Firefox, нам следует импортировать папку
\Documents and Settings\<user name>\Application Data\Mozilla\Firefox\Profiles\<random text>\Cache
После того, как папка будет сохранена на рабочей станции следователя, можно скомандовать Cache View, чтобы она начала извлекать файлы из неё, а не из папок локальных браузеров. На Рис. 4 показана эта ситуация:
После импорта папки с кэшированными файлами в Cache View, вы увидите нечто схожее с изображением на Рис. 5:
Как видно на Рис. 5, файлы рассортированы по доменным именам сайтов, которые посещал Джо. Кликая мышкой по папке by14fd.bay14.hotmail.msn.com
, мы увидим ссылки на посещенные страницы в рамках этого домена. Эти ссылки предоставят дополнительную информацию об активности Джо в почтовой системе Hotmail. Мы решаем провест тщательный анализ этих файлов. Этот процесс включает следующее:
Это достигается выделением всех ссылок в правом окне, нажатием правой кнопки мыши и выбором опции Copy to.. (Копировать в..), как показано на Рис. 6:
В результате первого шага файлы были скопированы в папку by14fd.bay14.hotmail.msn.com.
Затем в среде cygwin мы выполнили Unix-овую команду file для всех файлов в папке.
Из Рис. 7 видно, что файлы заархивированы с помощью gzip. Чтобы их разархивировать мы сделали копии файлов, назвали их 1.gz, 2.gz и 3.gz соответственно, а затем запустили программу gunzip.
Мы затем открыли разархивированный файл 1.gz с помощью браузера Firefox. Рис. 9 показывает посещенную страницу, восстановленную в ходе этого процесса:
На странице, показанной на Рис. 9, видно электронное сообщение, которое читал Джо на своем компьютере. Анализ страницы показал, что сообщение находится в почтовом ящике tedw1982@hotmail.com. Содержание письма прямым образом касается расследования. Из него следует, что Тэд Уилсон (Ted Wilson), владелец почтового ящика tedw1982@hotmail.com, послал Майку Грину (Mike Green) письмо с авторизационными данными сервера Docustodian, обсуждаемого в первой части статьи. Тэд также отметил, что клиентское ПО может потребовать лицензионные ключи, которые он вскоре вышлет Майку. Более того, письмо было послано 10 марта, 2005 года в 22:05, в то время как Джо был в отпуске с семьей. Значит мы вытащили кота из мешка! Тэд Уилсон виновен в несанкционированном доступе к серверу Docustodian.
Так кто же такой Тэд Уилсон и как он смог получить доступ к компьютеру Джо? Беседа с сотрудниками юридической фирмы выявила, что Тэд был молодым специалистом, заместителем Джо, пока он был в отпуске.
Если извлеченная страница с почтовым сообщением является недостаточной уликой, то дальнейшее расследование выявило файл licensecrack.java, расположенный в следующей директории:
C:\windows\system32\temp\temp\temp\
Дата последнего доступа у этого файла была 19:32, 11 марта 2005 года. Выдержка из файла приводится ниже:
/* * This program should be run on the same LAN * as the Docustodian client machine. * Modify the hosts file on the client machine accordingly. * It tricks the client in believing that it has a valid license * to access the server * Author: Ted Wilson */ import java.net.*; import java.io.*; import java.io.ByteArrayOutputStream; public class License { static DatagramSocket sock; // socket static DatagramPacket opkt; // communications packet static DatagramPacket ipkt; // communications packet static InetAddress clientIP; // IP address of client static String msg; // message sent and received static byte[] inbuf; // input message buffer static final int port = 4760; // port number to use static byte[] temp; static String[] hex ; static int port1; public static void main (String[] args) { // create the input packet hex = new String[3]; hex[0] = "e3e875cd5a946d78cbb3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e 3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3e3ea4213"; hex[1] = "d2d719c58e69159f46fad2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2 d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d6022a"; hex[2] = "c1c0fc1b57c5bffcaa45c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1 c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1";
Анализ содержимого файла предоставляет дополнительные доказательства вины Тэда Уилсона. Комментарии в самом начале файла указывают на автора файла и на злонамеренную цель этого файла. Детальный разбор исходного кода показал, что сервер Docustodian уязвим к атаке перехвата. При каждом соединении лицензированного клиента, клиент и сервер обменивались одним и тем же набором из шести пакетов. Более того, клиент, а не сервер, оценивал легитимность соединения. Подозреваемый эксплуатировал эту ситуацию, обманывая клиент Docustodian, заставляя его поверить в то, что licensecrack.java является лицензионным сервером. Этот дефект ПО, а также авторизационные данные Джо Чмо, превратили хранилище документов юридической фирмы в приватный “warez” сервер хакеров-подростков.
Последняя часть этой серии статей описала инструменты и методы восстановления кэшированных файлов браузеров Mozilla Firefox. Важно отметить, что простым посещением директории с кэшированными файлами Firefox’a мы могли бы не увидеть важную информацию, хранящуюся в блоковых файлах. Никакой поисковый запрос не нашел бы почтового сообщения Тэда Уилсона, т.к. оно было заархивировано в блоковом файле. Используя такие инструменты как Cache View, мы смогли восстановить нужную информацию об Интернет истории браузера Mozillf Firefox.
Вся информация, полученная следователем, была взята из истории активности в Интернете. Просто анализируя кэшированную информацию и файлы браузера, мы смогли решить загадку таинственного проникновения на сервер Docustodian.
Храним важное в надежном месте