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

  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

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

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:

(Source: https://research.checkpoint.com/extracting-code-execution-from-winrar/)

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:\\10.10.10.10\smb_folder_name\some_folder\some_file.ext \10.10.10.10\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 https://research.checkpoint.com/extracting-code-execution-from-winrar/

[2] ACE (compressed file format) https://en.wikipedia.org/wiki/ACE_(compressed_file_format)

Spoof All Domains Containing ‘d’ in Apple Products [CVE-2018-4277]

During this time I have been researching security issues on the browser front end, and I have found dozens of vulnerabilities in browsers such as Chrome, Safari, and Firefox. Unicode visual security and IDN homograph attack have also been the subject of my research.

Evil U+A771

In my research, I found Latin small letter dum (U+A771) glyph is very similar to Latin small letter D (U+0064) in Apple products. From the glyph standard of Unicode (U+A771), we can see that there should be a small apostrophe after d, but this is completely ignored in Apple products.


Continue reading “Spoof All Domains Containing ‘d’ in Apple Products [CVE-2018-4277]”

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 (){
        if(map.length>=uint256(msg.sender)){
            require(map[uint256(msg.sender)]!=1);
        }
        if(token.balanceOf(this)==0){
            //airdrop is over
            selfdestruct(msg.sender);
        }else{
            token.safeTransfer(msg.sender,100);

            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));
        require(blockNum>block.number);
        if(token.allowance(msg.sender,address(this))>0){
            token.safeTransferFrom(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(map[uint256(msg.sender)+x]!=0);
        require(block.number > map[uint256(msg.sender)+x]);
        require(block.blockhash(map[uint256(msg.sender)+x])!=0);
        uint256 answer = uint256(keccak256(block.blockhash(map[uint256(msg.sender)+x])))%10000;
        if (x == answer) {
            token.safeTransfer(msg.sender,token.balanceOf(address(this)));
            selfdestruct(msg.sender);
        }
    }
}

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”

Pwning PHP developers

TL;DR
A php programmer who use xdebug’s remote debugging feature may affects RCE when he just access to attacker’s website in modern browsers.

Xdebug is an extension for PHP to assist with debugging and development. PHP programmers or web security researchers always setup a local PHP debugging environments for convenience. If the debugging server can be directly accessed by an attacker, there is a Remote Code Execution vulnerability.

But usually, these servers are in Intranet and some even bind on 127.0.0.1, which makes it hard to be accessed. What if attacking Xdebug using CSRF?

Let’s read the Xdebug’s document first. As in the doc, if xdebug.remote_connect_back is enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER['HTTP_X_FORWARDED_FOR'] and $_SERVER['REMOTE_ADDR'] variables to find out which IP address to use.
Continue reading “Pwning PHP developers”

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.

1 PROTECTION METHODS

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”

BadTunnel – A New Hope


This article purposes a new attack model to hijack TCP/IP broadcast protocol across different network segment, named “BadTunnel”.

With this method, NetBIOS Name Service Spoofing can be achieved, regardless of the attacker and the victim is on the same or different network, the firewalls and NAT devices in between. All it need is the victim navigate to a malicious web page with IE or Edge, or open a specially crafted document, and the attacker can hijack the victim’s NetBIOS name query to spoof as print server or file server in the local network.

By hijacking the WAPD name, the attacker can hijack all network communications, including but not limited to usual web accesses, Windows Update service and Microsoft Crypto API Certificate revocation list updates. Once the hijack is successful, it is easy to achieve arbitrary execution of program on the target system by using Evilgrade [1].

This method is effective on all Windows versions before the June 2016 patch, and can be exploited through all Internet Explorer, Microsoft Edge, and Microsoft Office versions, and can also be exploited through third-party applications. In fact, BadTunnel attack can be conducted on anywhere that a file URI scheme or UNC path can be embedded. For example, if a shortcut’s icon path is pointed to the malicious file URI scheme or UNC path, the BadTunnel attack can be triggered at the moment the user sees it in the Windows Explorer, which means BadTunnel can also be exploited through web pages, emails, USB flash drives and many other ways. It can even impact Web servers and SQL servers [2].

(This article does not include all contents covered by the BadTunnel research, the remaining part will be released in my presentation “BadTunnel: How do I get Big Brother power” on BlackHat US 2016.)
Continue reading “BadTunnel – A New Hope”

Exceptions in Exceptions – Abusing Special Cases in System Exception Handling to Achieve Unbelievable Vulnerability Exploitation


Memory Read / Write / Execute attributes are one of the most important part of system security. Usually it is mandatory to have writable attribute set before overwriting a block of memory, and executable attribute set before executing code in a block of memory, otherwise an exception is generated. However, there are some special cases in the Windows exception handling procedure that we can take advantage of. By abusing such exceptions, we could write to the unwritable, and execute the unexecutable.
Continue reading “Exceptions in Exceptions – Abusing Special Cases in System Exception Handling to Achieve Unbelievable Vulnerability Exploitation”

Use Chakra engine again to bypass CFG


This post is initially inspired by a talk with @TK, during which I learned the process and detail on how to successfully bypass CFG (reference: use Chakra JIT to bypass DEP and CFG). Due to my interest in its technology, I spent some time reading related materials and found another position to bypass CFG. I would like to thanks @TK for enlightening me on the ideas and techniques mentioned in this post.

There are plenty of articles that focus on the analysis of CFG, if you are interested, you may refer to my previous speech on HitCon 2015(《spartan 0day & exploit》). To be clear, this post is the part that is not revealed in my speech. At this point, the method to implement arbitrary code execution on edge through a write to memory is completely revealed.

Continue reading “Use Chakra engine again to bypass CFG”