Комментарии 25
Поэтому всё важное надо хранить в облаке.
Нужно решение которое на уровне системы будет спрашивать разрешение на работу с файлом X программу Y. Или хотя бы глобально разрешать программе Y работать с файлами, но явно, как права в андроиде.
Когда-нибудь целое облако так зашифруют, тогда посмеёмся.
Итак: у меня облако. Работает синхронизация. Вирус шифрует файлы локально, через некоторое время они заливаются в облако стандартным механизмом облачного сервиса. в итоге в облаке лежит тоже зашифрованная версия.
Далеко не все облака хранят предыдущие версии файлов.
Далеко не все облака хранят предыдущие версии файлов.
«Расшифровать файлы без соответствующего ключа нереально. Требуемое время брутфорса, с использованием целой сети мощных ПК — около двух лет.»
Ох, теперь уже 2 года — нереально. Раньше нереальными считались столетия.
Ох, теперь уже 2 года — нереально. Раньше нереальными считались столетия.
Факторизация и подразумевает получение «соответствующего ключа». Суть анализа была в том, что ошибки в реализации нету и данные без ключа не расшифровать. Почему используется столь короткий RSA ключ — загадка, экономия и по объёму данных, и по времени шифрования не сильные.
Факторизация подразумевает получение ключа, который даёт коллизию на некоторой функции. Это вовсе не обязательно «соответствующий ключ». Фраза «расшифровать файлы без соответствующего ключа нереально» — предполагает недетерменированное (или детерменированное на _ОЧЕНЬ_ большом временном отрезке) вычисления ключа, дающего коллизию.
По определению факторизация подразумевает разложение составного числа на простые.
О какой коллизии вы говорите в данном случае? Факторизация однозначна, ни о каких коллизиях речи тут идти не может.
Содержимое метаданных позволяет расшифровать файл, метаданные зашифрованы открытым ключом асимметричного алгоритма RSA, для их расшифровки требуется закрытый ключ, который имеется только у автора этого зловреда.
О какой коллизии вы говорите в данном случае? Факторизация однозначна, ни о каких коллизиях речи тут идти не может.
Содержимое метаданных позволяет расшифровать файл, метаданные зашифрованы открытым ключом асимметричного алгоритма RSA, для их расшифровки требуется закрытый ключ, который имеется только у автора этого зловреда.
А если с терморектальным катализатором?
эпидемия началась какая то.За неделю 2 пк словили уже.
Сейчас массово предупреждаем всех бухов что бы не открывали непонятные письма.
Они маскируется типа «На вас заведено уголовное дело, срочно прочтите». Бух открыла, никакого текста не увидела, потом полезла с телефона открывать это письмо…
Сейчас массово предупреждаем всех бухов что бы не открывали непонятные письма.
Они маскируется типа «На вас заведено уголовное дело, срочно прочтите». Бух открыла, никакого текста не увидела, потом полезла с телефона открывать это письмо…
Такая же фигня была в январе этого года. Только-только начал внедрять систему резервного копирования, как продажники схватили криптолокер в архиве.
Я еще хочу в эксчейндже поставить запрет на прием всяких архивов типа *.zip и *.rar.
Я еще хочу в эксчейндже поставить запрет на прием всяких архивов типа *.zip и *.rar.
Зря — многие обмениваются файлами через почту.
Да, но, а что еще можно придумать?
- бэкапы помогут только восстановить зашифрованные файлы.
- Антивирус не всегда детектит.
- Запрет на запуск файлов не всегда помогает, т.к. приходят всякие скрипты, вирусы с расширениями от скринсевов и UAC не ругается даже.
- Говорят, что шифровщики удаляются после перезагрузки раб.станции, но вот тут хз. Сегодня удаляются, а завтра свое тело по всей сети рассылают или деактивируются на время, а потом опять шифровать начинают.
- На почту поставить запрет на прием архивов. Вот тут смотреть нужно, т.к. есть организации у которых ограничение на отправку вложения или если кроме одиночных файлов еще и какие-то каталоги отправляют.
Рекомедую поставить Антитвирус на почтовый север который умеет инспектить все известные арихивы (напимер: Symantec Mail Securety for Exchange). Настраиваете там правила, что все опасные разширения в архивах и без кидать в карантин а там уже будете рукуми разгребать если что-то понадобится. Список опасных разширений у меня такой:
ADE|ADP|APP|BAS|CHM|CRT|HLP|INF|INS|ISP|MDB|MDE|MSC|MST|MSU|PCD|SCT|SHB|SHS|URL|VSD|VSS|VST|VSW|PS1|PS1XML|PS2|PS2XML|PSC1|PSC2|MSH|MSH1|MSH2|MSHXML|MSH1XML|MSH2XML|SCF|LNK|INF|REG|EXE|PIF|APPLICATION|GADGET|MSI|MSP|COM|SCR|HTA|CPL|MSC|JAR|BAT|CMD|VB|VBS|VBE|JSE|WS|WSF|WSC|WSH
ADE|ADP|APP|BAS|CHM|CRT|HLP|INF|INS|ISP|MDB|MDE|MSC|MST|MSU|PCD|SCT|SHB|SHS|URL|VSD|VSS|VST|VSW|PS1|PS1XML|PS2|PS2XML|PSC1|PSC2|MSH|MSH1|MSH2|MSHXML|MSH1XML|MSH2XML|SCF|LNK|INF|REG|EXE|PIF|APPLICATION|GADGET|MSI|MSP|COM|SCR|HTA|CPL|MSC|JAR|BAT|CMD|VB|VBS|VBE|JSE|WS|WSF|WSC|WSH
Вот у меня сейчас на руках 900 файлов, шифрованных этим вирусом и 900 оригинальных. После пары вечером копания я выяснил это:
1. Да, шифруются первые 30000 байт, но потом могут быть вкрапления по 1024 байта ещё какого-то шифрования. Эти же вкрапления могут быть и среди первых 1024. Шифрование в этих блоках идёт по 96 байт. Информация об этих блоках записана в шифрованных файлах между {BLOCKSSTART}{BLOCKSEND}. Каждый такой блок описан тремя составляющими:
* номер блока — порядковый номер блока по 1024 байта, к-й зашифрован. т.е. шифрование этим типом начинается с 1024*номер_блока;
* видимо Количество зашифрованных байт;
* Массив из остатка зашифрованных байт, выходящий за рамки 1024 байта. Т.о. Количество зашифрованных байт всегда равно 1024 + длина остатка зашифрованных байт.
Кроме того, в тех файлах, что есть у меня первые 30000 байт зашифрованы вычитанием с периодом в 480 байт. Ключ для вычитания одинаков для всех файлов (900 штук). Кроме первых 767. Среди первых 767 байт ровно половина шифрована другим алгоритмом. Дельты индексы этих неправильно шифрованных байт повторяются с периодом 10. А сами возможные значения дельт между шифрованным байтом и оригинальным всегда принадлежит группе из 16 идущих подряд байт. Сами же группы тоже повторяются с периодом в 10 байт.
Итого, для каждого шифрованного файла их тех, что есть у меня я могу восстановить всё кроме 383 байт и иногда встречающихся 1024, к-е редко встречаются в заголовке.
Сейчас в IDA копаю дальше вирус, чтобы добить те 383 байта и попробовать добить блоки по 1024. Если получится — буду готовить материал на публикацию. Просто обычное вычитание не похоже на RSA.
1. Да, шифруются первые 30000 байт, но потом могут быть вкрапления по 1024 байта ещё какого-то шифрования. Эти же вкрапления могут быть и среди первых 1024. Шифрование в этих блоках идёт по 96 байт. Информация об этих блоках записана в шифрованных файлах между {BLOCKSSTART}{BLOCKSEND}. Каждый такой блок описан тремя составляющими:
* номер блока — порядковый номер блока по 1024 байта, к-й зашифрован. т.е. шифрование этим типом начинается с 1024*номер_блока;
* видимо Количество зашифрованных байт;
* Массив из остатка зашифрованных байт, выходящий за рамки 1024 байта. Т.о. Количество зашифрованных байт всегда равно 1024 + длина остатка зашифрованных байт.
Кроме того, в тех файлах, что есть у меня первые 30000 байт зашифрованы вычитанием с периодом в 480 байт. Ключ для вычитания одинаков для всех файлов (900 штук). Кроме первых 767. Среди первых 767 байт ровно половина шифрована другим алгоритмом. Дельты индексы этих неправильно шифрованных байт повторяются с периодом 10. А сами возможные значения дельт между шифрованным байтом и оригинальным всегда принадлежит группе из 16 идущих подряд байт. Сами же группы тоже повторяются с периодом в 10 байт.
Итого, для каждого шифрованного файла их тех, что есть у меня я могу восстановить всё кроме 383 байт и иногда встречающихся 1024, к-е редко встречаются в заголовке.
Сейчас в IDA копаю дальше вирус, чтобы добить те 383 байта и попробовать добить блоки по 1024. Если получится — буду готовить материал на публикацию. Просто обычное вычитание не похоже на RSA.
Вполне возможно, что мне просто повезло.
Я был не прав. Разобрал весь вирус в IDA и переписал его на C#. Да. Там простые арифметические функции для первых 30000 байт. Кроме того, после 1024 байта могут быть блоки по 1024 байта шифрованные RSA. Между BLOCKSSTART и BLOCKSEND записаны индекс блока, длина получившегося после RSA массива и собственно остаток от 1024 байта.
Шифрование математическими функциями может быть 10 видов. Какой тип использовать хранится в строке длиной 20, которая генерируется случайно один раз при запуске вируса. В качестве аргументов для математических функций используется массив из 30096 байт, Я назвал его specialBytes. Он генерируется так:
1. Генерится строка из 2048 символов: цифры, маленькие и большие латинские буквы. Одна для всех файлов.
2. Выбираются 512 случайных чисел от 1 до 2048 (они записываются в шифрованный файл в метаданные в открытом виде.)
3. Составляется строка из 512 символов. На i-ю позицию ставится символ из строки из п. 1, к-й в ней на позиции i-го числа из п. 2. Назовём её someStr.
То, что ниже повторяется до тех пор пока не набралось 30096 символов в specialBytes.
4. someStr хешируется MD5 (код один в один как по этой ссылке www.delphisources.ru/pages/faq/base/md5.html). Хэш добавляется в specialBytes.
5. к каждому байту someStr прибавляется 0x80. Опять генерится MD5 хэш от новой уже строки и добавляется в specialBytes.
6. К каждому байту someStr прибавляем предыдущий. Опять хешируем MD5 и прибавляем к specialBytes;
7. Каждый байт someStr умножаем на 2. Идём к пункту 4.
в specialBytes добавляется текстовое представление MD5 хэша. Т.е. от каждого хэша прибавляется по 32 байта. Т.е. за одну итерацию прибавляется 96 символов. После семи итераций someStr вырождается в ноль и потом уже идут всегда одинаковые хэши. Это объясняет почему у меня дельты были с периодом в 480 — НОК(96, 20) — между периодом повторений хэшей в specialBytes и длиной строки в которой описаны какие функции использовать. Также это объясняет почему первые 767 байт не подчинялись моей логике. Строка вырождается к 8-й итерации: 8*96 = 768.
Строка из п.1, строка описывающая типы мат. функций для шифрования и числа сгенерированные для RSA соединяются вместе через строку assHole и три раза шифруются RSA с уже известным только хакеру ключом. Потом записываются в каждый файл в начале метаданных.
В принципе, чтобы расшифровать первые 30000 байт в подавляющем большинстве файлов нужно иметь строку из п.1 и строку с мат. фукнциями. Второе получить легко, если имеется хотя бы один оригинальный файл. Как получить первое наверняка я пока не придумал. Есть варианты: либо перебор (64^2048 вариантов), либо нахождение p и q для RSA :-), либо попытаться установить такое же RandSeed, какое было в момент генерации этой строки. Все три варианта нерешаемы на обычных машинах за разумное время.
Если всё-таки интересно, могу написать статью как я в этом копался и как до всего этого дошёл. Но, увы, расшифровать невозможно.
З.Ы.: Вообще в коде вируса много смешных и забавных вещей, которые стоит показать.
Шифрование математическими функциями может быть 10 видов. Какой тип использовать хранится в строке длиной 20, которая генерируется случайно один раз при запуске вируса. В качестве аргументов для математических функций используется массив из 30096 байт, Я назвал его specialBytes. Он генерируется так:
1. Генерится строка из 2048 символов: цифры, маленькие и большие латинские буквы. Одна для всех файлов.
2. Выбираются 512 случайных чисел от 1 до 2048 (они записываются в шифрованный файл в метаданные в открытом виде.)
3. Составляется строка из 512 символов. На i-ю позицию ставится символ из строки из п. 1, к-й в ней на позиции i-го числа из п. 2. Назовём её someStr.
То, что ниже повторяется до тех пор пока не набралось 30096 символов в specialBytes.
4. someStr хешируется MD5 (код один в один как по этой ссылке www.delphisources.ru/pages/faq/base/md5.html). Хэш добавляется в specialBytes.
5. к каждому байту someStr прибавляется 0x80. Опять генерится MD5 хэш от новой уже строки и добавляется в specialBytes.
6. К каждому байту someStr прибавляем предыдущий. Опять хешируем MD5 и прибавляем к specialBytes;
7. Каждый байт someStr умножаем на 2. Идём к пункту 4.
в specialBytes добавляется текстовое представление MD5 хэша. Т.е. от каждого хэша прибавляется по 32 байта. Т.е. за одну итерацию прибавляется 96 символов. После семи итераций someStr вырождается в ноль и потом уже идут всегда одинаковые хэши. Это объясняет почему у меня дельты были с периодом в 480 — НОК(96, 20) — между периодом повторений хэшей в specialBytes и длиной строки в которой описаны какие функции использовать. Также это объясняет почему первые 767 байт не подчинялись моей логике. Строка вырождается к 8-й итерации: 8*96 = 768.
Строка из п.1, строка описывающая типы мат. функций для шифрования и числа сгенерированные для RSA соединяются вместе через строку assHole и три раза шифруются RSA с уже известным только хакеру ключом. Потом записываются в каждый файл в начале метаданных.
В принципе, чтобы расшифровать первые 30000 байт в подавляющем большинстве файлов нужно иметь строку из п.1 и строку с мат. фукнциями. Второе получить легко, если имеется хотя бы один оригинальный файл. Как получить первое наверняка я пока не придумал. Есть варианты: либо перебор (64^2048 вариантов), либо нахождение p и q для RSA :-), либо попытаться установить такое же RandSeed, какое было в момент генерации этой строки. Все три варианта нерешаемы на обычных машинах за разумное время.
Если всё-таки интересно, могу написать статью как я в этом копался и как до всего этого дошёл. Но, увы, расшифровать невозможно.
З.Ы.: Вообще в коде вируса много смешных и забавных вещей, которые стоит показать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программа-криптовымогатель шифрует пользовательские файлы в «оффлайне»