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

[Dread Pirate Roberts]

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

Спойлер: dedicated servers
моя работа над Supply Chain Attack затягивается и неизвестно когда закончится, поэтому вместо обещанной в моём (уже позапоза)прошлом топике одной большой статьи, я решил написать несколько не очень больших промежуточных. первая из них будет про виртуалки:


0. небольшой экскурс в мир хостинга и маркетингового буллщита

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

"VPS", "VDS", "Dedicated KVM", "Cloud Server" - это всё разные термины для описания одного и того же, а именно - виртуальной машины. хостеры используют разные термины для того, чтобы запутать клиентов и впарить им виртуальный сервер под видом выделенного.
некоторые наглые (или безграмотные?) хостеры объясняют "VPS - это виртуальный сервер, вон смотрите - там же слово 'Virtual' в аббревиатуре от 'Virtual Private Server'! а вот VDS - это выделенный сервер, вон смотрите - там же слово 'Dedicated' в аббревиатуре от 'Virtual Dedicated Server'!", намеренно опуская тот факт, что оба этих сервера - "Virtual", а потом клиенты этих хостингов распространяют этот бред, что VPS и VDS - это разные вещи, и что "надо брать VDS потому что это выделенный сервер". возможно, они считают, что эта аббревиатура значит "Vыделенный Dedicated Server"

есть даже совсем обнаглевшие хостеры, которые продают виртуальную машину, а называют её "dedicated server", вот пример: https://www.homepageuniverse.com/servers/

Your Dedicated Server on the Private Cloud
...
HomepageUniverse Dedicated Hosting Server is more than just a server, it is a fully dynamic cloud solution
Нажмите, чтобы раскрыть...

другие хостеры тоже продают якобы "dedicated server", но на самом деле виртуалку - они запускают на выделенном сервере гипервизор (софт для управления виртуалками) и создают единственную виртуальную машину, выделяя ей почти все ресурсы сервера (оставляя минимальный кусочек процессора и оперативы для гипервизора), при этом клиенту доступ к гипервизору не выдают.
вот пример одного из таких говнохостеров (один из крупнейших хостингов в мире, кстати): https://www.hostgator.com/help/article/do-you-allow-kvm-on-a-dedicated-server

Our dedicated servers are virtualized guests that are running under a KVM
...
HostGator does not provide customer level access to the Kernel Virtual Machine on a server
Нажмите, чтобы раскрыть...

а также все его реселлеры, которых можно нагуглить по бренду "resellerclub" или по фразе "Our Dedicated Servers are virtualised (1:1)" ("наши ВЫДЕЛЕННЫЕ сервера ВИРТУАЛИЗИРОВАНЫ", как тебе такое, Илон Маск?)


теперь немного о шифровании оперативной памяти: ходят слухи, что у современных процессоров есть функция шифрования оперативной памяти виртуальной машины, чтобы с хостовой системы было невозможно прочитать память гостевой системы, но я этим слухам не верю.
точнее, в существование-то этой функции я верю, вот документация от Интеля: https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
а вот от AMD: https://www.amd.com/en/developer/sev.html
(а вот топик с обсуждением на ХСС: https://xss.is/threads/97855/ )
но я не верю в использование этой функции хостерами: сложно себе представить, что хостинг провайдер добровольно откажется от доступа к данным своих клиентов.


резюмируя: не ведитесь на маркетинговый буллщит, арендуйте именно выделенные сервера, а не виртуалки!


далее для описания виртуальной машины я буду использовать аббревиатуру "VDS".
действия хостера буду выделять красным цветом, а действия клиента хостинга - зелёным
в качестве гипервизора я буду использовать Proxmox (не совсем ынтырпрайз решение, но некоторые популярные хостеры используют именно его), и в качестве гостевой системы - Debian 11.




1. брут пароля от шифрованного диска через дамп заголовка LUKS

представим такую ситуацию: ваш клиент зашифровал диск своего VDS, забыл от него пароль и просит помочь вспомнить.



для начала создам VDS и установлю в него Debian с полнодисковым шифрованием LUKS (для демонстрации я буду использовать простой пароль "rockyou", находящийся в самом начале популярного ворлдиста, чтобы он быстро сбрутился, а для быстроты установки я выберу минимальный набор ПО с консольным интерфейсом вместо предложенного по умолчанию графического):

после установки системы и ребута сервер просит расшифровать диск:

расшифрую диск и посмотрю информацию о шифрованном разделе, видимую изнутри VDS:

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





чтобы сделать дамп заголовка LUKS, сначала нужно найти этот раздел внутри виртуального диска VDS, так как разметка диска хостеру неизвестна - клиент мог насоздавать кучу разделов и зашифровать любой из них.

посмотрим, где в ОСи гипервизора лежит виртуальный диск клиента (можно посмотреть и в Web GUI гипервизора, но мы же простых путей не ищем!):

открываем файл-диск hex редактором:
Код: Скопировать в буфер обмена
$ hexedit /var/lib/vz/images/102/vm-102-disk-0.qcow2

и ищем начало шифрованного раздела: оно представляет собой строку ASCII "LUKS", сразу после которой идут два символа hex "BA BE", а чуть позже идёт ASCII строка вида "aes" или "sha".

- это НЕ начало раздела LUKS, потому что дальше идут какие-то "SKUL" и "Invalid" вместо "sha" или "aes", ищем дальше...

- а вот и оно, шифрованный раздел начинается с адреса hex 0x1E950000.

размер заголовка LUKS, если мне не изменяет память, 2 мегабайта, но cryptsetup отказывается показывать информацию по файлам размером меньше 16 мегабайт, поэтому для демонстрации команды "cryptsetup luksDump" я скопирую 16 мегабайт вместо 2:

Код: Скопировать в буфер обмена

$ dd if=/var/lib/vz/images/102/vm-102-disk-0.qcow2 bs=1 skip=$((0x1E950000)) count=16M of=header.bin
$ cryptsetup luksDump ./header.bin

и вот мы получили информацию о шифрованном разделе VDS, будучи внутри гипервизора, а не внутри VDS (проскроллив топик выше вы увидите, что данные совпадают с теми, что выводит "cryptsetup luksDump" изнутри VDS)

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

Код: Скопировать в буфер обмена
PBKDF: argon2i

на сегодня ( nn сентября 2023 года) hashcat и John-the-Ripper не поддерживают argon2i:
https://github.com/hashcat/hashcat/issues/2178 - обсуждение luks2
https://github.com/hashcat/hashcat/issues/1966 - обсуждение argon2

я подробно не изучал, можно ли чем-то ещё быстро сбрутить LUKS2-argon2, и просто взял первую попавшуюся программу из гугла - https://github.com/glv2/bruteforce-luks
для брута нормальных паролей она не подходит по причине скорости "1 поток на 1 ядро", но для демонстрации её более чем достаточно:

- пароль получен, теперь можно спокойно открывать зашифрованный диск и доставать данные клиента. копируем куда-нибудь виртуальный жёсткий диск:
Код: Скопировать в буфер обмена
$ cp /var/lib/vz/images/102/vm-102-disk-0.qcow2 /root/shit/
монтируем его в хостовой системе с помощью тулзы qemu-nbd (может понадобиться "modprobe nbd"):
Код: Скопировать в буфер обмена
$ qemu-nbd -c /dev/nbd0 -f qcow2 /root/shit/vm-102-disk-0.qcow2
и видим все разделы виртуального диска в файлах /dev/nbd0p*:
Код: Скопировать в буфер обмена

$ ls /dev/nbd0*
/dev/nbd0  /dev/nbd0p1  /dev/nbd0p2  /dev/nbd0p5

теперь ищем среди этих разделов зашифрованный: заветные строки ASCII "LUKS" + hex "BA BE" + (чуть позже) ASCII "sha" или ASCII "aes" должны быть в самом начале файла, если их там нет - берём следующий:

Код: Скопировать в буфер обмена

$ head -c 100 /dev/nbd0p1 | hexdump -C
$ head -c 100 /dev/nbd0p2 | hexdump -C
$ head -c 100 /dev/nbd0p5 | hexdump -C

(что-то я затупил, можно было сразу так сделать для поиска зашифрованного раздела и дампа заголовка LUKS )

зашифрованный раздел - /dev/nbd0p5, расшифровываем его с помощью cryptsetup и вводим сбрученный выше пароль "rockyou":

Код: Скопировать в буфер обмена
$ cryptsetup luksOpen /dev/nbd0p5 asdf

если пароль правильный, то cryptsetup не выдаст никаких ошибок, а в директории /dev/mapper/ появится файл "asdf". создаём новую директорию с любым названием и монтируем файл /dev/mapper/asdf в неё:
Код: Скопировать в буфер обмена

$ mkdir mnt; mount /dev/mapper/asdf /root/shit/mnt/
mount: /root/shit/mnt: unknown filesystem type 'LVM2_member'.

- оказалось, что вместо простой файловой системы клиент в зашифрованном разделе создал структуру LVM, которая может состоять из нескольких виртуальных разделов.
для того, чтобы примонтировать разделы внутри LVM нужно сначала активировать LVM с помощью команды "lvchange --activate y <имя LVM>", а имя LVM можно узнать с помощью команды "lvscan":

Код: Скопировать в буфер обмена

$ lvscan -v
  ACTIVE            '/dev/pve/root' [<931.01 GiB] inherit
  inactive          '/dev/debian-luks-vg/root' [9.50 GiB] inherit

- в моём случае "pve" - это LVM гипервизора Proxmox, а вот "debian-luks-vg" - это LVM виртуальной машины

Код: Скопировать в буфер обмена

$ lvchange -ay debian-luks-vg
$ lvscan -v
  ACTIVE            '/dev/pve/root' [<931.01 GiB] inherit
  ACTIVE            '/dev/debian-luks-vg/root' [9.50 GiB] inherit

- после активации LVM все разделы внутри неё появятся в директории "/dev/debian-luks-vg/", и уже эти разделы можно будет примонтировать как обычную файловую систему.
в моём случае внутри LVM оказался единственный раздел с названием "root", примонтировав "/dev/debian-luks-vg/root" в "/root/shit/mnt/" я увидел файлы виртуальной машины и узнал, что в ней установлен Debian 11:

- файлы клиента получены, клиент доволен

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





2. получение мастер-ключа шифрования через дамп оперативной памяти

сначала небольшой ликбез о шифровании LUKS (как я его понимаю, но могу ошибаться)

1) юзер вводит пароль для шифрования диска или его раздела
2) из этого пароля создаётся "мастер ключ" с помощью функции PBKDF "Password-Based Key Derivative Function"
3) для непосредственно шифрования диска используется именно "мастер ключ", а не пароль юзера
4) когда диск не расшифрован, мастер ключ хранится на диске (в заголовке LUKS - первых 2 мегабайтах раздела), в зашифрованном виде (этот пункт разбирался в предыдущем параграфе - долго и печально брутилась функция PBKDF "argon2i")
5) когда диск расшифрован (юзер ввёл пароль), и всё время, пока шифрованный раздел примонтирован, мастер ключ хранится в оперативной памяти сервера в расшифрованном виде, чтобы у операционной системы была возможность "на лету" шифровать/расшифровывать записываемые/читаемые данные.
подробнее тут: https://blog.elcomsoft.com/2021/11/...-ecryptfs-and-native-zfs-encryption-compared/

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

