Ghidra From XXE to RCE

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, 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.

if (tryTransparentNTLMServer) {
    tryTransparentNTLMServer =
    /* 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 =

Inside NTLMAuthenticationProxy.isTrustedSite method

public static boolean isTrustedSite(URL url) {
    try {
        return (Boolean)isTrustedSite.invoke(null, url);
    } catch (ReflectiveOperationException roe) {

    return false;

It calls isTrustedSite method in 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

Oracle JDK 8u161, Windows 10, Administrator

Ubuntu 16.04, IP

First execute script on attacker’s machine

python -ip -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

  1. Use Windows Firewall to block incoming SMB requests.

  2. If SMB server is required, enable SMB Sign.

  3. Upgrade to latest version of JDK

0x05 References

Investigating WinRAR Code Execution Vulnerability (CVE-2018-20250) at Internet Scale

Authors: lywang, dannywei

0x00 Background

As one of the most popular archiving software, WinRAR supports compress and decompress of multiple file archive formats. Check Point security researcher Nadav Grossman recently discovered a series of security vulnerabilities he found in WinRAR, with most powerful one being a remote code execution vulnerability in ACE archive decompression module (CVE-2018-20250).
To support decompression of ACE archives, WinRAR integrated a 19-year-old dynamic link library unacev2.dll, which never updated since 2006, nor does it enable any kind of exploit mitigation technologies. Nadav Grossman uncovered a dictionary traversal bug in unacev2.dll, which could allow an attacker to execute arbitrary code or leak Net-NTLM hashes.

0x01 Description

ACE archive decompression module unacev2.dll fails to properly filter relative paths when validating target path. Attacker can trick the program to directly use a relative path as target path. By placing malicious executable in system startup folder, it can lead to arbitrary code execution.

0x02 Root Cause

unacev2.dll validates destination path before extracting files from ACE archives. It gets file_relative_path from archive file and use GetDevicePathLen(file_relative_path) to validate the path. The path concatenation is performed according to return value of the function, as shown in following diagram:


When GetDevicePathLen(file_relative_path) returns 0, it will concatenate target path with relative path in archive to form a final path:

sprintf(final_file_path, "%s%s", destination_folder, file_relative_path);

Otherwise, it directly uses relative path as the final path:

sprintf(final_file_path, "%s%s", "", file_relative_path);

if an attacker can craft a malicious relative path that can bypass multiple filter and validation functions such as StateCallbackProc(), unacev2.dll!CleanPath(), and make unacev2.dll!GetDevicePathLen(file_relative_path) return a non-zero value, the malicious relative path will be used as final path for decompression.

Nadav Grossman successfully crafted two such paths:

# Malicious Path Final Path
1 C:\C:\some_folder\some_file.ext C:\some_folder\some_file.ext
2 C:\\\smb_folder_name\some_folder\some_file.ext \\smb_folder_name\some_folder\some_file.ext

Variation 1: Attacker can place a file at arbitrary path on victim’s computer.
Variation 2: Attacker can steal victim’s Net-NTLM hash. Attacker can then perform a NTLM relay attack to execute code on victim’s computer.

It is worth mentioning that WinRAR runs at normal user privilege. Therefore, an attacker cannot place a file in the common startup folder (“C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup”). Placing a file in user startup folder (“C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup”) requires guessing or brute-forcing a valid user name.
However, in most common scenarios, where victims download archive file to Desktop (C:\Users\<user name>\Desktop) or Downloads (C:\Users\<user name>\Downloads) folder then extract the archive file in-place, the working directory of WinRAR is the same as the archive file. By using directory traversal, attacker can release payload to Startup folder without guessing a user name. Nadav Grossman crafted the following path to build a remote code execution exploit:

"C:../AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\some_file.exe"

0x03 Affected Software

As a shared library, unacev2.dll is also used by other software that supports ACE file decompression. These software are also affected by this vulnerability.
Our Project A’Tuin system scans software at internet scale. We scanned through all software that used this shared library. The following diagram shows the version distribution of this library:

Project A’Tuin can also traces shared libraries back to their dependent software. We currently observe that 15 Chinese software and 24 non-Chinese software are affected.
Most of them can be categorized as utility software. Among them there are at least 9 file archivers, and 8 file explorer / commanders. Many other software seems to simply include unacev2.dll module as part of WinRAR package, for its own file decompression usage.

0x04 Mitigations

WinRAR released version 5.70 Beta 1 to patch this vulnerability. Since the vendor of unacev2.dll was out of business in August 2017 and it is a closed source product, WinRAR decided to remove ACE decompression feature from WinRAR entirely.
360Zip has also patched this vulnerability by removing unacev2.dll.
For users of other affected products, we suggest contacting the vendor for updated versions. If no updated version is available, users can temporarily work around this vulnerability by removing unacev2.dll from installation directory.

0x05 References

[1] Extracting a 19 Year Old Code Execution from WinRAR

[2] ACE (compressed file format)

Pay attention to the Ethereum hash collision problem from the “Stealing coins” incident

Author : Kai Song(exp-sky) , hearmen , salt , sekaiwu of Tencent Security Xuanwu Lab

“Stealing coins”

On November 6th, we observed that such a contract appeared on Ethereum. After investigation, it was found that a blockchain security vendor issued a contract to let everyone “Stealing coins”.

pragma solidity ^0.4.21;
contract DVPgame {
    ERC20 public token;
    uint256[] map;
    using SafeERC20 for ERC20;
    using SafeMath for uint256;
    constructor(address addr) payable{
        token = ERC20(addr);
    function (){
            //airdrop is over

            if (map.length <= uint256(msg.sender)) {
                map.length = uint256(msg.sender) + 1;
            map[uint256(msg.sender)] = 1;  

    //Guess the value(param:x) of the keccak256 value modulo 10000 of the future block (param:blockNum)
    function guess(uint256 x,uint256 blockNum) public payable {
        require(msg.value == 0.001 ether || token.allowance(msg.sender,address(this))>=1*(10**18));
        if (map.length <= uint256(msg.sender)+x) {
            map.length = uint256(msg.sender)+x + 1;

        map[uint256(msg.sender)+x] = blockNum;
    //Run a lottery
    function lottery(uint256 x) public {
        require(block.number > map[uint256(msg.sender)+x]);
        uint256 answer = uint256(keccak256(block.blockhash(map[uint256(msg.sender)+x])))%10000;
        if (x == answer) {

After observing, we found the security issue of an EVM storage we studied earlier in this contract, namely the hash collision problem in EVM storage.

Continue reading “Pay attention to the Ethereum hash collision problem from the “Stealing coins” incident”

Return Flow Guard

[DannyWei, lywang, FlowerCode] of Tencent Xuanwu Lab

Here is a preliminary documentation of the RFG implementation. We will update it once we have new findings and corrections.

We analyzed the Return Flow Guard introduced in Windows 10 Redstone 2 14942, released on October 7, 2016.


Microsoft introduced Control Flow Guard in Windows 8.1 to protect against malicious modification of indirect call function pointers. CFG checks the target function pointer before each indirect call. However, CFG cannot detect modification of the return address on stack, or Return Oriented Programming.
The newly added RFG effectively stops these kind of attacks by saving the return address to fs:[rsp] at the entry of each function, and compare it with the return address on stack before returning.
Enabling RFG require both compiler and operating system support. During compilation, the compiler instruments the file by reserving a certain number of instruction spaces in the form of nop instructions.
When the target executable runs on a supported operating system, the reserved spaces are dynamically replaced with RFG instructions to check function return addresses. Otherwise, these nop instructions will not interfere with normal execution flow of the program.
The difference between RFG and GS (Buffer Security Check) is that the stack cookie can be obtained by using information leak or brute forcing, the RFG return address is written to the Thread Control Stack out of reach of attackers. This significantly increased the difficulty of the attack.
Continue reading “Return Flow Guard”