stihl не предоставил(а) никакой дополнительной информации.
Depending on the customer’s preference, possible initial access vectors in our Для просмотра ссылки Войди или Зарегистрируйся typically include deployment of dropboxes, Для просмотра ссылки Войди или Зарегистрируйся or a stolen portable device. The latter is usually a Windows laptop protected by BitLocker for full disk encryption without pre-boot authentication i.e. without a configured PIN or an additional key file.
While hardware-based Для просмотра ссылки Войдиили Зарегистрируйся are well known and covered in Для просмотра ссылки Войди или Зарегистрируйся, they typically involve hunting down board schematics on Chinese websites and some prowess using a soldering iron. Physical craftsmanship is definitely not a strength of mine, which is why I was particularly interested when Thomas demonstrated a concrete software-only attack in his Для просмотра ссылки Войди или Зарегистрируйся.
Even compared to other Для просмотра ссылки Войдиили Зарегистрируйся such as the Для просмотра ссылки Войди или Зарегистрируйся, the exploitation of the abused bitpixie vulnerability is non-invasive, does not require any permanent device modifications and no complete disk image, thereby allowing a fast (~5 minutes) compromise and more flexible integration in certain social engineering scenarios.
или Зарегистрируйся, the concrete exploit code was not disclosed. To fully understand the attack, reproduce the original research, and demonstrate the concrete impact to our customers, I set out to develop a public proof of concept.
Для просмотра ссылки Войдиили Зарегистрируйся
The Linux-based exploitation strategy roughly depicted on the above diagram (from Thomas’ presentation) is to:
или Зарегистрируйся discussing possible remediation strategies, Microsoft uses different UEFI certificates to sign boot components based on their origin:
или Зарегистрируйся disable the latter by default.
Для просмотра ссылки Войдиили Зарегистрируйся
As a result, the above attack chain fails at step 4 because the third-party signing certificate used is not trusted. However, there is nothing conceptually stopping an attack flow where third-party signed components are replaced by their Windows native equivalents:
или Зарегистрируйся. Physical memory is scanned by incorporating the original pattern-matching code into a Для просмотра ссылки Войди или Зарегистрируйся (winpmem.exe). The Для просмотра ссылки Войди или Зарегистрируйся is implemented in a Для просмотра ссылки Войди или Зарегистрируйся (dislocker-metadata.exe).
As presented, the WindowsPE-based attack flow uses only core components signed by Microsoft. At least in theory, it should therefore be applicable to all affected devices, as long as they trust the Microsoft Windows Production PCA 2011 certificate used to sign the vulnerable boot manager. In practice, it seems to be somewhat less reliable than its Linux-based counter part. Nonetheless, the Для просмотра ссылки Войдиили Зарегистрируйся are hopefully useful in case you want to investigate whether your devices are affected.
Для просмотра ссылки Войдиили Зарегистрируйся
While hardware-based Для просмотра ссылки Войди
Even compared to other Для просмотра ссылки Войди
Bitpixie Linux Edition
While Thomas did release a Для просмотра ссылки ВойдиДля просмотра ссылки Войди
The Linux-based exploitation strategy roughly depicted on the above diagram (from Thomas’ presentation) is to:
- Enter the Windows Recovery Environment by using Shift+Reboot from the power menu of the login screen
- Downgrade to vulnerable Windows Boot Manager (bootmgfw.efi) via PXE boot
- Specify broken default Boot Configuration Data (BCD) to force a pxesoftreboot fallback
- PXE boot into signed Linux shim loader (shimx64.efi)
- Load signed GRUB (grubx64.efi) boot loader
- Load signed Linux kernel and initial ram filesystem
- Для просмотра ссылки Войди
или Зарегистрируйся to scan physical memory for BitLocker Volume Master Key (VMK) - Mount encrypted volume using the Для просмотра ссылки Войди
или Зарегистрируйся and the extracted VMK
Bitpixie WinPE Edition
As Thomas describes in his Для просмотра ссылки Войди- Microsoft 1st party certificate, signs all Windows bootloaders
- Microsoft 3rd party certificate, signs everything else commonly understood to boot under Secure Boot, such as Linux shims
Для просмотра ссылки Войди
As a result, the above attack chain fails at step 4 because the third-party signing certificate used is not trusted. However, there is nothing conceptually stopping an attack flow where third-party signed components are replaced by their Windows native equivalents:
- Boot into same Windows Boot Manager (bootmgfw.efi) a second time via PXE boot, but specify different BCD
- Load a WinPE based boot image (boot.wim) and corresponding ram disk (boot.sdi)
- Load signed Windows boot loader (winload.efi)
- Load signed Windows Kernel (ntoskrnl.exe)
- Scan physical memory for a VMK using a modified version of WinPmem which internally uses a signed driver (winpmem_x64.sys)
- Use VMK to decrypt encrypted recovery password stored in BitLocker meta data
- Use human-readable recovery password to unlock the encrypted volume
As presented, the WindowsPE-based attack flow uses only core components signed by Microsoft. At least in theory, it should therefore be applicable to all affected devices, as long as they trust the Microsoft Windows Production PCA 2011 certificate used to sign the vulnerable boot manager. In practice, it seems to be somewhat less reliable than its Linux-based counter part. Nonetheless, the Для просмотра ссылки Войди
Для просмотра ссылки Войди