экспертиза веб-браузеров, часть 2

обзор первой части

Это вторая часть серии статей об экспертизе веб-браузеров. В первой части мы начали расследование несанкционированного доступа на файловый сервер юридической фирмы, работающий на основе Docustodian. Мы доказали, что к серверу получил доступ хакер, или группа хакеров, которые использовали его в качестве хранилища MP3-музыки, MPEG-фильмов и пиратского программного обеспечения.

Также мы проанализировали файлы, хранящие историю активности главного подозреваемого, системного администратора Джо Чмо. Анализ активности показал, что Джо искал материалы по сетевому взлому, а также способы обхода лицензионной политики Docustodian. Однако все эти действия были совершены, пока Джо отдыхал во Флориде со своей семьей.

Во второй части мы узнаем, кто пользовался компьютером Джо, пока он был в отпуске. Мы продолжим расследование, проведя тщательный анализ Интернет-активности других браузеров, имеющихся на жестком диске компьютера Джо.

расследование

Дальнейшее расследование показало, что единственным браузером, кроме Internet Explorer, расположенным на компьютере Джо, оказался Mozilla Firefox. Просмотр файлов истории активности Mozilla Firefox нельзя сделать с помощью одного клика мышки как у IE. В основном это связано с нехваткой инструментов, позволяющих легко воссоздать действия пользователя. Как мы уже обсуждали в первой части, большинство подобных инструментов, типа FTK, IE History, и Web Historian, способны восстанавливать файлы истории для Mozilla Firefox, но они не ассоциируют локальные кэшированные файлы с Интернет-активностью. Это подразумевает, что мы имеем даты и время посещения сайтов, но не можем просмотреть их содержимое. Давайте начнем расследование с рассмотрения кэшированных файлов Firefox’a, расположенных на компьютере Джо. Они находятся в следующей папке: \Documents and Settings\\Application Data\Mozilla\Firefox\Profiles\\Cache.

Внутри этой директории находятся файлы, прямо относящиеся к нашему расследованию. Там 3 типа файлов:
- файл, отображающий структуру кэша (_CACHE_MAP_);
- три блоковых файла (_CACHE_001..003_);
- несколько файлов с кэшированными данными.

Мы проанализируем каждый из этих файлов, чтобы восстановить действия Джо.

файл, отображающий структуру кэша

Файл, отображающий структуру кэша, называется _CACHE_MAP_ и является главным помощником при восстановлении кэшированных данных Firefox’a. Структура самого файла довольно простая. Есть заголовок, за которым следуют области памяти (buckets), отображающие местонахождение кэшированных данных, как показано на рис. 1:


Рис. 1: Структура файла _CACHE_MAP_.

В этом файле 32 области памяти. В каждой области 256 записей. Это значит, что мы имеем 8192 записей в файле.
Каждая запись содержит информацию по одному событию в истории активности. Запись содержит четыре 32-битных числа:
- hash-идентификатор;
- степень вывода;
- расположение данных;
- расположение метаданных.

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 байт.

Напоследок нужно учесть побитовый заголовок блоковом файле. Этот заголовок определен в 4096 байт. Блоки начинаются сразу после этого заголовка. Используя вышеописанные алгоритмы, мы можем извлечь кэшированные данные и метаданные для каждой записи, описанной в файле _CACHE_MAP_.

отдельные файлы с кэшированными данными

Если кэшированные данные или метаданные слишком велики для размещения в блоковых файлах, то данные сохраняются в отдельные файлы. Названия файлов определяются следующим образом:

<ТИП><СГЕНЕРИРОВАННОЕ ЧИСЛО>

Hash-идентификатор берется из файла _CACHE_MAP_. «Тип» либо “d” для кэшированных данных, либо “m” для метаданных. «Сгенерированное число» - число, определяемое с помощью «bitwise AND 0x000000FF» расположения данных/метаданных.

восстановление кэшированных данных

Хорошим инструментом для восстановления кэшированных данных Mozilla Firefox является Cache View. Cache View позволяет просматривать кэшированные данные нескольких браузеров, включая Firefox. Для каждой кэшированной страницы, Cache View предоставляет URL посещенной страницы, имя локального кэшированного файла, размер файла, тип файла, время последнего изменения и другое. Эта информация является теми метаданными, которые мы обсуждали ранее. Пример работы Cache View показан на рис. 2.


Рис. 2. Cache View показывает посещенные страницы.

По умолчанию, Cache View обрабатывает кэшированные файлы браузеров, расположенных на локальной системе. В нашем случае, как и во многих других, обработка информации ведется на рабочей станции следователя, стоящей отдельно от системы с настоящими уликами. Таким образом, нам требуется импортировать кэшированные файлы браузеров с оригинала на нашу рабочую станцию. В случае с Firefox, нам следует импортировать папку \Documents and Settings\\Application Data\Mozilla\Firefox\Profiles\\Cache. После того, как папка будет сохранена на рабочей станции следователя, можно скомандовать Cache View, чтобы она начала извлекать файлы из нее, а не из папок локальных браузеров.

После импорта папки с кэшированными файлами в Cache View, вы увидите нечто схожее с изображением на рис. 3.


Рис. 3: Просмотрим кэшированные файлы браузера Firefox, импортированные с компьютера Джо Чмо.

Как видно на рис. 3, файлы рассортированы по доменным именам сайтов, которые посещал Джо. Кликая мышкой по папке by14fd.bay14.hotmail.msn.com, мы увидим ссылки на посещенные страницы в рамках этого домена. Эти ссылки предоставят дополнительную информацию об активности Джо в почтовой системе Hotmail. Мы решаем провест тщательный анализ этих файлов. Этот процесс включает следующее:
1. Копирование посещенных страниц в локальную папку.
2. Разархивирование копированных файлов.
3. Открытие разархивированных файлов Firefox’ом. Рис. 4 показывает посещенную страницу, восстановленную в ходе этого процесса.


Рис. 4. Восстановленная активность браузера Firefox.

На странице, показанной на рис. 4, видно электронное сообщение, которое читал Джо на своем компьютере. Анализ страницы показал, что сообщение находится в почтовом ящике 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.



Keith J. Jones и Rohyt Belani, перевод SecurityLab.


Сетевые решения. Статья была опубликована в номере 09 за 2005 год в рубрике save ass…

©1999-2024 Сетевые решения