Intel TDX / AMD SEV. использование защищённых анклавов для прятания от аверов?

[Dread Pirate Roberts]

есть такие интересные технологии, как Intel TDX https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
или AMD SEV https://www.amd.com/en/developer/sev.html
или заброшенный Intel SGX.

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

дискасс.

 

[Dread Pirate Roberts]

del

 

[coder]

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

 

[Dread Pirate Roberts]

Даже если ты спрячешь что то в анклаве, полезная нагрузка всё равно должна будет в том или ином виде существовать на машине, чтобы реализовать анклав

естественно. но на функцию создания анклава ни один авер не заикнётся, в отличие от обычных функций всякой малвари.

Ну хз, чего мы добьёмся этим, спасёт разве что от мемдетектов того что будет крутиться в анклаве, не более

бесконечно живущих ботов?

 

[coder]

естественно. но на функцию создания анклава ни один авер не заикнётся, в отличие от обычных функций всякой малвари.

бесконечно живущих ботов?

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

 

[DildoFagins]

это идеальное место жительства

Это все хорошо звучит на бумаге, но во-первых нужна поддержка на аппаратном уровне (как для SGX, так для VBS анклавов, если мы говорим о венде, как о хосте), а во-вторых даже в аппаратной реализации бывают уязвимости, для примера (я нихера из этого не понял, но уязвимости - это в принципе неизбежно): https://arstechnica.com/information...me-intel-cpus-is-more-bad-news-for-sgx-users/

 

[Dread Pirate Roberts]

её нужно будет криптовать

зачем? в том-то и прикол, что не надо ничего криптовать - внутри защищённой виртуальной машины нет антивиндуса, и снаружи он никак не узнает, что там запущено внутри.

 

[DildoFagins]

внутри защищённой виртуальной машины нет антивиндуса

Внутри защищенной "виртуальной машины" нет сисколлов, для взаимодействия со внешним миром нужен код вне анклава.

 

[Dread Pirate Roberts]

Внутри защищенной "виртуальной машины" нет сисколлов, для взаимодействия со внешним миром нужен код вне анклава.

если создать не просто мини-хранилище для данных с помощью SGX, а полноценную виртуальную машину с помощью TDX, то там целую операционную систему запустить можно.

короче, нужен кто-то, кто уже работал с этими технологиями, и может объяснить на пальцах, как они работают, а особенно как работает сеть (между хостом и гостем и между гостем и миром).

 

[coree]

софтварный анклав

Правильно ли я понимаю что речь о enclaveapi.h? Встроенном апи для винды

 

[coder]

Правильно ли я понимаю что речь о enclaveapi.h? Встроенном апи для винды

Я говорил о реализации софтварного анклава, которая описывалась инди. В реализацию на винапи я не вникал, по ней инчего сказать не могу

 

[SadisticApe]

there are such interesting technologies as Intel TDX https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
or AMD SEV https://www.amd.com/en/developer/sev.html
or the abandoned Intel SGX.

These technologies are designed to create secure enclaves in the computer's RAM, which no one except the owner/creator of the enclave can access. technologies are focused on the web hosting industry, namely the creation of virtual machines with encrypted RAM (only the encryption key is stored in the enclave, because the volume of the enclave is very small)
theoretically, a hypervisor with TDX/SEV enabled will not be able to receive data inside the virtual machine. that is, the hoster will not be able to steal the data of a client who purchased a VDS from this hoster.
and now let's look at it from the other side: it turns out that SEV/TDX/SGX is an amazing technology for hiding all sorts of goodness, because no anti-Windows can get inside a protected enclave. Of course, all sorts of lockers, stealers and HVNC will not work, because you cannot get out of the enclave into the host system, but for software that does not need a host system - such as Sox or Dudos bots - this is an ideal place of residence.

discass.

socks? the code would still need to get out of the enclave and perform syscalls for those socket operations.
best they can do is hide the `setup` (eg the protocol) inside the encrypted memory, but at the end of the day, everything will be out in the open once it interacts with the OS syscalls.

from my understanding, these technologies are only useful to add safeguards on specific pieces of the code which people may consider sensitive, sort of like using code virtualization techniques, but on another level.

 

[Dread Pirate Roberts]

socks? the code would still need to get out of the enclave and perform syscalls for those socket operations.
best they can do is hide the `setup` (eg the protocol) inside the encrypted memory, but at the end of the day, everything will be out in the open once it interacts with the OS syscalls.

from my understanding, these technologies are only useful to add safeguards on specific pieces of the code which people may consider sensitive, sort of like using code virtualization techniques, but on another level.

you did not get it: we could create a virtual machine with a completely different operating system inside, and hide its memory from the host operating system using SEV/TDX.
the software inside the virtualized OS will use syscalls of the virtualized OS, not of the host OS; the host OS will see only virtualization syscalls, 100% legit and clean for antiviruses. of course the AVs will also see the network communication, but if the target domains/IPs are clean then AVs will not react.

 

[Dread Pirate Roberts]

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

