There are no reviews yet. Be the first to send feedback to the community and the maintainers!
# Summary Siofra is a tool designed to identify and exploit DLL hijacking vulnerabilities in Windows programs. It is able to simulate the Windows loader in order to give visibility into all of the dependencies (and corresponding vulnerabilities) of a PE on disk, or alternatively an image file in memory corresponding to an active process. More significantly, the tool has the ability to easily generate DLLs to exploit these types of vulnerabilities via PE infection with dynamic shellcode creation. These infected DLLs retain the code (DllMain, exported functions) as well as the resources of a DLL to seamlessly preserve the functionality of the application loading them, while at the same time allowing the researcher to specify an executable payload to be either run as a separate process or loaded into the target as a module. Additionally, the tool contains automated methods of combining UAC auto-elevation criteria with the aforementioned functionality in order to scan for UAC bypass vulnerabilities. # Vulnerabilities At present, there is a very large number of vulnerabilities which this tool exposes. While testing this tool I encountered only several applications which were not vulnerable out of hundreds which I tested against. Note that these vulnerabilities can be exploited despite SafeDllSearchMode. A common misconception results from confusing the "current directory" (fixed with SafeDllSearchMode) with the "application directory" (the folder containing the .exe itself). The vast majority of DLL hijacking vulnerabilities currently present in Windows programs stem from the application directory (which comes first in the Windows search order). Several highlights are listed below in the output produced by the scanner in the tool. The last time these vulnerabilities were tested was in mid-July 2017. * Application name: Internet Explorer * Tested on OS: Windows 10 x64 Home/Pro * Command/output: Siofra64.exe --mode file-scan -f "c:\Program Files\Internet Explorer\iexplore.exe" --enum-dependency --dll-hijack ======== c:\Program Files\Internet Explorer\iexplore.exe [64-bit PE] ======== iexplore.exe USER32.dll [KnownDLL] win32u.dll [Base] api-ms-win-core-privateprofile-l1-1-1.dll [API set] kernel32.dll [KnownDLL] GDI32.dll [KnownDLL] api-ms-win-gdi-internal-uap-l1-1-0.dll [API set] gdi32full.dll [Base] msvcp_win.dll [Base] api-ms-win-crt-string-l1-1-0.dll [API set] ucrtbase.dll [Base] msvcrt.dll [KnownDLL] api-ms-win-downlevel-shell32-l1-1-0.dll [API set] shcore.dll [KnownDLL] RPCRT4.dll [KnownDLL] combase.dll [KnownDLL] bcryptPrimitives.dll [Base] ADVAPI32.dll [KnownDLL] api-ms-win-eventing-controller-l1-1-0.dll [API set] sechost.dll [KnownDLL] iertutil.dll [!] [!] Module iertutil.dll vulnerable at c:\Program Files\Internet Explorer\iertutil.dll (real path: C:\WINDOWS\system32\iertutil.dll) * Application name: Windows Defender * Tested on OS: Windows 10 x64 Home/Pro * Command/output: Siofra64.exe --mode file-scan -f "c:\Program Files\Windows Defender\MpCmdRun.exe" --enum-dependency --dll-hijack ======== c:\Program Files\Windows Defender\MpCmdRun.exe [64-bit PE] ======== MpCmdRun.exe msvcrt.dll [KnownDLL] KERNEL32.dll [KnownDLL] OLEAUT32.dll [KnownDLL] msvcp_win.dll [Base] api-ms-win-crt-string-l1-1-0.dll [API set] ucrtbase.dll [Base] combase.dll [KnownDLL] RPCRT4.dll [KnownDLL] bcryptPrimitives.dll [Base] ADVAPI32.dll [KnownDLL] api-ms-win-eventing-controller-l1-1-0.dll [API set] sechost.dll [KnownDLL] OLE32.dll [KnownDLL] GDI32.dll [KnownDLL] api-ms-win-gdi-internal-uap-l1-1-0.dll [API set] gdi32full.dll [Base] USER32.dll [KnownDLL] win32u.dll [Base] SspiCli.dll [!] mpclient.dll [!] CRYPT32.dll [Base] MSASN1.dll [Base] WINTRUST.dll [Base] [!] Module SspiCli.dll vulnerable at c:\Program Files\Windows Defender\SspiCli.dll (real path: C:\WINDOWS\system32\SspiCli.dll) * Application name: WMI * Tested on OS: Windows 10 x64 Home/Pro * Command/output: Siofra64.exe --mode file-scan -f "c:\WINDOWS\System32\wbem\wmiprvse.exe" --enum-dependency --dll-hijack ======== c:\WINDOWS\System32\wbem\wmiprvse.exe [64-bit PE] ======== wmiprvse.exe msvcrt.dll [KnownDLL] FastProx.dll [!] wbemcomn.dll [!] bcrypt.dll [!] WS2_32.dll [KnownDLL] api-ms-win-eventing-obsolete-l1-1-0.dll [API set] sechost.dll [KnownDLL] RPCRT4.dll [KnownDLL] api-ms-win-core-heap-obsolete-l1-1-0.dll [API set] kernel32.dll [KnownDLL] NCObjAPI.DLL [!] [!] Module wbemcomn.dll vulnerable at c:\WINDOWS\System32\wbem\wbemcomn.dll (real path: C:\WINDOWS\system32\wbemcomn.dll) [!] Module bcrypt.dll vulnerable at c:\WINDOWS\System32\wbem\bcrypt.dll (real path: C:\WINDOWS\system32\bcrypt.dll) [!] Module NCObjAPI.DLL vulnerable at c:\WINDOWS\System32\wbem\NCObjAPI.DLL (real path: C:\WINDOWS\system32\NCObjAPI.DLL) * Application name: Windows Search Indexer/Search Protocol Host * Tested on OS: Windows 10 x64 Home/Pro * Command/output: Siofra64.exe --mode file-scan -f "c:\WINDOWS\System32\SearchProtocolHost.exe" --enum-dependency --dll-hijack --explicit-loadlibrary ======== c:\WINDOWS\System32\SearchProtocolHost.exe [64-bit PE] ======== SearchProtocolHost.exe msvcrt.dll [KnownDLL] TQUERY.DLL [!] OLEAUT32.dll [KnownDLL] msvcp_win.dll [Base] api-ms-win-crt-string-l1-1-0.dll [API set] ucrtbase.dll [Base] combase.dll [KnownDLL] RPCRT4.dll [KnownDLL] api-ms-win-core-heap-obsolete-l1-1-0.dll [API set] kernel32.dll [KnownDLL] bcryptPrimitives.dll [Base] cryptdll.dll [!] api-ms-win-security-lsalookup-l2-1-1.dll [API set] advapi32.dll [KnownDLL] api-ms-win-eventing-controller-l1-1-0.dll [API set] sechost.dll [KnownDLL] api-ms-win-shell-namespace-l1-1-0.dll [API set] windows.storage.dll [Base] api-ms-win-shlwapi-winrt-storage-l1-1-1.dll [API set] shlwapi.dll [KnownDLL] GDI32.dll [KnownDLL] api-ms-win-gdi-internal-uap-l1-1-0.dll [API set] gdi32full.dll [Base] USER32.dll [KnownDLL] win32u.dll [Base] api-ms-win-appmodel-state-l1-2-0.dll [API set] kernel.appcore.dll [Base] api-ms-win-shcore-path-l1-1-0.dll [API set] shcore.dll [KnownDLL] api-ms-win-power-base-l1-1-0.dll [API set] powrprof.dll [Base] profapi.dll [Base] msfte.dll [Potential explicit Unicode] [!] msTracer.dll [Potential explicit Unicode] [!] Msidle.dll [Potential explicit Unicode] [!] winhttp.dll [Potential explicit Unicode] [!] [!] Module msfte.dll vulnerable at C:\WINDOWS\system32\msfte.dll (real path: Unknown) [!] Module msTracer.dll vulnerable at C:\WINDOWS\system32\msTracer.dll (real path: Unknown) # Capabilities The capabilities of this tool can be split into 3 separate categories, each corresponding to one of the execution modes of this tool. ## Infection mode When in infection mode, the tool is capable of generating infected copies of both 32 and 64-bit DLL files. These infected files are able to hijack the execution flow of a target application when they are loaded during process initialization, causing either a payload DLL to be loaded or a payload executable to be launched prior to the execution of the target application entry point. ## File scanning mode When in file scanning mode, the tool may be given either an executable file path or a folder (which will be searched for executable files, optionally with recursion) which will recursively have its PE imports, delay load imports, API sets, assembly dependencies, and explicitly loaded libraries enumerated and processed to determine the path at which each will be loaded during runtime process initialization. With this information, the tool is able to identify modules which are vulnerable to hijacking. During PE processing and loader simulation, the tool is capable of handling: 1. Modules imported using the primary PE imports section. 2. Modules imported via delay load. 3. WinSxS assembly dependency resolution (the PE manifest resource is parsed, assembly dependency IDs are extracted, and the WinSxS module path is identified using a custom implementation). 4. Explicitly loaded modules, imported via LoadLibrary at runtime. 5. API set resolution of all of the above import types. This is achieved via a custom implementation of a parser for the undocumented data structures found in ApiSetSchema.dll (note that only versions 2, 4 and 6 have been tested). 6. Searching for specific imported modules by name. 7. Identifying Windows components which can be leveraged for UAC bypass attacks (the UAC auto-elevation criteria are applied to a specified target PE in an automated way, then used in conjunction with a hijacking attack if one is present). 8. Automatically detect and filter module dependencies which are not vulnerable on the basis of: * KnownDLLs * Exempt ("Base") DLL status. Kernelbase.dll, ntdll.dll, etc. * Manifest override security mechanism (used by Microsoft in sysprep.exe) ## Memory scanning mode When in memory scanning mode, the tool can either enumerate local process names/IDs or it can be given a process ID to scan. Rather than parsing the image file corresponding to the given PID on disk, the tool will enumerate the modules currently loaded into the process and identify which of them may be vulnerable to hijacking. This is useful in instances where an executable on disk is packed/obfuscated and its imports cannot be identified through parsing the PE header. # Usage In order to display the tool usage information, simply run it with no parameters (output shown below). It is very important to use the appropriate compilation of the tool (32 or 64-bit) for the desired target depending upon whether it is a 32-bit PE or 64-bit PE file. Similarly, the 32-bit version of the tool can only enumerate and/or target 32-bit processes (Wow64 on an x64 OS) and the 64-bit version can only enumerate and/or target 64-bit processes. This principle applies both to scanning (Siofra64.exe will skip 32-bit PE and Siofra32.exe will skip 64-bit PE) and to PE infection. Siofra32.exe should be used to infect 32-bit DLLs and Siofra64.exe should be used to infect 64-bit DLLs. When the 32-bit version of the tool is run on x64 systems Wow64 path redirection is explicitly disabled by the tool, which means that if you were to target \Windows\System32\notepad.exe it would be a 64-bit PE (and therefore \Windows\Syswow64\notepad.exe should be used instead). Similarly if you were to target \Program Files\Common Files\microsoft shared\MSInfo\msinfo32.exe it would be a 64-bit PE, and therefore \Program Files (x86)\Common Files\microsoft shared\MSInfo\msinfo32.exe should be used instead. Siofra version 1.13 usage: Siofra32.exe --mode [Supported modes: "file-scan", "mem-scan" and "infect"] -v [Optional. Output verbosity level] Verbosity levels: 0 - No output 1 - Only critical success/failure status (default) 2 - Additional status details for success/failure status, including discarded PEs 3 - Everything File scan mode: -f [File or directory to scan] -r [Optional. Recursive scan] --signed [Optional. Process only signed binaries] --delayload [Optional. Include delayload imports in dependency list] --explicit-loadlibrary [Optional. Include potentially explicit imports in dependency list (these are *.dll strings which may have been called via LoadLibrary(Ex)A/W] --auto-elevate [Optional. Scan only auto-elevate binaries] Memory scan mode: --pid [Target process ID to scan. When not specified, a list of either 32 or 64-bit process names/PIDs will be enumerated (corresponding to either the 32 or 64-bit version of this tool)] Any scan mode: --enum-dependency [Enumerate dependencies] --show-unmapped-apiset [Optional. Include API sets which failed to map to a module from output (ignored by default)] --dll-hijack [Enumerate DLL hijacking vulns] --find-module [Optional. Scan dependencies for a specific module. Note that this excludes KnownDLLs] Infect mode: -f [DLL file to infect] -o [Output file] --payload-path [Path of DLL to be loaded into infected DLL at runtime, or path of executable to be launched at runtime] --payload-type [The type of payload specified in the parasite payload path. This can be "process" (generally indicating a exe) or "library" (generally indicating a DLL)] ## Examples 1. Scanning the entire home drive for 32-bit programs vulnerable to DLL hijacking using either standard or delay load imports through their PE headers. Siofra32.exe --mode file-scan -f "C:/" -r --enum-dependency --dll-hijack --delayload 2. Scanning the Windows Defender application folder on an x64 version of Windows for vulnerable modules loaded through the standard import table in their PE header. Siofra64.exe --mode file-scan -f "C:\Program Files\Windows Defender" -r --enum-dependency --dll-hijack 3. Scanning the 32-bit Java Update Scheduler program on an x64 version of Windows for vulnerable modules loaded through any known channel (standard or delayload imports, WinSxS, LoadLibrary). Siofra32.exe --mode file-scan -f "C:\Program Files (x86)\Common Files\Java\Java Update\jusched.exe" --enum-dependency --dll-hijack --delayload --explicit-loadlibrary 4. Scanning the Windows folder (and all its subfolders) for vulnerable modules (imported via the standard imports table in the PE header) in 64-bit programs which could be used for a UAC bypass attack (signed by Microsoft with an auto-elevate manifest). Siofra64.exe --mode file-scan -f "C:\Windows" -r --enum-dependency --dll-hijack --auto-elevate --signed 5. Infecting a 32-bit copy of WININET.dll (copied from \Windows\SysWOW64\WININET.dll to .\WININET_original.dll) with an implant which will launch a new notepad process when loaded during process initialization by a vulnerable program. It's important to note that simply loading an infected copy of this DLL (via LoadLibrary for example) will not trigger the payload. Infected DLLs are only meant to work in the context of a vulnerable module loaded via the standard imports section of its host process. Siofra32.exe --mode infect -f WININET_original.dll -o WININET.dll --payload-type process --payload-path c:\windows\system32\notepad.exe 6. Infecting a 64-bit copy of USERENV.dll (copied from \Windows\System32\USERENV.dll to .\USERENV_original.dll) with an implant which will load a hypothetical payload DLL stored at C:\Payload.dll. It's important to note that all DLLs loaded by a 64-bit process must be 64-bit DLLs, and all DLLs loaded by a 32-bit process must be 32-bit DLLs. Therefore in this hypothetical scenario, Payload.dll would need to be a 64-bit PE file for it to be loaded successfully by the implant in USERENV.dll. Siofra64.exe --mode infect -f USERENV_original.dll -o USERENV.dll --payload-type library --payload-path "C:\Payload.dll" # Future improvements * 32 and 64-bit versions of the tool to be combined into a single executable. * Capability to perform PE infections which can successfully load DLL/executable payloads within infected DLL files loaded explicitly via LoadLibrary or through delayed imports. * Support for all API set versions. # Source code I've decided to make some of this tool open source to help other security researchers understand the technical details of this project. Specifically I've provided assembler source code for one of the 64-bit implant shellcodes (for 64-bit PE DLL infection when specifying a "process" payload type). Details surrounding other technical aspects of the tool and OS details related to the Windows loader/search order, UAC, WinSxS etc. can be found within the PDF for this project. # License Siofra is licensed under the GPL 3 license. See LICENSE.MD for details. # Contact Forrest Williams - [email protected] / [email protected]
Logout4Shell
Use Log4Shell vulnerability to vaccinate a victim server against Log4ShellInvoke-WMILM
linux_plumber
A python implementation of a grep friendly ftrace wrapperultima
epic-sklearn
epic-jupyter
epic-serialize
epic-caching
epic-logging
epic-common
keychain-cleaner
epic-pandas
epic-lab
eztw
epic-bitstore
Love Open Source and this site? Check out how you can help us