Авторские статьи Почему стоковые логические бомбы - это плохо.

Discussion in 'Статьи' started by madhatter, 16 Jan 2014.

  1. madhatter

    madhatter Member

    Joined:
    7 Aug 2013
    Messages:
    562
    Likes Received:
    50
    Reputations:
    54
    0. Как бы предисловие.

    Идея написания данной заметки возникла после прочтения release-notes нового Kali Linux 1.0.6, основной фичей которого позиционируется несколько переписанный патч для cryptsetup для экстренного уничтожения данных. Приступим.


    1. Об архитектуре LUKS.

    Как многие, наверное, знют, luks - это идейное развитие cryptoloop, основном отличием которого является система управляения ключами и стандартный заголовок. Сейчас я не буду расписывать, почему заголовки в шифротексте - это плохо, а остановлюсь на самой системе. Все данные шифруются рандомным мастер-ключем, который, в свою очередь шифруется слотами ключей. Именно они вводятся при расшифровке диска, что позволяет реализовать смену и управление ключами без полного переписывания всех данных. Плюсы очевидны - менеджент ключей и как бы возможность быстрого уничтожения заголовка. Минусом же является сам заголовок, который, по сути, является большой мигающей красной плашкой "Все сюда, шифрование вот здесь!" с полным указанием алгоритмов. Вопрос - стоит ли оно того?


    2. Уничтожение заголовока и мастер-ключа.

    Из описания архитектуры можно сделать вывод, что уничтожение данных осуществляется простым затиранием всех ключевых слотов и мастер-ключа. По сути же, сам шифротекст никуда не денется - лишь только уничтожится его зашифрованный ключ. И в этом случае атакующему придется перебирать не человеко-запоминаемый ключ из ключевого слота, а сгенерированный luks'ом мастер-ключ. Это вопрос денег и ресурсов.

    Пара слов о реализации логической бомбы. Она довольна разумна, патч устанавливает volume key нулями по необходимой длине, и таким же образом понимает, что перед ним - nuke-ключ.


    3. О главном: почему такой вариант логической бомбы - не ок.

    Прежде всего, он публичен, известен и вскоре, вероятно, будет распространен. Это уже не очень хорошо. Logic bomb - одна из тех вещей, которые стоит держать в секретности. Иначе, если атакующей будет предполагать наличие логической бомбы и искать распространенные - какой в ней смысл?

    Но прежде всего стоит оценить риски и векторы атаки. У атакующего, очевидно, есть физический доступ как к носителю, так и к его владельцу.

    Итак, подумаем о возможных рисках для юзеров подобных систем. Наиболее вероятными будут следующие:
    1. Внезапное маски-шоу, шмон и съем данных.
    2. Кража носителя(куда ж без этого?)
    3. Съем данных в тайне от владельца без кражи носителя.
    4. Маски-шоу, но уже без корок-бумажек и прочих условностей.
    Итак, владелец, знающий nuke-ключ и способный его ввести будет иметь такую возможность максимум в (1) и (4) случаях. Казалось бы - все замечательно, в (1) и (4) мастер-ключ уничтожен, в (2) и (3) данные и мастер-ключ зашифрованы. Но здесь стоит детальнее остановиться на православном и правильном методе съема данных при криминалистической экспертизе, которая, по сути, в четвертом случае не особо отличается от первого.
    Если нет доступа к разлоченной системе при открытом носителе, то ни один сколько-нибудь понимающий недокриминалист не будет включать систему на машине подозреваемого и копировать данные по методу "вставил флешку - скопировал, что нашел, ушел". В таком случае снимается полная мастер-копия всего носителя, причем зачастую через аппартный блокиратор записи.
    При обнаружении шифрования можно "попросить" подозреваемого ввести ключ, но только после снятия подтвержденной мастер-копии. Таким образом nuke-ключ будет не только бесполезен(мастер-копия же есть!), но и в случае официального маски-шоу добавит подозреваемому неприятностей в виде уничтожения улик.
    К слову, о довольно забавном методе развода на логическую бомбу писал широко-известный-в-узких-кругах(тм) тов. Федотов, ведущий уютный бложик на секлабе.

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


    4. Что же делать, как же быть?

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

    Аналогичным образом стоит воткнуть экстренный вайпер на горячие клавиши в рабочей системе, чтобы хотя бы затереть ключ из памяти, а после - что успеет.