从一起“盗币”事件看以太坊存储 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沙箱”

BadBookmarklet

Bookmarklet,中文名可以翻译成小书签,它的存在形式和书签一样,都被保存在浏览器的收藏夹中。但它不是一个 HTTP、FTP、File 开头的 URL,而是一段 javascript: 开头的 javascript 代码。1995 年 Javascript 的作者 Brendan Eich 特意设计 javascript: URLs 和普通URL一样用于收藏夹,时至今日小书签已经于浏览器中存在了 20多年。

在这些年中浏览器以及WEB 上的攻防对抗风云幻变,也使小书签上的安全风险渐渐大于它的业务实用性。从攻击的角度来看,日渐复杂的应用场景、多样化的攻击手段层出不穷,使小书签可以执行任意 javascript 代码的这个特性演变成一了种攻击手段。而在防御层面,CSP 的出现与普及,也似乎预示着小书签的历史使命走到了尽头。

本文从在现代浏览器中导入和拖放小书签,来介绍小书签是如何变成一种致命攻击手段的。
继续阅读“BadBookmarklet”

Return Flow Guard

腾讯玄武实验室 DannyWei, lywang, FlowerCode

这是一份初步文档,当我们有新发现和更正时会进行更新。

我们分析了微软在2016年10月7日发布的Windows 10 Redstone 2 14942中加入的新安全机制Return Flow Guard。

1 保护原理

微软从Windows 8.1 Update 3之后加入了Control Flow Guard,用于阻止对间接跳转函数指针的篡改。CFG通过在每个间接跳转前检查函数指针合法性来实现,但是这种方式并不能阻止篡改栈上的返回地址或者Return Oriented Programming。

本次加入的新安全机制RFG,会在每个函数头部将返回地址保存到fs:[rsp](Thread Control Stack),并在函数返回前将其与栈上返回地址进行比较,从而有效阻止了这些攻击方式。

开启RFG需要操作系统和编译器的双重支持,在编译阶段,编译器会以nop指令的形式在目标函数中预留出相应的指令空间。当目标可执行文件在支持并开启RFG的系统上运行时,预留的指令空间会在加载阶段被替换为RFG指令,最终实现对返回地址的检测。当在不支持RFG的操作系统上运行时,这些nop指令则不会影响程序的执行流程。

RFG与GS最大的区别是,攻击者可以通过信息泄漏、暴力猜测等方式获取栈cookie从而绕过GS保护,而RFG是将当前的函数返回地址写入了攻击者不可控的Thread Control Stack,从而进一步提高了攻击难度。
继续阅读“Return Flow Guard”