Authors: tomato, salt of Tencent Security Xuanwu Lab
0x00 Background
Ghidra is a generic disassembler and decompiler released by the NSA. It attracted wide interest from the security community.
Security researchers have since found an XXE vulnerability in the Ghidra project loading process.
Based on our prior research on XXE vulnerability exploitation, we found that attackers can abuse Java features and weaknesses in NTLM protocol in Windows operating system to achieve remote code execution.
0x01 Technical Details
When sending HTTP requests using Java built-in class sun.net.www.protocol.http.HttpURLConnection, it will automatically determine authentication method when encounters a 401 status code.
If authentication method is NTLM, it will automatically authenticate using current user credentials.
The root cause is Java on Windows enables transparent NTLM authentication by default, and treats all URL as trusted, as shown in the following code block.
sun.net.www.protocol.http.AuthScheme#NTLM
if (tryTransparentNTLMServer) {
tryTransparentNTLMServer =
NTLMAuthenticationProxy.supportsTransparentAuth;
/* If the platform supports transparent authentication
* then check if we are in a secure environment
* whether, or not, we should try transparent authentication.*/
if (tryTransparentNTLMServer) {
tryTransparentNTLMServer =
NTLMAuthenticationProxy.isTrustedSite(url);
}
}
Inside NTLMAuthenticationProxy.isTrustedSite method
public static boolean isTrustedSite(URL url) {
try {
return (Boolean)isTrustedSite.invoke(null, url);
} catch (ReflectiveOperationException roe) {
finest(roe);
}
return false;
}
It calls isTrustedSite method in sun.net.www.protocol.http.ntlm.NTLMAuthentication using reflection, which trusts all URLs.
Attackers can deploy a HTTP Server with NTLM authentication to gather Net-NTLM Hash of current user.
The NTLM authentication protocol has weaknesses.
There is a well-known NTLM Relay attack, which has been widely discussed and not in the scope of this article.
In our scenario, we use a credential reflection attack, which relays victim’s Net-NTLM Hash back to victim.
Let’s look at the details.
Attacker first deploy a HTTP server with NTLM authentication enabled. And use an XXE/SSRF vulnerability to force a NTLM authentication from the victim.
It worth noticing that the NTLM has two versions, NTLMv1 and NTLMv2.
When authenticating with NTLMv1, attacker can directly relay the Net-NTLM Hash to the victim’s SMB service.
In the SMBv2 case, attacker must first modify the Negotiate Flags in the Type 2 Message to unset Negotiate Always Sign and Negotiate 0x00004000 flags.
This transforms it from local authentication to network authentication, and also strips the signature.
We wrote a proof of concept script to demonstrate this attack.
0x03 Reproduction
Victim
Oracle JDK 8u161, Windows 10, Administrator
Attacker
Ubuntu 16.04, IP 192.168.130.136
First execute script on attacker’s machine
python ultrarelay.py -ip 192.168.130.136 -smb2support
The script will serve HTTP requests on port 80.
Make a new Ghidra project. Edit the project file project.prp to insert a XXE exploit, as shown below:
When victim use Ghidra to open this malicious project, attacker can obtain NTLM Hash from the victim’s machine, therefore execute arbitrary command on victim’s machine.
0x04 Mitigations
- Use Windows Firewall to block incoming SMB requests.
-
If SMB server is required, enable SMB Sign.
-
Upgrade to latest version of JDK
0x05 References
https://twitter.com/sghctoma/status/1103392091009413120
https://conference.hitb.org/hitbsecconf2018dxb/materials/D2T2%20-%20NTLM%20Relay%20Is%20Dead%20Long%20Live%20NTLM%20Relay%20-%20Jianing%20Wang%20and%20Junyu%20Zhou.pdf
