В век облачных технологий, когда у каждого пользователя есть собственное облако для хранения фотографий, а компании арендуют сервера для облачных вычислений, встает вопрос о конфиденциальности хранимой информации. И если пользователи для защиты хранимых данных могут обойтись доверием к облаку или использованием крипто контейнеров, то у компаний дела обстоят хуже. Так как в облака переносится не только хранилище данных, но и сами вычисления.
Особенно страдает защита виртуальных машин, так как в случае компрометации хоста, не составит труда получить доступ к ВМ. До недавнего времени ни один из гипервизоров будь то VMware, Xen, Hyper-V не предоставляли каких-либо значимых технологий по защите ВМ.
А если злоумышленник получит физический доступ к серверу, то спасти может только шифрование дисков, и то не во всех случаях. Конечно арендуя сервер, часть защитных мер берет на себя дата центр. Но в таком случае необходимо доверять администраторам дата центра.
С релизом Windows Server 2016, в Microsoft решили уделить больше внимания безопасности хоста и виртуальной инфраструктуры. Появилась возможность изолировать ВМ от администратора хоста Hyper-V. А используя виртуальный TPM стало возможным шифрование данных ВМ с помощью bitlocker.
Таким образом используя новые технологии можно размещать виртуальные машины на неподконтрольных серверах или в корпоративных дата центрах, но с повышенным уровнем безопасности, разграничивая роли физического и виртуального доступа.
Используемые технологии
Shielded VM – технология изолирующая виртуальную машину от хоста. Защищает ВМ от случайных или преднамеренных действий администратора хоста и от вредоносного программного обеспечения.
Для работы Shielded VM необходимо наличие сервера Host Guardian Service(HGS), который выдает ключи доступа к ВМ и проверяет здоровье хоста Hyper-V.
HGS поддерживает два вида аттестации:
- TPM-trusted аттестация – проверка проходит на основе идентификатора TPM, последовательности загрузки ОС и политики целостности кода. Таким образом можно быть уверенным, что на хосте работает только одобренный код.
- Admin-trusted аттестация – проверка происходит на основе принадлежности к группе безопасности Active Directory.
Схема работы HGS
При запуске виртуальной машины защищённый хост проходит аттестацию у HGS сервера, который принимает решение о передачи ключей доступа к виртуальной машине.
Admin-trusted аттестацию целесообразно использовать внутри предприятия, когда нужно изолировать доступ к ВМ от администраторов.
TPM-trusted аттестацию лучше использовать при размещении ВМ на арендованном сервере, чтобы обеспечить изоляцию данных и ВМ от работников Дата Центра.
Связь сервера HGS и защищённого хоста осуществляется по http (https) протоколу. HTTPS не требуется, для обеспечения безопасной связи, но, если вы захотите включить HTTPS, вам потребуется дополнительный сертификат. В случае AD аттестации необходимо дополнительно настроить односторонний доменный траст.
Virtual Secure Mode (VSM) – технология работающая на основе виртуализации, которая позволяет изолировать критические для безопасности операции в мини ОС.
На VSM работают две другие технологии:
- Device Guard – проверка данных UEFI прошивки и драйверов режима ядра (контроль целостности кода).
- Credential Guard – изоляция процесса аутентификации пользователей (LSA).
Принцип работы VSM
Основная ОС запускается в виртуальном окружении. А гипервизор выступает в роли хостовой ОС, тем самым ограничивая доступ к оперативной памяти. В итоге вредоносное ПО запущенное на хосте даже с администраторскими правами не сможет получить доступ к памяти VSM. Также такая структура должна защищать от атаки на DMA порты.
Об организации Shielded VM
Заказывая Shielded VM подразумевается, что хост Hyper-V и сервер HGS находятся на стороне дата центра (так организованно в Microsoft Azure). В таком случае создавать экранированную виртуальную машину можно самостоятельно или используя предоставленный шаблон.
Создавая Shielded VM самостоятельно заказчик у себя на ПК разворачивает и настраивает ВМ, а потом шифрует ключом выданным Дата Центром. После переносит ВМ в Дата Центр.
Во втором случае, заказчик создает только PDK файл, защищающий ВМ созданную из шаблона. PDK файл связывает файл шаблона с HGS сервером. Но необходимо убедиться, что в шаблоне нет вредоносного ПО.
Первый способ выглядит более безопасным, так как файл данных ВМ попадает на хост в уже шифрованном виде. В любом случае ключи доступа к ВМ не попадают к администраторам Дата Центра в открытом виде.
Единственным местом подверженным атакам остался HGS сервер. Так как:
- Администратор HGS может понизить требования к политике безопасности.
- Злоумышленник получивший администраторские права может попробовать получить ключи доступа.
- Для работы HGS требуется AD и нет требования к обязательному наличию TPM, следовательно, ключи вероятней всего будут храниться в открытом виде.
Исходя из этого появилась, идея проверить возможность работы Shielded VM в условиях, когда сервер HGS размещается в своей инфраструктуре. Это еще больше обезопасит виртуальные машины. Также такой способ можно использовать если Дата Центр не предоставляет услугу Shielded VM. Минус этого подхода в том, что придётся самостоятельно администрировать эту структуру.
Может возникнуть вопрос о подмене сервера HGS администратором гипервизора — ведь для этого необходимо просто указать новый адрес. Защита от этого реализована достаточно просто, созданная ВМ зашифрована с использованием открытого ключа HGS сервера, поэтому другой HGS сервер не сможет выдать ключи для ее запуска.
Также стоит понимать, что технология Shielded VM шифрует только конфигурационные файлы виртуальной машины. VHDX файл остаётся незашифрованным. Для его шифрования нужно включить vTPM, и зашифровать диск битлокером.
Сочетание новых технологий предоставляет надежную защиту:
- человеческий фактор устранен;
- ключи передаются в зашифрованном виде;
- серверы защищены новыми технологиями, предусматривающими проверку целостности кода;
- белый список разрешенных приложений;
- изоляция ВМ от хоста.
Это все очень хорошо защищает от вредоносного ПО нацеленного на хост Hyper-V и предоставляет доступ к ВМ только владельцу, защищая от действий администраторов или кого-либо получившего администраторские права.
Требования к серверам Hyper-V и HGS
Требования указаны для использования TPM аттестации. AD аттестация менее требовательна, но при этом обеспечивает гораздо меньшую защиту.
HGS:
- Windows Server 2016
Hyper-V:
- Windows Server 2016 Datacenter Edition
- UEFI Secure Boot
- TPM v2
- IOMMU (VT-d)
Как настроить
Для примера будет рассмотрен вариант: вы арендовали выделенный сервер и хотите его обезопасить. Будет использована TPM аттестация. Соединение между хостом и HGS будет проходить по http протоколу. Если HGS сервер не имеет белого IP необходимо будет пробросить 80 порт или использовать реверс прокси.
Добавление и настройка HGS роли на сервере
Установка HGS сервера и создание домена
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart
HGS для работы необходим домен. Его можно подключить к уже существующему домену, но рекомендуется создание отдельного домена для повышения безопасности. Перед выполнением следующей команды необходимо убедиться, что компьютер не подключен к домену.
$adminPassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
Install-HgsServer -HgsDomainName 'relecloud.com' -SafeModeAdministratorPassword $adminPassword -Restart
Создание самоподписаных сертификатов
Для теста были созданы самоподписанные сертификаты, но для реальной среды лучше использовать PKI.
$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
$signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"
Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx'
$encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"
Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx'
Инициализация HGS сервера
Указываем сертификаты шифрования и подписи. Выбираем метод аттестации.
$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
Initialize-HgsServer -HgsServiceName '<HgsServiceName>' -SigningCertificatePath 'C:\signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:\encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]
Добавление охраняемого хоста Hyper-V
Получаем идентификатор TPM
Данную процедуру необходимо выполнить для каждого защищаемого хоста.
(Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8
Добавляем полученный файл на сервер HGS
Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName> -Force
Создаем и применяем Code Integrity Policy
При создании политики происходит сканирование всех установленных программ и добавление их в белый список. Перед созданием политики необходимо убедится, что в системе:
- Отсутствуют вирусы и вредоносное ПО
- Установлено необходимое для работы ПО и оно является благонадежным
Рекомендуется сначала проверить работу политики в режиме аудита. В таком случае исполняемый файл, запрещенный политикой будет отображен в логе.
Сканирование займет некоторое время.
New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'
Файл .p7b необходимо переименовать в SIPolicy.p7b и скопировать в папку C:\Windows\System32\CodeIntegrity\SIPolicy.p7b
Перезагружаем компьютер и проверяем работу системы под планируемой типичной нагрузкой. После успешной проверки работы системы отключаем режим аудита
Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'
Copy-Item -Path '<Path to HW1CodeIntegrity\_enforced.p7b>' -Destination 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-ComputerЕсли защищаться будет несколько идентичных хостов, политику можно создать только один раз.
Рекомендуется оставить исходный XML файл, чтобы в случае необходимости изменения политики не проводить повторное сканирование.
При включенной политике необходимо быть осторожным с обновлением или добавление драйверов режима ядра, так как это может предотвратить загрузку системы.
Регистрируем политику на HGS сервере
Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'
Создание TPM baseline политики
Эта политика основывается на PCR регистрах (Platform Configuration Registers), находящихся в модуле TPM. В них хранятся целостности метрик системы, начиная с загрузки BIOS до завершения работы системы. Если порядок загрузки будет изменен, например, руткитом, это отобразиться в регистрах PCR.
Политика создается для класса одинаковых аппаратных хостов. Перед ее созданием необходимо иметь установленный Hyper-V.
Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart
Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'Для данной команды необходимо включить Secure Boot, IOMMU (VT-d), Virtualization Based Security.
Можно использовать флаг -SkipValidation который позволить выполниться команде, но он не исправит ошибки.
Добавляем TCGlog файл на HGS сервере
Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'
Проверяем статус HGS сервера
На этом моменте настройка HGS сервера заканчивается. Для проверки выполненной работы проведем диагностику.
Get-HgsTrace -RunDiagnostics
Подключаем хост Hyper-V к HGS серверу
Для подключения защищаемого хоста к серверу HGS достаточно указать URL адрес сервера.
Set-HgsClientConfiguration -AttestationServerUrl 'http://<FQDN>/Attestation' -KeyProtectionServerUrl 'http://<FQDN>/KeyProtection'
При правильной настройке должно быть:
- IsHostGuarded: true
- AttestationStatus: passed
Если что-то настроено не верно в AttestationStatus будет указана причина.
Создание экранированной виртуальной машины
Получаем файл описания HGS сервера, который понадобиться для привязки ВМ к серверу.
Invoke-WebRequest http://<"HGSServer">FQDN>/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml
Создавать ВМ нужно на отдельной машине под управлением Windows Server 2016, не настроенной на использование HGS.
Создаем новую ВМ второго поколения, устанавливаем на нее ОС, настраиваем RDP и проверяем его работоспособность, шифруем битлокером.
Экранирование ВМ
Задаем название ВМ
$VMName = 'SVM'Выключаем ВМ
Stop-VM –VMName $VMNameСоздаем сертификат владельца
$Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificatesИмпортируем сертификат сервера
$Guardian = Import-HgsGuardian -Path 'C:\HGSGuardian.xml' -Name 'TestFabric' –AllowUntrustedRootСоздаем Key Protector
$KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRootВключаем экранирование
Set-VMKeyProtector –VMName $VMName –KeyProtector $KP.RawData
Set-VMSecurityPolicy -VMName $VMName -Shielded $trueВключаем vTPM в виртуальной машине
Enable-VMTPM -VMName $VMName
После настройки и включения защиты в ВМ ее необходимо переместить на охраняемый хост. Для этого экспортируем машину, переносим полученные файлы на хост, и импортируем ее в консоль Hyper-V.
На этом этапе настройка завершена, ВМ экранирована.
Проверяем работу Shielded VM
При попытке подключится к ВМ через консоль Hyper-V увидим сообщение:
Так же в настройках ВМ увидим предупреждение о невозможности менять настройки защиты:
Раздел виртуальной машины защищен BitLocker-ом:
Таким образом была произведена настройка Shielded VM, которая обеспечивает более высокий уровень защиты виртуальных машин. Если у вас остались вопросы, добро пожаловать в комментарии.
Больше статей на Servilon
Комментарии (22)
MazayZaycev
24.11.2016 10:09Если это происходит при попытке запуска экранированной ВМ, она не запуститься, так как не кому будет выдать ключи.
VladimirOrlov
24.11.2016 10:36А с кластерами работает? будет ли проходить миграция виртуалок между хостами?
MazayZaycev
24.11.2016 10:47Работает, все хосты кластера должны быть аттестованы HGS сервером. Миграция работать будет, при этом трафик будет шифроваться.
DenMMM
24.11.2016 10:47+1Типичная хрень от Microsoft. Навроде «кластера» с единой точкой отказа.
Что мешает сделать снапшот VM и покопаться в дампе памяти для поиска ключей? Благо инструментарий для этого есть.MazayZaycev
24.11.2016 10:54+2VSM не позволит это сделать, так как хостовая ОС сама запускается в виртуальном окружении.
n1nj4p0w3r
24.11.2016 13:47+1Что мешает сделать снапшот виртуальной хостовой ОС и ковыряться во всем что под ней запущено?
VahMaster
24.11.2016 10:54+1пару дней назад на хабре было большое обсуждение как быстро уничтожить SSD может правильный метод чем шифрование т.к. при физическом доступе к компьютеру шифрованный диск подвержен атаке Cold boot attack https://ru.wikipedia.org/wiki/Cold_boot_attack
VladimirOrlov
24.11.2016 15:24-2возможность шифрования виртуалок битлокером нормально работает и в 2012r2,
d_olex
24.11.2016 17:20+2К сожалению, Virtual Secure Mode aka VSM это решето: его безопасность во многом определяется защищенностью platform firmware, а с этим сейчас все очень и очень плохо. Даже Intel и AMI пока что не умеют чинить уязвимости в своих прошивках которые приводят к обходу VSM, я детально писал об этом (с пруфами, анализом патчей и прочим) в последней части своей последней на момент конца 2016-го года статьи.
PS: да, MS в курсе этого безобразия, но сделать с ним что-то что бы VSM стал крутым и безопасным они не могут — platform firmware попросту не их область ответственности.d_olex
24.11.2016 17:35+1https://www.bromium.com/sites/default/files/us-16-wojtczuk-analysis-of-the-attack-surface-of-windows-10-virtualization-based-security-wp-v2.pdf — неплохой документ про анализ векторов атак на Virtualization Based Security в Windows.
http://blog.cr4.sh/2016/10/exploiting-ami-aptio-firmware.html — статья с описанием моей уязвимости INTEL-SA-00057 которая помимо всего прочего приводит к обходу VSM на материнских платах от Intel. В переписке Intel подтвердили, что исправлять это в полной мере они не планируют: им важно что бы через этот баг secure boot и flash write protection не ломали, а до обхода VSM им дела нет.
d_olex
24.11.2016 18:35+1https://github.com/Cr4sh/fwexpl — вот кстати еще более старый проектик который позволяет обходить VSM через уязвимости в прошивке компьютеров от Lenovo. Он умеет выводить информацию о виртуаизированных домейнах Hyper-V а так же предоставляет API для чтения-записи физической памяти через System Management Mode. Таким образом, атакующий который работает в рут партиции Hyper-V может сдампить все содержимое памяти с защищенных виртуальных машин в обход VSM.
MazayZaycev
24.11.2016 19:12+2Не получится эксплуатировать этe уязвимость так как потребуется перезагрузка хоста или запуск приложения, чему будет препятствовать политика HGS. В случае ее нарушения ВМ не запуститься, так как не получит сеансовый ключ, который выдает HGS
d_olex
24.11.2016 19:40> чему будет препятствовать политика HGS
В теории — да, но на практике:
1) Эта штука упирается в Device Guard User Mode Code Integrity для которого только за последний год была целая пачка различных техник обхода;
2) Атакующий может использовать full ROP пейлод (см. Weird Machine и Return Oriented Programming) который проэксплуатирует уязвимость в platform firmware и запустит произвольный код в System Management Mode не используя никаких приложений (техника ROP подразумевает, что пейлод исполняющийся на скомпрометированном хосте будет составлен из уже имеющихся в памяти участков легитимного исполняемого кода переход вектора исполнения между которыми осуществляется за счет контроля над данными).
d_olex
24.11.2016 19:48Вот немного ссылок по обходу политик Device Guard и UMCI, HGS исполнение такого кода просто не «увидит»:
http://www.cvedetails.com/cve/CVE-2016-0188/
http://www.exploit-monday.com/2016/11/Effectiveness-of-Device-Guard-UMCI.html
http://www.exploit-monday.com/2016/08/windbg-cdb-shellcode-runner.html
https://enigma0x3.net/2016/11/21/bypassing-application-whitelisting-by-using-rcsi-exe/
https://enigma0x3.net/2016/11/17/bypassing-application-whitelisting-by-using-dnx-exe/
http://subt0x10.blogspot.ru/2016/09/bypassing-application-whitelisting.html
d_olex
24.11.2016 19:51… кроме этого:
* Есть JiT компиляторы типа .NET и JVM которым исполнение произвольного кода в памяти является необходимым бай дизайн, это можно использовать для обхода code integrity.
* В дефолтной поставке Windows есть огромное количество whitelisted приложений с валидной цифровой подписью от Microsoft которые позволяют творить всякое зло (данная тема неплохо раскрыта по ссылкам выше).VahMaster
25.11.2016 10:06Все это слишком сложно. Надо:
1. Найти хостинг, где стоят машины.
2. Подкупить сотрудника хостера или внедрить туда своего.
3. Взломать хостовую операционку (не сложно).
4. Попытаться поставить на работающий гипервизор программы для сбора дампов, так что бы клиент этого не заметил.
5. В случае, если эти уязвимости работают и не пропаченны 2 дня назад, скопировать дамп памяти.
6. Расшифровать дамп памяти, получить ключ.
7. Еще раз зайти на хост остановит гипервизор и взять VHD.
SobolevaV
25.11.2016 09:49на выделенном сервере (например хетцнер) такое можно реализовать?
MazayZaycev
25.11.2016 10:20+1ДА, если сервер поддерживает TPM. Проверьте:
PS C:\> Get-Tpm
TpmPresent : True
И разместите HGS на другом хосте, лучше в альтернативном датацентре, например, в небольшая ВМ в Azure
VladimirOrlov
Что произойдет, если недоступен HGS сервер?