Вирус-вымогатель LockFile обходит защиту с помощью частичного шифрования файлов
Новое семейство программ-вымогателей, появившееся в прошлом месяце, использует собственный набор приемов для обхода защиты с помощью новейшей техники «прерывистого шифрования».
Операторы вируса, получившего название LockFile, были замечены в эксплуатации недавно обнаруженных уязвимостей ProxyShell и PetitPotam с целью развертывании на серверах Windows шифрующего файлы вредоноса. Этот вирус использует особый алгоритм шифрования, скремблируя не весь файл, а только чередующие секции по 16 байтов, что дает ему возможность обходить системы защиты.
«Частичное шифрование обычно используется операторами вирусов-вымогателей для ускорения скремблирования и уже применяется группировками BlackMatter, DarkSide и LockBit 2.0, — сообщил Марк Ломан, директор инженерного департамента компании Sophos. – LockFile же выделяется среди них тем, что этот вирус не трогает первые несколько блоков документа, а шифрует последующие перемежающиеся отрезки из 16 байтов.
То есть, к примеру, текстовый документ остается частично читаемым и статистически выглядит как оригинал. Такой трюк позволяет успешно обманывать программы защиты, которые определяют наличие шифрования, используя статистический криптоанализ документов». – добавил он.
Заключение Sophos относительно LockFile строится на основе анализа артефакта, загруженного на VirusTotal 22 августа 2021 года.
После внедрения вредонос, используя интерфейс управления Windows (WMI), предпринимает шаги для завершения ключевых процессов, связанных с программами виртуализации и базами данных, после чего переходит к шифрованию основных файлов и объектов, отображая в итоге уведомление, стилистически схожее с используемым в LockBit 2.0.
Это уведомление также призывает связаться с определенным адресом электронной почты, contact@contipauper.com, что, по мнению специалистов Sophos, может быть пренебрежительным жестом в адрес конкурирующей группировки вымогателей Conti.
Более того, после успешного шифрования всех документов на устройстве вирус удаляет себя из системы, «не оставляя исполняемого файла, который бы могла обнаружить/очистить группа реагирования или антивирусное ПО».
«Для противодействующей стороны это все означает, что сфера киберугроз не стоит на месте, и злоумышленники готовы быстро воспользоваться любой представившейся уязвимостью или инструментом для проведения успешной атаки», — сказал Ломан.
Информация была обнародована в виде оперативного отчета ФБР США, раскрывающего подробности тактики новой группировки Hive, предлагающей ПО для виртуального вымогательства (RaaS). Эта группа состоит из нескольких операторов, использующих различные механизмы для взлома бизнес-сетей, кражи или шифрования их данных, после чего пытается получить выкуп в обмен на доступ к программе для дешифровки.
Расширение файла LCK
Program Lock Format
Что такое файл LCK?
Программы, которые поддерживают LCK расширение файла
Следующий список содержит программы, сгруппированные по 3 операционным системам, которые поддерживают LCK файлы. Файлы с суффиксом LCK могут быть скопированы на любое мобильное устройство или системную платформу, но может быть невозможно открыть их должным образом в целевой системе.
Программы, обслуживающие файл LCK
Как открыть файл LCK?
Проблемы с доступом к LCK могут быть вызваны разными причинами. К счастью, наиболее распространенные проблемы с файлами LCK могут быть решены без глубоких знаний в области ИТ, а главное, за считанные минуты. Ниже приведен список рекомендаций, которые помогут вам выявить и решить проблемы, связанные с файлами.
Шаг 1. Получить Referenced by various applications
Проблемы с открытием и работой с файлами LCK, скорее всего, связаны с отсутствием надлежащего программного обеспечения, совместимого с файлами LCK на вашем компьютере. Эта проблема может быть решена путем загрузки и установки # РЕКОМЕНДОВАННОЙ # или другой совместимой программы, такой как Microsoft FrontPage, Adobe PageMaker, Pegasus Mail. Полный список программ, сгруппированных по операционным системам, можно найти выше. Если вы хотите загрузить установщик Referenced by various applications наиболее безопасным способом, мы рекомендуем вам посетить сайт и загрузить его из официальных репозиториев.
Шаг 2. Обновите Referenced by various applications до последней версии
Вы по-прежнему не можете получить доступ к файлам LCK, хотя Referenced by various applications установлен в вашей системе? Убедитесь, что программное обеспечение обновлено. Разработчики программного обеспечения могут реализовать поддержку более современных форматов файлов в обновленных версиях своих продуктов. Причиной того, что Referenced by various applications не может обрабатывать файлы с LCK, может быть то, что программное обеспечение устарело. Самая последняя версия Referenced by various applications обратно совместима и может работать с форматами файлов, поддерживаемыми более старыми версиями программного обеспечения.
Шаг 3. Назначьте Referenced by various applications для LCK файлов
После установки Referenced by various applications (самой последней версии) убедитесь, что он установлен в качестве приложения по умолчанию для открытия LCK файлов. Следующий шаг не должен создавать проблем. Процедура проста и в значительной степени не зависит от системы
Изменить приложение по умолчанию в Windows
Изменить приложение по умолчанию в Mac OS
Шаг 4. Убедитесь, что LCK не неисправен
Вы внимательно следили за шагами, перечисленными в пунктах 1-3, но проблема все еще присутствует? Вы должны проверить, является ли файл правильным LCK файлом. Отсутствие доступа к файлу может быть связано с различными проблемами.
1. Проверьте LCK файл на наличие вирусов или вредоносных программ.
Если случится так, что LCK инфицирован вирусом, это может быть причиной, которая мешает вам получить к нему доступ. Рекомендуется как можно скорее сканировать систему на наличие вирусов и вредоносных программ или использовать онлайн-антивирусный сканер. Если файл LCK действительно заражен, следуйте инструкциям ниже.
2. Проверьте, не поврежден ли файл
Вы получили LCK файл от другого человека? Попросите его / ее отправить еще раз. Возможно, что файл не был должным образом скопирован в хранилище данных и является неполным и поэтому не может быть открыт. При загрузке файла с расширением LCK из Интернета может произойти ошибка, приводящая к неполному файлу. Попробуйте загрузить файл еще раз.
3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.
Существует вероятность того, что данный файл может быть доступен только пользователям с достаточными системными привилегиями. Выйдите из своей текущей учетной записи и войдите в учетную запись с достаточными правами доступа. Затем откройте файл Program Lock Format.
4. Проверьте, может ли ваша система обрабатывать Referenced by various applications
Если в системе недостаточно ресурсов для открытия файлов LCK, попробуйте закрыть все запущенные в данный момент приложения и повторите попытку.
5. Убедитесь, что ваша операционная система и драйверы обновлены
Современная система и драйверы не только делают ваш компьютер более безопасным, но также могут решить проблемы с файлом Program Lock Format. Возможно, файлы LCK работают правильно с обновленным программным обеспечением, которое устраняет некоторые системные ошибки.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла LCK мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле LCK.
Node.js-проекты, в которых лучше не использовать lock-файлы
Автор материала, перевод которого мы сегодня публикуем, говорит, что одна из проблем, с которыми приходится сталкиваться программистам, заключается в том, что у них их код работает, а у кого-то другого выдаёт ошибки. Эта проблема, возможно, одна из самых распространённых, возникает из-за того, что в системах создателя и пользователя программы установлены разные зависимости, которые использует программа. Для борьбы с этим явлением в менеджерах пакетов yarn и npm существуют так называемые lock-файлы. Они содержат сведения о точных версиях зависимостей. Механизм это полезный, но если некто занимается разработкой пакета, который планируется опубликовать в npm, lock-файлы ему лучше не использовать. Этот материал посвящён рассказу о том, почему это так.
Самое главное в двух словах
Lock-файлы крайне полезны при разработке Node.js-приложений вроде веб-серверов. Однако если речь идёт о создании библиотеки или инструмента командной строки с прицелом на публикацию в npm, то нужно знать о том, что lock-файлы в npm не публикуются. Это означает, что если при разработке применяются эти файлы, то у создателя npm-пакета, и у тех, кто этот пакет использует, будут задействованы разные версии зависимостей.
Что такое lock-файл?
Оба эти файла содержат некоторые крайне важные сведения о зависимостях:
Сравнение package.json и lock-файлов
Цель поля dependencies файла package.json заключается в том, чтобы показать зависимости проекта, которые должны быть установлены для его правильной работы. Но сюда не входят сведения о зависимостях этих зависимостей. В сведения о зависимостях могут входить точные версии пакетов или некий диапазон версий, указанный в соответствии с правилами семантического версионирования. При использовании диапазона npm или yarn выбирают наиболее подходящую версию пакета.
Если посмотреть документацию npm по семантическому версионированию, то можно узнать, что значок ^ указывает на то, что подходящей является любая версия пакета, номер которой больше или равен 3.30.3 и меньше 4.0.0. В результате, если в проекте нет lock-файла и выйдет новая версия пакета, то команда npm install или yarn install автоматически установит эту новую версию пакета. Сведения в package.json при этом обновляться не будут. При использовании lock-файлов всё выглядит иначе.
Это крайне полезно в том случае, если вы занимаетесь разработкой проекта наподобие веб-приложения или сервера, так как в CI-окружении нужно сымитировать поведение пользователя. В результате, если мы будем включать lock-файл в репозиторий проекта (например, созданный средствами git), мы можем быть уверенными в том, что каждый разработчик, каждый сервер, каждая система сборки кода и каждое CI-окружение используют одни и те же версии зависимостей.
Почему бы не сделать то же самое при публикации библиотек или других программных инструментов в реестре npm? Нам, прежде чем ответить на этот вопрос, нужно поговорить о том, как устроен процесс публикации пакетов.
Процесс публикации пакетов
В результате получается, что если кто-нибудь устанавливает чей-нибудь пакет, файл package-lock.json в этом участвовать не будет. То, что имеется в этом файле, который есть у разработчика пакета, не будет учитываться при установке пакета кем-то другим.
Это может, по несчастливой случайности, привести к проблеме, о которой мы говорили в самом начале. В системе разработчика код работает нормально, а в других системах выдаёт ошибки. А дело тут в том, что разработчик проекта и те, кто проектом пользуются, применяют разные версии пакетов. Как это исправить?
Отказ от lock-файлов и использование технологии shrinkwrap
Для того чтобы автоматизировать эту операцию, команду npm shrinkwrap можно добавить в раздел описания скриптов файла package.json в виде prepack-скрипта. Того же эффекта можно добиться, используя хук git commit. В результате вы сможете быть уверены в том, что в вашем окружении разработки, в вашей CI-системе, и у пользователей вашего проекта используются одни и те же зависимости.
Стоит отметить, что этой методикой рекомендуется пользоваться ответственно. Создавая shrinkwrap-файлы, вы фиксируете конкретные версии зависимостей. С одной стороны это полезно для обеспечения стабильной работы проекта, с другой — это может помешать пользователям в установке критически важных патчей, что, в противном случае, делалось бы автоматически. На самом деле, npm настоятельно рекомендует не использовать shrinkwrap-файлы при разработке библиотек, ограничив их применение чем-то вроде CI-систем.
Выяснение сведений о пакетах и зависимостях
Вот несколько подобных команд:
Итоги
Многое из того, о чём мы тут говорили, полагается на особенности выполнения различных операций средствами npm. Речь идёт об упаковке, публикации, установке пакетов, о работе с зависимостями. А если учесть то, что npm постоянно развивается, можно сказать, что всё это в будущем может измениться. Кроме того, возможность практического применения приведённых здесь рекомендаций зависит от того, как разработчик пакета воспринимает проблему использования различных версий зависимостей в разных средах.
LockFile function (fileapi.h)
Locks the specified file for exclusive access by the calling process.
To specify additional options, for example creating a shared lock or for block-on-fail operation, use the LockFileEx function.
Syntax
Parameters
A handle to the file. The file handle must have been created with the GENERIC_READ or GENERIC_WRITE access right. For more information, see File Security and Access Rights.
The low-order 32 bits of the starting byte offset in the file where the lock should begin.
The high-order 32 bits of the starting byte offset in the file where the lock should begin.
The low-order 32 bits of the length of the byte range to be locked.
The high-order 32 bits of the length of the byte range to be locked.
Return value
If the function succeeds, the return value is nonzero (TRUE).
If the function fails, the return value is zero (FALSE). To get extended error information, call GetLastError.
Remarks
If the call to LockFile completes synchronously, a completion entry may not be queued when a completion port is associated with the file handle.
The UnlockFile function unlocks a file region locked by LockFile.
Locking a region of a file gives the threads of the locking process exclusive access to the specified region using this file handle. If the file handle is inherited by a process created by the locking process, the child process is not granted access to the locked region. If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region.
Locking a region of a file does not prevent reading or writing from a mapped file view.
You can lock bytes that are beyond the end of the current file. This is useful to coordinate adding records to the end of a file.
Exclusive locks cannot overlap an existing locked region of a file. For more information, see LockFileEx.
If LockFile cannot lock a region of a file, it returns zero immediately. It does not block. To issue a file lock request that will block until the lock is acquired, use LockFileEx without the LOCKFILE_FAIL_IMMEDIATELY flag.
If a process terminates with a portion of a file locked or closes a file that has outstanding locks, the locks are unlocked by the operating system. However, the time it takes for the operating system to unlock these locks depends upon available system resources. Therefore, it is recommended that your process explicitly unlock all files it has locked when it terminates. If this is not done, access to these files may be denied if the operating system has not yet unlocked them.
In WindowsВ 8 and Windows ServerВ 2012, this function is supported by the following technologies.
Lock-файлы npm
Всем привет! В прошлом посте мы рассмотрели экосистему npm в качестве источника хаоса в нашем проекте, и научились с умом подходить к выбору зависимостей, чтобы минимизировать наши риски. Сегодня мы пойдем дальше и рассмотрим lock-файлы npm, которые помогают повысить стабильность проекта в процессе работы над ним.
Когда манифеста мало
Также разные версии npm могут иметь различные алгоритмы установки зависимостей, и структура файлов будет отличаться.
Вы помните, что список зависимостей в манифесте проекта содержит диапазон версий semver, что позволяет обновлять зависимости? Получается, что установка зависимостей в разное время будет приводить к разным результатам, потому что содержимое npm registry постоянно меняется, регулярно выходят новые пакеты. Кроме того, поскольку мы имеем дело с деревом зависимостей, то транзитивные зависимости (зависимости ваших зависимостей) тоже будут меняться во времени.
А еще может возникнуть ситуация, когда содержимое пакета, лежащего в npm registry, было заменено без обновления версии. Это называется мутацией пакетов и запрещено в официальном npm registry, однако в частных реестрах вполне возможно. А что, если содержимое пакета было заменено злоумышленником, чтобы внести в код какие-то закладки?
Учитывая все эти факторы, становится очевидно, что структура данных в директории node_modules очень нестабильна и может меняться во времени, даже если ваш манифест при этом остается нетронутым.
Наивно было бы попытаться зафиксировать зависимости, прописывая строгие версии в манифесте проекта (вместо диапазонов semver): как мы рассмотрели выше, это не даст существенных результатов, потому что транзитивные зависимости всё равно будут обновляться. Да и другие факторы не перестанут влиять на установку зависимостей. Кроме того, если вы заморозите ваши прямые зависимости, то получится ситуация, когда более старые версии будут работать с более свежими версиями транзитивных зависимостей, и потенциально это повышает вероятность проблем с интеграцией.
А теперь представьте, что у нас в проекте есть конвейер CI/CD и специальный сервер, который собирает, тестирует и выкатывает приложения в разные среды выполнения. Как правило, такие решения привязываются к ID коммита в Git (или к Git-тегам), и на каждый коммит система генерирует готовый к выкатке артефакт (архив с готовыми для выполнения файлами). Таким образом, на вход конвейера поступает код из Git-репозитория, версионированный через ID коммита, а на выходе вы получаете протестированный и готовый к выкатке артефакт. В идеале, это должно работать как чистая функция (pure function): если вы пересоберёте коммит, созданный несколько месяцев назад, то должны получить на выходе тот же самый артефакт. Однако мы не можем хранить содержимое node_modules в Git, и получается, что после клонирования репозитория нам необходимо вызывать установку зависимостей из реестра npm. А, как мы уже выяснили, этот процесс довольно нестабилен и привязан к глобальному состоянию экосистемы (содержимому npm registry, версиям npm и т. д.). Получается, что npm вносит хаос в наш конвейер CI/CD и мы уже не можем получить одинаковую сборку по ID коммита.
Lock-файлы приходят на помощь
Чтобы использовать преимущества lock-файла, его необходимо добавить в систему контроля версий. Таким образом, вы строго привяжете полное дерево зависимостей к коммитам в Git. Это будет гарантировать стабильное воспроизводство сборок в вашей системе CI/CD и позволит надежно «путешествовать во времени».
Кроме того, каждый разработчик, который склонирует Git-репозиторий к себе на машину, получит точно такое же дерево зависимостей, как и у вас. Это устранит известную проблему из разряда «странно, а у меня всё работает» (“it works on my machine”).
Структура package-lock.json
Npm генерирует lock-файл полностью автоматически на основе данных из манифеста проекта, глобального состояния npm registry и алгоритма установки зависимостей npm. Однако содержимое файла вполне читаемо человеком и может быть использовано даже на этапе code review. Diff lock-файла покажет, какие зависимости в дереве были обновлены, какие были удалены, а какие добавлены. Наверное, нет смысла изучать изменения этого файла при каждом обновлении, но при обнаружении каких-то деградаций это может сильно помочь в поиске виновного пакета и сэкономить вам кучу времени. Но чтобы это работал эффективнее и размер изменений был минимальным, я рекомендую обновлять зависимости как можно чаще (гораздо проще выявить проблему, если у вас обновилось три пакета в дереве зависимостей, а не сотня).
Оригинальный файл содержит почти 400 строк, но чтобы пример получился достаточно читабельным и наглядным, я показал только часть дерева зависимостей.
package-lock.json
Итак, давайте разбираться. Начнем с основных корневых свойств:
Дескриптор каждой отдельно взятой зависимости выглядит следующим образом:
Дублирующиеся зависимости
Подробнее про дублирование зависимостей мы поговорим в будущих статьях.
Ручные правки
Хотя структура lock-файла хорошо читается и довольно понятна, нельзя забывать, что этот файл генерируется автоматически. Не пытайтесь вносить в него правки, их будет невозможно сохранить. После очередного обновления lock-файла они будут потеряны.
Конфликт в lock-файлах npm
Если несколько разработчиков трудятся в одной ветке и используют lock-файлы, то в какой-то момент может возникнуть merge-конфликт в Git. В этом случае достаточно просто устранить конфликты в файле манифеста (если они есть), а потом выполнить npm install : менеджер пакетов автоматически исправит конфликты в lock-файле.
Установить merge-драйвер для npm можно следующим образом:
При возникновении конфликта при вызове команд Git в консоли будет выведено:
Обновление lock-файла
Установка зависимостей в CI/CD
Как я сказал выше, если npm обнаружит отставание lock-файла от манифеста, то это приведет к обновлению lock-файла и установке зависимостей из манифеста. Такое поведение очень удобно при разработке, но совершенно непригодно, и даже опасно в контексте конвейера CI/CD, потому что может привести к неожиданным результатам из-за слетевшей блокировки зависимостей.
По этой причине никогда не следует использовать команду npm install в рамках конвейера CI/CD, обязательно используйте npm ci вместо нее. Идите и проверьте это прямо сейчас! (я подожду).
Разные типы проектов
Давайте теперь поговорим про особенности использования lock-файлов в проектах разных типов. Первое, о чём стоит сказать: файл package-lock.json не публикуется в npm registry. Это означает, что если вы публикуете свой пакет в реестр npm (библиотека), то содержимое вашего lock-файла не будет оказывать влияния на дерево зависимостей при установке вашего пакета в чей-то проект. В этом случае играет роль только содержимое вашего манифеста. Это и хорошо: если бы каждая библиотека замораживала свои зависимости, то дерево зависимостей в конечном проекте было бы ещё больше (куда уж больше?) и содержало огромное количество дублей. Адекватно управлять зависимостями стало бы невозможно.
Shrinkwrap
Тестирование пакета-библиотеки
По этой причине вы не можете гарантировать среду, однако можете протестировать работу библиотеки со свежими версиями всех зависимостей, чтобы убедиться, что в новых и свежих проектах ничего не сломается. Однако, если вы будете использовать lock-файл в вашем проекте, то он будет постоянно оттягивать версии ваших зависимостей назад, не давая вам полноценно тестировать совместимость с самыми свежими версиями всех зависимостей (которые наверняка будут у ваших пользователей). Либо вам придется постоянно вызывать глубокий npm update перед каждым тестом.
Руководствуясь этим, некоторые разработчики советует вообще не использовать lock-файлы для проектов библиотек. Однако, я считаю это слишком радикальным советом. Дело в том, что помимо продуктовых runtime-зависимостей вашего пакета существуют еще и dev-зависимости. Если вы откажетесь от lock-файла, то ваши dev-зависимости выйдут из-под контроля, то есть вы потеряете некий островок стабильности.
Более подходящим решением, на мой взгляд, была бы реорганизация конвейера CI/CD таким образом, чтобы код библиотеки тестировался в проекте без использования lock-файла, путем установки самых свежих доступных зависимостей. Собирать же пакет (если требуется) можно и с участием lock-файла (для этого можно использовать два разных этапа в вашем CI/CD конвейере).
С глаз долой…
Надеюсь, теперь, лучше понимая, как работают эти механизмы, вы сможете эффективнее наладить управление зависимостями в вашем проекте и повысить его надежность и безопасность.
Обновляйтесь чаще!
Помните, задача lock-файлов заключается не в том, чтобы навсегда заблокировать все зависимости и больше никогда их не обновлять, а в том, чтобы обеспечить повторяемость их установки и прозрачность их обновления.
Залог высокого качества, поддерживаемости и удобства разработки вашего проекта заключается в частом обновлении зависимостей. Согласитесь, гораздо проще обновлять зависимости маленькими порциями по мере их выхода. Diff lock-файла всегда покажет, что именно обновилось. Если он будет небольшим, то вы легко сможете его прочитать. Если же после обновления возникнет проблема, то, скорее всего, она будет одна, и её будет несложно обнаружить и изолировать.
С другой стороны, если вы не будете полгода обновлять зависимости, то потом сделать это будет очень сложно, потому что крупное обновление очень сложно разделить на маленькие части. Вы получите огромный ворох изменений разной степени тяжести, а в случае возникновения проблемы (а она, скорее всего, придет не одна) выявить точное место будет гораздо сложнее (diff здесь уже будет бесполезен в силу его гигантского размера).
Поэтому не запускайте ваши зависимости, обновляйтесь регулярно, возьмите это в привычку, тогда издержки на поддержку кодовой базы будут минимальны. Переход же на новые мажорные версии библиотек будет более планомерным: гораздо проще обновиться на одну мажорную версию библиотеки, чем на несколько сразу.
Продолжение следует
Мы рассмотрели столь важный инструмент повышения надежности и безопасности управления зависимостями, как lock-файлы npm. Использование этого механизма позволит вам существенно повысить стабильность работы вашего проекта и улучшить качество и удобство разработки.
В следующем посте я еще дальше углублюсь в вопросы безопасности npm.
Если вам понравился материал, то, пожалуйста, ставьте лайки, подписывайтесь на наш блог и делитесь ссылками с коллегами. Так мы будем понимать, что наша работа востребована, и будем продолжать радовать вас новыми полезными материалами.
Если у вас есть вопросы или желание что-то добавить по теме, то не бойтесь оставлять комментарии, я с радостью приму участие в обсуждении и учту ваши пожелания в следующих постах.
