Главная » Безопасность » Как не стоит прятать конфиденциальную информацию
как нельзя прятать информацию

Как не стоит прятать конфиденциальную информацию

Большинство людей желающих скрыть конфиденциальные данные — далеко не профессионалы в информационной безопасности, поэтому используемые ими способы сокрытия данных наивны. В этой статье мы рассмотрим разные способы сокрытия информации и обсудим стоит ли ими пользоваться.

Еще по теме: Как спрятать конфиденциальную информацию

Перемещение данных в другую папку

Нет, сейчас мы обсуждаем не «сокрытие» коллекции порнографических картинок в папке «Курсовые по сопромату». Мы обсуждаем наивный, но достаточно действенный способ спрятать информацию, просто переместив определенные данные в другое место на диске.

Что это, очевидная глупость или запредельное простодушие? Каким бы наивным ни казался этот способ, он вполне может сработать для редких и экзотических данных — таких как jump lists (кстати, а знаете ли вы, что это такое?) или база данных мессенджера WhatsApp.

У злоумышленника может просто не найтись времени или достаточной целеустремленности, чтобы обшаривать весь компьютер в поисках базы данных от… а от чего, собственно? Программ для мгновенного обмена сообщениями существует сотни, если не тысячи; поди пойми, какой из них пользовался пользователь. И, заметьте, у каждого приложения сугубо собственные пути к файлам, имена и даже свои форматы баз данных. Искать их вручную на компьютере с десятками тысяч папок и сотнями тысяч файлов — занятие бесперспективное.

как нельзя прятать информацию
jump lists

Очевидно, что такой способ сокрытия конфиденциальной информации сработает, исключительно если у злоумышленника мало времени на тщательный анализ содержимого компьютера. В таких и только таких случаях метод — назовем его «методом Неуловимого Джо» — может сработать.

Использование «безопасных» методов коммуникации

Защищенные мессенджеры не всегда являются достаточно защищенными. Здесь и исследование областей freelist баз данных в формате SQLite, и официальные запросы к производителям мессенджеров (например, Microsoft без лишних вопросов отдаст следствию логи бесед в Skype — ведь хранятся они на серверах компании), и даже запросы к производителям смартфонов (здесь вспоминается история, в которой компания BlackBerry помогла канадской полиции локализовать банду наркоторговцев, решивших воспользоваться фирменным мессенджером компании на старой платформе BlackBerry OS).

В этой связи на ум приходит курьезный случай. Американская полиция задержала человека, подозревавшегося в наркоторговле в особо крупных размерах. Подозреваемый немного разбирался в IT в качестве единственного метода общения выбрал Apple iMessage. Сообщения iMessage не сохраняются на серверах Apple, а подозреваемый тщательно очищал историю переписки после каждой сессии. В резервной копии его iPhone не обнаружилось ничего интересного.

Однако, когда полиция взялась за исследование его компьютера (у преступника был Mac), их радости не было предела: на компьютере нашлись сотни тысяч сообщений, о самом существовании которых преступник (теперь уже точно преступник) вовсе не подозревал. Осудить наркоторговца помогла новинка (на тот момент) от Apple — система Continuity, которая синхронизировала сообщения iMessage между всеми устройствами, зарегистрированными в одной учетной записи.

Мораль?

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

Переименование файлов

Еще одна наивная попытка спрятать информацию — переименование файлов. Как бы просто это ни звучало, переименование, к примеру, зашифрованной базы данных какого-нибудь защищенного мессенджера во что-то вроде C:\Windows\System32\oobe\en-US\audit.mui вполне в состоянии пройти мимо внимательного взгляда эксперта. Действительно, в каталогах Windows хранятся тысячи файлов; найти среди них что-то необычное (особенно если оно не выделяется размерами) — задача, ручным трудом не решаемая.

Каким образом ищут такие файлы?

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

Используется отнюдь не только поиск по имени файла; применяется комплексный подход, когда анализируются следы (например, в реестре Windows) установленных приложений, после чего отслеживаются пути к файлам, к которым получали доступ эти приложения.

Другой популярный способ поиска переименованных файлов — так называемый карвинг, или сквозной поиск по содержимому. В точности такой же подход, иначе известный как «поиск по сигнатурам», использовался с начала времен абсолютно во всех антивирусных программах. При помощи карвинга можно проанализировать как содержимое файлов на диске, так и содержимое самого диска (или только занятых областей) на низком уровне.

Стоит ли переименовывать файлы?

Это — очередная хитрость «Неуловимого Джо», способная защитить лишь от очень ленивого злоумышленника.

Удаление файлов

Не уверен, насколько «наивно» на сегодняшний день пытаться скрыть улики, удаляя файлы. Дело в том, что файлы, удаленные с обычных жестких дисков, как правило, довольно легко восстанавливаются при помощи уже хорошо знакомого сигнатурного поиска: диск сканируется поблочно (сейчас нас интересуют фрагменты, не занятые существующими файлами и прочими структурами файловой системы), каждый прочитанный блок данных анализируется на соответствие ряду критериев (является ли он заголовком файла определенного формата, частью текстового файла и так далее).

При помощи такого сканирования, выполняемого, к слову, в полностью автоматическом режиме, вероятность успешного (хотя бы частичного) восстановления удаленных файлов достаточно велика.

