Эта публикация будет необычной. Мы не расскажем о найденных в iOS или Android уязвимостях и не поделимся опытом взлома паролей. Вместо этого мы поговорим о том, как обычные пользователи пытаются скрыть цифровые улики – и почему это иногда получается.
Причина, побудившая нас написать эту статью, достойна отдельного рассказа. Время от времени к нам обращаются за консультацией; как правило, мы в меру своих сил стараемся помочь экспертам и представителям правоохранительных органов. Несколько месяцев назад нас попросили прокомментировать документ – руководство для полицейских экспертов по поиску цифровых улик. Документ оказался настолько интересным, что, вдохновившись и испросив официального разрешения от его авторов, мы решили написать на его основе собственное исследования – взглянув, однако, на ситуацию под другим углом. Давайте рассмотрим методы и уловки, которыми подследственные пытаются запутать цифровой след и скрыть улики.
Почему преступники – наивные? Большинство подследственных, не являющихся членами преступных группировок, далеки от мира IT безопасности. Наивны и способы, которыми они пытаются замести цифровой след. Не смотря на это, многие уловки срабатывают именно так, как от них ожидалось просто по принципу «неуловимого Джо». Далеко не у каждого следователя будет достаточно времени, квалификации и мотивации на проведение подробного анализа цифровых улик – особенно если дело на первый взгляд не связано с кибер-преступностью. Помочь отыскать улики могут специализированные программы, автоматизирующие поиск и анализ улик, сокрытых с помощью «наивных» способов.
Какие же способы использует среднестатистический Василий П., чтобы сокрыть улики? Набор уловок невелик, а сами уловки достаточно нехитры.
Нет, сейчас мы обсуждаем не «сокрытие» коллекции картинок сомнительного качества и содержания в папке «Курсовые по сопромату». Мы обсуждаем наивный, но достаточно действенный способ сокрытия улик путём простого перемещения определённых данных в другое место на диске.
Что это, очевидная глупость или запредельное простодушие? Не спешите с ответом. Каким бы наивным ни казался этот способ, он вполне может сработать для редких и экзотических данных — таких, как jump lists (кстати, не все знают, что это такое и какие улики позволяет извлечь) или база данных Telegram. У эксперта может просто не найтись времени или достаточной целеустремлённости, чтобы обыскивать весь компьютер в поисках базы данных от… а от чего, собственно? Программ для мгновенного обмена сообщениями существует сотни, если не тысячи; поди пойми, какой из них пользовался преступник. При этом у каждого приложения собственные пути к файлам, имена и даже форматы баз данных. Отыскать их вручную на компьютере с десятками тысяч папок и сотнями тысяч файлов – занятие бесперспективное.
Очевидно, что такой способ сокрытия улик сработает исключительно в случаях расследования преступлений, не связанных с информационной безопасностью. У следователя может не возникнуть вопросов по поводу содержимого жёсткого диска подозреваемого, и его анализ превратится в формальность. В таких и только таких случаях метод – назовём его «методом Неуловимого Джо» – может сработать.
Как обнаруживаются такие файлы? Даже полностью автоматизированный анализ посредством одного (а чаще – нескольких) криминалистических продуктов позволит найти практически все базы данных, медиа-файлы, архивы и документы, где бы они не находились (за исключением разве что зашифрованных томов – о них позднее).
Современные правонарушители могут неплохо ориентироваться в вопросах безопасности. Они довольно хорошо представляют, каким образом передаются сообщения между участниками чата, где они сохраняются и как их удалять.
Какими возможностями может воспользоваться следствие для того, чтобы получить доступ к чатам? Здесь и низкоуровневое сканирование диска с целью поиска баз данных в известных форматах, и исследование областей freelist баз данных в формате SQLite, и официальные запросы к производителям приложений (например, Microsoft без лишних вопросов отдаст следствию журналы бесед в Skype – ведь хранятся они на серверах компании), и даже запросы к производителям смартфонов. Но и здесь время от времени возникают курьёзные случаи, которые со временем превращаются в своеобразные «городские легенды».
Можно вспомнить один такой случай, рассказанный докладчиком на одном полицейском мероприятии. Американской полицией был задержан человек, подозревавшийся в наркоторговле в особо крупных размерах. Подозреваемый был неплохо подкован технически, и в качестве единственного метода общения выбрал Apple iMessage. На тот момент (задолго до выхода iOS 11.4, которая, как известно, сообщения синхронизирует с облаком) сообщения iMessage не сохранялись на серверах Apple и хранились исключительно локально. Подозреваемый тщательно очищал историю переписки после каждой сессии. В резервной копии его iPhone не нашлось ничего интересного.
Однако, когда полиция взялась за исследование компьютера подозреваемого (у преступника был Mac), их радости не было предела: на компьютере нашлись сотни тысяч (!) сообщений, о самом существовании которых преступник вовсе не подозревал. Осудить наркоторговца помогла новинка (на тот момент) от Apple – система Continuity, которая доставляла сообщения iMessage на устройства пользователя, зарегистрированные в одной учётной записи.
К слову, докладчик жаловался, что все существовавшие на тот момент программы для анализа баз данных iMessage не справлялись с таким количеством сообщений; полиции пришлось писать собственную утилиту для анализа разбухшей БД.
Мораль? Морали здесь нет: не будучи специалистом в IT, знать о подобных моментах заранее невозможно. Простой тест: а в курсе ли читатель, что Apple синхронизирует информацию о телефонных звонках с iCloud? И если в курсе, знает ли он о том, как эту возможность отключить? Этот простой вопрос способен поставить в тупик даже полицейских экспертов, не говоря уже об обычных пользователях.
Ещё одна наивная попытка спрятать улики – переименование файлов. Как бы просто это ни звучало, переименование, к примеру, зашифрованной базы данных какого-нибудь защищённого мессенжера во что-то вроде c:\Windows\System32\oobe\en-US\audit.mui вполне в состоянии пройти мимо внимательного взгляда эксперта. Действительно, в каталогах Windows хранятся тысячи файлов; найти среди них что-то необычное (особенно если оно не выделяется размерами) – задача, ручным трудом нерешаемая.
Каким образом ищут такие файлы? Наивному обывателю простительно не знать о существовании целого класса специализированных программ, предназначенных именно для поиска подобных файлов на дисках (и образах дисков) подозреваемых. К примеру, существуют и активно используются обширные базы данных, в которых содержатся контрольные суммы стандартных файлов (компонентов Windows и многих сторонних приложений), позволяющие исключить из дальнейшего анализа как сами такие файлы, так и занимаемое ими дисковое пространство. Используется и противоположный подход, когда приложение пытается найти именно такие файлы, контрольные суммы которых присутствуют в соответствующих базах данных.
Другой популярный способ поиска переименованных файлов – так называемый «карвинг», или сквозной поиск по содержимому. В точности такой же подход, иначе известный как «поиск по сигнатурам», использовался с начала времён в абсолютно всех антивирусных программах. При помощи карвинга можно проанализировать содержимое как файлов на диске, так и содержимого самого диска (или только занятых областей) на низком уровне.
Стоит ли переименовывать файлы? Это – очередная уловка «неуловимого Джо», способная защитить лишь от очень ленивого следователя.
Не уверен, насколько «наивным» на сегодняшний день является сокрытие улик посредством удаления файлов. Дело в том, что удалённые файлы с обычных жёстких дисков, как правило, довольно легко восстанавливаются при помощи уже хорошо знакомого сигнатурного поиска: сканируется поверхность диска (сейчас нас интересуют фрагменты, не занятые существующими файлами и прочими структурами файловой системы). Каждый прочитанный блок данных анализируется на соответствие ряду критериев (является ли он заголовком файла определённого формата; является ли он частью текстового файла, и так далее). При помощи такого сканирования, выполняемого, к слову, в полностью автоматическом режиме, вероятность успешного (хотя бы частичного) восстановления удалённых файлов достаточно велика.
Казалось бы, удаление файлов – классическая «наивная» попытка спрятать улики. Но только не в случаях, когда файлы удаляются с SSD дисков.
Здесь нужно рассказать чуть подробнее о том, как работает удаление (и последующее чтение) данных на SSD. Наверняка ты слышал о существовании «сборщика мусора» и функции TRIM, позволяющих современным SSD поддерживать высокую производительность при записи (и особенно – перезаписи) данных. Команда TRIM подаётся операционной системой; она сообщает контроллеру SSD, что определённые блоки данных с определёнными физическими (на самом деле нет) адресами освобождены и более не используются.
Задача контроллера теперь – очистить (произвести стирание данных) указанные блоки, подготовив их таким образом для того, чтобы в них можно было быстро записать новую информацию.
Но стирание данных – процесс очень медленный, и происходит он в фоновом режиме, когда нагрузка на диск падает. А если сразу после команды TRIM поступает команда записи в тот самый «физический» блок? В этом случае контроллер мгновенно подменяет такой блок на пустой, просто модифицировав значение в таблице переадресации. А тот блок, который предназначен для стирания, получает другой «физический» адрес или вовсе помещается в неадресуемый пул из резервной области.
Вопрос на засыпку: а если контроллер не успел физически стереть данные из подвергнутых операции TRIM блоков, сможет ли сигнатурный поиск найти что-либо в свободных областях SSD?
Правильный ответ: в большинстве случаев при попытке считать данные из блока, на который поступила команда TRIM, контроллер выдаст либо нули, либо другую последовательность данных, ничего общего не имеющую с реальным содержимым блока. Связано это с особенностями реализации протоколов в современных SSD, в которых чётко определяется поведение контроллера при попытке считать блок после команды TRIM. Значений здесь всего три: Undefined (контроллер вернёт реальное содержимое блока; в современных SSD практически не встречается), DRAT (Determined Read After Trim, или фиксированные данные после Trim; в потребительских моделях встречается чаще всего) и DZAT (Determined Zeroes After Trim, или всегда возвращать нули после команды Trim; часто встречается в моделях, предназначенных для работы в составе RAID, NAS и в серверных сценариях).
Таким образом, в подавляющем большинстве случаев контроллер вернёт данные, не имеющие ничего общего с реальным содержимым накопителя. Восстановить удалённые файлы с SSD в большинстве случаев не удастся даже спустя секунды после их удаления.
Данные – в облаке? Казалось бы, всякой наивности должен быть предел. И тем не менее, пользователи с завидным постоянством забывают отключить то iCloud Photo Library, то резервные копии в iCloud, то синхронизацию паролей (iCloud Keychain или Chrome Sync), а то и более экзотические виды синхронизации – например, настройку (которой, кстати, в iOS вовсе нет; может, поэтому забывают?), благодаря которой информация о звонках с iPhone сразу попадает на серверы Apple. Пожалуй, здесь нечего добавить, кроме того, что данные из «облака» компании выдают полиции без особого сопротивления.
Использование зашифрованных твердотельных накопителей для хранения и транспортировки информации, связанной с нелегальной деятельностью, кажется преступникам гениальной идеей. Казалось бы, ничего не нужно удалять – достаточно просто извлечь зашифрованный накопитель из USB порта, и доступ к данным не получит никто и никогда (если защита стойкая). Именно так рассуждают наивные преступники.
Почему «наивные»? Дело в том, что большинство простых пользователей не имеет представления о «хвостах», которые остаются после практически любых манипуляций с USB устройствами. Так, полицией однажды расследовался случай с распространением детской порнографии. Преступная группа использовала исключительно внешние накопители (обычные флешки, на которых создавался криптоконтейнер); на дисках не хранилось ничего.
Преступники не учли сразу два момента. Первый: информация о подключении USB устройств сохраняется в реестре Windows; если её не удалять, то хранится она там очень и очень долго. И второй момент: если для доступа к изображениям пользоваться встроенным в Windows проводником, то автоматически создаются (и сохраняются!) уменьшенные превью фотографий (thumbnails), обычно по адресу %LocalAppData%\Microsoft\Windows\Explorer\. Проанализировав уменьшенные изображения и сопоставив идентификаторы USB-устройств с конфискованными, следствию удалось доказать причастность обвиняемых к инкриминируемому преступлению даже без расшифровки содержимого самих накопителей.
А что же с шифрованием? И здесь не всё очевидно. Во-первых, существуют специализированные приложения, позволяющие создать образ оперативной памяти компьютера и извлечь из него криптографические ключи, использующиеся для доступа к зашифрованным томам (в частности, к популярному среди наивных преступников BitLocker To Go). Пример такой программы – Elcomsoft Forensic Disk Decryptor, при помощи которой можно как захватить, так и проанализировать дамп в полностью автоматическом режиме.
Во-вторых, ни для кого не секрет, что многие криптоконтейнеры автоматически депонируют ключи шифрования в «облако». И если Apple при активации FileVault 2 несколько раз уведомит пользователя о том, что восстановление доступа к разделу будет возможно через iCloud, то Microsoft при шифровании тома с использованием BitLocker Device Protection просто молча создаёт депонированный ключ в учётной записи пользователя Microsoft Account. Ключи эти доступны непосредственно со страницы https://account.microsoft.com/devices/recoverykey
Как получить доступ к учётной записи? Если в компьютере настроен логин при помощи Microsoft Account (а не локальной учётной записи Windows), то офлайновая атака прямым перебором может восстановить пароль, который будет совпадать с паролем от онлайновой учётной записи Microsoft Account.
В IT давно придуманы надёжные способы как защитить, так и скрыть информацию. Что может быть безопаснее вложенного криптоконтейнера, для доступа к которому используется защищённый паролем аппаратный ключ? Казалось бы, непробиваемая защита: преступник может быть уверен, что даже в худшем случае улики останутся недоступны следствию.
Теоретически преступник прав. Практически же могут быть тонкости юридического плана, которые будут отличаться от юрисдикции к юрисдикции.
Интереснейший юридический казус случился в Соединённых Штатах Америки. Франсис Роулз, обвиняемый в скачивании и хранении детской порнографии, третий год находится в заключении в американской тюрьме за то, что отказывается выдать пароли к зашифрованным контейнерам. Официальное обвинение – отказ подозреваемого выдать пароли от зашифрованных внешних хранилищ (NAS), где, по мнению суда, хранится детская порнография.
Хранится она там или нет – неизвестно; соответствующего содержимого у обвиняемого найдено не было. Но обвинение серьёзное, есть косвенные улики. Соответственно, обвиняемый сидит и будет сидеть до тех пор, пока не раскроет пароли или не умрёт от старости или иных причин.
Не так давно правозащитники подали апелляцию, в которой указывалось, что по закону по данной статье (отказ от сотрудничества со следствием) максимальный срок заключения – 18 месяцев. Апелляция была отклонена судом несмотря на то, что судья признал аргументы адвоката «интересными и разносторонними».
Мораль? Мораль проста: «не воруй». Игра в прятки с правосудием не стоит свеч.
Выражаем благодарность Юрию Губанову, генеральному директору «Белкасофт», поделившемуся некоторыми интересными подробностями о нескольких недавно раскрытых случаях.