Ghidra 从 XXE 到 RCE

作者：腾讯安全玄武实验室 tomato, salt

0x00 背景

Ghidra是 NSA 发布的一款反汇编工具,它的发布引起了安全研究人员的极大兴趣。
有研究人员发现Ghidra在加载工程时会存在XXE，基于笔者之前对XXE漏洞利用研究发现，攻击者可以利用Java中的特性以及Windows操作系统中NTLM认证协议的缺陷的组合来完成RCE。

0x01 技术细节

Java在使用内置类 sun.net.www.protocol.http.HttpURLConnection 发送HTTP请求遇到状态码为401的HTTP返回头时，会判断该页面要求使用哪种认证方式，若采用的NTLM认证则会自动使用当前用户凭据进行认证。
其根本原因在于Windows下的Java默认启用了透明NTLM认证，并且将所有由外部传入的URL地址都认为是可信的。如下面代码段所示

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);
    }
}

再跟入NTLMAuthenticationProxy.isTrustedSite方法

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

    return false;
}

通过反射调用了sun.net.www.protocol.http.ntlm.NTLMAuthentication中的isTrustedSite方法，在此方法中将所有外部传入的URL都判定为可信的。

攻击者通过搭建基于NTLM认证的HTTP Server即可获取到当前用户的Net-NTLM Hash。

我们再来看NTLM认证协议的缺陷。NTLM认证协议中存在一种很古老的攻击的技术，被称作为NTLM Relay攻击。此攻击的原理网上已经有很多文章进行说明，在此不再赘述。
但在此次漏洞利用方式中我们使用的凭据反射攻击，即为攻击者将受害者的Net-NTLM Hash再次Relay给受害者，达到以彼之道还施彼身的效果。

下面来看看这个过程的具体实现，攻击者首先搭建基于NTLM认证的恶意HTTP Server，然后通过XXE/SSRF等漏洞使受害者向恶意的HTTP Server进行NTLM认证。

值得注意的是，NTLM认证分为两个版本NTLMv1和NTLMv2，在进行NTLMv1类型认证时攻击将获取到的Net-NTLM Hash直接Relay给受害者的SMB服务即可，但是在使用NTLMv2类型认证时，攻击者在Relay时需要将NTLM认证中Type 2 Message的Negotiate Flags进行修改，将Negotiate Always Sign与Negotiate 0x00004000 两个标志位从设置改为不设置，这其中具体代表的含义为让此次认证被认作在网络上(Relay给本机会被当做是一次本地认证)进行以及将认证中的签名进行去除。

为完成该攻击过程，笔者已经编写好脚本。

0x03 复现步骤

受害者环境 Oracle JDK 8u161、Win10、Administrator账户

攻击者环境 Ubuntu16.04 IP为192.168.130.136

首先在局域网内另一台机器上运行前面提到的脚本

python ultrarelay.py -ip 192.168.130.136 -smb2support

脚本将会在80端口开启HTTP服务。然后回到Win10中新建一个Ghidra工程，修改工程中的project.prp，插入XXE攻击代码，如下图所示

再次使用Ghidra打开此恶意工程，攻击者就能获取到受害者机器的NTLM Hash，也可通过脚本中的参数在受害者机器上执行任意命令。

0x04 防御措施

1.开启Windows防火墙，禁止外部请求访问SMB服务

2.若要提供SMB服务则建议开启SMB Sign

3.升级JDK至最新版本

0x05 参考资料

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

全网筛查 WinRAR 代码执行漏洞 (CVE-2018-20250)

作者：lywang, dannywei

0x00 背景

WinRAR 作为最流行的解压缩软件，支持多种压缩格式的压缩和解压缩功能。今天，Check Point公司的安全研究员 Nadav Grossman 公开了他在 WinRAR 中发现的一系列漏洞。其中以 ACE 解压缩模块的远程代码执行漏洞（CVE-2018-20250）最具危害力。
WinRAR 为支持 ACE 压缩文件的解压缩功能，集成了一个具有 19 年历史的动态共享库 unacev2.dll。而此共享库自 2006 年以来再未更新过，也未开启任何漏洞利用缓解技术。Nadav Grossman 在 unacev2.dll 中发现了一个目录穿越漏洞，成功利用此漏洞可导致远程代码执行或 Net-NTLM hash 泄露。

0x01 漏洞描述

ACE 文件的解压模块 unacev2.dll 对解压缩路径进行验证时，未能正确过滤压缩文件中的“相对路径”，导致攻击者结合一些技巧可以绕过安全检查，使压缩文件中恶意构造的“相对路径”被直接用作了解压路径使用。从而可以将恶意代码静默释放到系统启动目录中，最终实现远程代码执行或 Net-NTLM hash 泄露。