Как не стоит прятать информацию
Криминалистическое ПО (на скриншоте — Belkasoft Evidence Center) умеет восстанавливать удаленные данные, такие, например, как чаты скайпа, с помощью глубокого анализа баз SQLite

Казалось бы, удаление файлов — классическая «наивная» попытка спрятать улики. Но только не когда файлы удаляются с 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, то синхронизацию OneDrive или Google Drive, а то и более экзотические виды синхронизации — например, настройку (которой, кстати, в iOS вовсе нет; может, поэтому забывают?), благодаря которой информация о звонках с iPhone (как по телефону, так и через FaceTime) сразу попадает на серверы Apple. Примеры с «забытым» режимом Continuity и мессенджером BlackBerry я уже приводил выше.

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

Еще по теме: Безопасность облачных хранилищ

Использование внешних накопителей

Использование зашифрованных флешек для хранения информации, кажется некоторым пользователям гениальной идеей. Казалось бы, ничего не нужно удалять — достаточно выдернуть флешку из компьютера, и доступ к данным не получит никто и никогда (если защита стойкая). Именно так рассуждают наивные пользователи пытающиеся сохранить чувствительную, конфиденциальную информацию.

Почему «наивные»?

Дело в том, что большинство простых пользователей не имеет представления о «хвостах», которые остаются после практически любых манипуляций с USB-устройствами. Так, однажды расследовался случай с распространением нелегального контента. Преступники использовали исключительно внешние накопители (обычные флешки); на дисках не хранилось ничего.

Преступники не учли сразу два момента. Первый: история подключении USB-устройств сохраняется в реестре Windows; если ее не удалять, то хранится она там очень и очень долго. И второй момент: если для доступа к изображениям пользоваться встроенным в Windows проводником, то автоматически создаются (и сохраняются!) уменьшенные превью фотографий (thumbnails), в последних версиях Windows по адресу %LocalAppData%\Microsoft\Windows\Explorer\. В Windows XP — файл Thumbs.db. Проанализировав уменьшенные изображения и сопоставив идентификаторы USB-устройств с конфискованными, следствию удалось доказать причастность обвиняемых к инкриминируемому преступлению.

А что же с шифрованием?

И здесь не все очевидно. Во-первых, существуют специализированные приложения, позволяющие создать дамп оперативной памяти компьютера и извлечь из него криптографические ключи, использующиеся для доступа к зашифрованным томам (в частности, к популярному среди наивных пользователей BitLocker To Go).

Пример такой программы — Elcomsoft Forensic Disk Decryptor, при помощи которой можно проанализировать дамп в полностью автоматическом режиме. А создать образ оперативной памяти можно при помощи бесплатной утилиты Belkasoft RAM Capturer.

как нельзя скрывать информацию
Belkasoft RAM Capturer

Во-вторых, ни для кого не секрет, что многие криптоконтейнеры автоматически депонируют ключи шифрования в облако. И если Apple при активации FileVault 2 несколько раз уведомит пользователя о том, что восстановление доступа к разделу будет возможно через iCloud, то Microsoft при шифровании тома с использованием BitLocker Device Protection просто молча создает депонированный ключ в учетной записи пользователя Microsoft Account. Ключи эти доступны непосредственно на странице аккаунта пользователя.

Как получить доступ к учетной записи?

Если в компьютере настроен логин при помощи Microsoft Account (а не локальной учетной записи Windows), то офлайновая атака прямым перебором может восстановить пароль, который — сюрприз! — будет совпадать с паролем от онлайновой учетной записи Microsoft Account.

Кому интересно, вот статья о взломе BitLocker.

Вложенные криптоконтейнеры с аппаратным ключом

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

Теоретически — да. Практически… практически — есть тонкости юридического плана. И вот яркий пример.

Обвиняемый в скачивании и хранении нелегальной контента находится в заключении в американской тюрьме вот уже два с лишним года. Официальное обвинение — отказ подозреваемого выдать пароли от зашифрованных внешних хранилищ (NAS), где, по мнению суда, хранится запрещенный контент.

Хранится она там или нет — неизвестно; соответствующего содержимого у обвиняемого найдено не было. Но обвинение очень серьезное, а здесь можно и пожертвовать такими мелочами, как презумпция невиновности и право не свидетельствовать против самого себя. Так что обвиняемый сидит и будет сидеть до тех пор, пока не раскроет пароли или не умрет от старости или иных причин.

Не так давно правозащитники подали апелляцию, в которой указывалось, что по закону по данной статье (отказ от сотрудничества со следствием) максимальный срок заключения — 18 месяцев. Апелляция была отклонена судом несмотря на то, что судья признал аргументы адвоката «интересными и разносторонними». Обвинение посерьезнее — и судьи закроют глаза на что угодно, включая писаные законы.

Выводы

Если вы особо не интересуетесь информационной безопасностью, тогда до вас рано или поздно доберутся или хакеры или спецслужбы. Быть в курсе информационной безопасности можно с помощью таких сайтов как наш. Подписка на наши паблики в соцсетях бесплатна!

4 комментария

  1. 1

    «какой из них пользовался пользовался пользователь.»

    • Falcon

      Спасибо. Уже пофиксили.

  2. Anon

    Спасибо за Ваши труды!

  3. Михаил

    Познавательно и даже для…
    А можно ссылку на последний пример из судебной практики США
    Пожалуйста

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *