Comments 14
Относительно «Не надо внедрять в систему вредоносный код, достаточно его прямо в системе написать и выполнить» — это что-то наподобие Win+R → PowerShell (New-Object System.Net.WebClient).DownloadFile → (New-Object -com Shell.Application).ShellExecute?
> Но такая магия основывается на информации о типовых алгоритмах шифрования, и если киберпреступник использует другой алгоритм, или оригинальную их комбинацию — магия может и будет работать, а может и нет.
Вот тут вы не правы, т.к. по определению энтропия зашифрованного блока зашифрованного надежным крипто-алгоритмом — максимальна. Если какой-то вирус будет использовать «шифрование» которое не увеличивает энтропию — значит это шифрование можно сломать в два счета.
Вот тут вы не правы, т.к. по определению энтропия зашифрованного блока зашифрованного надежным крипто-алгоритмом — максимальна. Если какой-то вирус будет использовать «шифрование» которое не увеличивает энтропию — значит это шифрование можно сломать в два счета.
Да, пожалуй нужно уточнить. Я не могу оценить все достоинства и недостатки математической модели, поэтому вполне можно предположить, что она работает. Более важный довод идет следующим: для любого алгоритма защиты существуют варианты обхода и определенный процент ложных срабатываний (увеличение энтропии без шифрования). Нельзя полагаться на единственный алгоритм. Собственно, автор утилиты сам об этом прямо говорит.
И мне кажется, есть способы скрыть увеличение энтропии при шифровании.
И мне кажется, есть способы скрыть увеличение энтропии при шифровании.
Конечно данная защита не идеальна. Она например не определит тот факт, что шифровальщик начал шифровать .mp3 или .avi файлы, т.к. обычно их энтропия и так уже близка к максимальной.
> И мне кажется, есть способы скрыть увеличение энтропии при шифровании.
Есть только один способ — не шифровать.
Криптографически надежный шифр должен являться PRP перестановкой, а это значит что для блока скажем в 128 бит, любые исходные 128 бит данных после шифрования должны с равной вероятностью стать любым из возможных сочетаний 128 бит. Если энтропия не максимальна, значит эта функция не является PRP по определению, т.к. некоторые из возможных значений будут иметь большую вероятность оказаться шифротекстом.
> И мне кажется, есть способы скрыть увеличение энтропии при шифровании.
Есть только один способ — не шифровать.
Криптографически надежный шифр должен являться PRP перестановкой, а это значит что для блока скажем в 128 бит, любые исходные 128 бит данных после шифрования должны с равной вероятностью стать любым из возможных сочетаний 128 бит. Если энтропия не максимальна, значит эта функция не является PRP по определению, т.к. некоторые из возможных значений будут иметь большую вероятность оказаться шифротекстом.
> И мне кажется, есть способы скрыть увеличение энтропии при шифровании.
Впрочем больное воображение рисует такой вариант, который может сойти для криптолокеров: данные жмуться максимально, потом шифруется, потом шифрованные данные по заданному паттерну «разбавляются» нулями, так чтобы получился файл примерно такого-же размера. Тогда энтропия примерно не изменится, но с точки зрения криптографии это не будет надежной защитой. Впрочем для криптолокеров это возможно прокатит, т.к. от ряда крипто-атак им не нужно защищаться.
Впрочем больное воображение рисует такой вариант, который может сойти для криптолокеров: данные жмуться максимально, потом шифруется, потом шифрованные данные по заданному паттерну «разбавляются» нулями, так чтобы получился файл примерно такого-же размера. Тогда энтропия примерно не изменится, но с точки зрения криптографии это не будет надежной защитой. Впрочем для криптолокеров это возможно прокатит, т.к. от ряда крипто-атак им не нужно защищаться.
Да, я как раз такой вариант имел в виду. Не думаю, что прямо сейчас писатели локеров будут этим заниматься, им достаточно потенциальных жертв вообще без защиты.
Такой вариант не годится для уже сжатых данных — видео, аудио, картинки — т.е. для всего того, на что нацелены криптовымогатели. Даже документы ms-офиса сегодня — это упакованные в zip данные. Хотя чисто теоретически, конечно, идея интересная.
> Есть только один способ — не шифровать.
К сожалению, дурное дело нехитрое. Криптолокеру необязательно шифровать весь файл. Чтобы файл испортить, достаточно зашифровать только его часть — например, заголовок и псеводослучайно выбранные байты в середине. Энтропия возрастёт незначительно, а исправить будет сложно.
К сожалению, дурное дело нехитрое. Криптолокеру необязательно шифровать весь файл. Чтобы файл испортить, достаточно зашифровать только его часть — например, заголовок и псеводослучайно выбранные байты в середине. Энтропия возрастёт незначительно, а исправить будет сложно.
В этом случае достаточно снизить энтропию не изменяя алгоритма шифрования, к примеру использовать стеганографию. Пример: зловред читает исходный файл, шифрует данные, пишет зашифрованные данные в виде младших бит цвета bitmap-контейнера (старшие биты обнулены), затем затирает нулями исходный файл. В этом случае энтропия записываемых данных, будет ниже энтропии зашифрованных данных.
> значит это шифрование можно сломать в два счета.
я зашифрую файл, а потом продублирую его.
энтропия уменьшилась в два раза, размер увеличился в 2 раза, сломать шифрование легче не стало.
я зашифрую файл, а потом продублирую его.
энтропия уменьшилась в два раза, размер увеличился в 2 раза, сломать шифрование легче не стало.
Sign up to leave a comment.
Security Week 16: взлом мыши с 225 метров, детектор криптолокеров в Mac OS X, миллион долларов за взлом iPhone