0x02 漏洞成因

unacev2.dll 模块在解压 ACE 文件时，将对解压缩路径进行验证。它从压缩文件中提取待解压文件的相对路径 file_relative_path，使用 GetDevicePathLen(file_relative_path) 对其进行校验，根据返回结果进行最终解压路径的拼接。如下图所示：

(图片来源：https://research.checkpoint.com/extracting-code-execution-from-winrar/)

当 GetDevicePathLen(file_relative_path) 返回 0 时，将使用 WinRAR 提供的解压路径与压缩文件中的相对路径拼接，得到最终的解压路径：

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

而当 GetDevicePathLen(file_relative_path) 返回非 0 时，仅使用压缩文件中的“相对路径”作为最终的解压路径：

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

因此，若攻击者能够构造恶意的相对路径，在绕过 WinRAR 回调函数 StateCallbackProc() ，unacev2.dll!CleanPath() 等一系列路径检测和过滤函数的前提下，使 unacev2.dll!GetDevicePathLen(file_relative_path) 返回非0值，便可以使得使用恶意构造的相对路径作为最终解压路径，将恶意文件解压至指定目录中。

最终，Nadav Grossman 构造了两种攻击路径：

编号	恶意的相对路径	最终的解压路径
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

攻击路径 1 的危害：攻击者可以使用漏洞，将恶意文件静默释放至可能造成危害的路径中实现攻击。
攻击路径 2 的危害：攻击者可以获取受害者的Net-NTLM hash，从而使用NTLM Relay的方式攻击受害者。

值得一提的是，由于 WinRAR 运行在普通用户权限下，使得攻击者无法将恶意文件静默释放至路径已知的系统启动目录（”C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup”）。而释放至用户启动目录（”C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup”）需要提前预知受害者的登陆用户名或者进行暴力猜测。
好在大多数此类攻击场景均是受害者将恶意构造的压缩文件下载至桌面（C:\Users\<user name>\Desktop）或者下载目录（C:\Users\<user name>\Downloads），而当压缩文件通过双击解压或右键解压缩时，当前的WinRAR的工作路径与压缩文件一致。这使得攻击者无需猜测受害者用户名，可通过目录穿越的方式将恶意文件释放至用户启动目录，待受害者系统启动时实现任意代码执行。在此前提下， Nadav Grossman 构造了如下的相对路径，使得远程代码执行攻击得以成功：

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

0x03 影响范围

unacev2.dll 作为一个第三方共享库，也被其它一些支持 ACE 文件格式解压的软件所使用，这些软件也同样受到该漏洞的影响。
利用玄武实验室自研的“阿图因”系统，我们对已收录的全网 PC 软件进行了扫描，统计了 unacev2.dll 的使用情况，其版本分布情况如下图所示：

通过“阿图因”系统，我们还能够对使用了该共享库的软件进行反向溯源，目前扫描到了受影响的有 24 款国外软件，15 款国产软件。
多数受影响的软件都可以被归类为工具软件。其中至少有9款压缩软件，以及8款文件浏览器。还有其它许多软件将 unacev2.dll 作为 WinRAR 的一部分放在了自己的软件包中，作为解压模块使用。

0x04 修复建议

目前，WinRAR 已经在 5.70 Beta 1 版本中修复了这个问题。由于开发 ACE 解压模块的公司已于 2017 年 8 月关闭，而且 unacev2.dll 共享库并没有公开源码，导致漏洞无法被正确修复。因此 WinRAR 的修复方案是直接将 unacev2.dll 模块移除，并决定不再支持 ACE 文件格式的解压。

另外，360压缩在最新版本中也已经修复了这个问题，修复方案同样是移除 unacev2.dll 模块。
对于其它受影响软件的用户，我们建议您关注相关软件的修复更新情况，及时更新版本。在软件开发商主动修复之前，可以通过手动删除安装目录下的 unacev2.dll 模块来应急修复。

0x05 参考资料

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

从一起“盗币”事件看以太坊存储 hash 碰撞问题

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

“盗币”

十一月六日，我们观察到以太坊上出现了这样一份合约，经调查发现是某区块链安全厂商发布的一份让大家来“盗币”的合约。

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);
        }
    }
}

经过观察之后，我们在这个合约中，发现了我们之前研究的一个 EVM 存储的安全问题，即 EVM 存储中的 hash 碰撞问题。

继续阅读“从一起“盗币”事件看以太坊存储 hash 碰撞问题”

来自微信外挂的安全风险

