Восстанавливаем файлы после вируса vault

Как восстановить и расшифровать файлы после вируса vault

Вот мы и подошли к самому главному моменту. Как же нам получить обратно свою информацию. Компьютер мы вылечили, что могли восстановили, прервав шифрование. Теперь надо попытаться расшифровать файлы. Конечно, проще и желанней всего было бы получить готовый дешифратор vault для расшифровки, но его не существует. Увы, но создать инструмент, чтобы дешифровать данные, зашифрованные ключом RSA-1024 технически невозможно.

Так что к великому сожалению, вариантов тут не очень много:

1. Вам очень повезло, если у вас включена защита системы. Она включается для каждого диска отдельно. Если это было сделано, то вы можете воспользоваться инструментом восстановления предыдущих версий файлов и папок. Находится он в свойствах файла. Подробнее можно поискать в интернете, статей по поводу этого инструмента восстановления остаточно.
2. Если у вас оказались зашифрованы файлы на сетевых дисках, ищите архивные копии, проверяйте, не включена ли на этих дисках корзина, там будут ваши исходные файлы. Хотя стандартно на сетевых дисках ее нет, но можно настроить отдельно. Я чаще всего это делаю, когда настраиваю сетевые шары. Вспомните, нет ли у вас архивных копий ваших локальных данных.
3. Если у вас пострадали данные в папках, которые подключены к хранилищам данных в интернете типа Яндекс.Диск, Dropbox, Google disk, загляните к ним в корзину, там должны остаться оригинальные файлы до шифрования.
4. Попробуйте найти файл secring.gpg.Файл этот должен быть создан на вашей машине (как правило в %TEMP% юзера) в момент запуска процесса шифрования. К сожалению, вероятность успешного поиска secring.gpg невелика, поскольку шифратор тщательно затирает данный ключ с помощью утилиты sdelete.exe:

   "%temp%\sdelete.exe" /accepteula -p 4 -q "%temp%\secring.gpg"

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

Если ничего из перечисленного выше вам не помогло, а информация зашифровалась очень важная, у вас остается только один вариант — платить деньги создателям вируса для получения дешифратора vault. По отзывам в интернете это реально работает, есть шанс с высокой долей вероятности восстановить свои файлы. Если бы это было не так, то никто бы не платил деньги после нескольких отрицательных отзывов.

Вирус vault настолько популярен, что в сети появилась реклама, где некие товарищи предлагают за деньги торговаться с хакерами, чтобы сбить цену на расшифровку данных. Я не знаю, насколько реально они сбивают цену и сбивают ли вообще, возможно это просто разводилы, которые возьмут с вас деньги и смоются. Тут уже действуйте на свой страх и риск. Я знаю только, что сами хакеры реально восстанавливают информацию. Одна знакомая компания, где пострадали сетевые диски, и из бэкапов не смогли полностью восстановить данные, заплатили злоумышленникам и смогли восстановить часть информации. Но только часть, потому что вышла накладка. Так как было почти одновременно заражено несколько компьютеров, то и шифрование производилось не с одного, а как минимум с двух одновременно. При оплате же ты покупаешь только один ключ дешифратора vault от одной машины. Чтобы расшифровать файлы, зашифрованные вторым компьютером пришлось бы отдельно покупать закрытый ключ еще и к нему. Это делать не стали, удовлетворившись полученным результатом.

Какую цену назначат вам за расшифровку зависит от количества зашифрованных файлов и от вашего умения найти общий язык с шифраторами. С хакерами возможно живое общение в чате. Информация о ваших зашифрованных файлах хранится в CONFIRMATION.KEY, о котором я упоминал ранее. Так же для расшифровки вам понадобится VAULT.KEY. Как связаться с хакерами рассказано непосредственно в информационном сообщении, которое вы получаете после заражения. Сервер хакеров работает не круглосуточно, а примерно 12 часов в сутки. Вам придется сидеть и проверять время от времени его доступность.

Больше мне нечего добавить по теме дешифровки данных. Пробуйте варианты. Вообще, выходит чистая уголовщина и суммы гоняют приличные эти негодяи. Но как найти управу на преступников я не знаю. Куда жаловаться? Участковому?

Повторю еще раз на всякий случай. Для описанной мной модификации vault дешифратора не существует! Не тратьте деньги, если кто-то будет предлагать вам его купить. Создать дешифратор ваулт в данном случае технически невозможно.

Backends (Бэкенд)

Бэкенды — ключевые компоненты всего Vault. Вы уже видели дефолтный бэкенд типа , где все данные хранятся в пути . Это работает похоже на файловую систему Unix – вы можете производить mount/unmount различных типов для путей.

$ vault mountsPath          Type       Default TTL  Max TTL  Descriptionsecret/       generic    system       system   generic secret storagesys/          system     n/a          n/a      system endpoints used for control ...vault mount -path=django -description="Secrets used in a Django project" genericvault mountsPath          Type       Default TTL  Max TTL  Descriptionsecret/       generic    system       system   generic secret storagedjango/       generic    system       system   Secrets used in a Django projectsys/          system     n/a          n/a      system endpoints used for control ...# We can write our data in this namespacevault write django/aws-secret-key value="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"vault write django/aws-access-key value="AKIAIOSFODNN7EXAMPLE"

Каждый бэкенд служит разным целям:

• mysql и postgresql бэкенды — можете использовать их для динамического создания/удаления пользователей БД с определёнными наборами привелегий;
• aws — позволит вам создавать/удалять Amazon credentials на основании политик IAM;
• ssh — вы можете использовать его для хранения/раздачи приватных SSH ключей;
• cubbyhole — этот бэкенд работает как уникальное пространство имён для каждого токена. Уничтожение токена удаляет также все данные в его cubbyhole пространстве.

Установка Vault

Для развёртывания Vault в Проде, вам понадобится init скрипт, который в комплект не входит. Можно написать свой, упаковать Vault в Docker контейнер (самый простой вариант) или демонизировать его с помощью Supervisord.

Следующий этап — выбор хранилища: места, где Vault будет хранить ваши sensitive данные. Можно использовать файлы, S3, MySQL, Consul и т.д.

Лично я нахожу S3 сбалансированным решением между простотой использования и надёжностью. В Vault версии 0.4 вы не можете вывести список секретов, но сможете проверить их через Amazon Console.

# vault.hclbackend "s3" {  bucket = "vault"  access_key = "AKIAIPR2HA"  secret_key = "nO6TK2NAPpZkBf+iSWrnQAojIp"  region = "eu-west-1"}listener "tcp" {  address = "127.0.0.1:8200"   tls_disable = 1}vault server -config=vault.hclvault init# Key 1: 4cdc4cccb9e2ddda8a2163e8d1a1b94522e6e9c6d25d6a5a12e9677262547c1401# Key 2: 8b94a7e4614956778ccce9a185d736e9d4a86dd75ca588056f9c10da60a8f31d02# Key 3: 42378fbd9549091da0bcf6c14f9287e961e0738eb129b4b28d79538e702ab9db03# Key 4: b35c835644358269219fd75378507380d9cc76ca47fe5f64ce28b28e9eb5f82c04# Key 5: 7affab0fb035dd030defc833b215c2806c846893aa7263d32ccdf1da8e37b2ea05# Initial Root Token: 8a5dbab4-43cc-8b8d-e6a6-04d5e458dca9# You have to provide any 3 of the 5 keys printed to stdout after the init commandvault unseal# authenticate with the root token, configure Vault, set policies, etc.vault auth 8a5dbab4-43cc-8b8d-e6a6-04d5e458dca9

Vault использует TLS сертификат для защиты TCP сокета, на котором исполняется. Вам придётся сгенерировать один и в документации не поясняется, как это сделать. Docker использует схожий механизм безопасности, так что его документация может стать референсом.

Вариантом попроще для охраны вашего экземпляра Vault может стать фронтенд через nginx/apache. К примеру, вы можете настроить basic auth или разрешить доступ только с определённых IP.

