Разного рода ransomware, программ-криптовымогателей развелось сейчас довольно много. Некоторые просто блокируют ПК, пока пользователь не заплатит. Иные разновидности такого ПО шифруют файлы, отправляя ключ на сервер, контролируемый мошенниками. Но есть и другие виды криптовымогателей, которые действуют еще более оригинально.

Исследователи из компании Check Point недавно провели анализ работы одной из разновидностей такого рода программ, которая использует альтернативный метод шифрования файлов и предоставления ключа своим создателям. Сама программа — не новая, впервые ее заметили в июне прошлого года. С тех пор автор неоднократно обновлял свое творение (примерно раз в два месяца), криптовымогатель постоянно эволюционирует и совершенствуется. По мнению специалистов по информационной безопасности, этот образец был создан русскоязычными злоумышленниками, и работает это ПО, как правило, с пользователями из России.

При загрузке на ПК жертвы это ПО шифрует все файлы пользователя, одновременно их переименовывая. Новые имена даются по маске:

email-[address to contact].ver-[Ransomware internal version].id-[Machine identifier]-[Date & Time][Random digits].randomname-[Random name given to the encrypted file].cbf (пример: email-Seven_Legion2@aol.com.ver-CL 1.0.0.0.id-NPEULAODSHUJYMAPESHVKYNBQETHWKZOBQFT-10@6@2015 9@53@19AM5109895.randomname-EFWMERGVKYNBPETHVKZNBQETHWKZNB.RGV.cbf).

При этом данные на сервер злоумышленников не передаются, никакая информация ПО и не принимается (вроде ключа шифрования).

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

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

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

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

По словам специалистов, изучивших ПО, заплатить — единственный способ получить свои данные обратно в данном случае (если у вас нет бекапа).

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

Комментарии (25)


  1. zagayevskiy
    06.11.2015 14:27
    -5

    Поэтому всё важное надо хранить в облаке.


    1. Zibx
      06.11.2015 14:43
      -1

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


      1. zagayevskiy
        06.11.2015 14:47

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


    1. AMDmi3
      06.11.2015 14:45
      +12

      Когда-нибудь целое облако так зашифруют, тогда посмеёмся.


    1. ayakovlev
      06.11.2015 16:23
      +3

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


      1. alexsupra
        08.11.2015 13:34
        +4

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


  1. Sild
    06.11.2015 14:33
    +5

    «Расшифровать файлы без соответствующего ключа нереально. Требуемое время брутфорса, с использованием целой сети мощных ПК — около двух лет.»

    Ох, теперь уже 2 года — нереально. Раньше нереальными считались столетия.


    1. BiTHacK
      06.11.2015 15:12

      Факторизация и подразумевает получение «соответствующего ключа». Суть анализа была в том, что ошибки в реализации нету и данные без ключа не расшифровать. Почему используется столь короткий RSA ключ — загадка, экономия и по объёму данных, и по времени шифрования не сильные.


      1. Sild
        06.11.2015 15:43
        -1

        Факторизация подразумевает получение ключа, который даёт коллизию на некоторой функции. Это вовсе не обязательно «соответствующий ключ». Фраза «расшифровать файлы без соответствующего ключа нереально» — предполагает недетерменированное (или детерменированное на _ОЧЕНЬ_ большом временном отрезке) вычисления ключа, дающего коллизию.


        1. BiTHacK
          06.11.2015 15:58
          +3

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


          1. Sild
            06.11.2015 16:00
            +1

            Извините, попутал с банальным хешем.


    1. dom1n1k
      06.11.2015 16:56
      -2

      А если с терморектальным катализатором?


      1. Raegdan
        07.11.2015 11:44

        Сможете отыскать автора вируса физически? Тогда конечно, криптоанализатор вам в руки, вам все будут очень благодарны. А в реальности их даже Интерпол найти не может.


        1. NYBR
          07.11.2015 14:15

          видимо просто не пытается, так как реально денежный — то след всяко есть


  1. timsoid
    06.11.2015 15:06
    -1

    эпидемия началась какая то.За неделю 2 пк словили уже.

    Сейчас массово предупреждаем всех бухов что бы не открывали непонятные письма.
    Они маскируется типа «На вас заведено уголовное дело, срочно прочтите». Бух открыла, никакого текста не увидела, потом полезла с телефона открывать это письмо…


    1. susnake
      06.11.2015 19:13
      -1

      Такая же фигня была в январе этого года. Только-только начал внедрять систему резервного копирования, как продажники схватили криптолокер в архиве.
      Я еще хочу в эксчейндже поставить запрет на прием всяких архивов типа *.zip и *.rar.


      1. Scf
        06.11.2015 21:30
        -1

        Зря — многие обмениваются файлами через почту.


        1. susnake
          06.11.2015 22:13

          Да, но, а что еще можно придумать?

          • бэкапы помогут только восстановить зашифрованные файлы.
          • Антивирус не всегда детектит.
          • Запрет на запуск файлов не всегда помогает, т.к. приходят всякие скрипты, вирусы с расширениями от скринсевов и UAC не ругается даже.
          • Говорят, что шифровщики удаляются после перезагрузки раб.станции, но вот тут хз. Сегодня удаляются, а завтра свое тело по всей сети рассылают или деактивируются на время, а потом опять шифровать начинают.
          • На почту поставить запрет на прием архивов. Вот тут смотреть нужно, т.к. есть организации у которых ограничение на отправку вложения или если кроме одиночных файлов еще и какие-то каталоги отправляют.


          1. xolod79
            07.11.2015 00:40
            -2

            Рекомедую поставить Антитвирус на почтовый север который умеет инспектить все известные арихивы (напимер: 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


            1. susnake
              07.11.2015 12:00
              -2

              Спасибо. Нужно будет посмотреть. У нас уже SEP от них стоит.


            1. xolod79
              07.11.2015 12:35
              -2

              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


  1. T-D-K
    07.11.2015 10:03
    +6

    Вот у меня сейчас на руках 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. T-D-K
      07.11.2015 10:12

      Вполне возможно, что мне просто повезло.


    1. T-D-K
      11.11.2015 00:35
      +2

      Я был не прав. Разобрал весь вирус в 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, какое было в момент генерации этой строки. Все три варианта нерешаемы на обычных машинах за разумное время.
      Если всё-таки интересно, могу написать статью как я в этом копался и как до всего этого дошёл. Но, увы, расшифровать невозможно.
      З.Ы.: Вообще в коде вируса много смешных и забавных вещей, которые стоит показать.


      1. zagayevskiy
        11.11.2015 12:49
        +1

        Пишите уже :-)