Исследователи Центра Гельмгольца по информационной безопасности (CISPA) опубликовали новый метод атаки CacheWarp, позволяющий скомпрометировать механизм защиты AMD SEV (Secure Encrypted Virtualization), применяемый в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы. Предложенный метод позволяет злоумышленнику, имеющему доступ к гипервизору, добиться выполнения стороннего кода и повышения привилегий в виртуальной машине, защищённой при помощи AMD SEV.
Атака основана на использовании уязвимости (CVE-2023-20592), вызванной некорректной работой с кэшем во время выполнения процессорной инструкции INVD, при помощи которой можно добиться рассогласования данных в памяти и кэше, и обойти механизмы поддержания целостности памяти виртуальных машин, реализованные на базе расширений SEV-ES и SEV-SNP. Уязвимость затрагивает процессоры AMD EPYC с первого по третье поколения.

...

Для проверки своих систем на наличие уязвимости опубликован прототип эксплоита, позволяющий выполнить подстановку исключения в виртуальную машину, защищённую через AMD SEV, и откатить в старое состояние несброшенные в память изменения в VM. Откат изменения может быть использован для изменения хода выполнения программы через возвращение старого адреса возврата в стеке или для использования при входе параметров старого сеанса, для которого ранее была выполнена аутентификация, через возвращение значения признака аутентификации.
Например, исследователями продемонстрирована возможность применения метода CacheWarp для совершения атаки Bellcore на реализацию алгоритма RSA-CRT в библиотеке ipp-crypto, позволившей восстановить закрытый ключ через подстановку ошибок при вычислении цифровой подписи. Также показано как можно подменить параметры проверки сеанса к OpenSSH при удалённом подключении к гостевой системе, а затем изменить состояние проверки при выполнении утилиты sudo для получения прав root в Ubuntu 20.04. Работа эксплоита проверена на системах с процессорами AMD EPYC 7252, 7313P и 7443.

 

[Dread Pirate Roberts]

Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of...

arxiv.org

"Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation"

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in cloud scenarios. AMD SEV encrypts the main memory of virtual machines with VM-specific keys, thereby denying the higher-privileged hypervisor access to a guest's memory. To enable the cloud customer to verify the correct deployment of his virtual machine, SEV additionally introduces a remote attestation protocol.This paper analyzes the firmware components that implement the SEV remote attestation protocol on the current AMD Epyc Naples CPU series. We demonstrate that it is possible to extract critical CPU-specific keys that are fundamental for the security of the remote attestation protocol.Building on the extracted keys, we propose attacks that allow a malicious cloud provider a complete circumvention of the SEV protection mechanisms. Although the underlying firmware issues were already fixed by AMD, we show that the current series of AMD Epyc CPUs, i.e., the Naples series, does not prevent the installation of previous firmware versions. We show that the severity of our proposed attacks is very high as no purely software-based mitigations are possible. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider. To overcome these issues, we also propose robust changes to the SEV design that allow future generations of the SEV technology to mitigate the proposed attacks.

 

[Yuji0x01]

Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of...

arxiv.org

"Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation"

thanks for the info ^_^ i really enjoyed reading this...keep on <3

 

[jaskolka]

есть такие интересные технологии, как Intel TDX https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
или AMD SEV https://www.amd.com/en/developer/sev.html
или заброшенный Intel SGX.

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

дискасс.

Хочу уточнить, получается речь идет именно о том, что АВ на хостовой ОС не могут видеть память VM, но многие АВ для тех же ESXI выдают сенсоры, которые как раз ставятся на ВМ и по сути сенсор работает внутри сессии и имеет доступ к анклаву? Или я неправильно что понял?

/upd чуть вник в вопрос, из того что понял простыми словами, функция SEV на новых процессорах AMD обеспечивает шифрование ОЗУ на VM (для ее защиты от хостовой ОС) на гипервизорах KVM/QEMU/Hyper-V/ESXI/Xen/, соответственно vbox/VMware Workstation не того уровня гипервизор, и ВМ не имеет доступа к железу напрямую и берет все (соответственно и ОЗУ) из хостовой ОС.

Также хочу добавить для тех кто будет разбираться в этом, что функция SEV это именно аппаратная опция направленная на защиту ОЗУ в ВМ, и не стоит ее путать с TSME (Transparent Secure Memory Encryption), т.к. SME это отдельная опция которая обеспечивает аппаратное шифрование ОЗУ с целью защиты от несанкционированного дампа, к примеру таких как холодные загрузки, и тд. По идеи их нужно комбинировать эти опции/

Dread Pirate Roberts, ты не тестировал снятие дампа, например через те же снапшоты с хостовой ОС? Насколько можно обеспечить безопасность ВМ с включенным SEV и полносистемным шифрованием ОС?​

 

[Dread Pirate Roberts]

Хочу уточнить, получается речь идет именно о том, что АВ на хостовой ОС не могут видеть память VM, но многие АВ для тех же ESXI выдают сенсоры, которые как раз ставятся на ВМ и по сути сенсор работает внутри сессии и имеет доступ к анклаву?

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

ты не тестировал снятие дампа, например через те же снапшоты с хостовой ОС?