# Full configuration at https://mozilla.github.io/server-side-tls/ssl-config-generator/# /etc/nginx/sites-enabled/vaultserver {        listen 80;        listen 443 ssl;        server_name vault;        return 301 https://vault.yourdomain.com$request_uri;    }        server {        listen 443 ssl;        location / {            proxy_buffering    off;            proxy_pass         http://127.0.0.1:8200;            proxy_redirect     off;            proxy_set_header   Host $http_host;        }}

Моё впечатление от Vault

Я недавно документировал мой опыт работы с Terraform, другим проектом Hashicorp, который я часто использую. Опыт работы с Vault был очень похож — действительно уникальный и стоящий проект, однозначно заслуживающий добавления к инструментарию DevOps.

Из минусов — крутая кривая обучения, нехватка документации, мало описанных примеров. Есть вероятность, что решать задачи/проблемы придётся в google groups, stackoverflow и т.д., что может отнимать много времени.

»Deployment System Requirements

The following table provides guidelines for server sizing. Of particular note is
the strong recommendation to avoid non-fixed performance CPUs, or Burstable
CPU in AWS terms, such as T-series instances.

Sizing for Vault Servers

Size	CPU	Memory	Disk	Typical Cloud Instance Types
Small	2 core	4-8 GB RAM	25 GB	AWS: m5.large
				Azure: Standard_D2_v3
				GCE: n1-standard-2, n1-standard-4
Large	4-8 core	16-32 GB RAM	50 GB	AWS: m5.xlarge, m5.2xlarge
				Azure: Standard_D4_v3, Standard_D8_v3
				GCE: n1-standard-8, n1-standard-16

Sizing for Consul Servers

Size	CPU	Memory	Disk	Typical Cloud Instance Types
Small	2 core	8-16 GB RAM	50 GB	AWS: m5.large, m5.xlarge
				Azure: Standard_D2_v3, Standard_D4_v3
				GCE: n1-standard-4, n1-standard-8
Large	4-8 core	32-64+ GB RAM	100 GB	AWS: m5.2xlarge, m5.4xlarge
				Azure: Standard_D4_v3, Standard_D8_v3
				GCE: n1-standard-16, n1-standard-32

Hardware Considerations

The small size category would be appropriate for most initial production
deployments, or for development/testing environments.

The large size is for production environments where there is a consistent high
workload. That might be a large number of transactions, a large number of
secrets, or a combination of the two.

In general, processing requirements will be dependent on encryption workload and
messaging workload (operations per second, and types of operations). Memory
requirements will be dependent on the total size of secrets/keys stored in
memory and should be sized according to that data (as should the hard drive
storage). Vault itself has minimal storage requirements, but the underlying
storage backend should have a relatively high-performance hard disk subsystem.
If many secrets are being generated/rotated frequently, this information will
need to flush to disk often and can impact performance if slower hard drives are
used.

Consul servers function in this deployment is to serve as the storage backend
for Vault. This means that all content stored for persistence in Vault is
encrypted by Vault, and written to the storage backend at rest. This data is
written to the key-value store section of Consul’s Service Catalog, which is
required to be stored in its entirety in-memory on each Consul server. This
means that memory can be a constraint in scaling as more clients authenticate to
Vault, more secrets are persistently stored in Vault, and more temporary secrets
are leased from Vault. This also has the effect of requiring vertical scaling on
Consul server’s memory if additional space is required, as the entire Service
Catalog is stored in memory on each Consul server.

Furthermore, network throughput is a common consideration for Vault and Consul
servers. As both systems are HTTPS API driven, all incoming requests,
communications between Vault and Consul, underlying gossip communication between
Consul cluster members, communications with external systems (per auth or secret
engine configuration, and some audit logging configurations) and responses
consume network bandwidth.

Due to network performance considerations in Consul cluster operations,
replication of Vault datasets across network boundaries should be achieved
through Performance or DR Replication, rather than spreading the Consul cluster
across network and physical boundaries. If a single Consul cluster is spread
across network segments that are distant or inter-regional, this can cause
synchronization issues within the cluster or additional data transfer charges
in some cloud providers.