玄武实验室联合独立安全研究员 em 发现在 Mac OS 上用户量比较大的两款微信防撤回外挂存在安全问题，装了此外挂的用户只要在浏览器里访问攻击者页面并停留一分钟左右，攻击者即可拿到该用户的好友列表，聊天记录，甚至以该用户的身份给好友发送消息，对用户的信息安全造成巨大威胁。

目前这两款外挂的用户量较大，比较热门的一款目前在 Github 上的 star 数量接近 8800，实际安装的用户数量可能更多。经过玄武实验室与微信安全部门沟通，为了避免让众多用户暴露在安全风险中，我们决定先对该外挂进行漏洞通报，然后再发文提示用户安全威胁。em 于10月15日在对应的 Github 仓库中提交了修复代码，其中一个已经进行修补，而另一个尚无操作。玄武实验室联合微信安全提醒大家，不要随意安装微信外挂。

一个攻击演示的视频如下。

继续阅读“来自微信外挂的安全风险”

利用恶意页面攻击本地Xdebug

TL;DR
PHP开发者以及一些安全研究人员经常会在本地搭建一个基于Xdebug的PHP的调试服务，在大部分配置情况下，Xdebug采用HTTP请求头中的X-Forwarded-For字段作为DBGp协议的回连地址。受害者浏览攻击页面一段时间，攻击者可利用DNS Rebind技术向本地服务器发送带有恶意X-Forwarded-For的请求，即有可能在受害者电脑上执行任意代码。

Xdebug是用于调试PHP的扩展，可以根据本地源码远程调试服务器上的PHP代码。很多开发者和安全研究人员通常会在本地搭建一套PHP的调试环境，用于日常的开发和调试。如果服务器开启了Xdebug的回连，并且攻击者能直接访问到服务器的话，可以直接造成RCE。

但是大部分情况下，这些服务器处于内网环境中，有些甚至监听在127.0.0.1上，攻击者很难直接访问到，导致无法利用。如果把开发人员当做代理，利用CSRF来攻击位于内网的Xdebug呢？

我们首先看一下Xdebug有关远程调试的文档。
如果xdebug.remote_connect_back启用，xdebug.remote_host没有设置，Xdebug会主动连接发起HTTP请求的客户端。Xdebug会依次检测$_SERVER['HTTP_X_FORWARDED_FOR']、$_SERVER['REMOTE_ADDR']来决定回连的IP地址。
继续阅读“利用恶意页面攻击本地Xdebug”

对华为HG532远程命令执行漏洞的新探索

2017年11月27日Check Point 公司报告了一个华为 HG532 系列路由器的远程命令执行漏洞，漏洞编号为CVE-2017-17215。利用该漏洞，向路由器UPnP服务监听的37215端口发送一个特殊构造的 HTTP 请求包，即可触发命令执行。此端口在默认配置下并不能从外网访问，但由于该系列路由器数量极其巨大，所以互联网上仍有较多可访问到该端口的设备存在。目前已经有蠕虫在利用这些暴露在互联网上的端口进行传播[1]。

近期国内外已有不少对该漏洞原理的分析[2]，在此不再赘述。但我们发现该漏洞实际的威胁可能比目前大家所认为的更为严重，某些对该漏洞的防御建议也是不够的甚至错误的。37215端口暴露在互联网上的HG532系列设备只占其中很少一部分，就已经足够多到被蠕虫利用，而如果其它那些只在内网能访问到的37215端口也可以被攻击者利用呢？

在2013年，国内爆发了一次家用路由器 DNS 劫持事件，利用的是WEB安全里的CSRF攻击技术。这种攻击技术能利用在现在HG532路由器的这个漏洞上吗？如果可以，那么只要诱使HG532路由器的用户用手机、电脑访问一个恶意页面，就可以导致路由器完全被攻击者控制。
继续阅读“对华为HG532远程命令执行漏洞的新探索”

Browser UI Security 技术白皮书

Browser UI ,是指浏览器用户界面。浏览器经过几十年的发展，对于用户界面并没有一个统一的规定标准，目前大多数现代浏览器的用户界面包括：前进和后退按钮、刷新和停止加载按钮、地址栏、状态栏、页面显示窗口、查看源代码窗口、标签等。另外可能还会有一些其他的用户界面，例如下载管理、页面查找、通知、系统选项管理、隐身窗口等等。我们可以把Browser UI认为是一个前端标签式的页面管理器或者Web的外壳，用户不必去考虑浏览器应用程序底层是如何处理数据的，所有的网络行为结果，均由Browser UI去展现给用户。

