В конце рабочего дня бухгалтер одного из предприятий получила письмо по электронной почте от контрагента, с которым постоянно велась деловая переписка, письмо, в котором содержался вложенный файл, именуемый, как «Акт сверки.xls». При попытке открытия визуально ничего не произошло с точки зрения бухгалтера. Несколько раз повторив попытки открытия бухгалтер удостоверилась, что excel не собирается открывать присланный файл. Отписавшись контрагенту о невозможности открыть полученный ею файл, бухгалтер, нажала кнопку выключения ПК, и, не дождавшись завершения работы ПК, покинула рабочее место. Придя утром, обнаружила, что компьютер так и не отключился. Не придав этому особого значения, попыталась начать новый рабочий день, привычно кликнув по ярлыку 1С Бухгалтерии, но после выбора базы ожидал неприятный сюрприз.
рис. 1
Последующие попытки запуска рабочей среды 1С также не увенчались успехом. Бухгалтер связалась с компанией, обслуживающей вычислительную технику их организации, и запросила техническую поддержку. Специалистами обслуживающей организации выяснено, что проблемы куда более масштабные, так как кроме того что файлы базы 1С Бухгалтерии 7.7 были зашифрованы и имели расширение “BLOCKED“, зашифрованными оказались и файлы с расширениями doc, docx, xls, xlsx, zip, rar, 1cd и другие. Также обнаруживался текстовый файл на рабочем столе пользователя, в котором сообщалось, что файлы зашифрованы с использованием алгоритма RSA 2048, и что для получения дешифратора необходимо оплатить услуги вымогателя. Резервное копировании 1С баз осуществлялось ежедневно на другой жесткий диск установленный в этом же ПК в виде создания zip архива с папкой 1С баз, и копия архива помещалась на сетевой диск (NAS). Так как ограничения доступа к резервным копиям не было, то вредоносное программное обеспечение имело доступ и к ним.
Оценив масштаб проблемы, специалисты обслуживающей организации выполнили копирование только шифрованных файлов на отдельный накопитель и произвели переустановку операционной системы. Также из почтового ящика бухгалтера были удалены письма, содержащие вредоносное ПО. Попытки расшифровки с использованием популярных дешифраторов антивирусных компаний на тот момент результата не дали. На этом обслуживающая организацию компания закончила свои работы.
Перспективы начать с ввода первичной документации в новую 1С базу, не сильно радовали бухгалтеров. Посему были рассмотрены дальнейшие возможности восстановления шифрованных файлов.
К сожалению, не были сохранены оригинальное тело вредоносного ПО и сообщение вымогателя, что не позволило дизассемблировать тело и установить алгоритм его работы посредством анализа в отладчике. Так же не было возможности проверить, встречался ли он различным антивирусным компаниям.
Поэтому сразу приступаем к анализу файлов, структуры которых хорошо известны. В данном случае удобно использовать для анализа DBF файлы из базы 1С, так как структура их весьма предсказуема. Возьмем файл 1SENTRY.DBF.BLOCKED (журнал бухгалтерских проводок), размер данного файла 53 044 658 байт
рис. 2
Рассматривая шифрованный DBF файл, обращаем внимание на то, что первые 0x35 байт не зашифрованы, так как присутствует заголовок, характерный для данного типа файлов, и наблюдаем часть описания первого поля записи. Произведем расчет размера файла. Для этого возьмем: WORD по смещению 0x08, содержимое которого равно 0x04C1 (в нем указан размер заголовка DBF файла), WORD по смещению 0x0A, содержимое которого равно 0x0130 (в нем указан размер одной записи в базе), DWORD по смещению 0x04, содержимое которого равно 0x0002A995 (количество записей), и 0x01 – размер конечного маркера. Решим пример: 0x0130*0x0002A995+0x04C1+1=0x0032965B2 (53 044 658) байт. Размер файла, согласно записи файловой системы, соответствует расчетному на основании информации в заголовке DBF файла. Выполним аналогичные проверки для нескольких DBF файлов и удостоверимся, что размер файла не был изменен вредоносным ПО.
Анализ содержимого DBF показывает, что небольшие файлы начиная со смещения 0x35 зашифрованы целиком, а крупные нет.
рис. 3
Номера счетов, даты и суммы изменены, чтобы не нарушать соглашения о конфиденциальности в том числе и в зашифрованном участке.
Начиная со смещения 0x00132CB5 обнаруживаем отсутствие признаков шифрования до конца файла, выполнив проверки в иных крупных файлах подтверждаем предположение, что целиком шифруются только файлы менее 0x00132CB5 (1 256 629) байт. Многие авторы вредоносного ПО выполняют частичное шифрование файлов с целью сокращения времени искажения пользовательских данных. Руководствуются вероятно тем, чтобы их вредоносный код за минимальное время нанес максимально возможный ущерб пользователю.
Приступим к анализу алгоритма шифрования
рис. 4
На рис. 4 на месте заголовков полей DBF файла присутствуют почти одинаковые последовательности из 16 байт (смещения 0x50, 0x70, 0x90), также видим частичное повторение последовательностей из 16 байт (смещения 0x40,0x60,0x80), в которых есть отличия только в байтах, где должно прописываться имя поля и тип поля.
На основании этого наблюдения, имея небольшое представление об алгоритмах работы криптографических алгоритмов вроде AES, RSA, можно сделать однозначный вывод, что данные не шифрованы с использованием этих алгоритмов. То есть, информация об алгоритме шифрования, поданная заказчиком, недостоверна. Недостоверной она может быть как из-за неких ошибочных выводов заказчика, так и являться следствием обмана автором вредоносной программы. Проверить это мы не можем, так как нам доступны только зашифрованные файлы.
Исходя из особенностей строения заголовков DBF файлов и изменений байт в последовательностях, можно сделать предположение, что шифрование выполнено посредством XOR операции над данными с неким паттерном. Также можно сделать предположение, исходя из длины повторяющихся последовательностей, что длина паттерна 16 байт (128 бит). Заголовок базы равен 0x04C1 байт, размер описания одного поля в заголовке 0х20 (32) байт. Из этого следует, что заголовок данного DBF файла содержит (0x4C1-0x21)/0x20=0x25 (37) описаний полей. На рис. 4 подчеркнуты красным фрагменты записей двух полей начиная со смещения 0x10, которые в случае 1С как правило имеют нулевые значения, кроме самого 0x10 (так как по этому смещению указывается размер поля), на основании этого можно полагать, что уже имеем 15 из 16 байт ключа шифрования 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.
Для нахождения последнего байта в ключе возьмем другой фрагмент этого же DBF файла.
рис. 5
На рисунке 5 обратим внимание на нулевой столбец, точнее на его нешифрованную часть, и видим, что там преобладает значение 0x20 (код пробела согласно ASCII таблицы). Соответственно, и в шифрованной части столбца будет преобладать некое одинаковое значение. Легко заметить, что это 0xFA. Для получения оригинального значения недостающего байта ключа необходимо выполнить 0xFA xor 0x20=0xDA.
Подставив полученное значение на недостающую позицию, получим полный ключ 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.
После выполнения процедуры xor операции с полученным ключом над шифрованными участками получили оригинальное содержимое файла
рис. 6
Для окончательного контроля проведем операцию расшифровки zip архива, затем распакуем архив. Если все файлы извлеклись и не возникало ошибки CRC для какого-либо файла, то можно окончательно подтвердить корректность ключа. И финальным этапом будет распаковка остальных файлов согласно технического задания.
Данный пример говорит о том, что вероятно не все высказывания авторов вредоносного программного обеспечения правдивы. И нередко можно решить задачу восстановления пользовательских данных посредством анализа измененных данных.
Наряду с подобными простыми случаями встречаются трояны-шифровальщики, которые действительно будут использовать современные криптографические алгоритмы и в случае их атаки подобное простое решение в принципе невозможно. Посему будьте предельно осторожны при открытии любых файлов, полученных по электронной почте даже от доверенных источников. Регулярно обновляйте антивирусное ПО и делайте резервное копирование таким образом, чтобы ваши данные во всех копиях не были доступны кому-либо единовременно.
рис. 1
Последующие попытки запуска рабочей среды 1С также не увенчались успехом. Бухгалтер связалась с компанией, обслуживающей вычислительную технику их организации, и запросила техническую поддержку. Специалистами обслуживающей организации выяснено, что проблемы куда более масштабные, так как кроме того что файлы базы 1С Бухгалтерии 7.7 были зашифрованы и имели расширение “BLOCKED“, зашифрованными оказались и файлы с расширениями doc, docx, xls, xlsx, zip, rar, 1cd и другие. Также обнаруживался текстовый файл на рабочем столе пользователя, в котором сообщалось, что файлы зашифрованы с использованием алгоритма RSA 2048, и что для получения дешифратора необходимо оплатить услуги вымогателя. Резервное копировании 1С баз осуществлялось ежедневно на другой жесткий диск установленный в этом же ПК в виде создания zip архива с папкой 1С баз, и копия архива помещалась на сетевой диск (NAS). Так как ограничения доступа к резервным копиям не было, то вредоносное программное обеспечение имело доступ и к ним.
Оценив масштаб проблемы, специалисты обслуживающей организации выполнили копирование только шифрованных файлов на отдельный накопитель и произвели переустановку операционной системы. Также из почтового ящика бухгалтера были удалены письма, содержащие вредоносное ПО. Попытки расшифровки с использованием популярных дешифраторов антивирусных компаний на тот момент результата не дали. На этом обслуживающая организацию компания закончила свои работы.
Перспективы начать с ввода первичной документации в новую 1С базу, не сильно радовали бухгалтеров. Посему были рассмотрены дальнейшие возможности восстановления шифрованных файлов.
К сожалению, не были сохранены оригинальное тело вредоносного ПО и сообщение вымогателя, что не позволило дизассемблировать тело и установить алгоритм его работы посредством анализа в отладчике. Так же не было возможности проверить, встречался ли он различным антивирусным компаниям.
Поэтому сразу приступаем к анализу файлов, структуры которых хорошо известны. В данном случае удобно использовать для анализа DBF файлы из базы 1С, так как структура их весьма предсказуема. Возьмем файл 1SENTRY.DBF.BLOCKED (журнал бухгалтерских проводок), размер данного файла 53 044 658 байт
рис. 2
Рассматривая шифрованный DBF файл, обращаем внимание на то, что первые 0x35 байт не зашифрованы, так как присутствует заголовок, характерный для данного типа файлов, и наблюдаем часть описания первого поля записи. Произведем расчет размера файла. Для этого возьмем: WORD по смещению 0x08, содержимое которого равно 0x04C1 (в нем указан размер заголовка DBF файла), WORD по смещению 0x0A, содержимое которого равно 0x0130 (в нем указан размер одной записи в базе), DWORD по смещению 0x04, содержимое которого равно 0x0002A995 (количество записей), и 0x01 – размер конечного маркера. Решим пример: 0x0130*0x0002A995+0x04C1+1=0x0032965B2 (53 044 658) байт. Размер файла, согласно записи файловой системы, соответствует расчетному на основании информации в заголовке DBF файла. Выполним аналогичные проверки для нескольких DBF файлов и удостоверимся, что размер файла не был изменен вредоносным ПО.
Анализ содержимого DBF показывает, что небольшие файлы начиная со смещения 0x35 зашифрованы целиком, а крупные нет.
рис. 3
Номера счетов, даты и суммы изменены, чтобы не нарушать соглашения о конфиденциальности в том числе и в зашифрованном участке.
Начиная со смещения 0x00132CB5 обнаруживаем отсутствие признаков шифрования до конца файла, выполнив проверки в иных крупных файлах подтверждаем предположение, что целиком шифруются только файлы менее 0x00132CB5 (1 256 629) байт. Многие авторы вредоносного ПО выполняют частичное шифрование файлов с целью сокращения времени искажения пользовательских данных. Руководствуются вероятно тем, чтобы их вредоносный код за минимальное время нанес максимально возможный ущерб пользователю.
Приступим к анализу алгоритма шифрования
рис. 4
На рис. 4 на месте заголовков полей DBF файла присутствуют почти одинаковые последовательности из 16 байт (смещения 0x50, 0x70, 0x90), также видим частичное повторение последовательностей из 16 байт (смещения 0x40,0x60,0x80), в которых есть отличия только в байтах, где должно прописываться имя поля и тип поля.
На основании этого наблюдения, имея небольшое представление об алгоритмах работы криптографических алгоритмов вроде AES, RSA, можно сделать однозначный вывод, что данные не шифрованы с использованием этих алгоритмов. То есть, информация об алгоритме шифрования, поданная заказчиком, недостоверна. Недостоверной она может быть как из-за неких ошибочных выводов заказчика, так и являться следствием обмана автором вредоносной программы. Проверить это мы не можем, так как нам доступны только зашифрованные файлы.
Исходя из особенностей строения заголовков DBF файлов и изменений байт в последовательностях, можно сделать предположение, что шифрование выполнено посредством XOR операции над данными с неким паттерном. Также можно сделать предположение, исходя из длины повторяющихся последовательностей, что длина паттерна 16 байт (128 бит). Заголовок базы равен 0x04C1 байт, размер описания одного поля в заголовке 0х20 (32) байт. Из этого следует, что заголовок данного DBF файла содержит (0x4C1-0x21)/0x20=0x25 (37) описаний полей. На рис. 4 подчеркнуты красным фрагменты записей двух полей начиная со смещения 0x10, которые в случае 1С как правило имеют нулевые значения, кроме самого 0x10 (так как по этому смещению указывается размер поля), на основании этого можно полагать, что уже имеем 15 из 16 байт ключа шифрования 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.
Для нахождения последнего байта в ключе возьмем другой фрагмент этого же DBF файла.
рис. 5
На рисунке 5 обратим внимание на нулевой столбец, точнее на его нешифрованную часть, и видим, что там преобладает значение 0x20 (код пробела согласно ASCII таблицы). Соответственно, и в шифрованной части столбца будет преобладать некое одинаковое значение. Легко заметить, что это 0xFA. Для получения оригинального значения недостающего байта ключа необходимо выполнить 0xFA xor 0x20=0xDA.
Подставив полученное значение на недостающую позицию, получим полный ключ 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.
После выполнения процедуры xor операции с полученным ключом над шифрованными участками получили оригинальное содержимое файла
рис. 6
Для окончательного контроля проведем операцию расшифровки zip архива, затем распакуем архив. Если все файлы извлеклись и не возникало ошибки CRC для какого-либо файла, то можно окончательно подтвердить корректность ключа. И финальным этапом будет распаковка остальных файлов согласно технического задания.
Данный пример говорит о том, что вероятно не все высказывания авторов вредоносного программного обеспечения правдивы. И нередко можно решить задачу восстановления пользовательских данных посредством анализа измененных данных.
Наряду с подобными простыми случаями встречаются трояны-шифровальщики, которые действительно будут использовать современные криптографические алгоритмы и в случае их атаки подобное простое решение в принципе невозможно. Посему будьте предельно осторожны при открытии любых файлов, полученных по электронной почте даже от доверенных источников. Регулярно обновляйте антивирусное ПО и делайте резервное копирование таким образом, чтобы ваши данные во всех копиях не были доступны кому-либо единовременно.
Комментариев нет:
Отправить комментарий