Date: Fri, 9 Oct 2020 15:13:17 +0800
From: houjingyi <houjingyi647@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] Cisco Webex Teams Client for Windows DLL Hijacking
	Vulnerability

new dll hijacking scenario found by accident
<http://houjingyi233.com/2020/10/09/new-dll-hijacking-scenario-found-by-accident/>

Speaking of dll hijacking, many people may think it is a 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
<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-teams-dll-drsnH5AN>

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

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists