0%

new dll hijacking scenario found by accident

Speaking of dll hijacking, many people may think it is very useless. However, I noticed researchers disclosured some special dll hijacking scenarios that can lead to LPE and even RCE. Some times ago, I accidentally discovered vulnerability in dll loading mechanism in cisco webex teams that can lead to LPE, and as far as I know, no one has ever mentioned this kind of dll hijacking scenario before.

Cisco Webex Teams Client for Windows DLL Hijacking Vulnerability

I found cisco webex teams was installed to “C:\Users\username\AppData\Local\CiscoSpark” and I decided to take a look at current_log.txt。

It seems that several dlls were not loaded successfully the first time. This is very strange, CiscoCollabHost.exe wants to load these dlls from “dependencies”, error code 126 means “The specified module could not be found”, but “dependencies” and CiscoCollabHost.exe are in the same directory, and in “dependencies” these dlls exist. So something must be wrong…

Until I found the corresponding code in spark-windows-media.dll in IDA, and it took some time before I realized what was going on.

In AddDllDirectory documentation says that the parameter should be “An absolute path to the directory to add to the search path”. However, Microsoft did not say you cannot use relative path, nor did they say what would happen if you use it. What’s even more interesting is that if you use a relative path like L”\\dependencies” like here, in fact windows will treat it as “C:\dependencies”!

We can write code like:

1
2
3
4
5
6
7
8
9
10
PCWSTR pcwstr = L"\\dependencies";

if(!AddDllDirectory(pcwstr))
{
std::cout << "failed!\n";
}

LoadLibraryExW(L"test.dll", 0, LOAD_LIBRARY_SEARCH_DEFAULT_DIRS);

std::cout << "Hello World!\n";

Compile poc.exe, then put poc.exe into C:\example\poc.exe, if C:\dependencies\test.dll and C:\example\dependencies\test.dll both exist, poc.exe will load C:\dependencies\test.dll.

So it is very simple to exploit this vulnerability here, just put wmeclient.dll into C:\dependencies\wmeclient.dll. After the victim opens cisco webex teams and successfully logs in, this wmeclient.dll will be loaded and executed by cisco webex teams. Directly writing PE files to C:\ requires administrator rights, but creating a directory in C:\ and then writing PE files to that directory does not require administrator rights.

Consider another situation where the exe and the dll are not in the same path. If C:\abc\def\poc.exe wants to load C:\abc\lib\test.dll, can we write code like LoadLibraryW(L”.. \\lib\\test.dll”)? This will also lead to vulnerability, because windows will treat “..\\lib\\test.dll” directly as “C:\lib\test.dll”. I found such code in another renowned manufacturer’s product. I reported this to them and I am still waiting for reply. I will add more details 90 days after my report or a security bulletin available.

Not only the path related to load dll handled in this way by windows, functions like CreateProcess may also cause vulnerability if given a relative path. Because some products have both windows and linux versions, developers may mix the code of these two platforms. For example, if you write code like this:

1
2
3
4
5
6
7
8
9
TCHAR szCmdLine[] = {TEXT("\\bin\\whoami")};
STARTUPINFO si;
memset(&si, 0, sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_SHOW;
PROCESS_INFORMATION pi;

CreateProcess(NULL, szCmdLine, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);

Windows will add C:\ and .exe, which means put whoami.exe into C:\bin\whoami.exe and it will be executed. I found codes similar to this in cisco DCNM. They told me that this problem only exists on server 2019 and server 2019 is not an environment supported by DCNM by default, so no CVE for this:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv65124

I also reported my findings to MSRC, but MSRC said this is the default behavior. I am not surprised, if the default behavior is to let developers write vulnerable code, that’s fine.

I am sharing my discovery because I haven’t seen anyone mention these and similar vulnerabilities may exist in other products. At the same time, I want to remind developers should make sure that all your dlls are loaded correctly. I want to thank cisco PSIRT although they do not have a bug bounty program but I am still willing to report vulnerability to them. They are very professional and will give you feedback at every stage(received-confirmed-coordinate disclosure time-final public disclosure).

timeline:

2020-06-30: vulnerability found and reported to cisco PSIRT

2020-07-01: cisco PSIRT assigned PSIRT-0447917012

2020-07-10: cisco PSIRT was not able to reproduce this, more details provided

2020-07-15: cisco PSIRT confirmed this vulnerability

2020-08-05: cisco PSIRT informed that the vulnerability will be fixed in the new version released on August 27, and security bulletin will be released on September 2

2020-08-19: cisco PSIRT hoped to postpone the release of security bulletin to October 7 to ensure that all users can upgrade to the unaffected version before public disclosure

2020-10-07: cisco PSIRT released security bulletin