从安全的角度来说，浏览器UI上最容易发生的攻击就是用户界面欺骗，也就是UI Spoof。通常UI Spoof被用来进行网络钓鱼攻击使用。网络钓鱼是社会工程学中用于欺骗用户，进而获取用户的敏感信息的一种攻击手段，通常使用伪造网站等方法，诱使用户从视觉感官上相信其是合法真实的，当用户在浏览器中进行操作后，敏感信息就有可能被攻击者获取到。

因此浏览器UX团队在开发UI过程中，在便捷用户浏览的同时，对UI安全模型上的设计、策略、逻辑也显得非常重要，安全的UI能帮助用户在上网时快速、准确的做出正确安全的决策。而UI一旦出现了缺陷，攻击者就可能伪造浏览器UI中的某些关键信息，进而对用户实施网络钓鱼攻击。

本技术白皮书中将给大家介绍什么是UI Spoof漏洞，并对多个浏览器UI上的安全漏洞进行详细分析。

下载链接： Browser-UI-Security-技术白皮书.pdf

从一个补了三次的漏洞看WCF的安全编程

背景

笔者在2016年11月发现并报告了HP Support Assistant (HPSA) 的权限提升漏洞，HP Product Security Response Team (HP PSRT) 响应迅速，但却以此漏洞可以通过软件的自动更新功能自动修复为由拒绝为其发布安全公告和CVE。4月份想起这件事后，笔者又分析了一遍修补后的HPSA，发现HP的开发人员在修补中犯了更为低级的错误，导致补丁可以被绕过重新实现权限提升。在随后与HP PSRT的沟通与合作中，再一次利用其它技巧绕过了其后续修补，最终笔者协助HP PSRT完成了漏洞的修补。

本文将分析此漏洞的成因及多次补丁绕过，希望能以此为案例提高开发人员对安全的认识和理解，以减少由于对所用技术理解不到位和安全编程意识匮乏而导致的安全漏洞。

继续阅读“从一个补了三次的漏洞看WCF的安全编程”

深入分析NSA用了5年的IIS漏洞

Author: Ke Liu of Tencent’s Xuanwu Lab

1. 漏洞简介

1.1 漏洞简介

2017年3月27日，来自华南理工大学的 Zhiniang Peng 和 Chen Wu 在 GitHub [1] 上公开了一份 IIS 6.0 的漏洞利用代码，并指明其可能于 2016 年 7 月份或 8 月份被用于黑客攻击活动。

该漏洞的编号为 CVE-2017-7269 [2]，由恶意的 PROPFIND 请求所引起：当 If 字段包含形如 <http://localhost/xxxx> 的超长URL时，可导致缓冲区溢出（包括栈溢出和堆溢出）。

微软从 2015 年 7 月 14 日开始停止对 Windows Server 2003 的支持，所以这个漏洞也没有官方补丁，0patch [3] 提供了一个临时的解决方案。

无独有偶，Shadow Brokers 在2017年4月14日公布了一批新的 NSA 黑客工具，笔者分析后确认其中的 Explodingcan 便是 CVE-2017-7269 的漏洞利用程序，而且两个 Exploit 的写法如出一辙，有理由认为两者出自同一团队之手：

两个 Exploit 的结构基本一致；
都将 Payload 数据填充到地址 0x680312c0；
都基于 KiFastSystemCall / NtProtectVirtualMemory 绕过 DEP；

本文以 3 月份公布的 Exploit 为基础，详细分析该漏洞的基本原理和利用技巧。

继续阅读“深入分析NSA用了5年的IIS漏洞”

用SQL注入穿IE沙箱

0x00 前言

每一个安全初学者都喜欢问这样一个问题，“我应该做web安全还是做二进制安全，哪个更有意思？哪个更有钱途？”

二进制安全就只等于反汇编，逆向，调试，内核 ……？

Web安全就只等于XSS，SQL注入，CSRF，webshell ……？

当两者结合起来的时候会发生什么美妙的事情呢？

一个典型的Web系统运行于Linux平台，使用Apache作为服务器，用PHP完成功能逻辑，重要数据存储在MySQL数据中，接收用户输入并返回信息。对于客户端软件来说其实也存在类似的架构，软件运行在Windows系统上，用C/C++完成功能逻辑，可能用SQLite存储重要数据，支持进程间通信。

那么在二进制漏洞挖掘中是否可用使用Web漏洞挖掘的思路呢？

笔者在研究某客户端软件时发现了一个非常有意思的逻辑安全漏洞。本文笔者将展示如何使用客户端软件中存在的SQL注入漏洞，实现本地权限提升，使用漏洞可以绕过IE沙箱等的限制，在高权限进程的上下文中执行任意代码。
继续阅读“用SQL注入穿IE沙箱”