тестировал снятие дампа с НЕ шифрованных ВМ: https://xss.pro/threads/98554/
с шифрованными ВМ дел не имел, и разбираться с TXD/SEV некогда, буду рад, если кто-нибудь разберётся и сделает демонстрацию и/или напишет мануал по настройке.

Насколько можно обеспечить безопасность ВМ с включенным SEV и полносистемным шифрованием ОС?

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

 

[jaskolka]

Включил в биосе 5 опций отвечающих за шифрования ОЗУ:

1. TSME (Transparent Secure Memory Encryption)​

Определение: Transparent Secure Memory Encryption (TSME) — это технология аппаратного шифрования оперативной памяти, которая автоматически шифрует данные при записи в память и расшифровывает их при чтении. TSME обеспечивает шифрование всего содержимого оперативной памяти без необходимости модификации операционной системы или приложений, работая прозрачно для них.

Назначение: TSME предназначен для защиты данных в оперативной памяти от несанкционированного доступа, даже если злоумышленник имеет физический доступ к оборудованию.

2. SVM Enable (Secure Virtual Machine Enable)​

Определение: Secure Virtual Machine (SVM) Enable — это настройка в BIOS, которая активирует поддержку технологий виртуализации процессора AMD, включая поддержку SEV (Secure Encrypted Virtualization). Включение SVM позволяет гипервизору использовать возможности виртуализации, предоставляемые процессором.

Назначение: SVM Enable необходимо для включения аппаратной поддержки виртуализации на уровне процессора, что позволяет запускать и управлять виртуальными машинами (ВМ).

3. SMEE (Secure Memory Encryption Enable)​

Определение: Secure Memory Encryption Enable (SMEE) — это настройка в BIOS, которая активирует функцию Secure Memory Encryption (SME). SME обеспечивает шифрование данных в оперативной памяти с использованием аппаратных средств процессора.

Назначение: SMEE используется для защиты данных в оперативной памяти от несанкционированного доступа, шифруя все данные, хранящиеся в памяти.

4. SNP Memory (RMP Table) Coverage​

Определение: SNP Memory (RMP Table) Coverage — это настройка в BIOS, которая определяет, какой объем системной памяти будет покрыт технологией Secure Nested Paging (SNP). SNP использует таблицы управления памятью (RMP — Reverse Mapping Table) для защиты и изоляции данных виртуальных машин (ВМ).

Назначение: Включение SNP Memory Coverage обеспечивает защиту всей системной памяти с помощью SNP, улучшая безопасность виртуализированных сред и защищая данные ВМ от атак.

5. SVM Lock​

Определение: SVM Lock — это настройка в BIOS, которая позволяет заблокировать или разблокировать использование функций Secure Virtual Machine (SVM) после включения. Когда SVM Lock включен, любые изменения настроек виртуализации SVM будут заблокированы, предотвращая несанкционированные изменения.

На скрине лог изменений в биос, SVM Lock оставил в режиме "авто", как он и стоял, поэтому изменений в логе нет, и TSME уже был включен, по сути на скрине только опции SEV включил.

В качестве хоста у меня Linux Mint, в качестве гипервизоры - Virt-manager QEMU/KVM, галочка на "host-passthrough" стоит включенной.

Дампил ОЗУ с хоста командой:

sudo virsh dump --memory-only --domain win10 '/home/user/Рабочий стол/forensics/win10_ram_dump.raw',

что я делал не так - не знаю, но по итогу в дампе ОЗУ успешно нашлись мастер-ключи, которые должны быть зашифрованы SEV

Уверен, что где-то я что-то неправильно сделал, или не включил, тыкните пожалуйста кто знает в чем проблема?


//upd 1

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

libvirt: Launch security with AMD SEV

libvirt, virtualization, virtualization API

libvirt.org

GitHub - AMDESE/AMDSEV: AMD Secure Encrypted Virtualization

AMD Secure Encrypted Virtualization. Contribute to AMDESE/AMDSEV development by creating an account on GitHub.

github.com

AMD Secure Encrypted Virtualization (AMD-SEV) Guide | SLES 15 SP5

documentation.suse.com

https://www.amd.com/pt/developer/sev.html

AMD Secure Encrypted Virtualization (SEV) — QEMU documentation

www.qemu.org

//upd 2

Самое главное, так это то, что вообще непонятно зачем тестировать SEV на Qemu/KVM, т.к. это подразумевает локальный запуск ВМ с доверенного хоста. Только ради того, чтоб увидеть что SEV защищает ОЗУ и увидеть это на тесте.. Возможно протестирую на ESXI

 

[Dread Pirate Roberts]

Самое главное, так это то, что вообще непонятно зачем тестировать SEV на Qemu/KVM, т.к. это подразумевает локальный запуск ВМ с доверенного хоста. Только ради того, чтоб увидеть что SEV защищает ОЗУ и увидеть это на тесте.. Возможно протестирую на ESXI

да, в первую очередь надо убедиться, что ты и на обычном дистрибутиве не можешь прочитать данные виртуалки, а потом уже сооружать типичный "cloud hosting environment"
если память читается - то или SEV не работает, или ты что-то делаешь не так.