Vault Production Hardening Recommendations
provides guidance on best practices for a production hardened deployment of
Vault.

Наш процесс работы:

Нам не подошёл официальный процесс работы с Vault по причине излишней трудоёмкости внедрения Vault в эксплуатацию сервиса. Поделюсь нашими решениями и ответами на возникающие вопросы в процессе внедрения Vault.

• Отказоустойчивость:
  Мы используем Consul в инфраструктуре, поэтому выбрали его как отказоустойчивый бэкенд для Vault.
• Количество ключей для распечатки хранилища:
  Распечатывание — исключительно ручной процесс, во время которого зашифрованный контейнер с секретами помещается в память и восстанавливается мастер-ключ для расшифровки. . Дать возможность распечатать хранилище одному человеку — риск, потому что при компрометации этого ключа или ключей злоумышленники получат доступ к хранилищу (но пока не к секретам). Надо понимать, что если вы не наберёте необходимый минимум ключей для распечатывания хранилища, доступ к данным будет утерян. Мы решили, что нам достаточно 4 владельцев ключей и 2 ключей для расшифровки.
• Root токены и их роль в системе:
  Официальная позиция Hashicorp — использовать эти токены только для управления политиками, ролями, настройками системы и для выдачи токенов для сервисов. Чем меньше root ключей в системе, тем меньше вероятности компрометации ключей. Но чем меньше таких ключей в системе, тем больше всё завязывается на определённых людей, которые болеют, ходят в отпуск, в общем — бывают недоступны. Мы начали с 4 root-ключей на группу из 7 человек. Это было неудобно, поэтому мы в первый раз отступили от официального процесса — выдали root-токены всем инженерам эксплуатации и перестали создавать мастер-токены для управления секретами сервиса. Все операции производятся под root-токенами. Создаются только read-only токены.
