从一个补了三次的漏洞看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”

CVE-2016-1779 技术分析及其背后的故事

Geolocation API被用来获取用户主机设备的地理位置,并且它有一套完整的保护用户隐私的机制。但CVE-2016-1776这个漏洞,绕过了Geolocation认证源的安全机制,并有可能导致用户隐私泄漏。本文在分析CVE-2016-1779漏洞成因的基础上探讨了Geolocation隐私机制,其中穿插的获取苹果公司的地理位置的“故事”,对用户隐私更是一个警醒。
继续阅读“CVE-2016-1779 技术分析及其背后的故事”

异常中的异常——借助系统异常处理特例实现匪夷所思的漏洞利用

内存的读、写、执行属性是系统安全最重要的机制之一。通常,如果要改写内存中的数据,必须先确保这块内存具有可写属性,如果要执行一块内存中的代码,必须先确保这块内存具有可执行属性,否则就会引发异常。然而,Windows系统的异常处理流程中存在一些小小的特例,借助这些特例,就可以知其不可写而写,知其不可执行而执行。

继续阅读“异常中的异常——借助系统异常处理特例实现匪夷所思的漏洞利用”

再利用Chakra引擎绕过CFG

本文源自一次与TK闲聊,期间得知成功绕过CFG的经过与细节(参考:利用Chakra JIT绕过DEP和CFG)。随即出于对技术的兴趣,也抽出一些时间看了相关的东西,结果发现了另一处绕过CFG的位置。所以这篇文章中提到的思路与技术归根结底是来自TK提示的,在此特别感谢。

关于CFG的分析文章已经有很多了,想要了解的话可以参考我之前在HitCon 2015上的演讲(spartan 0day & exploit)。要说明的是,本文的内容即为我演讲中马赛克的部分,至此通过一次内存写实现edge的任意代码执行方法就全部公开了。
继续阅读“再利用Chakra引擎绕过CFG”

IE沙箱拖拽安全策略解析

IE沙箱逃逸是IE浏览器安全研究的一个重要课题,其中有一类漏洞会借助ElevationPolicy设置中的白名单程序的缺陷来完成沙箱逃逸。IE在注册表中有一个和ElevationPolicy类似的名为DragDrop策略设置,这引起了我们的注意。在本文中,笔者将以一个攻击者的视角,尝试各种途径来突破IE沙箱的这一安全策略,通过分析所遇到的障碍,达到对IE沙箱拖拽安全策略进行详细解析的目的。

继续阅读“IE沙箱拖拽安全策略解析”