инструкция для хостера: помогаем забывчивому клиенту достать данные с VDS
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/
другие хостеры тоже продают якобы "dedicated server", но на самом деле виртуалку - они запускают на выделенном сервере гипервизор (софт для управления виртуалками) и создают единственную виртуальную машину, выделяя ей почти все ресурсы сервера (оставляя минимальный кусочек процессора и оперативы для гипервизора), при этом клиенту доступ к гипервизору не выдают.
вот пример одного из таких говнохостеров (один из крупнейших хостингов в мире, кстати): https://www.hostgator.com/help/article/do-you-allow-kvm-on-a-dedicated-server
теперь немного о шифровании оперативной памяти: ходят слухи, что у современных процессоров есть функция шифрования оперативной памяти виртуальной машины, чтобы с хостовой системы было невозможно прочитать память гостевой системы, но я этим слухам не верю.
точнее, в существование-то этой функции я верю, вот документация от Интеля: https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
а вот от AMD: https://www.amd.com/en/developer/sev.html
(а вот топик с обсуждением на ХСС: https://xss.pro/threads/97855/ )
но я не верю в использование этой функции хостерами: сложно себе представить, что хостинг провайдер добровольно откажется от доступа к данным своих клиентов.
резюмируя: не ведитесь на маркетинговый буллщит, арендуйте именно выделенные сервера, а не виртуалки!
далее для описания виртуальной машины я буду использовать аббревиатуру "VDS".
действия хостера буду выделять красным цветом, а действия клиента хостинга - зелёным
в качестве гипервизора я буду использовать Proxmox (не совсем ынтырпрайз решение, но некоторые популярные хостеры используют именно его), и в качестве гостевой системы - Debian 11.
1. брут пароля от шифрованного диска через дамп заголовка LUKS
представим такую ситуацию: ваш клиент зашифровал диск своего VDS, забыл от него пароль и просит помочь вспомнить.
для начала создам VDS и установлю в него Debian с полнодисковым шифрованием LUKS (для демонстрации я буду использовать простой пароль "rockyou", находящийся в самом начале популярного ворлдиста, чтобы он быстро сбрутился, а для быстроты установки я выберу минимальный набор ПО с консольным интерфейсом вместо предложенного по умолчанию графического):
после установки системы и ребута сервер просит расшифровать диск:
расшифрую диск и посмотрю информацию о шифрованном разделе, видимую изнутри VDS:
теперь я забываю пароль и прошу хостера помочь достать данные с зашифрованного диска...
чтобы сделать дамп заголовка LUKS, сначала нужно найти этот раздел внутри виртуального диска VDS, так как разметка диска хостеру неизвестна - клиент мог насоздавать кучу разделов и зашифровать любой из них.
посмотрим, где в ОСи гипервизора лежит виртуальный диск клиента (можно посмотреть и в Web GUI гипервизора, но мы же простых путей не ищем!):
открываем файл-диск hex редактором:
и ищем начало шифрованного раздела: оно представляет собой строку ASCII "LUKS", сразу после которой идут два символа hex "BA BE", а чуть позже идёт ASCII строка вида "aes" или "sha".
- это НЕ начало раздела LUKS, потому что дальше идут какие-то "SKUL" и "Invalid" вместо "sha" или "aes", ищем дальше...
- а вот и оно, шифрованный раздел начинается с адреса hex 0x1E950000.
размер заголовка LUKS, если мне не изменяет память, 2 мегабайта, но cryptsetup отказывается показывать информацию по файлам размером меньше 16 мегабайт, поэтому для демонстрации команды "cryptsetup luksDump" я скопирую 16 мегабайт вместо 2:
и вот мы получили информацию о шифрованном разделе VDS, будучи внутри гипервизора, а не внутри VDS (проскроллив топик выше вы увидите, что данные совпадают с теми, что выводит "cryptsetup luksDump" изнутри VDS)
теперь можно брутить этот заголовок, чтобы получить пароль шифрования диска.
но есть один нюанс...
на сегодня ( 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 ядро", но для демонстрации её более чем достаточно:
- пароль получен, теперь можно спокойно открывать зашифрованный диск и доставать данные клиента. копируем куда-нибудь виртуальный жёсткий диск:
монтируем его в хостовой системе с помощью тулзы qemu-nbd (может понадобиться "modprobe nbd"):
и видим все разделы виртуального диска в файлах /dev/nbd0p*:
теперь ищем среди этих разделов зашифрованный: заветные строки ASCII "LUKS" + hex "BA BE" + (чуть позже) ASCII "sha" или ASCII "aes" должны быть в самом начале файла, если их там нет - берём следующий:
(что-то я затупил, можно было сразу так сделать для поиска зашифрованного раздела и дампа заголовка LUKS)
зашифрованный раздел - /dev/nbd0p5, расшифровываем его с помощью cryptsetup и вводим сбрученный выше пароль "rockyou":
если пароль правильный, то cryptsetup не выдаст никаких ошибок, а в директории /dev/mapper/ появится файл "asdf". создаём новую директорию с любым названием и монтируем файл /dev/mapper/asdf в неё:
- оказалось, что вместо простой файловой системы клиент в зашифрованном разделе создал структуру LVM, которая может состоять из нескольких виртуальных разделов.
для того, чтобы примонтировать разделы внутри LVM нужно сначала активировать LVM с помощью команды "lvchange --activate y <имя LVM>", а имя LVM можно узнать с помощью команды "lvscan":
- в моём случае "pve" - это LVM гипервизора Proxmox, а вот "debian-luks-vg" - это LVM виртуальной машины
- после активации 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 на "другом сервере":
запускаем клиент iperf на тестовой виртуалке:
чтобы продемонстрировать, что это не фотошоп, а реальный дамп памяти, "клиент" откроет на 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-битные ключи
обращаем внимание на идущие подряд hex адреса 0x89d4b8a0 и 0x89d4baa0 и понимаем, что эти две строки по 256 бит и есть искомая 512-битная строка.
получается, что мастер-ключ LUKS - это строка "348e313062a99366e4b90ef97a17ef7e35c5f26a49dfef4ddd9bf6dbd9db14915f1dba602193936f855b06806bdfa15aea9334d202a71b6bc30b0f3c210bfda6"
важно: половинки ключа могут храниться в памяти не по очереди "часть1, часть2", но и наоборот - "часть2, часть1", при расшифровке диска надо проверять оба варианта!
вот, например, два клона одной и той же виртуальной машины, запущенные одновременно:
- видно, что в одном клоне ключ хранится в памяти в виде "часть2, часть1", а во втором - "часть1, часть2"
чтобы расшифровать раздел с помощью мастер-ключа, нужно воспользоваться утилитой "dmsetup":
или
где "описание раздела" это:
"начало данных" - номер сектора диска, откуда начинаются данные. в LUKS данные начинаются с первого же сектора, поэтому тут "0".
"отступ" - это объём служебных данных LUKS, пользовательские данные начинаются после этого отступа. размер отступа указывается в секторах диска, а не в байтах.
"отступ IV" - с какого сектора диска начитается вектор инициализации (IV) шифрования, в LUKS это значение равно "0".
"размер данных" - это длина шифрованного раздела в секторах минус отступ в секторах.
подробнее тут: https://www.kernel.org/doc/Documentation/device-mapper/dm-crypt.txt
для начала надо отмонтировать директорию из предыдущей части статьи, дезактивировать LVM, и зашифровать раздел обратно через "cryptsetup luksClose":
теперь смотрим размер шифрованного раздела в секторах, вспоминаем тип шифра мастер-ключа, и смотрим отступ откуда в шифрованном разделе начинаются данные (а так как cryptsetup показывает отступ в байтах, а нам нужен в секторах, то ещё смотрим размер сектора):
- размер всего раздела = 19968000 секторов, тип шифра = aes-xts-plain64, отступ = 16777216 байт (нам нужен самый первый), размер сектора - 512 байт.
переводим размер отступа из байтов в секторы, разделив 16777216 на 512, получаем 32768.
размер раздела минус отступ = 19968000 - 32768 = 19935232 секторов, итого команда для расшифровки будет такая:
если мастер-ключ правильный, то 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 работает, мы можем помочь нашему клиенту!
создам контейнер и положу в него какой-нибудь файл с суперсекретным содержимым:
забываю пароль от веракрипта и прошу хостера помочь...
залезаем внутрь виртуального диска клиента, воспользовавшись первой или второй частью этой статьи, и натыкаемся на файл с интересным названием "vera.bin" и необычно высокой энтропией:
- не снижающаяся на протяжении всего файла энтропия в 99.95% означает, что это зашифрованный контейнер.
создаём снэпшот VDS и парсим его с помощью findaes:
нашлось две комбинации 512-битных ключей -
первый ключ:
(почему-то в двух видах сразу - и "часть1, часть2", и "часть2, часть1")
и второй ключ, уже знакомый нам по пункту №2:
попробуем примонтировать зашифрованный файл с помощью dmsetup, вспомнив команду из второй части статьи:
"cryptsetup luksDump" нам уже не поможет, поэтому тип шифра придётся подбирать из этого списка: https://www.veracrypt.fr/en/Encryption Algorithms.html
а другие параметры - с помощью гугла или методом научного тыка.
предположим, что клиент использовал шифрование типа AES, в этом случае тип шифра = "aes-xts-plain64"
...методом научного тыка было установлено, что отступ IV и отступ данных для шифрования AES в Veracrypt равняются 256 секторам. поиск размеров отступов для других методов шифрования оставляю читателю в качестве домашнего задания...
размер шифрованного файла в секторах - 204800
вычитаем из 204800 всего секторов 256 секторов отступа данных и 256 секторов отступа IV, получаем размер данных внутри криптоконтейнера = 204288 секторов.
dmsetup не умеет работать напрямую с файлами, ему нужно "устройство диска", поэтому делаем из файла дисковое устройство с помощью тулзы losetup:
и расшифровываем это устройство с помощью dmsetup:
- 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/
)
4. выводы и копирайты
- хостинг провайдер может беспрепятственно достать заголовок шифрованного диска клиента и сбрутить пароль от диска. конкретно этот методслива клиентских данных помощи клиентам в доставании их данных будет работать всегда: даже если хостер шифрует оперативную память VDS (в чём я сильно сомневаюсь), то образ виртуального диска VDS всегда лежит на хостовой системе в открытом виде.
- если оперативная память VDS не шифруется на уровне процессора с помощью технологии Intel TDX или AMD SEV, то хостинг провайдер может беспрепятственно получить доступ к данным на зашифрованном диске внутри запущенного VDS (после того, как клиент введёт пароль от диска и мастер-ключ запишется в оперативную память VDS), включая данные внутри примонтированного шифрованного контейнера типа Truecrypt или Veracrypt (после того, как клиент введёт пароль от криптоконтейнера)
- исходя из вышесказанного: виртуальные сервера не подходят для хранения самых ценных мемов с котятами, а годятся только для баянов.
скорее всего у этого топика будет небольшое, но очень интересное продолжение, когда именно - пока неизвестно.
буду благодарен, если кто-нибудь напишет инструкцию по настройке Proxmox VE или VMWare ESXI для включения шифрования оперативной памяти виртуалок (AMD SEV или Intel TDX).
также, если кто-то разбирается в работе этих технологий, приглашаю для дискуссии сюда: https://xss.pro/threads/97855/
автор я ( https://xss.pro/members/296627/ ), распространять разрешаю только при указании ссылки на этот топик ( https://xss.pro/threads/98554/ )
донаты на жестокое обращение с компьютерами слать сюда: 1dprEpsBVpjXfiaBtwyFp5X7Dtfs5VVR1
моя работа над 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/
другие хостеры тоже продают якобы "dedicated server", но на самом деле виртуалку - они запускают на выделенном сервере гипервизор (софт для управления виртуалками) и создают единственную виртуальную машину, выделяя ей почти все ресурсы сервера (оставляя минимальный кусочек процессора и оперативы для гипервизора), при этом клиенту доступ к гипервизору не выдают.
вот пример одного из таких говнохостеров (один из крупнейших хостингов в мире, кстати): https://www.hostgator.com/help/article/do-you-allow-kvm-on-a-dedicated-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.pro/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 -c /dev/nbd0 -f qcow2 /root/shit/vm-102-disk-0.qcow2
Код:
$ 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>")
- по
я сделаю дамп двумя способами - снэпшот из 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и второй ключ, уже знакомый нам по пункту №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теперь монтируем устройство /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/
... умножаем ещё на 2, потому что мастер-ключ в памяти может храниться "задом наперёд" и получаем 150 комбинаций (или 20 строк кода на вашем любимом скриптовом языке для перебора всех вариантовElcomSoft сказал(а):
)4. выводы и копирайты
- хостинг провайдер может беспрепятственно достать заголовок шифрованного диска клиента и сбрутить пароль от диска. конкретно этот метод
- если оперативная память VDS не шифруется на уровне процессора с помощью технологии Intel TDX или AMD SEV, то хостинг провайдер может беспрепятственно получить доступ к данным на зашифрованном диске внутри запущенного VDS (после того, как клиент введёт пароль от диска и мастер-ключ запишется в оперативную память VDS), включая данные внутри примонтированного шифрованного контейнера типа Truecrypt или Veracrypt (после того, как клиент введёт пароль от криптоконтейнера)
- исходя из вышесказанного: виртуальные сервера не подходят для хранения самых ценных мемов с котятами, а годятся только для баянов.
скорее всего у этого топика будет небольшое, но очень интересное продолжение, когда именно - пока неизвестно.
буду благодарен, если кто-нибудь напишет инструкцию по настройке Proxmox VE или VMWare ESXI для включения шифрования оперативной памяти виртуалок (AMD SEV или Intel TDX).
также, если кто-то разбирается в работе этих технологий, приглашаю для дискуссии сюда: https://xss.pro/threads/97855/
автор я ( https://xss.pro/members/296627/ ), распространять разрешаю только при указании ссылки на этот топик ( https://xss.pro/threads/98554/ )
донаты на жестокое обращение с компьютерами слать сюда: 1dprEpsBVpjXfiaBtwyFp5X7Dtfs5VVR1
Последнее редактирование:
LUKS в нём тестить бессмысленно, потому что и так понятно, что все ключи найдутся.