• Схема хранения секретов:
  Для нас я выбрал следующую схему — храним секреты сервисов в /secret/service_name/env. А обще-инфраструктурные ключи (например, api-token для jenkins или реквизиты для доступа к пакетному репозиторию) храним в /secret/infra/*.

• Именование секретов:

  или, например,

  Решите этот вопрос до того, как ваш список секретов начнёт быстро расти и вы начнёте прикручивать различные средства автоматизации. Мы используем первую схему.

• Учёт ключей и мониторинг их времени жизни:
  По-умолчанию максимальный срок жизни НЕ root токена равен 30 дням. Мы ведём учёт accessor-ключей для токенов с помощью репозитория — и это неудобно. Зато позволило настроить мониторинг, который сообщает об истечении срока жизни ключей за 5 дней.
  В планах завести небольшой сервис для учёта ключей и написать небольшую обёртку для автоматизации некоторых действий с токенами (например, автоматическую запись вновь созданного токена в сервис).

Настройка SSL

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

Первое, что нам нужно, это получить сертификат. Правильнее всего купить сертификат или запросить через Let’s Encrypt. После прописать в конфигурационном файле vault путь до данного сертификата. Но мы рассмотрим процесс получения самоподписанного сертификата, но при этом, который примет система. Для этого необходимо выполнить несколько условий:

• Сертификат должен быть выдан для hostname, по которому мы будем отправлять запросы.
• Для сертификата мы должны указать альтернативное имя subjectAltName.

И так, создаем каталог для хранения сертификатов:

mkdir /etc/ssl/vault

Проверяем версию openssl:

openssl version

Она должна быть 1.1.1 и выше. В противном случае, необходимо выполнить обновление OpenSSL. Как правило, данное действие требуется только на CentOS 7.

Генерируем сертификат:

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/vault/cert.pem -keyout /etc/ssl/vault/cert.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=vault.dmosk.local» -addext «subjectAltName = DNS:vault.dmosk.local»

* в данном примере мы сгенерируем необходимые ключи по пути /etc/ssl/vault; обязательно, нужно поменять значения vault.dmosk.local на имя сервера, который используется у вас.

Если команда вернет ошибку, проверяем, что у нас обновленная версия openssl, которая поддерживает ключ addext.

Теперь откроем конфигурационный файл hashicorp vault:

vi /etc/vault.d/vault.hcl

Приведем секцию HTTPS listener к виду:

# HTTPS listener
listener «tcp» {
  address       = «0.0.0.0:8200»
  tls_cert_file = «/etc/ssl/vault/cert.pem»
  tls_key_file  = «/etc/ssl/vault/cert.key»
}

* необходимо поменять пути до файлов tls_cert_file и tls_key_file.

Перезапускаем сервис:

После перезагрузки сервиса, он станет запечатанным и нам нужно будет снова ввести 3 части ключа (команды vault operator unseal).

systemctl restart vault

Меняем в окружении переменную VAULT_ADDR:

export VAULT_ADDR=https://vault.dmosk.local:8200

* мы указываем протокол https, обращения должны выполняться по доменному имени, для которого мы получили сертификат; также указываем порт 8200.

Выполняем команду:

vault status

Мы должны получить состояние системы. Значит запросы по https работают.

И последнее, снова открываем файл:

vi /etc/environment

И также меняем значение для переменной VAULT_ADDR:

VAULT_ADDR=https://vault.dmosk.local:8200

3: Инициализация Vault

При первом запуске Vault не будет инициализирован – то есть пока что он не будет готов к получению и хранению данных. Бэкэнд, который фактически хранит зашифрованные секретные данные, тоже не инициализирован. Запустите сервис Vault, чтобы инициализировать бэкэнд и запустить Vault.

Чтобы убедиться в том, что сервис успешно запустился, введите:

Результат этой команды включает несколько фрагментов информации о запущенном сервисе, например, идентификатор процесса и использование ресурсов. Убедитесь, что в выводе есть следующая строка, которая указывает, что сервис работает правильно.

Если сервис не активен, посмотрите на сопровождающие строки логов в конце вывода команды, чтобы понять, в чем проблема.

Затем установите переменную среды, чтобы сообщить команде vault, как подключиться к серверу Vault. На данный момент Vault прослушивает только локальный интерфейс loopback, поэтому установите в переменной VAULT_ADDR локальную конечную точку HTTPS.

Команда vault теперь может взаимодействовать с демоном

Обратите внимание, что вместо простого localhost или 127.0.0.1 необходимо указать имя хоста для проверки сертификата HTTPS

Убедитесь, что хранилище vault не было инициализировано.

Сервер должен вернуть ошибку 400, что говорит о том, что хранилище не инициализировано

Во время инициализации Vault будет отображать два фрагмента информации, которые не будут доступны в других точках:

• Исходный токен root: эквивалентен правам root на развертывание Vault, что позволяет управлять всеми политиками Vault, монтированием и т. д.
• Ключи разблокировки: используются для вскрытия Vault при запуске демона, что позволяет демону Vault расшифровывать хранилище секретных данных бэкэнда.

При инициализации Vault вы можете выбрать, сколько вам нужно ключей и сколько их нужно в момент вскрытия, чтобы успешно открыть Vault.

Обычно запрашивается три ключа вскрытия, два из которых используется непосредственно в момент вскрытия. Благодаря этому недостаточно взломать один ключ, чтобы вскрыть Vault.

Другими словами, для обеспечения доступности и готовности к использованию сервиса Vault при его запуске потребуется не менее двух ключей для вскрытия. До этого момента файлы с конфиденциальной информацией будут зашифрованными и недоступными.

Инициализируйте Vault с такими параметрами:

Сохраните токены для вкрытия и исходный токен root в безопасном месте. Например, можно сохранить один токен вскрытия в диспетчере паролей, второй на USB-накопителе, а третий в GPG-зашифрованном файле.

Теперь вы можете вскрыть хранилище с помощью токенов. Начните с одного ключа.

Команда запросит токен:

После ввода токена команда сообщит, что процесс вскрытия выполняется, но для его завершения требуется еще один токен.

Еще раз запустите команду unseal:

Введите второй токен:

Вывод команды указывает, что процесс вскрытия и завершен успешно.

Теперь хранилище Vault вскрыто и готово к использованию. Процесс вскрытия необходим после каждой загрузки или перезагрузки Vault.

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

Где можно заразить компьютер Ваултом и как от него защититься?

Как и большинство вредоносных кодов, этот вирус можно заполучить в интернете. На почту приходят письма разного характера (чаще всего якобы от банковских служб, кредитных отделов, каких-либо государственных  учреждений), которое обязательно вас заинтересует и заставит нажать на ту самую ссылку, которая и запустит загрузку вируса Vault на ваш компьютер или ноутбук. После завершения шифровального процесса на вашем устройстве появится текстовый документ. В нём сообщается о том, что ваши документы и данные закодированы и для их разблокировки вам нужно получить специальный ключ.

Антивирусы практически не реагируют на этот код, так как для его работы использует популярный алгоритм шифрования RSA-1024, который по своей природе не является вирусом. В связи с этим возникает множество проблем: как тогда защититься от вредоносного кода, если даже антивирусы бессильны? Конечно, очень важна бдительность при работе в интернете. Хакеры не сидят сложа руки, а пользователи интернета являются очень лёгкой добычей. А всё из-за невнимательности: пользователи нажимают на всё подряд, особенно это касается рекламных баннеров, под которыми и скрываются «тёмные силы». Всплывающая реклама не только мешает работе в сети, но и может стать причиной ваших будущих технических проблем.

Как обезопасить себя от вируса Ваулт?

1. Если ваш компьютер уже им заражён, вы знаете что именно делать не нужно. Но если вы до сих пор не поняли, почему ваши файлы зашифрованы, читайте дальше.
2. При получении любого письма на электронную почту всегда тщательно проверяйте следующие данные: от кого пришло (часто злоумышленники пишут похожее название электронного адреса с каким-нибудь знакомым брендом, но с небольшими изменениями, чтобы пользователи не заметили), тема письма, его содержание (любое сомнительное письмо сразу должно удаляться из вашего почтового ящика) и оформление письма.
3. Для начала подумайте: вы подписывались на получение почтовой рассылки от этой компании? Если нет, то тут однозначно можно отправлять в чёрный список. Если да, то всё же ещё раз внимательно посмотрите, кто отправитель письма. Скопируйте этот адрес и найдите его в поисковой системе. Возможно, кто-то сталкивался с подобным и на форумах написал, что же это за отправитель. Можете скопировать и таким же способом найти текст самого письма. Это очень полезная практика, которая позволит вам «выиграть войну» ещё до её начала.
4. Нигде не пишите свой номер или другие конфиденциальные данные на сайтах, интернет-ресурсах.
5. Никогда не открывайте ссылки, если не уверены хотя бы в одном пункте.

Этих рекомендаций должно быть достаточно. Как вы могли заметить, везде здесь основным ключевым моментом является бдительность самого пользователя

Малейшая неосторожность может стать переломной в жизни ваших файлов, документов, фотографий и другой информации

»Glossary

Vault Cluster

A Vault cluster is a set of Vault processes that together run a Vault service.
These Vault processes could be running on physical or virtual servers, or in
containers.

Consul storage backend cluster

HashiCorp recommends and supports Consul being used as the storage backend for
Vault. A Consul cluster is a set of Consul server processes that together run a
Consul service. These Consul processes could be running on physical or virtual
servers, or in containers.

Availability Zone

A single failure domain on a location level that hosts part of, or all of a
Vault cluster. The latency between availability zones should be < 8ms for a
round trip. A single Vault cluster may be spread across multiple availability
zones.

Examples of an availability zone in this context are:

• An isolated datacenter
• An isolated cage in a datacenter if it is isolated from other cages by all
  other means (power, network, etc)
• An availability zone in AWS, Azure or GCP

Region

A geographically separate collection of one or more availability zones. A region
would host one or more Vault clusters. There is no defined maximum latency
requirement between regions in Vault architecture. A single Vault cluster would
not be spread across multiple regions.