сделать дамп оперативной памяти VDS можно несколькими способами:

- воспользоваться штатным функционалом гипервизора: например, сделать "snapshot" виртуалки, то есть полную копию текущего состояния VDS со всем запущенным на нём софтом, в целях бэкапа или для переноса VDS на другой физический сервер. у некоторых гипервизоров есть даже специальная функция для дампа только оперативы, а не полного состояния VDS.
- воспользоваться сторонним софтом типа CRIU ( https://criu.org/Memory_dumping_and_restoring )
- сделать "core dump" дебаггером gdb (команда "gcore -a <PID>")
- по хардкору Unix-вею парсить /proc/<PID>/maps и читать куски из файла /proc/<PID>/mem ( https://unix.stackexchange.com/ques...plications-from-swap-space-into-ram/6271#6271 )



я сделаю дамп двумя способами - снэпшот из web GUI гипервизора, и дебаггером gdb.

чтобы показать, насколько незаметно для клиента хостер может снять дамп памяти с VDS, я пущу гигабит трафика между VDS и другим сервером с помощью iperf, и буду следить за просадкой скорости с помощью nload на другом сервере.

запускаем iperf на "другом сервере":
Код: Скопировать в буфер обмена
$ iperf3 -f m -i 2 -s -4 -B IP.AD.DRE.SS

запускаем клиент iperf на тестовой виртуалке:
Код: Скопировать в буфер обмена
$ iperf3 -t 0 -4 -O 2 -c IP.AD.DRE.SS

чтобы продемонстрировать, что это не фотошоп, а реальный дамп памяти, "клиент" откроет на VDS текстовый редактор и напишет рандомную строку, а "хостер" найдёт эту строку в дампе оперативы. так как текстовый редактор будет открыт, то данные из окна редактора будут держаться в оперативной памяти VDS.

сначала сделаю дамп через gdb: https://files.catbox.moe/3ug6ud.gif

(сюда большие гифки не грузятся, поэтому залил на файлообменник. слева - "другой сервер", справа-сверху - консоль VDS, справа-снизу - консоль гипервизора Proxmox. не обращайте внимания, что nload иногда показывал нулевую скорость - это нормально, его порой так глючит.)

- на записи видно, что дамп 2 гигабайт оперативной памяти VDS занял примерно 2 секунды, и это явно заметил только "удалённый сервер" - скорость упала до нуля, а вот внутри VDS тормоза были почти незаметны - сервер не останавливался, лишь просела скорость с ~950 до ~200 мегабит на ~2 секунды.
=> при обычной работе с VDS дамп его памяти будет почти незаметен для пользователя, любой человек подумает, что это был просто лаг сети.

теперь сделаю снэпшот через веб интерфейс гипервизора: https://files.catbox.moe/s4z6i6.gif

- дамп сделался меньше, чем за секунду, просадка производительности почти не заметна ни на виртуальном сервере, ни на "другом сервере".
=> при обычной работе с VDS пользователь абсолютно ничего не заметит во время создания снэпшота.

такая большая разница (если можно назвать "большой" разницу в одну секунду) происходит из-за того, что gdb дампит "VIRT" память (сколько VDS теоретически может занять в памяти хостовой системы), а гипервизор дампит "RES" память (сколько VDS фактически занимает места в хостовой памяти):

тут стоит заметить, что у разных гипервизоров разные методы создания снэпшота: VMWare ESXI в отличие от Proxmox делает полный дамп виртуальной памяти VDS, а также полную копию виртуального диска, поэтому снэпшот делается медленнее и во время этого VDS заметно притормаживает. но всё равно ни один клиент не обратит внимания на странные тормоза его сервера, если они длятся всего несколько секунд

теперь достанем из дампа памяти ключ шифрования.

информация о шифрованном разделе показала, что используется шифр "aes-xts-plain64" с ключом длиной 512 бит. ключи AES бывают длиной 128, 192, и 256 бит, LUKS в качестве 512-битного ключа использует два совмещённых ключа по 256 бит.
для скана бинарных файлов на строки, похожие на приватные ключи AES, существует как минимум две тулзы - "aeskeyfind" и "findaes", первая у меня сегфолтится, поэтому буду использовать вторую: https://sourceforge.net/projects/findaes/

сначала просканю "core dump":

- нашлись две строки, похожие на 256-битные ключи

Код: Скопировать в буфер обмена

Found AES-256 key schedule at offset 0x89d4b8a0:
34 8e 31 30 62 a9 93 66 e4 b9 0e f9 7a 17 ef 7e 35 c5 f2 6a 49 df ef 4d dd 9b f6 db d9 db 14 91
Found AES-256 key schedule at offset 0x89d4baa0:
5f 1d ba 60 21 93 93 6f 85 5b 06 80 6b df a1 5a ea 93 34 d2 02 a7 1b 6b c3 0b 0f 3c 21 0b fd a6

обращаем внимание на идущие подряд hex адреса 0x89d4b8a0 и 0x89d4baa0 и понимаем, что эти две строки по 256 бит и есть искомая 512-битная строка.
получается, что мастер-ключ LUKS - это строка "348e313062a99366e4b90ef97a17ef7e35c5f26a49dfef4ddd9bf6dbd9db14915f1dba602193936f855b06806bdfa15aea9334d202a71b6bc30b0f3c210bfda6"

важно: половинки ключа могут храниться в памяти не по очереди "часть1, часть2", но и наоборот - "часть2, часть1", при расшифровке диска надо проверять оба варианта!
вот, например, два клона одной и той же виртуальной машины, запущенные одновременно:

- видно, что в одном клоне ключ хранится в памяти в виде "часть2, часть1", а во втором - "часть1, часть2"

чтобы расшифровать раздел с помощью мастер-ключа, нужно воспользоваться утилитой "dmsetup":
Код: Скопировать в буфер обмена
$ dmsetup create <название нового раздела> --table "<описание раздела>"
или
Код: Скопировать в буфер обмена
$ echo "<описание раздела>" | dmsetup create <название нового раздела>

где "описание раздела" это:
Код: Скопировать в буфер обмена
<начало данных> <размер данных> crypt <тип шифрования> <мастер-ключ> <отступ IV> /путь/к/шифрованному/разделу <отступ>

"начало данных" - номер сектора диска, откуда начинаются данные. в LUKS данные начинаются с первого же сектора, поэтому тут "0".
"отступ" - это объём служебных данных LUKS, пользовательские данные начинаются после этого отступа. размер отступа указывается в секторах диска, а не в байтах.
"отступ IV" - с какого сектора диска начитается вектор инициализации (IV) шифрования, в LUKS это значение равно "0".
"размер данных" - это длина шифрованного раздела в секторах минус отступ в секторах.
подробнее тут: https://www.kernel.org/doc/Documentation/device-mapper/dm-crypt.txt


для начала надо отмонтировать директорию из предыдущей части статьи, дезактивировать LVM, и зашифровать раздел обратно через "cryptsetup luksClose":

Код: Скопировать в буфер обмена

$ umount /root/shit/mnt
$ lvchange -an debian-luks-vg
$ cryptsetup luksClose asdf

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

$ fdisk -l /dev/nbd0p5
Disk /dev/nbd0p5: 9.52 GiB, 10223616000 bytes, 19968000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
$ cryptsetup luksDump /dev/nbd0p5 | grep -iE "(cipher|sector|offset)"
        offset: 16777216 [bytes]
        cipher: aes-xts-plain64
        sector: 512 [bytes]
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        Area offset:32768 [bytes]

- размер всего раздела = 19968000 секторов, тип шифра = aes-xts-plain64, отступ = 16777216 байт (нам нужен самый первый), размер сектора - 512 байт.

переводим размер отступа из байтов в секторы, разделив 16777216 на 512, получаем 32768.
размер раздела минус отступ = 19968000 - 32768 = 19935232 секторов, итого команда для расшифровки будет такая:

Код: Скопировать в буфер обмена
$ echo "0 19935232 crypt aes-xts-plain64 348e313062a99366e4b90ef97a17ef7e35c5f26a49dfef4ddd9bf6dbd9db14915f1dba602193936f855b06806bdfa15aea9334d202a71b6bc30b0f3c210bfda6 0 /dev/nbd0p5 32768" | dmsetup create xcxzczx

если мастер-ключ правильный, то dmsetup не выдаст никаких ошибок, а в директории /dev/mapper/ появится файл "xcxzczx".
вспоминаем предыдущий параграф про LVM, выполняем lvscan (и lvchange --activate y, если потребуется), монтируем раздел изнутри LVM в любую папку, и наблюдаем расшифрованные клиентские файлы:

а теперь проверим, найдёт ли findaes что-нибудь в снэпшоте VDS:

- да, нашлись те же самые две строки, то есть мастер ключ LUKS был успешно получен и из снэпшота, сделанного штатными средствами гипервизора.





и небольшое отступление: чтобы показать, что мастер-ключ был найден верно, я сделаю его дамп изнутри VDS, выполнив команду "cryptsetup luksDump /путь/к/зашифрованному/разделу --dump-master-key" и введя пароль шифрования (в моём случае "rockyou"):

- "MK dump" совпадает с тем, что было найдено в дампе оперативной памяти, и мы выяснили, что он действительно "allows access to encrypted partition without a passphrase"




3. получение информации из контейнера Veracrypt


представим такую ситуацию: ваш клиент помимо полнодискового шифрования LUKS решил дополнительно использовать криптоконтейнер Veracrypt для хранения самой важной информации. создал криптоконтейнер, положил в него самые смешные мемы с котятами, и забыл пароль...
до тех пор, пока криптоконтейнер примонтирован и VDS работает, мы можем помочь нашему клиенту!




создам контейнер и положу в него какой-нибудь файл с суперсекретным содержимым:

Код: Скопировать в буфер обмена

$ veracrypt --non-interactive -c /root/vera.bin --volume-type=normal --filesystem=none --size=104857600 --hash=SHA-512 --encryption=AES --random-source='/dev/urandom' -p udaudi7XeeC0zoo6ohgheSosieseeghe7
$ mkdir /vera
$ veracrypt --non-interactive --filesystem=none -p udaudi7XeeC0zoo6ohgheSosieseeghe7 /root/vera.bin /vera
$ mkfs.ext2 /dev/mapper/veracrypt1
$ veracrypt -d
$ veracrypt /root/vera.bin /vera 
$ echo 'top secret 1234567890 qwertyuiop' > /vera/supersecret.txt

забываю пароль от веракрипта и прошу хостера помочь...




залезаем внутрь виртуального диска клиента, воспользовавшись первой или второй частью этой статьи, и натыкаемся на файл с интересным названием "vera.bin" и необычно высокой энтропией:

- не снижающаяся на протяжении всего файла энтропия в 99.95% означает, что это зашифрованный контейнер.

создаём снэпшот VDS и парсим его с помощью findaes:

нашлось две комбинации 512-битных ключей -

первый ключ:
Код: Скопировать в буфер обмена

76 c1 2d cd fc 60 65 b7 23 5a 75 09 d2 26 52 1c 5c 4e bf 32 54 70 e4 1c 5e ce ab 46 20 46 80 ee
13 3b 29 94 d1 23 90 3a 8e 6a d5 b0 b7 e3 44 11 94 d8 5a 2f 3c 51 42 30 82 1d d8 4b 45 21 11 cb

13 3b 29 94 d1 23 90 3a 8e 6a d5 b0 b7 e3 44 11 94 d8 5a 2f 3c 51 42 30 82 1d d8 4b 45 21 11 cb
76 c1 2d cd fc 60 65 b7 23 5a 75 09 d2 26 52 1c 5c 4e bf 32 54 70 e4 1c 5e ce ab 46 20 46 80 ee

(почему-то в двух видах сразу - и "часть1, часть2", и "часть2, часть1")


и второй ключ, уже знакомый нам по пункту №2:
Код: Скопировать в буфер обмена

34 8e 31 30 62 a9 93 66 e4 b9 0e f9 7a 17 ef 7e 35 c5 f2 6a 49 df ef 4d dd 9b f6 db d9 db 14 91
5f 1d ba 60 21 93 93 6f 85 5b 06 80 6b df a1 5a ea 93 34 d2 02 a7 1b 6b c3 0b 0f 3c 21 0b fd a6

попробуем примонтировать зашифрованный файл с помощью dmsetup, вспомнив команду из второй части статьи:
Код: Скопировать в буфер обмена
$ echo "<начало данных> <размер данных> crypt <тип шифрования> <мастер-ключ> <отступ IV> /путь/к/шифрованному/разделу <отступ>" | dmsetup create <название нового раздела>

"cryptsetup luksDump" нам уже не поможет, поэтому тип шифра придётся подбирать из этого списка: https://www.veracrypt.fr/en/Encryption Algorithms.html
а другие параметры - с помощью гугла или методом научного тыка.
предположим, что клиент использовал шифрование типа AES, в этом случае тип шифра = "aes-xts-plain64"
...методом научного тыка было установлено, что отступ IV и отступ данных для шифрования AES в Veracrypt равняются 256 секторам. поиск размеров отступов для других методов шифрования оставляю читателю в качестве домашнего задания...

размер шифрованного файла в секторах - 204800
Код: Скопировать в буфер обмена

$ fdisk -l vera.bin
Disk vera.bin: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

вычитаем из 204800 всего секторов 256 секторов отступа данных и 256 секторов отступа IV, получаем размер данных внутри криптоконтейнера = 204288 секторов.

dmsetup не умеет работать напрямую с файлами, ему нужно "устройство диска", поэтому делаем из файла дисковое устройство с помощью тулзы losetup:
Код: Скопировать в буфер обмена

$ losetup -f # находим первое незанятое loop устройство
/dev/loop0
$ losetup /dev/loop0 ./vera.bin # привязываем это устройство к файлу

и расшифровываем это устройство с помощью dmsetup:
Код: Скопировать в буфер обмена
$ echo "0 204288 crypt aes-xts-plain64 76c12dcdfc6065b7235a7509d226521c5c4ebf325470e41c5eceab46204680ee133b2994d123903a8e6ad5b0b7e3441194d85a2f3c514230821dd84b452111cb 256 /dev/loop0 256" | dmsetup create zzzzzz
- dmsetup не выдал ошибки - значит, ключ был найден верно.
теперь монтируем устройство /dev/mapper/zzzzzz в любую папку и достаём все мемчики нашего клиента:

заметка: если ваш клиент использовал многоуровневое шифрование типа Serpent-Twofish-AES, то надо найти в дампе памяти три ключа (то есть наоборот: если в дампе памяти нашлось три разных набора ключей - то это значит, что ваш клиент использовал тройное шифрование), и примонтировать файл с помощью dmsetup три раза по очереди - сначала в режиме serpent-xts-plain64, потом twofish-xts-plain64, и потом aes-xts-plain64.
а точнее, придётся перебрать в dmsetup все возможные комбинации типов шифрования используя все найденные в памяти ключи, подробнее тут: https://blog.elcomsoft.com/2021/06/...ng-and-extracting-on-the-fly-encryption-keys/

ElcomSoft сказал(а):
In VeraCrypt, information about the encryption algorithm or the KDF is never saved in the disk header. When encrypting the disk, users have the choice of 15 encryption algorithms (including combinations) and 5 hash functions. That makes it 15×5=75 possible combinations of symmetric ciphers and one-way hash functions to try. If you don’t know exactly which cipher and which hash function has been used to encrypt the container, you’ll have to try all of the 75 combinations ...
Нажмите, чтобы раскрыть...

... умножаем ещё на 2, потому что мастер-ключ в памяти может храниться "задом наперёд" и получаем 150 комбинаций (или 20 строк кода на вашем любимом скриптовом языке для перебора всех вариантов )




4. выводы и копирайты

- хостинг провайдер может беспрепятственно достать заголовок шифрованного диска клиента и сбрутить пароль от диска. конкретно этот метод слива клиентских данных помощи клиентам в доставании их данных будет работать всегда: даже если хостер шифрует оперативную память VDS (в чём я сильно сомневаюсь), то образ виртуального диска VDS всегда лежит на хостовой системе в открытом виде.
- если оперативная память VDS не шифруется на уровне процессора с помощью технологии Intel TDX или AMD SEV, то хостинг провайдер может беспрепятственно получить доступ к данным на зашифрованном диске внутри запущенного VDS (после того, как клиент введёт пароль от диска и мастер-ключ запишется в оперативную память VDS), включая данные внутри примонтированного шифрованного контейнера типа Truecrypt или Veracrypt (после того, как клиент введёт пароль от криптоконтейнера)
- исходя из вышесказанного: виртуальные сервера не подходят для хранения самых ценных мемов с котятами, а годятся только для баянов.

скорее всего у этого топика будет небольшое, но очень интересное продолжение, когда именно - пока неизвестно.

буду благодарен, если кто-нибудь напишет инструкцию по настройке Proxmox VE или VMWare ESXI для включения шифрования оперативной памяти виртуалок (AMD SEV или Intel TDX).
также, если кто-то разбирается в работе этих технологий, приглашаю для дискуссии сюда: https://xss.is/threads/97855/


автор я ( https://xss.is/members/296627/ ), распространять разрешаю только при указании ссылки на этот топик ( https://xss.is/threads/98554/ )

донаты на жестокое обращение с компьютерами слать сюда: 1dprEpsBVpjXfiaBtwyFp5X7Dtfs5VVR1