Detours is a library offered by Microsoft Research for interception of functions on x86 and x64 platforms. It is sold for commercial use to various vendors that build products ranging from security to gaming applications.

Detours is often injected into most or all of the processes, either system-wide or in the context of the logged in user. The most common way this is done is through theAppInit_Dllsregistry value. Because the injection is typically applied to a large number of processes running under various permissions, extra care must be taken to ensure the library and its usage are very carefully reviewed by engineers with a strong understanding of the implications of such wide hooking.

We have used this library in our own security products at Cisco (both CSA and AnyConnect) to provide certain security functions on the system. During one of our research projects earlier this year, we noticed a peculiar pattern on Windows systems where processes we were hooking had a change in the in-memory permissions, which marked the headers of the modules from the normal READ/EXECUTE to now include WRITE as well.

This was quite alarming to us, because adllshould not be writeable when loaded into memory. What was interesting, and led to clues of what might be the cause, was that it was only thedlls that had functions we were actively trying to hook. They were the common Win32dlls that one would typically intercept methods for, such asKernel32.dll.

At first we assumed we had done something wrong in our own code and so we did a thorough inspection and security review on how we were performing the function hooking. After we verified it was not our own doing, we then decided to inspect the Detours source code. Analyzing the code, we realized that there was an error in the implementation.

Because of the license agreement associated with this code, we cannot show you the fragment that was the cause.

We contacted Microsoft and reported the issue at the time we discovered it and a fix was made available to vendors on March, 21, 2013 at no cost. Additionally, Microsoft informed our security incident team that they have reached out to other vendors who are using the Detours library to ensure they are aware of the issue.

The specific concern with this defect is that it essentially defeats the protections provided by DEP, ASLR, and SafeSEH in any process where the vulnerable version of Detours is present. Consequently, it provides a simple way for a malicious actor to have a predictable location to inject their shell code when they find a vulnerability in a component.

Because of the way Detours is typically used, it is injected in most of the processes on a system. So any code that has an exploitable flaw, whether from 3rd party vendors or the OS, becomes a very easy target due to protections such as DEP, ASLR, and SafeSEH being neutralized.

Additionally, this is not adllprovided by the OS itself. Instead, it is compiled and redistributed by any number of 3rd party vendors as a private library. This makes it much more difficult to patch this issue, as every vendor using this library must ensure they are not distributing a vulnerable implementation.

To detect a vulnerable version of the Detours library installed on your computer, we offer a simple code fragment you can compile into an executable. Compile and then run the code below on a Windows system and if Detours hooking is present there is a strong likelihood this will catch it (we will update this blog post with a comprehensive check at a later date).

//TODO enumerate all modules and check each one as the hook might
//only target some parts of the system (e.g. winsock functions only, for example).
//

//Load the module handle for kernel32, which is almost always the target
//when hooking -detouring.
//
HMODULE module = ::GetModuleHandle(_T("Kernel32.dll"));

//Test the header of the file to see if it is writeable.
BOOL bReturn = ::IsBadWritePtr(module, 1);

//If the header of the file is writeable... it is the vulnerability.
//
if (!bReturn)
{
//TODO, Enumerate the modules and try to find detoured.dll or some flavor of it.
//Look at how it was injected, etc. (e.g AppInit_Dll in registry, hook api, etc.)
//

//Popup a message box
::MessageBox(::GetDesktopWindow(), _T("The system is vulnerable... The kernel32.dll file header is writeable..."), _T(""), MB_ICONERROR);
}

You could also use the tool, VMMap.exe, from Sysinternals, and look at a bunch of loaded processes running under various security contexts (System, User, etc.) and see if any of the loadeddllheaders are incorrectly changed to have write permission.

If you find you have a system that is vulnerable, we suggest you inspect how thedllinjection is performed on the system. Typically, you will find an entry forAppInit_Dllswith one or more entries in it, though that is not the only technique.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"AppInit_DLLs"="foobar64.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows]
"AppInit_DLLs"="foobar.dll"

From there, you might be able to identify the vendor product by the properties of the file(s) located in the System32 and/or SysWOW64 directories that match the registry value name. Note that thedllfound inAppInit_Dllswill not be Detours. It will be the first injectiondllthat, in turn, will load Detours from a vendor-specific program file location. From there, you will need to look in the vendor program file location and try to find a file with a name likedetoured.dll(though it does not have to be that exact name).

Contact the vendor and report the vulnerability and ask for mitigations until a patch is available (it might be as simple as removing theAppInit_Dllsentry and rebooting).

Endpoint AV/HIDS and security posture products should consider putting a test in to try to detect this scenario, as well as offer additional system protections until all vendor products are patched.

At the time of this writing, we have notified vendors who are using the vulnerable Detours library in their product as we have come across them.

Unfortunately, this is the type of vulnerability that will keep cropping up until it is widely understood by 3rd party vendors that they might, in fact, be distributing a vulnerable version of the Detours toolkit. Although it is ironic that a utility commonly used in security products might have the inverse effect, it shows that reporting security vulnerabilities can help keep everyone on the right track.

Researchers: Vinny Parla and Andrew Zawadowskiy
Cisco Secure Access & Mobility R & D team