riusksk's blog

信安之路入坑指南

2020-07-12T11:37:43.000Z

疫情下的高考已结束，又快到填志愿的时候了，又有不少知青要加入信安这个圈子。为了响应组织号召，撰写此文作为信安行业的入坑指南，希望能对刚入圈的同学有所帮助。

如何入门学习

1、明确目标，并以目标为导向，用以致学

刚开始的时候，相信很多人会先去搜索信息安全要学什么课程，可能有人会告诉你要先C，再学数据结构和算法，学数据结构和算法前又要学离散数学，总之会有无穷无尽的东西在等着你，导致最后自己都不知道该学啥了……

其实学习什么课程都只是手段而已，但你学习这些课程的目标是什么需要先明确，比如想去国内个的漏洞奖励平台刷web或软件漏洞拿奖金，或者报个CVE漏洞，开源个安全项目等等，这样目标和动力就都有了。

2、细化目标制定具体的学习内容

假设你的目标是挖腾讯PC软件漏洞赚奖金吧，那腾讯PC软件有啥，电脑管家、腾讯视频、QQ、QQ影音等等，先选个门槛低点的QQ影音吧，目标就细化成挖掘音视频文件解析软件的漏洞。

挖掘文件解析漏洞的技术就涉及代码审计、Fuzzing、逆向等等，再细化下目标，挑Fuzzing吧。

入门Fuzzing涉及哪些系统性的技术内容呢？可以拿国外知名大会的培训课程为例，比如BlackHat、CanSecWest等等，这里以CanSecWest上的“Advanced Fuzzing and Crash Analysis”培训课程为例:

https://cansecwest.com/dojos/2019/vulndisco.html

4天的培训课程计划已经给出了循序渐进的学习内容，你只需要多利用搜索引擎去查找相关的书籍、论文、工具进行学习和实践。

比如课程给出的前置条件：

Students should be prepared to tackle challenging and diverse subject matter and be comfortable writing functions in in C/C++ and python to complete exercises involving completing plugins for the discussed platforms. Attendees should have basic experience with debugging native x86/x64 memory corruption vulnerabilities on Linux or Windows.

涉及C/C++、Python和汇编，这里就需要先去找相应语言的经典书籍先入个门，至少保证先看得懂代码。

再看第一天的课程目录，用相关标题去搜索就可以得到相关的知识点，比如AFL、libFuzzer、Corpus generation等等，遇到不懂的就是一个知识点，自己设法去弄懂并实践它就是学习的过程：

整个示例过程总结起来就是：

挖腾讯漏洞赚钱 =》PC软件 =》QQ影音 =》文件Fuzzing =》培训课程目录 =》搜索相关书籍、论文、工具进行学习

其它目标的学习内容制定类似，包括web渗透、内核攻击等等。

3、无限循环：学习=》应用=》反馈=》学习

完成第2步的学习之后，就去实践（示例：挖QQ影音的漏洞，或者其它已公开的漏洞的挖掘验证），看能否挖到0day或1day，若不能就针对公开漏洞的信息继续改进优化，再验证效果，以此不断循环，直至相信这是体力问题，也不是能力问题。

这里以二进制漏洞学习为例，但其它领域web、IoT方向都均适用。学习过程遇到迷茫，很多时候只是不知道目标和手段（学习计划等）之间的关联性而已，设法找到它，并细化到可执行的内容，再设置一些里程碑目标（比如重现历史漏洞的挖掘过程）来增加自信心，最后就是持之以恒下去。

关于CTF

在学校时，有机会就多去打打CTF，提高实战能力，国内不少课程内容都比较落后，现在也有一些高校会直接采用工业界出版的一些书籍作为教材，也是一种进步。

一本书的出版经常代表着其内容已经过时，除了一些计算机基础书籍，比如C/C++、编译原理、系统原理等等这些，即使再过10年也不会过时。其它很多技术会随时时代变迁，技术日新月异，而CTF题目往往会跟着技术热潮来变更，在学习基础的同时，又能帮助跟上技术的更新变化节奏。

学习工具推荐

印象笔记、Mendeley、Inoreader是我最想推荐的三款工具，均有跨平台客户端，以及浏览器插件，数据在多平台同步，搭配使用非常方便。

关于Mendeley和Inoreader的使用，我也曾写过文章推荐，详见《谈谈追踪前沿学术研究的技巧》和《RSS-优秀的个人情报来源》

平时我Inoreader订阅RSS，用印象笔记来收藏文章，用Mendeley追踪学术论文，并在上面作笔记，方便未来查阅和复习。另外，Mendeley还有个功能，就是会根据你所收藏的论文，去推荐更多相关技术的论文，比如参考文献中的内容。比如关注Linux Kernel Fuzzing，那么它会推荐更多的内核Fuzzing论文给你，如果有公开的PDF下载，还可以直接通过它索引下载，这种学术论文的追踪并不是印象笔记能比的。个人主要是用印象笔记来收藏一些非学术论文的文章，还有一些工业界安全会议的ppt等等。

对推荐书单的补充说明

之前笔者曾发过”信息安全从业者书单推荐”（https://github.com/riusksk/secbook），相信很多圈内人看过，期间也很多人提问过，这里整理补充说明下。

配合书籍，注重实战：列举那么多书并不是想让大家从头翻到尾看完，而主要是向大家推荐一些我曾经看过并觉得较好的书而已，大家自己根据自己需要选择即可。同时，理论归理论，很多东西需要配合实战，光看书也没用，依然建议大家试试”用以致学”的方法。
书单并非网上收集列举的：由于书单较多，有不少人质疑只是把网上有的书随便收集罗列下而已。之前在github回应过，这里再说明下。书单均是个人看过或者业界认可的经典书籍（部分书籍没全看完，但不妨碍对书籍质量的判断），跟网上罗列的安全书单不同，并非把网店上的各安全书籍都罗列上的。如果你有何好书推荐可在Github Issues上提交合并，待我看过之后，如果觉得可以就会在此处更新，会在Github上不定期更新书单。
关于阅读时间的问题：多数人一看到书单，就会问这些得多久才能读完？我觉得没必要纠结于此，有空有兴趣就挑本书看下即可，读书没必要把它当作一种负担，保持细水长流的方式，持续学习就好了。如果真的说时间的话，我从06开始学习安全，到今天差不多14年，14年读完那些书，我觉得问题也不大，但关键在于自己掌握了多少。我建议抛开时间、数量的考量，遵循自我内心的喜好，保持学习即可。
书单仅代表个人喜好：不同人对同一本书通常会有不同的评价，这里仅代表个人喜好，你可以有不同的看法。比如有些人曾推荐过《逆向工程核心原理》，但我觉得它内容过旧，且没有《加密与解密》写得好，所以我一直没入书单推荐。但你觉得此书对你有帮助，那就保持你的这份喜好，不必执着于书单本身。

【书评】聊聊打CTF的那本书

2020-07-12T08:09:41.000Z

最近的《CTF特训营》一书挺火的，在朋友圈和公众号上刷屏了。同时，我也发现安全圈的一个怪现象，通常在朋友圈推荐书籍的人，大多是没看过那本书的。

我在第一时间就入手了此书，花了几个晚上翻了一遍。本着”不吐槽、不毒舌、舍己为人”的宗旨，今天就来聊聊这本书。

对于写书评，我一直觉得，若不认识作者，且无利益相关等“屁股束缚脑袋”的事情，写起来会轻松许多，因为这样比较容易做到“有好说好，有坏说坏”的中立态度。

先说好的。

据说此书三天销完3000册的首印数量。这对于IT书籍来说，其实是不错的销量了。要知道安全书籍能卖个5000册，就算正常水平了，上万册就已经是畅销书籍了。所以说，写书是不赚钱的，一般按书价的8％收取稿费。此书定价89元，正常稿费就是一本赚7.12元，畅销卖个一万册的话也就税前71200元。另外听说作者们只要了1%，即0.89元，即使卖一万册也才8900元。这种公益行为，还是令人偑服的。

个人一直觉得CTF是提升安全实战技能的最佳途径之一，有时面试我也习惯问下。此书算是国内第一本讲述CTF的书籍，起了个好头。相信在未来两三年内，CTF主题的书籍会逐渐出现，正如当年的“企业安全建设”这个话题一样，说不定明年也可能出现“从0到1：CTFxxx”之类的书籍。国内出版社的编辑们也不妨去找找有此话题出书意向的人，或者引进国外的优秀CTF书籍。

CTF本身就是一项偏于实战的训练方式，书籍内容自然也是比较偏于实战的，避免了无用的空头理论。虽然题目是刻意构造的，但有些解题思路还是令人眼前一亮，对实战也有一定帮助。另外，有些精心构造的题目很好地呈现对应漏洞类型的危险和常用攻击手法，对于开发有很好的安全教育价值。所以，我觉得此书除了在校生打比赛外，一些此前对安全了解不足的开发也可以看看。况且近两年，各行各业也开始流行搞行业的CTF比赛，比如金融业、工控业等等，将此书当作CTF参考书也还可以。

本书整体定位偏入门，但覆盖的安全领域还是比较广的，对于专注于某安全领域的同学，也可以拿来扩宽下思路。搞web的看看二进制，搞pc的看看Android，也是甚好。

在web篇中，本书汇总了几项常见漏洞类型，虽然知识点没那么全面，但简短精要地汇总了一些常见的漏洞利用技巧，是套不错的解题技巧。这点既是它的优点，也是它的缺点。因为这就像考试画重点一样，可以高效地应付考试，但对于解决实际问题依然缺少体系化的知识构建，知识点是零散的，实际问题的解决方法不可能总是单点知识就能解决。

再说坏的。

部分知识讲解的先后顺序颠倒。这是多人协作经常出现的问题，主要还是缺少一个主编审稿改稿。个人觉得一本书最好不要超过3人，一人写书太累，太多人写书，容易导致风格差异太大，知识点的衔接不连贯，甚至错乱重复。

以PWN篇为例，开篇讲的是PWN基础，里面先讲了写bbs段的exploit技巧，但下一节又开始介绍程序内存布局，讲BBS段是什么。还有其中的真题解析，直接扔了exploit代码（里面还留着三叶草syclover的名字……），一个空行都没留，看着好累啊。里面的ret2dl_resolve技术介绍得有点粗糙，其中有几个相关案例也只是简单帖下代码，解释稀少，应该是作者偷懒了，急着给答案。虽为“PWN基础”，但对基础人士其实不够友好。

同类型web漏洞案例过多，条件竞争漏洞（国内还是很多人习惯叫“竞争条件”）就列举了3个，其实可以把sqli和xss这种常见漏洞案例拿来讲讲，丰富案例，避免重复。

APK篇主要介绍一些常见工具的使用，太多知识只是蜻蜓点水，更关键的是居然没有CTF案例，这与书的主旨就不太符合了。个人觉得，全书里面写得最不理想的篇章就是APK篇了。

总体来说，还是推荐那些对CTF感兴趣的同学看看，还有一些信息安全的在校生可借此多提升下实战能力，以及想了解多个安全方向的同学也可以用来扩展思路。但对于想深入某一安全领域，以及应付复杂的业务场景问题，可能此书并不太合适。

信息安全从业者书单推荐（2020.6.28更新）

2020-06-28T05:07:01.000Z

近来也读过不少书，推荐几本个人觉得不错的：

《Vue.js项目开发实战》张帆
《我的第一本算法书》【日】宫崎修一；石田保辉，入门书籍，无代码进行图解
《算法图解：像小说一样有趣的算法入门书》【美】Aditya Bhargava
《编译与反编译技术实战》庞建民
《重构：改善既有代码的设计》【美】Martin Fowler
《Docker技术入门与实战》杨保华；戴王剑；曹亚仑
《一本小小的蓝色逻辑书》【加】布兰登•罗伊尔
《精进：如何成为一个很厉害的人》采铜

最近也买了极客时间上的几门课程，有几门我觉得不错的，虽然没有实体书出版，但课程依然还是按照书籍写作方式来写，比较系统化，有兴趣的也可以看看：

《左耳听风》
《软件工程之美》
《项目管理实战20讲》

不过有一门课是不推荐的，就是《程序员进阶攻略》，后来作者也出了实体书，但总觉得作者对武侠小说过着迷，课程写得有点过于武侠风，技术与武侠关联得过于牵强。

书单均是个人看过或者业界认可的经典书籍，跟网上罗列的安全书单不同，并非把网店上的各安全书籍都罗列上的。如果你有何好书推荐可在Issues（https://github.com/riusksk/secbook/issues）上提交，或者提交合并，待我看过之后，如果觉得可以就会在此处更新，这里也会不定期更新书单。

文末附完整的思维导图，欢迎收藏。

计算机及系统原理

· 《编码：隐匿在计算机软硬件背后的语言》【美】Charles Petzold

· 《深入理解计算机系统》【美】Randal E.Bryant

· 《深入理解Windows操作系统》【美】Russinovich,M.E.；Solomon,D.A.

· 《Linux内核设计与实现》【美】Robert Love

· 《深入理解Android内核设计思想》林学森

· 《Android系统源代码情景分析》罗升阳

· 《深入理解Mac OS X & iOS操作系统》【美】Jonathan Levin

· 《深入理解Linux内核》【美】DanielP.Bovet

· 《代码揭秘：从C/C++的角度探秘计算机系统》左飞

· 《Android Dalvik虚拟机结构及机制剖析（第1、2卷）》吴艳霞；张国印

· 《Android Internals::Power User’s View》【美】Jonathan Levin，中译本《最强Android书：架构大剖析》

编程开发

系统平台

Windows

· 《Windows程序设计》【美】Charles Petzold

· 《Windows核心编程》【美】Jeffrey Richter

· 《Windows环境下32位汇编语言程序设计》罗云彬

· 《Windows驱动开发技术详解》张帆

Linux/Unix

· 《UNIX环境高级编程》【美】W.Richard Stevens；Stephen A.Rago

· 《Linux程序设计》【美】Neil Matthew；Richard Stones

· 《Linux设备驱动程序》【美】Jonathan Corbet；Alessandro Rubini；Gerg Kroah-Hartman

macOS/iOS

· 《iOS编程》【美】Christian Keur；Aaron Hillegass

· 《OS X与iOS内核编程）【澳】Halvorsen,O.H.；Clarke,D

Android

· 《第一行代码——Android》郭霖

· 《Android编程权威指南》【美】Brian Hardy；BillPhillips

编程语言

C

· 《C语言程序设计》【美】Brian W.Kernighan；Dennis M.Ritchie

· 《C Primer Plus》【美】Stephen Prata，入门书籍

· 《C和指针》【美】Kenneth A.Reek

· 《C陷阱与缺陷》【美】Andrew Koenig

· 《C专家编程》【美】Peter van der Linden

C++

· 《C++ Primer Plus》【美】Stephen Prata，入门书籍

· 《C++ Primer》【美】Stanley B.Lippman；Josée Lajoie；Barbara E.Moo，进阶书籍

ASM

· 《Intel汇编语言程序设计》【美】Kip Irvine

· 《Intel开发手册》

· 《汇编语言（第3版）》王爽

· 《x86汇编语言：从实模式到保护模式》李忠

Java

· 《Java核心技术》【美】Cay S.Horstmann；Gary Cornell，入门书籍

· 《Java 编程思想》【美】Bruce eckel，进阶书籍

JavaScript

· 《JavaScript DOM编程艺术》【美】Jeremy Keith；【加】Jeffrey Sambells

· 《JavaScript高级程序设计》【美】Zakas.Bicholas C.

· 《Vue.js项目开发实战》张帆

Python

· 《Python核心编程（第2版）》【美】Wesley J·Chun

Shell

· 《Linux Shell脚本攻略》【印】Sarath Lakshman

调试技术

· 《软件调试》张银奎

· 《Debug Hacks》【日】吉冈弘隆；大和一洋；大岩尚宏；安部东洋；吉田俊辅

· 《格蠹汇编：软件调试案例锦集》张银奎

数据结构与算法

· 《数据结构与算法分析——C语言描述》【美】Mark Allen Weiss

· 《算法导论》【美】Thomas H.Cormen；Chales E.Leiserson；Ronald l.Rivest

· 《我的第一本算法书》【日】宫崎修一；石田保辉，入门书籍，无代码进行图解

· 《算法图解：像小说一样有趣的算法入门书》【美】Aditya Bhargava

编译原理

· 《编译系统透视：图解编译原理》新设计团队，入门书籍

· 《编译原理》（龙书）【美】Alfered V.Aho；Monica S.Lam；Ravi Sehi；Jeffrey D.Ullmam

· 《编译与反编译技术实战》庞建民

其他

· 《编程高手箴言》梁肇新

· 《代码整洁之道》【美】Robert C.Martin

· 《代码大全》【美】Steve McConnell

· 《重构：改善既有代码的设计》【美】Martin Fowler

网络技术

· 《TCP/IP详解（卷1：协议）》【美】Kevin R.fall；W.Richard Stevens

· 《Wireshark数据包分析实战》【美】Chris Sanders

安全技术

安全开发

· 《天书夜读：从汇编语言到Windows内核编程》谭文；邵坚磊

· 《Rootkit：系统灰色地带的潜伏者》【美】Bill Blunden

· 《Rootkits——Windows内核的安全防护》【美】Gerg Hoglund；James Butler

· 《BSD ROOTKIT设计——内核黑客指引书》【美】Joseph Kong

· 《寒江独钓：Windows内核安全编程》谭文；杨潇；邵坚磊

逆向工程

· 《加密与解密》段钢

· 《恶意软件分析诀窍与工具箱——对抗“流氓”软件的技术与利器》【美】Michael Hale Ligh；Steven Adair

· 《C++反汇编与逆向分析技术揭秘》钱林松；赵海旭

· 《IDA权威指南》【美】Chris Eagle

· 《逆向工程权威指南》【乌克兰】Dennis Yurichev，多平台入门大全

· 《Android软件安全与逆向分析》丰生强

· 《macOS软件安全与逆向分析》丰生强

· 《iOS应用逆向工程（第2版）》沙梓社；吴航

Web安全

· 《黑客攻防技术宝典：Web实战篇》【美】Marcus Pinto，Dafydd Stuttard

· 《白帽子讲Web安全》吴翰清

· 《Web安全测试》【美】Paco Hope；Ben Waltber

· 《Web前端黑客技术揭秘》钟晨鸣；徐少培

· 《精通脚本黑客》曾云好

软件/系统安全

· 《0day安全：软件漏洞分析技术（第2版）》王清，入门书籍

· 《漏洞战争：软件漏洞分析精要》林桠泉，进阶书籍

· 《捉虫日记》【德】Tobias Klein，进阶书籍

· 《黑客防线2009缓冲区溢出攻击与防范专辑》

· 《内核漏洞的利用与防范》【美】Enrico Perla；Massimiliano Oldani

· 《Fuzzing for Software Security Testing and Quality Assurance（第2版）》【美】Charlie Miller，博文视点翻译中

· 《iOS Hackers’s Handbook》【美】Charlie Miller，不推荐中文版

· 《The Mac Hacker’s Handbook》【美】Charlie Miller

· 《Android安全攻防权威指南》【美】Joshua J.Drake；【西】Pau Oliva Fora；【美】Collin Mulliner

· 《The Art of Softwar Security Assessment:Identifying and Preventing Software Vulnerabilities》【美】Mark Dowd

· 《Android Security Cookbook》【美】Keith Makan; Scott Alexander-Bown，中译本《Android安全攻防实战》

· 《模糊测试-强制性安全漏洞挖掘》【美】Michael Mutton

· 《Exploit编写系列教程》【美】Corelan Team

· 《MacOS and iOS Internals,Volume Ⅲ: Security & Insecurity》【美】Jonathan Levin，博文视点翻译中

· 《灰帽黑客：正义黑客的道德规范、渗透测试、攻击方法和漏洞分析技术》【美】Allen Harper；Shon harris

· 《威胁建模：设计和交付更安全的软件》【美】Adam Shostack

无线电安全

· 《无线电安全攻防大揭秘》杨卿；黄琳

硬件安全

· 《硬件安全攻防大揭秘》简云定，杨卿

汽车安全

· 《智能汽车安全攻防大揭秘》李均；杨卿

· 《汽车黑客大曝光》【美】Craig Smith

产品

· 《人人都是产品经理》苏杰

运营

· 《运营之光2.0：我的互联网运营方法论与自白》黄有璨

设计

· 《写给大家看的设计书》【美】Robin Williams

· 《听故事，学PPT设计》杨雪

运维

· 《Docker技术入门与实战》杨保华；戴王剑；曹亚仑

· 《鸟哥的Linux私房菜》鸟哥

软技能

· 《软技能：代码之外的生存指南》【美】John Sonmez

· 《程序员健康指南》【美】JoeKutner

· 《影响力》【美】Robert B.Cialdini

· 《穷爸爸富爸爸》【美】Robert Toru Kiyosaki

· 《横向领导力》【美】Roger Fisher；Alan Sharpe

· 《职业情商》张新越

· 《程序员的成长课》安晓辉；周鹏

· 《高效演讲：斯坦福最受欢迎的沟通课》【美】Peter Meyers；Shann Nix

· 《程序员的英语》【韩】朴栽浒；李海永

· 《思考，快与慢》【美】丹尼尔·卡尼曼

· 《少有人走的路》【美】斯科特·派克

· 《异类：不一样的成功启示录》【加】马尔科姆·格拉德威尔

· 《见识》吴军

· 《英语写作手册：风格的要素》【美】William Strunk

· 《非暴力沟通》【美】马歇尔·卢森堡

· 《风格感觉：21世纪写作指南》【美】史蒂芬·平克

· 《浪潮之巅》（上下册）吴军

· 《一本小小的蓝色逻辑书》【加】布兰登·罗伊尔

· 《精进：如何成为一个很厉害的人》采铜

附思维导图：

HITB 2020：二进制漏洞挖掘仍是会议主流方向

2020-06-07T04:44:41.000Z

本周Hack In The Box官方已经将大会演讲视频上传到YouTube，之前在官网有提供部分议题的pdf下载，但有些未提供的议题，这次也公开了视频，可以看到议题ppt内容。

今年的议题更多集中在二进制漏洞挖掘上，占比43%，而这些议题涉及（Windows、macOS、IoT、工控等等），其它议题方向包括恶意软件、二进制分析工具、容器安全、漏洞奖励计划等等，可以看出当前工业界的一些研究议题，还是比较喜欢二进制漏洞挖掘这个方向，这次一个Web相关议题都没有。

精彩议题推荐

1、60 CVEs in 60 Days

主要分享Windows平台下高权限进程的Symlink攻击（高权限进程在操作文件时，未作严格的权限校验，导致攻击利用符号链接到一些受保护的目录文件，比如C盘的系统DLL文件，后面系统或应用去自动加载时，实现代码执行并提权），这种攻击方式最早是由Project Zero大牛James Forshaw公布的，当时还开源了个利用测试工具(https://github.com/googleprojectzero/symboliclink-testing-tools) ，指定目录参数来测试，但它还算不上完整的漏洞挖掘工具。

漏洞原理较为简单，关键在于如何批量自动化挖掘，为此作者实现了一款叫 Ichanea 的自动化漏洞挖掘工具。

原理：通过过滤驱动捕获文件操作相关的IRP包，然后获取归属进程的相关信息，包括路径、进线程token等等，然后判断是否为高权限进程，若是就拿Token去检测文件的访问权限，如果可以就发消息给高权限的服务进程，创建/RCP/Control的加载点及符号链接进行DLL劫持测试，从而将监控、发现和利用集成一体。

最后在26家厂商（包括微软、Intel、Adobe、华为等等）产品中，挖到上百个漏洞，其中已有60个CVE致谢，产量颇丰。

2、Pwning Adobe Reader Multiple Times with Malformed Strings

腾讯玄武实验室出品，分享Adobe Reader在处理字符串时的安全问题。通过PDF JS来构造恶意字符串去触发，JS上的漏洞也更便于写exploit。虽然Adobe用了一些自定义的字符串安全处理函数，但其使用不当导致仍会造成漏洞。主要有两方面原因：

1、传错参数，比如拷贝字符时max_bytes参数误传0x7FFFFFFF，可能造成溢出；

2、字符串类型检测不当，比如误将ASNI当作Unicode字符串处理，千万类型混淆漏洞。

感觉这个攻击面还是有点偏门，找到一块新大陆，刷起漏洞来应该很爽，但估计也就一波过，可能没剩下啥了。

3、Exploiting directory permissions on macOS

有点类似前面Windows Symlink攻击提权的思路，介绍了macOS下系统对文件及目录的权限管控方式，用fs_usage去监控进程的文件操作行为，从而找出一些可能被用于提权的目录/文件。利用的正是文件与目录高低权限的差异化，借助软硬链实现对受保护文件的越权操作。有些只能写，但内容不可控，或者只能删除，也有可被用于root提权的漏洞。最后作者也简单地介绍一些文件操作方面的安全建议，比如对于安装器，若是/tmp就生成随机名目录，其它的要控制好权限，比如就root权限，其它则收回，安装前清理目录，删除移动文件时避免支持链接方式等等。

4、Documents of Doom – Infecting Macos Via Office Macros

以前Office宏病毒在Windows还是流行过一段时间的，其实macOS上也有，作者就列举了2017、2018、2019年的三次真实的宏攻击案例，也介绍了olevba之类的分析工具。

除此之外，还介绍了一些mac版Office沙盒逃逸的漏洞，用户打开doc后，可以无提示无交互的实现代码执行。作者自己也挖过一个沙盒逃逸漏洞，正是利用Python这条漏网之鱼，于用它将app添加版系统的自启动项，实现非沙盒下的执行权限。

5、Fuzzing File System Implementations to Uncover Security Bugs

PPT上写的关键信息不多，但重要的是作者把工具开源了，针对BSD文件系统（支持FFS、UFS、EXT、ZFS文件系统格式）进行Fuzzing，工具地址：https://github.com/0xricksanchez/fisy-fuzz 。所以重点可以看下该工具，支持Ubuntu，要求KVM、QEMU和libvirt，采用的是暴力Fuzzing 文件系统，直接用到了radamsa，自己也作了全局的随机变异，然后尝试加载，若加载成功就调用syscall执行一些文件操作，看是否崩溃，最后再借助虚拟机快照还原运行环境。

完整议题列表

60 CVEs in 60 Days
The State of ICS Security: then and Now
Pwning Adobe Reader Multiple Times with Malformed Strings
Open the Gates – the (In)Security of Cloudless Smart Door Systems
Hiding in Plain Sight: Analyzing Recent Evolutions in Malware Loaders
Building Next-gen Security Analysis Tools with Qiling Framework
Exploiting Directory Permissions on macOS
Documents of Doom – Infecting Macos Via Office Macros
From Man-in-the-Middle to Privesc and Rce: Exploiting the Netlogon Protocol
The Dna of Hidden Cobra – a Look at a Nation State’s Cyber Offensive Programs
Prisoner Number 6
Fuzzing File System Implementations to Uncover Security Bugs
Breaking and Securing Cloud Platforms
Army of Undead: Tailored Firmware Emulation
Bugrank: a Community Bug Bounty Platform
Virtual Lab: Bare-metal Reverse Engineering & Hardware Hacking

议题ppt及视频地址参见：https://conference.hitb.org/lockdown-livestream/

谈谈追踪前沿学术研究的技巧

2020-05-30T05:55:39.000Z

以前找论文都只知道上中国知网CNKI，很多是中文，且论文质量一般，更重要的还是收费。所以，我离开学校后，有时下载论文，都是找别人帮忙。

最近一年刷Twitter，经常发现一些漏洞研究论文都是在一个叫arXiv的网站提供免费下载，而且经常是会议开始前很早就公开了。

这里介绍下http://arXiv.org这个学术论文搜索引擎。

arXiv（读音如英语的 archive ）是一个收集物理学、数学、计算机科学与生物学论文预印本的网站。arXiv 原先是由物理学家保罗·金斯巴格在1991年建立的网站，本意在收集物理学的论文预印本，随后括及天文、数学等其它领域。金斯巴格因为这个网站获得了2002年的麦克阿瑟奖。 arXiv 原先挂在洛斯阿拉莫斯国家，现在挂在康奈尔大学下面。

为了防止自己的想法在论文被收录前被他人剽窃，作者会将预稿上传到arvix作为预收录，以证明论文的原创性。

所以上面的论文经常比投稿大会更早放出，而且免费下载。英语通常是学术论文的第一语言，牛逼的学术论文也基本是英语写的，这点上国外的学术检索引擎就占据了一定优势，很多在CNDI是检索不到的，况且免费论文也不适合让你拿来收费。

如果本文只是介绍arXiv让你搜索论文，那就没意思了。

下面介绍如何通过web feed免费订阅最新论文的方法。
我平时是用Inoreader订阅RSS，但arXiv并没有提供RSS。刚好最近Inoreader出了新功能叫Web Feed，通过定时爬取特定页面来实现RSS订阅的类似效果。

这里我以论文标题含fuzz的关键词来检索计算机科学论文，如果不检索标题，可能会出现非漏洞研究论文，所以推荐检索标题会更准确一些。同时，注意开启按最新时间排序。

将搜索完生成的链接输入Inoreader搜索：

订阅效果：

以后就可以及时获取最新论文的下载。

技术人的修炼之道：从业余到专业

2020-05-05T06:01:41.000Z

马斯克坐在他们前面一排,正在电脑前打字。“我们心想,“这个呆子,他现在还能干吗?”这时马斯克突然转过身来,亮出了他制作的电子表格。“兄弟们,”他说,“我觉得我们可以自己造火箭。”

马斯克把他的笔记本电脑递给格里芬和坎特雷尔,他们惊呆了。表格里详细列明了建造、装配和发射一枚火箭所需的成本。根据马斯克的计算,他需要建造一枚大小适中的火箭,以满足那些搭载小型卫星和研究设备的细分市场的需求,这样就能节省一笔发射费用。他在表格中还列出了假设的火箭性能特性,内容十分详细。“我说,‘埃隆,你从哪里得到这些数据的?”’坎特雷尔说。

马斯克用了几个月的时间研究航天工业及其背后的物理原理。他从坎特雷尔和其他人那里借来了《火箭推进原理》( RocKet Propulsion E1ements)、《天体动力学基础》( Fundamentals of Astrodynam-ics )、《燃气涡轮和火箭推进的空气动力学》( Aerothermodynamics of Gas Turbine and RocKet Propul-sion ),还有其他各种专业书籍。马斯克仿佛又找到了童年时的状态,他努力吸收关于太空的一切知识,在这一系列近似冥想的学习过程中,他终于意识到,自己制造的火箭可以,而且也应该比俄罗斯人的更便宜。忘了老鼠计划吧。忘了可以回传生长影像的植物吧,它有可能在火星上死掉。通过更低的太空探索成本,马斯克可以激发人们重新思考太空探索。

——摘自《硅谷钢铁侠》

造火箭这种事，对于绝大多数人而言，也就吹吹牛逼而已。但马斯克勇于挑战，最后还真让他干成了。

对于跨学科的领域知识，马斯克也是花了不少时间先从基础教科书入手，然后将知识点与现有知识和经历进行关联，以转化为自己的知识，再作迁移学习与应用。哪怕最后他搞出来的可回收火箭比NASA还牛逼，技术上更加创新，但他也是先从底层的基础技术入手，以不变应万变。像计算机科学迅速发展了这么多年，出现了许多新技术，但底层的那些基础知识还是那一些，变化不大。

通常每个学科领域都有一些基础专业课，比如医学有四大基础课程：药理、病理、生理、解剖；计算机也有五大基础课程：操作系统原理、计算机组成原理、计算机网络、数据结构与算法、编译原理。

不过，对于刚接触新领域的人，一般不知道刚开始要学什么，这时搜索引擎就派上用场了。如果有认识的专业人士，问下自然是最快的，但这种情况可遇不可求，所以还是老实地google下吧。

刚准备学安全的时候，鬼知道要学啥，要看啥书。一头扎进图书馆，随便挑有“黑客”二字的，能看懂的就借来看，再后来发现“黑客”之书看多了没什么提升，于是开始学一些计算机专业的基础课，就这样不断地来回挑书借书读书，久而久之就知道该学什么了。

所以，判断一个人对新领域是真的感兴趣，还是仅仅好奇而已，最好的方式就是把他扔进图书馆，让他自己挑书看，一本不行再换一本，来回折腾个五六遍，看他能否坚持学习下去。

之前看过一则寓言故事：两个农夫上山砍柴，挑柴回家的路上，累了就在中途休息一下。期间一位农夫突发奇想，就问同伴：你说这皇帝每天会用什么挑柴？另一个人回答：肯定是用金扁担。

农夫受自身阅历限制，对不了解的事情，只能凭借已有知识来理解和猜测。不知与不会是两个概念，业余与专业的区别就在于此：专业者知道自己的不足，业余者则感觉专业的还不如自己。也就是说，专业者知道自己不会什么，业余者不知道自己不会什么。

自己都不知道哪里不足，就不知道要去学什么。帮助我从“不会”进阶到“不知”的是看雪学院，它让我知道了逆向工程、软件漏洞、内核驱动这些知识盲点。在看雪上知道了《加密与解密》、《网络渗透技术》、《0day安全：软件漏洞分析技术》这些经典书籍，但当时的我哪看得懂这些天书。最先看到的是网渗一书，当我翻开第一章的时候，我就懵逼了，什么GDB、SoftICE调试器、IDA反汇编器一类的工具，都是什么鬼啊？然后在安全焦点上看到介绍如何学习网渗一书的建议，其中就提到了《深入理解计算机系统》，然后我花了好长时间把这书读了两遍，还做了笔记。再跟着看雪精华集里的文章都多动手实践，crackme破解一遍，exploitme利用一遍。当时我就一个目标：读懂《网络渗透技术》。后来我大约花了三四年时间才达到这一目标（没办法，天赋不足，后天来凑）。所以，一个好的技术社区可以帮助自己提升认知，认清自己的知识盲点，从而找到适合自己的学习方向。

学习金字塔告诉我们，通过主动学习后，知识的留存率最高。什么是主动学习？就是说、写、教、做的输出式学习。

说：给学弟学妹们分享些技术，给企业/学校作培训，上学术/工业顶会演讲，都可以作为主动学习的方式。

写：作演讲也要写ppt或文章，给一些杂志/门户网站投稿，都可以帮助加深对知识的理解，有时还能顺便赚点稿费。直至后来出版社因为之前的技术文章找过来，才有了《漏洞战争》一书。

教：自己理解了是一回事，教会别人又是另一回事，要求更高，除了理解知识本身之外，还要以受教者可理解的话也讲述。特别是向非专业者讲述专业知识时，对教授者的知识理解程度更高。

做：就是应用实践，比如打CTF，刷漏洞悬赏平台。计算机技术是一项重实践的学科，编程、调试和挖洞无不如此，若毕业生刚来就大谈架构设计、设计模式，那谁来写代码呢？

兴趣是第一动力，但不是唯一的。

大学时代，很多人会去勤工俭学，牺牲自己休息和学习的时间。但我没这么干，因为我觉得勤工俭学与学习是个零和游戏，两者此消彼长，而我希望达到1+1>2的效果。当然，自己也不想去端盘子就是。

于是我选择给《黑客防线》投稿，一开始边翻译边学习，边学习边投稿，再拿稿费吃饭上网买书（当时没个人电脑），然后继续保持学习，从翻译到原创。为了写稿，就要不断地学习新知识，不然也没钱吃饭买书。就这样：

学习 —》写稿 —》赚钱 —》买书/上网 —》学习

自此建立起良性循环的学习动力，而内在的学习驱动力比努力的被动学习更加有效。

2013年，“自媒体”成为热词。2012年年末，“简书”上线，“今日头条”上线，“知乎”开放用户注册，微信推出订阅号。每个人都可以是媒体，每个人都可以提供知识服务。这一年，人均每周上网时间大幅增加到25小时，阅读一篇文章的平均用时却降到57秒。

——摘自《这样读书就够了》

现在每天快餐式的知识太多了，文章更多的是表达观点、方法或某些知识点的碎片化知识，一般都是不成体系的（但也不是绝对的，有些论文就写得很系统完整），需要自己加工吸收，将其与己有的知识领域关联并应用起来。

《这样读书就够了》介绍了一种方法，教你如何将碎片化知识进行加工，转化为自成体系的知识。

什么是体系？不是点，不是线，而是网，是立体的网络。

最初，你接收到的是一个知识点：

然后，你给这个碎片信息加上前因（为什么要这么做）后果（行动之后的结果）：

其后再加上适用边界（如特定场景、前提条件、使用条件等等）：

但这样的信息仍然是线性的，需要再加一个维度，让它变得立体，即与自己关联和互动起来：反思和行动。反思（A1）指向过去，行动(A2)指向未来。

这就是“举一反三”：为一个信息或知识点构建3个维度。加工后的信息不再是一个孤立的点，而是伸出了6根触角，等待与其他信息连接。当你有了多个这样加工过的知识点之后，不同知识点会相连，互相对接、榫合、支撑，形成一个晶格体系，这就是你自己的知识体系。

之前付费知识兴起时，我也在“得到”app上买了几门课，听的时候感觉很有道理，听完之后感觉啥也没留下。其中有门课叫《有效训练你的研究能力》，共6篇短文而已，网上搜索下就有，可以不用购买。虽然学完并不能有效训练你的研究能力，可操作性差些，但其中讲到的三种意识可以借鉴下。

作品意识：刻意地追求卓越

本质上就是刻意练习地去追求更好，也不是单纯地完成任务。比如做饭，多数人虽然做一辈子饭，但大多成不了专业厨师，缺乏的就是不断练习不断反思提升的作品意识。

目标意识：防止研究过程跑偏

在研究学习前，经常要收集资料，有时遇到自己感兴趣的资料，可能会多深入学习下，但学着学着就容易忘记原有目标了。所以，搜集资料既要足量，又要克制，避免过多偏离目标的资料干扰。

局外意识：保持研究的客观性

有时我们在调研对比竞品安全检测能力时，可能会直接用自己的测试样本库，而自研的安全系统已经专门针对自己的测试样本库作过对比，那对比结果肯定是有失偏颇的。最好的方式是使用多方样本库进行对比测试，以保证结论的客观性。所以在研究过程中，有时就要跳出局外，以旁观者的角度来看待以保证研究结论的公平可靠。

我是个容易产生知识焦虑的人，所以也干过一些伪学习的事。伪学习完全脱离了学习本身，仅仅是为了满足自我的良好感觉，帮助自己摆脱焦虑。个人认为的伪学习主要有以下几种情况：

单纯拼数量的学习：鼓吹一年要读100，300本书，一年要听多少在线课程，10分钟读透xx书籍等等。
追捧“大神”式的学习：缺乏辨别能力，盲目追随“大神”，网上各种买课程，想当然地以为听了“大神”的课，自己也变成大神了。
沉迷于不解决实际问题的学习：一整年看的都是不用思考的书籍，比如小说，只图一时爽，对提升能力无任何帮助。
干货收藏式学习：看个标题和开头，直接微信收藏，或存印象笔记，然后就没然后了。之前我也有过这种做法，后来一些看得慢的资料就干脆打印出来慢慢学习了。

本文主要介绍了一些学习方法和个人入门安全领域的一点经验，更多是想强调基础知识的重要性，输出式的主动学习能够实现更高效的学习，也介绍了知识体系建设方法和研究过程中需要注意的三个点，最后提醒大家避免进入伪学习的坑。第一次在手机上写这么长的文章，且个人经历有限，如有误欢迎指正探讨。

关于Adobe PDF 0day的故事

2020-04-11T05:40:55.000Z

今天StarLabs 发布了他们之前在天府杯上用的adobe pdf 完整exploit，该漏洞是一个 JS API UAF漏洞，利用代码公布在github上，以及利用思路分析文章：https://starlabs.sg/blog/2020/04/tianfu-cup-2019-adobe-reader-exploitation/

去年天府杯上，Adobe Reader应该是最大的目标了，很多人打，但临赛前，很多人却退赛了。因为当时的比赛规则是奖金池固定，所有攻破团队来平分那笔钱，所以越多人参赛就越吃亏。但即便退赛了，一些攻破团队拿到钱再平分下也没多少了，最后还不如直接报ZDI，甚至可能还不如上HackerOne报个xss。挖个xss多久？可能几天，利用都不用写。但挖个pdf漏洞多久，可能挖洞一周，写利用一个月，这性价比自不必多言，因此这届比赛，奖金规则一直被圈内人吐槽。

当时在现场了解到，可能不少人的pdf 0day都是js api，这种通过js完成利用比较方便通用，当然其它非js模块的漏洞也同样可借助js堆喷利用。这些用js api漏洞的人最应该担心撞洞了，现场也有人用其它模块的pdf 0day，反正最后手上有个洞被撞没了。一个只在当最新版出现的漏洞，当时Project Zero报了一堆那个模块的漏洞，结果坑爹的Adobe修了漏洞1，却造就了漏洞2出来。在Adobe安全公告上，看到那个被撞的漏洞致谢上仍然写的是Project Zero的人（没错，未出现传说中的TFB)……

至少通过这件事情告诉我们，跟着PZ有肉吃！！！

Adobe的JS引擎用的是2013年左右的SpiderMonkey修改的，所以当初像domato这种js fuzzer神器出来之后，直接拿来fuzz，你都可以搞出一堆Adobe Reader的0day出来，也确实被刷了一波，看公告致谢时间，好像是我带的坏头😂…

前两年，pdf中的图片解析漏洞盛行，被玄武的刘姓小哥刷爆了。当时如果我报10个此类漏洞，那么可能就会有3个撞洞，就是这么惨烈，连windows上xps这种偏门格式，都被撞，也跟360的撞过。

在此之后，被刷最多的pdf 漏洞，除了常规的js api外，postscript被国外安全研究员mr_me刷了不少，他写了个ps语法模板生成器去fuzz，产量颇丰。如果没记错的话，据他自己在Twitter上公布的，其2018全年在ZDI的收益是近20万刀，相当于140万元。之前他创办了一个公司，但公司员工就一人。没错，就是他自己，基本就是专职挖洞和培训。今年他入职360 vulcan了，远程办公。

最后聊点pdf的通用利用技术，毕竟本公众号是技术导向的，但请原谅我的排版和无图内容，因为本文是在手机上写的，且全程在车上完成。

上文提到的文章已经给出了完整的利用思路，整体而言：

1. 无论何种内存破坏漏洞，一些逻辑漏洞除外，首先都设法转换成任意读写。利用js array堆喷去内存布局，实现uaf的占坑，或其它越界写的后堆块填充，以实现写内容和位置的控制，而js array本身可读，进而实现信息泄露。

2. 覆盖虚表指针去控制eip。寻找上下文可用的虚表指针去实现劫持，像starlabs用CTextField去创建一批对象，目的就是用来覆盖它的虚表指针

3.绕过DEP和CFI。2019年3月左右，Adobe终于加入了CFI，导致常规的ROP失效。每次这种新安全机制出来的时候，最佳的绕过方式一定是先寻找未受保护的模块或代码块。回望过往的DEP、ASLR、CFI和PAC，无不如此。这次starlab亦然，他们直接搜索Adobe安装目录下的pe文件，若OPTIONAL_HEADER.DllCharacteristics & 0x4000 = 0，即代表无CFI保护，最后他们找到icucnv58.dll用来构造ROP，分配可执行的shellcode来达到任意代码执行。

除了第一步需要依赖漏洞上下文场景来转换任意读写外，利用的难点也是在此，而后续工作都是可以套路化。

可以看到，直至2020年了，Adobe的整体漏洞利用思路依然变化不大，仍是《漏洞战争》中各案例所分享过的方法，只是需要根据漏洞场景作些适配，比如寻找UAF对象同大小的对象，像starlab就用currentValueIndices方法来占坑。不好意思，这里打了下个人广告，可惜公众号app不能直接插入书籍广告，不然就广告彻底一些🤑

持续Fuzzing在DevSecOps中的应用

2020-03-01T10:48:50.000Z

长期以来，一直有个疑问：

Fuzzing为何一直未被引入DevSecOps中？

刚好本周有两件事引起我的关注：

Google发布CIFuzz以支持Github项目实现CI构建过程中的持续Fuzzing（Continuous Fuzzing）
RSA创新沙盒比赛中ForAllSecure公司的参赛产品Mayhem——下一代Fuzzing解决方案

这两件事其实是往着同一目标前进的，就是将Fuzzing引入到CI持续集成中，直观的表现就是，当往代码仓库提交代码后，可被自动编译并完成Fuzzing，最后输出结果以进入下一开发环节。

这跟我去年11月在”天府杯”上分享的《Fuzzing平台建设的研究与设计》中的思路是类似的，当时国内外还没任何公开的产品，这次CIFuzz与Mayhem的出现，终于填补了这个空白。

先聊聊CIFuzz的实现原理

使用CIFuzz有2个要求：

1、只允许GitHub上的项目使用；

2、项目必须整合OSS-Fuzz

它主要利用GitHub Actions来实现下载、编译和运行oss-fuzz中的Fuzzer，若要fuzzing自己的项目，就得自己把先fuzzer提交到oss-fuzz。整个过程在docker中的ubuntu中运行，整个过程用workflow来定义这些操作行为:

name: CIFuzz
on: [pull_request]
jobs:
 Fuzzing:
   runs-on: ubuntu-latest
   steps:
   - name: Build Fuzzers
     uses: google/oss-fuzz/infra/cifuzz/actions/build_fuzzers@master
     with:
       oss-fuzz-project-name: 'example'
       dry-run: false
   - name: Run Fuzzers
     uses: google/oss-fuzz/infra/cifuzz/actions/run_fuzzers@master
     with:
       oss-fuzz-project-name: 'example'
       fuzz-seconds: 600
       dry-run: false
   - name: Upload Crash
     uses: actions/upload-artifact@v1
     if: failure()
     with:
       name: artifacts
       path: ./out/artifacts

所说GitHub 为每个 workflow 提供独享 1 核虚拟 CPU, 3.75GB 内存和 100GB 的磁盘空间，提供相当慷慨的计算资源。对于想将Fuzzing引入CI中的DevSecOps建设，确实挺耗计算资源的。还有另一种方法，就是由开发本地提交代码时，自动完成Fuzzing后再提交，利用的是开发者本地的计算资源，对于Fuzzing平台建设是最节约成本的。

当发现崩溃后，会在前端输出崩溃的栈回溯和测试用例等关键信息：

在腾讯内部，我们一般称workflow为流水线，在产品体验上这功能绝对秒杀GitHub，就是我之前贴着这张图：

再来看看Mayhem

对于Mayhem的信息是有限的，只有官网提供的相关文档。先来看下Mayhem的工作原理，大体流程跟上面一致的：

它将符号执行与覆盖引导技术结合用于Fuzzing测试，但符号执行整体上是偏于理论，且难以用于大项目，因为它容易出现路径爆炸问题。虽然他们用来打过CGC机器人CTF比赛，但其赛题都是定制的，并不能完全代表真实的软件世界，这点还需要时间来考验。

Mayhem提供有比较友好的前端界面，在功能上要比CIFuzz更加完善和自动化，体现出一个完整商业产品的特点：

发现崩溃后，也能够提供更加详细的崩溃信息，包括重现方法、样本下载、崩溃指令和地址等等：

Continuous Fuzzing实现上的常见问题

个人对持续Fuzzing建设的一些思考总结，列举一些常见问题和解决方案，欢迎私信探讨。

1、如何设置Fuzzing时长，既能保证测试的有效性，又能保证CI流程的流畅，避免产品发布受阻？

以往Fuzzing跑个几天是很常规的姿势，最长的我也跑过几个月的，但这在CI中显然是不合适的，必须为此设置时长限制，Google CIFuzz是默认10分钟，但个人觉得太短了，最好是几小时，但这要结合业务场景来定，有些产品一天构建N次，这得浪费不少计算资源。如果资源有限的话，最好每天一款产品只能Fuzzing一次。

2、如何编写Fuzzer保证测试的有效性？

CIFuzz是自己提供Fuzzer，需要开发者基于libfuzzer编写的fuzzer；而Mayhem没有明说，但一般都得开发者或者安全人员来开发。这个问题之前我也在《Fuzzing平台建设研究与设计》中说过，可以培训开发用libfuzzer来写fuzzer，也可以直接写单元测试程序，以及安全人员作定制化的fuzzer。

3、如何保证Fuzzing执行时的服务器安全？

使用者提交自己的代码并编译执行，如果不作隔离，肯定就后门无数，沦为大家的肉鸡。使用docker作隔离的容器是已经很成熟的方案了，不仅fuzz，其它一些DevSecOps建设中的其它安全测试方案同样适用，比如CI中的代码审计，我们也是用docker来做的。

4、如何提供测试样本？

CIFuzz是自己在oss-fuzz中指定好的样本，Mayhem是明说，但估计也是需要用户提供。在之前的文章，有讲过我的实现思路：以后缀名来区分文件格式，自动爬虫收集，根据输入数据的格式自动提供，对于特殊的输入数据，需要自己另外去收集，比如hook收集等等。本质上，无非就是开发者提供测试数据，或者平台建设者提供各种常见格式的测试样本。

如果你对DevSecOps建设、漏洞挖掘感兴趣，欢迎私信。

终端安全工程师（深圳）

岗位职责:
1.安全评估：对公司内的移动终端产品进行安全评估，并提供自动化检测规则，探索与实践DevSecOps
2.代码审计：开发自动化的代码审计系统
3.应急响应。对外部报告的终端漏洞进行响应，分析漏洞，排查影响范围，并提供检测与防御方案；
4.业界追踪。保持关注业界最新安全动态、新安全技术及发展趋势，促进安全技术的提升；
5.沉淀培训：形成技术知识的沉淀和分享，开展公司内交流和培训工作。

岗位要求:
1.本科及以上学历；
2.2年以上的安全工作经验；
3.熟悉常见的终端安全风险的危害、原理及其防御方案；
4.熟悉x86和ARM汇编，熟练使用IDA、GDB等逆向分析与调试工具
5.熟悉主流语言的代码安全审计技术，具备⼈工审计与自动化审计系统开发能⼒
6.熟悉DevSecOps并且有参与过其中一些安全过程的技术和经验；
7.熟悉移动终端应⽤隐私合规检测技术
7.至少熟悉C/C++、Python、Java其中的⼀门语⾔，能够独立开发漏洞检测工具
8.具备较强的学习能力、动手能力、沟通能力、团队合作意识及综合分析能力；

具备优秀安全基础能力或某一领域深度安全能力并对安全有浓厚兴趣者优先；
有终端自动化审计系统开发经验者优先；
有代码审计系统开发经验者优先；
有知名软件的CVE漏洞发现与利用成果的优先。

用afl玩超级玛丽：通过Fuzzing探索程序空间状态以发现更多执行路径

2020-02-29T06:47:24.000Z

今年S&P顶会上有一篇研究论文“IJON: Exploring Deep State Spaces via Fuzzing”，他们通过改造AFL来探测程序的空间状态，以发现更多程序行为，并拿游戏”超级玛丽”来作演示：

当前最流行的Fuzzing技术就是基于覆盖率的方法，Edge Coverage应该是当前最有效的覆盖率统计方法，比BasicBlock方式多记录调用边界，而afl对覆盖率的探测很多是暴力猜解的，一些afl家族工具也对其进行扩展，比如切割多字节指令为单字节作数据比较，提取cmp指令的一些常量操作值作变异。但是，这种方法对于一些特定的代码结构，若不去探测程序状态空间的中间点，就很难触发新的覆盖路径。

何为程序状态空间？

状态空间代表程序所有可能状态的集合，状态代表内存和寄存器的一种配置，以及系统提供的状态(比如文件描述符、类似原语)。状态空间比代码覆盖统计空间更大，若改造AFL就需要实现对状态空间的支持，以优化测试用例达到状态的多样性。

论文主要贡献

分析当前主流Fuzzer的反馈机制，并实现如何用它们表示状态空间；
扩展当前主流的覆盖反馈Fuzzer的能力，允许分析人员通过程序状态空间解决当前业界方法无法解决的路径约束问题；
展示了可信平台模块(TPM)、复杂格式解析器、超级马里奥游戏、迷宫和散列映射实现的软件仿真器的状态空间，演示其是如何被Fuzzer有效探索到的。顺便，解决掉一些CGC挑战集合中的难题（CGC专门为机器人自动打CTF而设计的题目，与真实软件场景还是有差异的），也发现了一些真实软件的漏洞（其实就是一个偏门的dmg2img工具而已）。

主要设计原理

作者设计了一套源码注释原语，其实就是给源码加个一两行补丁代码，用来干预Fuzzer的反馈功能。在可交互的Fuzzing会话中，分析人员可以人工介入去分析一直无法触达的执行路径，然后为其增加补丁代码解决路径探索障碍的问题。

afl-gcc或afl-clang本身就是对gcc/clang编译器的封装，添加一些编译选项，以及代码插桩的功能，作者为其编写了个链接库，以实现前面所说的注释原语，包括一些自定义函数和宏等，通过它能够访问AFL用于存储覆盖信息的位图（其实是个哈希表），直接添加和设置条目上去，将状态值直接反馈给Fuzzer。同时，也允许相同的edge coverage存储到不同的覆盖位图中，因为不同的状态值可能触发的是同一处edge coverage，这代表它能够实现更细粒度的反馈，为此它还提供扩展用于存储覆盖位置的共享内存区域。对于状态空间爆炸的问题，也会提供”爬山算法”（hill-climbing）作出优化选择。

作者对超级玛丽作了修改，使所有的键盘命令都可以从标准输入中读取，并且马里奥只能不停地向右跑，只要停下来就死掉，这个设计主要是为节省时间。

作者还用改造后的Ijon与AFL作对比，运行12小时的AFL看其能打到哪一关，而使用注释原语的Ijon只几分钟就通过了大部分的关卡，有些确实过不了。下图是超级玛丽打喷火怪兽那关，线条是Fuzzer发现的所有执行路径，对比还是比较明显的，AFL暴力探测的密集度比较明显，更关键还是没通关，至少从作者统计图上看是如此的。

论文链接：https://www.syssec.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2020/02/27/IJON-Oakland20.pdf

从研究者的视角看Fuzzing技术发展30年

2020-01-22T08:16:48.000Z

源起

1988年，在威斯康星大学Barton Miller教授的计算机实验课上（http://pages.cs.wisc.edu/~bart/fuzz/CS736-Projects-f1988.pdf ），首次提出Fuzz生成器(Fuzz Generator)的概念，用于测试Unix程序的健壮性，即用随机数据来测试程序直至崩溃。因此，Barton Miller教授也被多数人尊称为”模糊测试之父”。但是，当时更多是为了验证代码质量和程序的稳定性，而非专门用于挖掘安全漏洞，真正用于软件安全漏洞挖掘的开端要从下面两件事说起。

从学术界到工业界的证明

2001年，芬兰奥卢大学公布PROTOS测试集项目的研究成果（https://rd.springer.com/content/pdf/10.1007%2F978-0-387-35413-2_16.pdf ），首次将Fuzzing技术应用在网络协议的安全测试当中，他们针对不同的网络协议构造出不同的测试用例集，这些在其官网（https://www.ee.oulu.fi/research/ouspg/Protos ）上依然可以下载到。2002年，PROTOS逐渐成熟，Microsoft开始为该项目提供资金支持。于是，2003年项目组成立了Codenomicon公司，开始将Fuzzing技术应用于商业产品，也确实发现了不少安全问题。因此，PROTOS项目可以说是Fuzzing技术发展历程中的一次重要里程碑。可能大家对Codenomicon公司不太了解，但说到”心脏滴血”漏洞，应该无人不知无人不晓。没错，它就是Codenomicon公司发现的。

2002年，在BlackHat USA黑客大会上，来自Immunity安全公司（PS：还有人记得Immunity Debugger吗？）的Dave Aitel发表议题“An Introduction to SPIKE, the Fuzzer Creation Kit”，至此著名的Fuzzer工具SPIKE公布了，它是基于块模板定义的网络协议测试工具，优点是支持定义可变长度数据块的能力，除生成随机数据外，它还提供一些现成的边界值生成，以提供触发崩溃的概率。SPIKE的诞生，使得广大用户能够依据自身需求定制网络协议Fuzzer，这对Fuzzing技术的普及起到巨大的推动作用。早些年，笔者也曾写过一篇SPIKE的教程“基于SPIKE的网络协议Fuzzing技术(http://riusksk.me/2011/12/30/spike-fuzz/)"，但现在其实基本不用了。

从PROTOS到SPIKE的诞生，代表着学术界与工业界对Fuzzing技术在商业与安全实战领域的应用提供了有力的证明。

文件Fuzzing技术的兴起

2004年，Peach模糊测试框架的发布，标志着文件Fuzzing时代的到来。最初Peach是用Python开发的，后来在2007年被收购后改用C#重写，并分为社区版和付费版。Peach支持文件格式、网络协议、ActivieX控件等多种形式，通过编写pit文件(xml格式)来定义数据格式，每次开始写的时候其实挺费劲的，后来有人提供自动将010editor格式解析器（仿C语言的bt文件）转换为pit，在一定程度上可以缓解劳动力。笔者第一次通过文件Fuzzing挖到漏洞也是借助Peach实现的。

直至今日，Peach依然还有人在用，更有人将Peach与AFL打通，在Github上发布aflsmart的开源项目。

文件Fuzzing应该是当前Fuzzing应用中最为普遍的形式，即使是网络协议等其它目标的Fuzzing，也是可以转换为文件Fuzzing的。比如OpenSSL网络协议Fuzzing，通过源码打Log的方式先收集网络数据为本地文件，再调用其API写个hareness用AFL或libfuzzer进行本地测试，就顺利地将网络协议Fuzzing转换为文件Fuzzing。

语法模板Fuzzing：打开攻击浏览器的大门

2008年，Mozilla安全团队发布了jsfunfuzz和DOMfuzz，基于JS语法模板来生成测试用例，以挖掘浏览器漏洞，后来两款工具合称funfuzz( https://github.com/MozillaSecurity/funfuzz )，以开源的形式对外公开。这款工具在当时确实挖到了不少浏览器的漏洞，但其语法模板的可扩展性并不友好，只能在其代码上作修改，这点不如dharma( https://github.com/MozillaSecurity/dharma )，以及后来Project Zero发布的Domato( https://github.com/googleprojectzero/domato )。这种基于语法模板的Fuzzing方式，挖完一波后，就要求保持模板的更新才能持续产出，同时要理解测试目标在JS代码上的触发逻辑，比如JIT可通过for循环来触发代码优化，Dom UAF可通过创建Dom元素，并调用相关元素的方法来触发删除和引用，以探测是否存在UAF的可能。整体上依赖于对语法和目标原理的理解，才能构造出好的语法模板。

在funfuzz之后，业界也出现了好多款优秀的JS语法Fuzzing工具，比如grinder、nduja、crossfuzz等等。当年PC流行时代，用grinder来Fuzzing Windows IE浏览器的人应该比较多。

浏览器一直是网络攻击中最受关注和最常用的入口，过去如是，现今依然。因为系统自带，且用户使用率高，又是远程访问的最佳途径。渲染引擎和JS引擎一直是浏览器主要攻击面，主要以html、js、vbs作为解析语言，因此对这些语言的语法Fuzzing就自然而然的产生了。除此之外，如今WebSQL也开始备受关注，比如Chrome上的sqlite模块，SQL语法的fuzzing也随之而来。

除了浏览器，pdf的JS和flash的as语法解析，也一度作为攻击Adobe Reader和Adobe Flash的入口。

符号执行：学术与工业之争

2008年，基于LLVM的符号执行引擎KLEE发布后，引领了一波程序分析新姿势的潮流。后来，符号执行被应用于Fuzzing中，经常被用来打CTF比赛，用来找key、解混淆、fuzzing等用途。比如，将AFL与angr结合的driller（https://github.com/shellphish/driller )，还被用在了CGC(Cyber Grand Challenge)自动网络攻防竞赛上，但这种比赛都是特定场景下的比赛，不能完全代表真实的软件世界；还有，将AFL与KLEE结合的kleefl（https://github.com/julieeen/kleefl ），这款工具知道的人应该不多。

符号执行在学术界中应用得比较多，工业界相对少一些，这是现状。将符号执行应用在Fuzzing中，通过约束求解新路径的条件值，以增加代码覆盖率，可以一定程度上弥补暴力变异的不足。符号执行主要的挑战在于路径爆炸问题，约束求解能力的局限性，以及性能消耗问题，比如内存和时间消耗过大。符号执行与约束求解对于小型应用比较有效果，也常被用于CTF比赛，在CTF中使用最广的当属angr框架。但是，基于当前的业界情况，符号执行仍然比较难以应用于大型软件中。符号执行在Fuzzing中的应用并没有真正带来新的技术浪潮，真正的技术浪潮始于代码覆盖引导技术的引入。

代码覆盖引导技术：Fuzzing技术的分水岭

2013年底，afl-fuzz（ http://lcamtuf.coredump.cx/afl/ ）发布了，首次采用源码编译插桩和QEMU模式来实现代码覆盖引导Fuzzing的方式，这绝对是Fuzzing技术发展历程中最重要的一次里程碑，也是技术分水岭，它开启了Fuzzing技术的新篇章。刚发布的时候，afl并没有那么火，主要是在2014和2015年期间，被很多人使用后挖到不少主流开源软件的0day，并在Twitter上宣传，使得更多人关注到并使用，这证明了代码覆盖引导技术在Fuzzing实战中的价值。

随后，基于afl二次开发的fuzzer如雨后春笋般涌现出来，比如winafl、libfuzzer、AFLFast、Vuzzer等等，而且针对各种语言的版本出相继出现，比如go、python、js、ruby等等。一些已知名的Fuzzer也迅速跟进，比如syzkaller内核Fuzzer，它原本是基于API调用模板的，后来也引入了代码覆盖引导能力。同时，业界都在试图将其移植到各种平台上（比如windows、android、IOT平台等等），并实现支持闭源程序的代码覆盖引导能力，这一直是近几年来Fuzzing技术研究的热点方向，比如动静态插桩、虚拟机模拟执行、硬件特性等等。无论是工业界大会(BlackHat、OffensiveCon、CCC等等)，还是学术界四大顶会，关于Fuzzing的议题也越来越多，相信这种趋势会持续下去。

系统函数调用模板Fuzzing一度成为攻击内核的常用手段

2015年Google开源了syzkaller，一款用于Fuzzing Linux内核的工具，漏洞产出特别高。现在依然很多人用它来挖各系统平台的内核漏洞，包括Android、macOS、Windows等主流系统平台。syzkaller通过定义系统函数调用模板来实现，在模板中定义系统调用函数参数类型，并解决函数调用的顺序依赖和值依赖问题。Project Zero官方博客就曾写过一篇利用syzkaller fuzz socket挖掘Linux内核漏洞的文章，叫“Exploiting the Linux kernel via packet sockets(syzkaller usage)” ( https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html )，详细讲述了如何编写模板，以及syzkaller的使用方式。

Windows平台也常被通过构建GUI API调用模板来Fuzzing系统内核，macOS平台内核Fuzzing就常拿IOKit函数开刀，都是基于这种系统函数调用模板的Fuzzing方式实现的。

2016年Google提出”结构感知型Fuzzing”(Structure-Aware Fuzzing )，并基于libfuzzer与protobuf实现了libprotobuf-mutator(https://github.com/google/libprotobuf-mutator)，其实现思路与syskaller相似，它弥补了peach的无覆盖引导的问题，也弥补了afl和libfuzzer对于复杂输入类型的低效变异问题。正如前面提到的，也有人将afl与peach整合成aflsmart，以此实现类似功能。现在Project Zero也用libprotobuf-mutator来fuzzing iOS内核，详见“SockPuppet: A Walkthrough of a Kernel Exploit for iOS 12.4”(https://googleprojectzero.blogspot.com/2019/12/sockpuppet-walkthrough-of-kernel.html)。

结构感知型Fuzzing并不是什么新技术，跟Peach的实现思路是一样的，只是对输入数据类型作模板定义，以提高变异的准确率。只是当前大家更倾向于将结构感知与覆盖引导等多种技术优势整合一块，基于系统函数模板用于Fuzzing系统内核，相信这种方式未来仍会被经常使用。

助力开源生态安全建设

在工业界中，最知名的Fuzzing平台当属Google的clusterfuzz（ https://github.com/google/clusterfuzz ），运行在25000+台机器上，发现过16000+个Chrome bug，11000+开源项目bug，这个平台整合了OSS-Fuzz(https://github.com/google/oss-fuzz )，既支持libfuzzer和AFL的代码覆盖引导Fuzzing，也支持黑盒Fuzzing。OSS-Fuzz和clusterfuzz分别在2016年和2019年开源对外，业界同行可以协同开发，对于提交fuzzer后挖到新漏洞的，Google会美刀奖励提交者，对于主流开源项目的0Day，Google也是有奖励机制的。同时，Google开发了ASan、MSan、TSan、UBSan、LSan等多种编译时插桩工具用来帮助检测漏洞，有些漏洞只在开启相关Sanitizer之后才会触发异常，跟在Windows下开启页堆的方式类似，可以帮助更有效地发现崩溃场景，在发现和分析漏洞上提供帮助。

Google对开源生态安全建设的贡献，是各大互联网公司不能比的。他们的贡献不仅帮助提高各大主流开源项目的安全性，也降低了Fuzzing的技术成本，在资金和技术上对开源生态安全的建设提供了大力支持。

语法树变异成为语法解析引擎漏洞挖掘的新方向

2012年，USENIX安全顶会上发布一篇论文“Fuzzing with code fragments”，研究者开发了一款叫LangFuzz的工具，他们从firefox、webkit、chromium等开源的浏览器项目以及网络上去收集js测试样本，然后用ANTLR其进行AST语法树分析，再将样本拆分成非终止语法的代码片断，放入代码池中，最后再基于代码池的代码片断对输入样本作交叉变异，主要取同类型的代码片断作替换或插入，再运行生成的变异样本进行测试。

基于LangFuzz的思路，后面又有人开源了IFuzzer，并发表相关论文公开，在LangFuzz的基础上增加遗传算法，对输入样本进行评估，筛选出优秀的个体进行组装以产生新样本。不过这个工具并没有那么完善，也未见到比较好的实际漏洞产出。

2018年，Project Zero的Samuel Groß发布一款叫fuzzilli的JS语法Fuzzer工具，它整合了语法变异、模板生成、覆盖引导等多种技术，使用自定义中间语言用于语法变异，再将变异后的中间语言转换成JS代码。fuzzilli在3大主流JS引擎的测试中，战果颇丰，发现了不少漏洞，也因此被业界同行拿去作二次开发，又发现了其它新的漏洞。

2019年，有2篇学术论文发布，他们都引用了论文“Fuzzing with code fragments”中的思想，它们分别是”CodeAlchemist: Semantics-Aware Code Generation to Find Vulnerabilities in JavaScript Engines“和”Superion: Grammar-Aware Greybox Fuzzing“，CodeAlchemist将输入样本进行语法树分析和数据流分析，为拆分出来的代码片段设置前置和后置的约束条件，前置条件代表一些引用的变量需要先定义，后置条件代表代码片段的输出结果，通过两者来解决一些未定义变量引用的问题。Superion是将语法树变异规则置入AFL中实现的，借助AFL筛选变异后的输入样本，而且支持多种语言，也是采用ANTLR作语法树分析，其在语法扩展上比较友好。两款工具均在最新JS解析引擎上发现过若干0day漏洞，并且均已在Github上开源。

除了传统的模板Fuzzing，语法变异(无论是AST，还是自定义中间语言)也是一项值得探索的方向。

人工智能在Fuzzing中的应用仍亟待探索

2018年是人工智能元年，很多领域都在探索AI的应用，漏洞挖掘领域亦然。之前笔者阅读过一些AI应用在Fuzzing中的相关议题，主要集中在测试样本生成的训练上，利用已知漏洞的样本或正常样本作训练，然后重新生成测试样本进行测试。可惜从效果上来看，是一种高投入低产出的事情，有些还不如直接暴力变异来得高效高产。但这也不是说，AI没有价值，只是它在这方面的发展时间较短，很多东西仍亟待探索，还有待时间的年轮来证明。

Fuzzing平台建设的研究与设计(paper)

2020-01-21T02:19:37.000Z

引言

近年来，无论是工业界，还是学术界，Fuzzing技术的应用都非常广泛。每年的BlackHat、OffensiveCon、CCC等工业界顶会，以及学术界四大顶会（ S&P、CCS、Security、NDSS ），经常可以见到Fuzzing相关议题。Google Project Zero也公布其近5年的漏洞挖掘方式占比，其中Fuzzing占比37.2%，手工占比54.2%，其它占比8.6%，这对于高产的P0来说，37.2%的占比已经意味着不少漏洞了。按Project Zero官方公布的bug列表来看，当前共有1975个漏洞公开（包括一些无效、未修复的，这里仅作粗略估算），按37.2%来算，大约有735个漏洞是通过Fuzzing挖掘到的，着实不少的数量，况且大多是高质量漏洞。所以说，Fuzzing依然是当前安全界所热衷的漏洞挖掘方式。

本文主要探讨下企业内部关于Fuzzing平台建设的一些想法，个人主要是想表达一个观点：协同Fuzzing，即整合企业内部各工种（开发、测试、安全、运维等等）的力量，将Fuzzing合入CI构建中，通过DevSecOps协同模式来完成产品的Fuzzing工作，以便将漏洞消除在上线前阶段。

Fuzzing平台的价值思考

虽说Project Zero超过一半是人工审计发现的，但对于企业内部，项目之多，代码语言和代码行也是非常之多，很难单纯靠人工来解决的。量级的变化，自然会导致自动化需求的诞生，才能更加高效地发现、消除和监管企业内部的代码风险。

产品从开发到发布，涉及到多工种协作，如果能让他们一块参与到安全工作当中，那么有时也可以弥补安全人力的不足，同时让非安全出身的业余选手也能干专业的事，帮助安全人员覆盖更多的攻击面测试，提升漏洞发现率。

安全人员参与到产品的整个研发流程当中，可以将发现漏洞的时间线提前，有助于在产品上线前发现并解决安全风险，提高产品安全性。

协同Fuzzing平台的设计思路

以往我们在帮业务产品作安全测试时，开始前业务同事会提供文档资料或者开会分享产品功能设计的方方面面，以及担心的安全风险问题，安全同事需要花时间消化，前期双方都需要消耗不少时间成本，况且在有限的时间内，对产品的攻击面剖析也不一定足够到位。

假设当前需要对产品进行Fuzzing测试，一般需要一个支持命令行的测试程序，通常称为harness。开发或者测试的同学可能本身就会开发有相应的测试程序，如果没有，安全测试人员就得自己开发，有API或者源码都好办，没有的话，可能还得做Hook。

对产品最了解的，一般当属开发同学。所以，如果开发者在开发完相应功能后，开发以及质量测试人员若能够编写相应的接口测试程序，将对于安全测试会有很大帮助。一方面是工作效率的提升，另一方面是测试面的覆盖广度提升。

如此之后，我们可以设计出协同Fuzzing平台的工作流水线：

开发阶段：开发人员编写相应的harness程序，尽可能覆盖用于解析外部数据的处理函数。直接开发或者使用libfuzzer等安全测试库进行开发均可，安全人员也可定期对其进行安全培训，指导libfuzzer等工具的使用。
构建阶段：对于源码编译场景，支持多种构建触发方式，最佳的方式还是基于git事件触发，即提交代码后触发，然后将源码下载到指定的构建机编译，开发者需要配置编译命令，此处也可以开启ASAN或者AFL编译等功能；对于非编译场景，则直接提供相应的可执行程序下载地址，将其归档打包至用于Fuzzing的服务器上。目前，“腾讯CI”已将构建功能嵌入到自家git平台“工蜂”上，提供覆盖所有主流编译工具和语言，因此未来其在安全领域上的应用还有发挥的空间。
测试阶段：配置相应的测试命令，即harness程序的参数，以及运行环境，包括Windows、Linux、macOS，如果硬件资源丰富的话，Android和iOS又何尝不可。提交在服务器上布署好常见Fuzzer工具（afl/libfuzzer/honggfuzz等等），或者自主开发的其它Fuzzer，同时部署一些常见文件格式的样本库。对于特殊数据格式，比如自定义协议/文件格式，最好由开发或测试同学提供，否则只能安全测试人员去解决，一些提取样本数据的方法后面会介绍。
告警阶段：若发现崩溃，则作二次运行确认，确认二次崩溃则告警出来，可邮件、工单、微信等多种方式，将运行命令参数、崩溃场景的栈回溯、可利用性分析等基本信息同步出来。对于崩溃容忍度较低的产品，可设置“质量红线”，去重后的崩溃数量超过多少个禁止发布。开发修复漏洞后，继续从第一步的开发阶段开始继续循环下去，直至无新漏洞发现。

Fuzzing三要素

Github上已有很多知名Fuzzer被开源，圈内也有不少人借此挖到漏洞，直接基于现成工具，或者二次开发挖到的都有，也有人借鉴思路自主开发新的工具。对于一款新漏洞挖掘工具的发布，多数人可能会认为，开源作者应该是已经挖完漏洞了才公布的，应该已经挖不到0day了。但有时，你又会发现，老树开新花的事情还是很常见的。那么决定Fuzzer能否挖到漏洞的关键因素有哪些？根据个人经验，笔者觉得主要有三要素：目标、策略、样本。

目标：攻击面分析

对于企业内部产品的测试，直接找开发要设计文档，甚至源码，都可以帮我们快速分析出攻击面。面对黑盒测试时，尤其是主流软件/系统的Fuzzing测试时，能够让我们参考的主要还是其官方文档，比如MSDN、Apple开发文档、Acrobat Javascript API手册等等。当初winafl诞生时，从MSDN找API去Fuzzing的方式屡试不爽，运气好的，一个API拿10个CVE也不是没干过；Apple开发文档中的系统的各个模块介绍，github上的示例代码等等，无不成为寻找攻击面的最佳途径；还有Acrobat 一个JS API产生好几个漏洞的情况，也有人直接写脚本分析API手册，提取API模板作Fuzzing；其它系统平台上写爬虫提取系统函数原型模板，作驱动Fuzzing。

这些从官方手册，以及官方放置在Github的示例代码，无不成为最佳的目标攻击面分析途径。如果你搞过上面这些，应该明白我在说什么。

除了文档，一些业界公开的漏洞信息，比如Project Zero、ZDI、厂商的补丁公告等等都是挖洞方向标。在以上信息都缺失的情况，就只能人工逆向分析来寻找攻击面了。

比如2019年微软的一次补丁公告中，出现了很多Jet数据库引擎的远程代码执行漏洞：

于是从MSDN入手去寻找可能存在的攻击面，然后用手上的Fuzzer框架进行Fuzzing，几小时之后直接挖到一个品相极佳的漏洞，因为生成的poc直接控制了EIP：

策略：变异之法

常见的变异策略主要有以下几种：

基于暴力：随机数据替换、插入、删除、数值增减、边界值替换、拷贝覆盖等等，比如radamsa等；
基于模板：文件格式、协议格式、API原型模板、语法模板变异等等，比如peach、domato等；
基于代码覆盖引导：通过提高代码路径的反馈方式来优化样本，比如AFL、Libfuzzer等等；
基于语法树变异：通过AST语法树变异来Fuzzing语法解析引擎，比如Fuzzilli，该工具本身也实现基于模板和代码覆盖引导的功能。

除了以上常规的变异方法之外，有时需要针对当前的应急漏洞作新变异规则，或者适配特定的业务场景作定制化，这就要求我们的Fuzzer平台具备可扩展的变异策略插件开发，这种方式不仅可以社区化方式协同，企业内部也可以协同开发，类似oss-fuzz。

举个案例，2018年word公式编辑器开始流行起来，还被在野利用过。当时笔者就用python开发个针对OLE中“Equation Native” 的变异器，然后用riufuzz跑起来（riufuzz是笔者基于honggfuzz二次开发的fuzzer，2018及之前的新功能已在github上开源，之后开发就未开源了，大家可以自行发挥）：

有时在变异前、变异后可能有特列的处理机制需要处理，比如pdf js fuzz，输入pdf可能得提取js再作变异，这是变异前处理；再比如png图片变异，变异后会导致crc校验失效，需要作变异后修复。还有对于复合文档中的某特定格式的文件变异后，需要重组打包，比如变异docx中的图片、pdf中的字体图片等等，此过程注意后缀名的变更问题。

样本的收集与筛选

以前笔者都是手工去网上找样本去下载那种包含很多文件的压缩包，但这种方式太费劲了，用过想再更新又得再去找。后来就干脆用scrapy写个爬虫去搜索引擎搜索，像pdf、office文档、图片几乎都是爬不尽的，但它支持的文件格式比较有限。因此，我就改去Github爬虫，很多开发者在开发时，也需要一些测试样本来验证，因此项目内经常包含有各种文件格式的样本，但它的搜索结果只有100页，需要变换关键词（字典库、单词库、输入法词库等等）来搜索，但整体搜索到的数量还是没有Google等搜索引擎多，可以当作互补方案。

若是遇到如openssl这种特殊协议数据，以及其它非完整文件格式的自定义格式，一般就得通过源码加Log，或者Hook技术去dump出二进制流样本数据，以此作为输入样本。

当我们获取的样本过多时，就需要作筛选，以避免过多的无用测试。对于开源项目，用AFL的工具足矣，但闭源程序就需要自己实现，以下就是笔者基于pin开发的语料库蒸馏器，用C++和Python开发的，支持跨平台：

以macOS上的pdf样本筛选为例，整体效果还不错：

1
2
3

总体大小：16.17G => 563.8M
文件数量：10074 => 1105
运行时间：3 天22 小时

效果

基于上述方法论，笔者在近3年内，共获取国际四大厂商（Apple、Microsoft、Google、Adobe）70余次CVE漏洞致谢，其它一些厂商产品的漏洞暂且不计。

总结

本文主要介绍了协同Fuzzing的设计思路，将Fuzzing置入CI构建中的方法，并分享了决定Fuzzing效果的关键三要素：目标、策略、样本，对这些要素一一分析，并附相应的实战案例。未来，我们也会尝试多去实践和推广这种多工种协同Fuzzing的工作方式，并建设更加完善的平台管理控制系统，方便实现多人协同工作。

基于笔者水平有限，这套设计方案有些在企业内部实施的话，难免会有不足之处，欢迎业界同行斧正。

Frida框架在Fuzzing中的应用

2019-11-30T02:06:03.000Z

由于Frida（https://frida.re ）动态插桩框架的跨平台、简单易用，现在已经被广泛应用于安全领域。相比Xposed而言，虽不能更底层地去Hook系统进程，但它可以免启动，应对App的hook完全够用，更关键的是，它完全可以用JavaScript来写代码，免去编译的烦恼，调试也方便。

之前在工作中，也就用Frida去Hook Android与iOS应用来做安全测试，效果挺好的，开发起来也挺高效的。本文主要围绕Fuzzing领域，来分析和记录最近一些使用Frida的Fuzzer。

定制型Fuzzer

用Frida来Fuzzing APP的方法，首先推荐Project Zero大神写的Adventures in Video Conferencing系列博文，详细介绍了Hook WhatApps和iMessage的输入数据处理函数并进行Fuzzing的方法，同时也开源了Hook iMessage的工具：https://github.com/googleprojectzero/iOS-messaging-tools/tree/master/iMessage ，提供dump和发送消息的功能，自己在额外构造变异数据去Fuzzing。

这种方式特别适用于拥有私有的定制协议或数据格式的APP Fuzzing，只是需要花时间去逆向分析程序的输入数据解析流程，找到关键的处理函数。

通用型Fuzzer

最近又看到两款使用Frida的Fuzzer，出自同一人之手，用Python和JS写的，代码量不多：

frida-js-afl-instr（https://github.com/andreafioraldi/frida-js-afl-instr ）：打通AFL++与Frida实现内存Fuzzing的工具，仅限Linux平台
frida-qbdi-fuzzer（https://github.com/andreafioraldi/frida-qbdi-fuzzer ）：基于Frida与QBDI的Android Fuzzer，借鉴AFL的代码覆盖引导思路，实现Android平台下闭源程序的覆盖引导Fuzzing。

下面直接画时序图来看它的原理，就不贴源码分析了：

frida-js-afl-instr原理图

frida-qbdi-fuzzer原理图

总结

用Frida来实现闭源程序的代码覆盖引导，代码量很少，以Python和JS就可以快速开发起来，但涉及到python等进程的启动，肯定没有纯C/C++的代码运行速度快，但对于Fuzzing，一般还是够用的，还是值得学习和使用的。

Fuzzing平台建设的研究与设计

2019-11-18T10:01:55.000Z

Android应用逻辑漏洞半自动化挖掘思路

2019-11-02T01:22:25.000Z

大清早起来就看到F-Secure LABS团队（以前叫MWR，就是那支用13个逻辑漏洞攻击chrome的团队，是pwn2own专业户）发了一篇文章“Automating Pwn2Own with Jandroid” (https://labs.f-secure.com/blog/automating-pwn2own-with-jandroid/ )，讲述如何利用Jandroid实现Android应用逻辑漏洞的半自动化挖掘思路。

专注逻辑漏洞有一些好处，尤其是打比赛用途的，撞洞率较低，且利用稳定，一般都不用搞什么内存布局控制的，MWR尤其擅长此类漏洞的挖掘，之前就在pwn2own上攻击破过华为手机和chrome浏览器。

文中介绍了Jandroid (https://github.com/FSecureLABS/Jandroid )这款开源工具，要求python 3.4以上版本运行，支持apk/dex/system.img/ext4文件解析。

python3 src/jandroid.py -h                                            

----------------------------
           JANDROID
----------------------------

usage: jandroid.py [-h] [-f FOLDER] [-p [{android}]] [-e [{device,ext4,img}]]
                   [-g [{neo4j,visjs,both}]]

A tool for performing pattern matching against applications.

optional arguments:
  -h, --help            show this help message and exit
  -f FOLDER, --folder FOLDER
                        app分析目录，所以支持应用的批量分析
  -p [{android}], --platform [{android}]
                        支持的平台，目前仅支持android平台
  -e [{device,ext4,img}], --extract [{device,ext4,img}]
                        支持从连接设备、ext4、system.img中提取应用
  -g [{neo4j,visjs,both}], --graph [{neo4j,visjs,both}]
                        支持检测结果的图表显示

它通过定义json模板来标记污点传播路径，比如拥有android.intent.category.BROWSABLE浏览器打开权限的Activity，再查找Landroid/webkit/WebView;->addJavascriptInterface看是否存在JavaScript接口，以判断是否可能存在远程攻击的条件，但这种只能是半自动化辅助，还需要人工逆向确认。

模板示例：

{
    "METADATA": {
        "NAME": "JSbridgeBrowsable"
    },    
    "MANIFESTPARAMS": {
        "BASEPATH": "manifest->application->activity OR manifest->application->activity-alias",
        "SEARCHPATH": {
            "intent-filter": {
                "action": {
                    "LOOKFOR": {
                        "TAGVALUEMATCH": "<NAMESPACE>:name=android.intent.action.VIEW"
                    }
                },
                "category": {
                    "LOOKFOR": {
                        "TAGVALUEMATCH": "<NAMESPACE>:name=android.intent.category.BROWSABLE"
                    }
                },
                "data": {
                    "RETURN": ["<NAMESPACE>:host AS @host", "<NAMESPACE>:scheme AS @scheme"]
                }                
            }
        },
        "RETURN": ["<smali>:<NAMESPACE>:name AS @activity_name"]
    },
    "CODEPARAMS": {
        "SEARCH": {
            "SEARCHFORCALLTOMETHOD": {
                "METHOD": "Landroid/webkit/WebView;->addJavascriptInterface",
                "RETURN": "<class> AS @web_view"
            }
        },
        "TRACE": {
            "TRACEFROM": "<method>:@web_view[]->loadUrl(Ljava/lang/String;)V",
            "TRACETO": "<class>:@activity_name",
            "TRACELENGTHMAX": 10,
            "RETURN": "<tracepath> AS @tracepath_browsablejsbridge"
        }
    },
    "GRAPH": "@tracepath_browsablejsbridge WITH <method>:<desc>:<class> AS attribute=nodename"
}

各字段含义看示例就好了，这里不作详解。读者也可参考F-Secure发的文章，里面有详解。

总结起来，模板支持：

AndroidManifest.xml的匹配搜索
smali代码的匹配搜索
传播路径的图表显示，以及显示的文件格式定义
函数调用参数追踪
函数调用的起点与终点定义、追踪以及追踪深度

我直接找个apk分析运行，会出错提示以下错误：

Traceback (most recent call last):
  File "src/jandroid.py", line 408, in <module>
    inst_jandroid.fn_main()
  File "src/jandroid.py", line 227, in fn_main
    self.pull_source
  File "/Volumes/Macintosh/Users/riusksk/Android-Security/工具/Jandroid/src/plugins/android/main.py", line 51, in fn_start_plugin_analysis
    app_pull_src
  File "/Volumes/Macintosh/Users/riusksk/Android-Security/工具/Jandroid/src/plugins/android/requirements_checker.py", line 53, in fn_perform_initial_checks
    raise JandroidException(
NameError: name 'JandroidException' is not defined

直接在Jandroid/src/plugins/android/requirements_checker.py开头加以下代码即可解决：

1	from common import JandroidException

运行效果：

python3 src/jandroid.py -f ./apps -g visjs

----------------------------
           JANDROID
----------------------------

INFO     Creating template object.
INFO     1 potential template(s) found.
DEBUG    Parsing /Volumes/Macintosh/Users/riusksk/Android-Security/工具/Jandroid/templates/android/sample_basic_browsable_jsbridge.template
INFO     Initiating Android analysis.
INFO     Performing basic checks. Please wait.
INFO     Basic checks complete.
INFO     Beginning analysis...
DEBUG    1 app(s) to analyse, using 2 thread(s).
DEBUG    Created worker process 0
DEBUG    Created worker process 1
DEBUG    AnalyzeAPK
DEBUG    Analysing without session
INFO     Analysing ctrip.android.view_8.13.0_1248.apk in worker thread 0.
DEBUG    AXML contains a RESOURCE MAP
DEBUG    Start of Namespace mapping: prefix 47: 'android' --> uri 48: 'http://schemas.android.com/apk/res/android'
DEBUG    START_TAG: manifest (line=2)
DEBUG    found an attribute: {http://schemas.android.com/apk/res/android}versionCode='b'1248''
DEBUG    found an attribute: {http://schemas.android.com/apk/res/android}versionName='b'8.13.0''
DEBUG    found an attribute: 
......
DEBUG    Settings basic blocks childs
DEBUG    Creating exceptions
DEBUG    Parsing instructions
DEBUG    Parsing exceptions
DEBUG    Creating basic blocks in Landroid/support/constraint/solver/LinearSystem;->createRowDimensionPercent(Landroid/support/constraint/solver/LinearSystem; Landroid/support/constraint/solver/SolverVariable; Landroid/support/constraint/solver/SolverVariable; Landroid/support/constraint/solver/SolverVariable; F Z)Landroid/support/constraint/solver/ArrayRow; [access_flags=public static] @ 0x199210
......
DEBUG    Looking for subclasses of Lctrip/business/map/SimpleOverseaMapActivity;
DEBUG    ctrip.android.view_8.13.0_1248.apk took 349 seconds to analyse.
DEBUG    Finished analysing ctrip.android.view_8.13.0_1248.apk with output {'bug_obj': {'JSbridgeBrowsable': False}, 'graph_list': []}.
INFO     Finished analysing apps.
INFO     Creating custom graph.
INFO     Custom graph can be found at /Volumes/Macintosh/Users/riusksk/Android-Security/工具/Jandroid/output/graph/jandroid.html
INFO     All done.

输出结果会在上面jandroid.html中显示，但由于我这里没有检测到满足JSbridgeBrowsable条件的代码，因此html里面的图是空的。如果有满足条件的代码，会得到类似如下的图：

Jandroid还提供有GUI操作界面，包括模板创建功能，所以使用也很方便，运行以下命令即可打开：

1	python3 gui/jandroid_gui.py

比如追踪DexClassLoader.loadClass加载外部dex文件的情况：

再举个实例，下图是MWR当初分析三星时，一个Unzip目录穿越漏洞的函数传播路径图，漏洞被用于Mobile Pwn2Own 2017：

所以，Jandroid还是非常适合用来挖掘逻辑漏洞的辅助工具，核心思想依然是污点追踪的思路，操作简单，可视化效果也很好。基于模板的定制化，增加了其运用的灵活性，尤其对于复杂的业务逻辑设计，很适合作定制化地批量检测，但依然需要人工分析确认，并非完全自动化的。

漫谈网络安全应急要略

2019-09-07T02:04:32.000Z

【注】：本文仅代表个人观点，与公司立场无关。

早上看到朋友圈有人说Metasploit公布BlueKeep远程执行漏洞的利用，一些安全群里也有人喊着加班了，但这漏洞明明很早就已经发布补丁了，现在才加班应急明显是有问题的。因此才有了本文，谈谈关于安全应急的一些个人想法。

要略一：急则治其标，缓则治其本

在韩剧《幽灵》中，男主角在入侵犯罪者的电脑后，发现他正在上传受害者视频，在电脑里他看到一份名为申孝静的文件，里面全是照片，男主在照片里看到那个戴金表的男人，还没看清扫描出他的脸，幽灵就把网线拔掉了。

假如服务器因漏洞被入侵，是先修漏洞还是先上面韩剧那样拔网线呢？

估计你想拔网线都拔不到，可以先关闭外网止损。虽然这里本因是漏洞导致的，如果入侵后还在线上补漏洞，估计等你补完，裤子都被脱光了。

这里”标”是数据泄露，”本”是漏洞，紧急情况下，先治标，及时止损，防止数据泄露；缓解之后，再治本，修补漏洞，也包括安全系统监控与拦截机制被绕过的问题。

如果今天还在应急BlueKeep漏洞，说明补丁日的时候没有及时打补丁，才导致今天的局面。

毕竟，你总不能老是靠拔网线来解决问题吧！

要略二：数据安全高于一切

日剧《医龙》中，跟随男主的一位护士突发气胸，情况危急，如果叫救护车可能来不及，于是男主直接拿根笔管折断，插入患者的两侧胸腔放气，以降低胸腔压力。正常人的胸腔是负压，当气体进入后会压缩肺脏，导致呼吸困难，片中的场景应该是张力性气胸，即胸腔压力大于外部气压时，才插入胸腔放气。但是，如此风骚的非常规手段，未消毒，还产生新创伤的治疗手段，明显是不符合医疗操作流程的，但若不这样做，又可能没命。所以，危急情况下，总有一点最高优先级的标准，那就是：生命高于一切！

在各公司里面，都有自己要求的产品发布流程，从需求、开发、测试、发布都有一系列的流程要走，这也是对产品质量的保证。但是，若被外部发现严重漏洞，想发布补丁也这样走一遍，中间还涉及各种审批，搞完都得好多天了，到时候，裤子又要被脱光了！那到底是遵守，还是不遵守。

这就要求同样要有一条最高优先级的标准，那就是：数据安全高于一切！

数据包括公司保密信息、用户数据等等不宜公开的数据，如果在危害数据安全的情况下，就不该过于拘泥于繁文缛节，应有相应的应急通道去完成快速发布安全补丁的途径。

要略三：举一反三，触类旁通

每起安全应急事件背后，都有其导致事件的问题存在，很多时候它又代表着一类问题，而非单一案例作单一处理，最好能保证一个案例，引出一类问题并解决掉。

比如由于SQL注入导致的拖库事件，并非止损修漏洞就完事了，其背后的扫描器为何漏扫，WAF为何被绕过，或者漏洞代码为何回滚（上个月苹果就因此导致iOS 12.4被拿旧洞越狱）。解决背后引发漏洞的各类问题，是不是就能够拿扫描器发现更多业务的同类漏洞，WAF是不是能够帮各多业务防御漏洞，代码发布流程的完善是否可以避免代码回滚导致的漏洞……

要略四：广开言路，以德服人

在电影《巴斯特·斯克鲁格斯的歌谣》中，巴斯特·斯克鲁格斯是个牛仔，穿戴着闪闪发光的马刺和崭新的白色马裤，喜欢唱歌，还有无人能敌的好枪法，他自诩是全西部决斗掏枪最快的枪手，还把这编成了歌谣，天天弹着吉他唱在口头，他以一种无敌的姿态一路杀一路唱一路跳。

但最终他遇上了旗鼓相当的对手，被人以自己惯用规则和套路一枪爆头。

这个故事告诉我们，装逼一时爽，过头火葬场。

同样地，再牛逼的安全系统也可能被绕过，再安全的网站也可能被入侵，没有绝对安全的地方。

现在流行建设SRC与众测，也是为了与自身安全团队的能力作互补，广开言路，博采众长，改善自身安全系统，解决自己未能发现的问题。

为何提到以德服人，一方面是指善待白帽子，保持有效沟通，另一方面是指避免”文人相轻”的现象。谁都年轻过，搞技术的人有时多少有点傲气，报洞的BS收洞的，甚至报洞者之间互相BS。如果企业也带着相同的情绪，难免会导致与白帽子之间沟通矛盾，所以说善待白帽子，以德服人，哪怕白帽子少凌晨两三点搞事，也是好的。

这些年，微软对漏洞的处理的态度变化最大，从最初放言绝不为漏洞买卖，散漫地漏洞处理态度，到现在及时响应，建立完善的漏洞奖励计划，奖金力度也在不断提高，同时每年在BlackHat上公布TOP 100最具价值的安全研究员名单，赋予帽子荣誉感。

这些都代表着行业对漏洞，对白帽子的态度的一路转变历程。

要略五：未雨绸缪，防范未然

现在行业都在推广DevSecOps，是由Gartner 在2012年的一份报告中提出的概念。在这份报告中，Gartner提出信息安全专业人士需要更主动的融入DevOps的实践中，秉承DevOps的精神，拥抱团队协作、敏捷和职责共担的哲学。说得直白点就是，将安全融入到研发、运营等各个流程中，以实现安全自动化，连续响应和检测机制，帮助各团队之间协同合作。

在应急事件中至少覆盖到：

事前防范：包括漏洞扫描、代码审计、渗透测试、威胁情报、数据保护等等；
事中拦截：包括WAF、EDR、RAPS、IDS、杀软等等；
事后追溯：包括日志记录、取证系统等等。

要略六：犯罪者，虽远必诛

早作最坏的打算，因为白帽子也有”黑化”的可能。之前微软得罪过多少个白帽子了，就曾有白帽子在一气之下，每隔一段时间就爆0day出来。虽然其中微软也有责任，但白帽子这种行为总是不对的。

特别鄙视那些借测试之名，行不轨不事的人，搞了破坏还要钱，这就是不厚道，耗人品的耻事。

即使是现在的SRC与众测，虽说是奖励机制，但本质上依然是种利益交换行为，有利益就可能产生冲突。所以，需要时刻为这种冲突准备着。

坚持”不搞事，不怕事”的态度，贯彻”决不放弃使用武力”的作战方针，保留犯罪证据，在必要的时候，坚决拿起法律武器捍卫自身权益。

一句话：犯罪者，虽远必诛！

安全研究的价值思考

2019-08-18T05:27:14.000Z

【注】：纯属个人言论，与公司立场无关！

最近的Black Hat大会议题ppt已提供下载，里面有两个非技术议题，其视角比较有趣，一些问题值得思考，因此才有本文。

这两个议题分别是”Project Zero File Years Of Make 0day Hard”和”Selling 0-days to governments and offensive security companies”，一个讲述5年来Google的Project Zero团队在漏洞研究上的工作效果，一个讲述关于漏洞交易的一些现状、流程。

安全研究都干啥

安全研究并不局限于漏洞领域，但它依然是目前最主流的方向，研究范围也可以包括网络安全、反病毒、大数据安全、业务安全等诸多安全领域。这里主要聊下漏洞领域的研究，看看Project Zero的人主要都在干啥：

总结一下就是（主要指漏洞研究领域，估计很多人只干1、3、4的工作）：

漏洞挖掘与利用
方法论建设
技术写作
行业交流与合作
软件工程化建设，可能是指DevSecOps，包括安全防御策略建设、libfuzzer自动化测试等的应用

###从招聘职责看研究目的

谈研究价值，不妨先来谈谈研究的目的，我特意从各招聘网站上搜集了一些关于安全研究岗位的招聘信息，主要统计其岗位职责描述的关键词，生成如下词云：

可以看到，当前的研究岗位普遍就是招漏洞挖掘职位的，都是搞主流系统及软件为主，但挖洞的目的又是为什么呢，这种在很少企业会写在招聘帖的。从统计结果看，主要有以下3个研究目的：

挖掘主流系统/软件漏洞；
帮助安全产品提升检测能力；
为业务提供技术支持。

第一点是手段，等于啥也没说，第2点算是做安全产品，第3点是得看是什么业务，如第2点也算业务，但如果是一些非安全产品业务，其实所能提供的技术支持就相对比较局限，可能人家业务也不一定看得上你这研究。

影响力价值

搞安全研究，普遍都是为了影响力公关（PR），国内外均是如此，BlackHat上的Pwnie Awards都有一个“最名不副实漏洞奖”，叫做”most over-hyped bug”，就是用来批评那些过度炒作的漏洞。但是一些确实危害比较大的漏洞，及时负责任地披露反而有利于防御工作的开展。Project Zero议题中讲到一句话，开放的攻击研究相对攻击者而言，对防御者更为有利。之前国内试颁行的某提案，因可能阻碍安全研究者公开研究成果，遭到不少圈内人的反对。这跟古时候，有的国家禁止人民用刀一样，最终只是阻碍生产力的发展而已。其实只要不是急功近利，获得与研究成果相匹配的影响力也是合理的。那获得影响力之后的价值呢？对团队，对个人，可能获取得更多交流与学习的机会，也可能获得更多业务合作机会，直接点，可能找份工作防止中年危机都更有资本了。

商业价值

何为商业价值？就是赚钱嘛！通过安全研究落地为产品，然后拿去卖；也可提供技术服务，比如帮助对IoT、车联网产品等新兴行业产品进行安全测试。产品一般比技术服务更值钱，技术服务经常是一波过，产品却是可以长期收费的，比如IDA一年卖几万刀，用户每年都得交钱，而若只是提供逆向服务，费劲且不持久，赚得还少。如果是漏洞交易，高质量的漏洞利用链也是可以获得不菲的利益。在0day漏洞交易感兴趣的，主要涉及以下3类角色：

防御型企业、漏洞奖励计划和平台
黑客比赛举办者，类似漏洞收购中间商，自己可能也会去挖洞，也可能收购poc来自己写exploit，或者直接收购exploit，再转手卖出去赚差价
攻击型企业、政府、黑产团伙

现在国内已经限制参加Pwn2Own之类的国外比赛，从2018年开始，国内由”天府杯”比赛代替，主要是防止漏洞外流危害国家网络安全。这些比赛也推动了厂商对漏洞处理的态度，以及漏洞奖励计划的建设，使得报告者能够合法地获得相应的奖励和认可。

新型业务安全预防

提前研究一些公司业务可能涉足的新领域，避免新兴业务产品出来后，无能力解决上面的安全问题。但整个的前提是，该新产品能活下来，否则一切都是白搭。

行业贡献

在安全行业贡献榜上，Project Zero无疑是佼佼者。在5年内，他们共贡献1500+个主流系统/软件漏洞，推动很多安全防御机制的诞生，甚至影响漏洞在市场上的价格。漏洞研究者有时担心手上的漏洞被撞掉，会直接报给厂商，混个致谢，搞不好年底还能混个”MSRC Top 100”，今年开始它改名叫”最具价值安全研究员”，更高大上了。这个月，我就被Project Zero的人撞掉了一个微软漏洞。在PZ分享的议题里面，提出一些衡量”make 0day hard”的标准，但毕竟是相对概念，仅当作参考：

挖到品相优秀的漏洞所花费的时间；
漏洞平均生存时间；
撞洞数量；
漏洞利用链的长度；
新型高质量的攻击面的发现概率。

个人保值防老

研究本身就是一种学习方式。相信爱学习的人，最终运气都不会太差。尤其是现在鼓吹35岁中年危机的互联网时代，保持学习是最靠谱的个人保值防老方式。如果保持工作内容不变，那么通常头一年所积累的技术与工作方法足够应付绝大部分工作。若再不搞点有挑战的新工作内容，或者业余做点研究，那就要成为拿着一套技术吃N年的”老白兔”了。持续学习，保持或者超越与年龄相符的技术能力才是王道。

一些值得学习的Fuzzer开源项目

2019-07-14T02:42:40.000Z

之前GitHub上有人整理过一个叫Awesome-Fuzzing的资料，整理了关于Fuzzing技术的电子书、视频、工具、教程以及用于练习的漏洞程序。整体上不错，但工具上还是不够全，有些不错且希望阅读代码学习的工具，发现未在其中，因此重新整理出下面这一份资源，其中有些还曾二次开发过，有些是还未来得及学习的，写出来权且当作学习计划。

AFL——支持源码插桩的代码覆盖引导的Fuzzer，绝对是fuzzer领域的一大里程碑，虽然它也支持基于QEMU的闭源程序，但效果不好，且容易出错，由它衍生出来非常多afl分支版本，借助它已经被挖出非常多的漏洞，但它的变异策略其实有待提高。

http://lcamtuf.coredump.cx/afl/
WinAFL——windows版本的afl，使用DynamoRIO去插桩闭源程序以获取代码覆盖率信息，同时支持硬件PT获取覆盖率信息，但PT获取覆盖率其实并没有插桩获取得全，但速度可能会快一些。

https://github.com/googleprojectzero/winafl
AFLFast——加速版的AFL，Fuzzing速度确实会比原版快一些。

https://github.com/mboehme/aflfast
Vuzzer——支持闭源程序的覆盖引导Fuzzer，使用LibDFT的pin工具实现数据流追踪，结合动静态分析，以获取更多的代码路径，比如比较语句中的比较值，它会先作记录，再未来变异时使用。

https://github.com/vusec/vuzzer
PTfuzzer——Linux平台下的采用 Interl PT硬件支持的覆盖引导Fuzzer，所以它支持闭源程序。

https://github.com/hunter-ht-2018/ptfuzzer
afl-unicorn——采用Unicorn模拟指令的AFL，支持Linux闭源程序

https://github.com/tigerpuma/Afl_unicorn
pe-afl——通过静态插桩实现针对Windows闭源程序的覆盖引导的AFL Fuzzer，支持用户层应用和内核驱动

https://github.com/wmliang/pe-afl
kAFL——支持QEMU虚拟机下的系统内核Fuzzing的AFL，适用于Linux、macOS与Windows

https://github.com/RUB-SysSec/kAFL/
TriforceAFL——基于QEMU全系统模拟的AFL，借助系统仿真器实现分支信息跟踪，支持Linux内核Fuzzing

https://github.com/nccgroup/TriforceAFL
ClusterFuzzer——Google开源的可扩展的Fuzzing基础设施

https://github.com/google/clusterfuzz
LibFuzzer——进程内覆盖率引导的开源的fuzz引擎库，属于llvm的一部分，在各大主流开源库中，以及Google内部最经常用的安全测试工具

https://llvm.org/docs/LibFuzzer.html
OSS-Fuzz——基于LibFuzzer的开源软件Fuzzer集合，实现docker下自动下载、编译安装及运行

https://github.com/google/oss-fuzz
honggfuzz——Google开发的基于软硬件的覆盖驱动型Fuzzer，单纯暴力Fuzz的效果也挺好的，支持多平台，包括Linux\macOS\Windows\Android

https://github.com/google/honggfuzz
KernelFuzzer——跨平台内核Fuzzer框架，不开源策略，只在其paper中提及变异策略，需要自己实现，支持Windows、OSX和QNX系统，但只提供Windows编译脚本

https://github.com/mwrlabs/KernelFuzzer
OSXFuzzer——基于Kernel Fuzzer的macOS内核Fuzzer

https://github.com/mwrlabs/OSXFuzz.git
PassiveFuzzFrameworkOSX——通过Hook实现被动式的OSX内核Fuzzer

https://github.com/SilverMoonSecurity/PassiveFuzzFrameworkOSX
Bochspwn——基于Boch插桩API实现Double Fetches内核漏洞的检测

https://github.com/googleprojectzero/bochspwn
Bochspwn-reloaded——基于Boch插桩API实现内核信息泄露的检测

https://github.com/googleprojectzero/bochspwn-reloaded
syzkaller——基于覆盖率引导的Linux内核Fuzzer，需要基于其模板语法实现API调用模板，提供给syzkaller进行数据变异，也曾被移植到其它平台

https://github.com/google/syzkaller
dharma——基于语法模板生成的Fuzzer，由Mozilla开源的用于Fuzz Firefox JS引擎

https://github.com/MozillaSecurity/dharma
domator——Project Zero团队开源的DOM Fuzzer，用python实现基于模板生成的Fuzzer

https://github.com/googleprojectzero/domato
Fuzzilli——基于语法变异的JavaScript引擎Fuzzer，先通过语法模板生成测试用例，再生成中间语法进行变异，结合覆盖率引导以触发更多代码路径

https://github.com/googleprojectzero/fuzzilli
Razzer——内核竞争条件漏洞Fuzzer

https://github.com/compsec-snu/razzer
ViridianFuzzer——用于Fuzzing Hyper-V hypercalls的内核驱动，由MWRLabs公司出品

https://github.com/mwrlabs/ViridianFuzzer
ChromeFuzzer——基于grinder语法生成器改装的Chrome浏览器Fuzzer

https://github.com/demi6od/ChromeFuzzer
funfuzz——Mozilla开源的JS fuzzer工具集合，主要用于Fuzz SpiderMonkey

https://github.com/MozillaSecurity/funfuzz

Infiltrate2019议题学习

2019-06-29T02:26:18.000Z

Infiltrate2019安全大会是在5月初举办的，会议资料收集后放在电脑上1个多月了，连续几个周末都有事，一直没来得及学习，今天刚好学习下，有些议题其实跟MOSEC上有重复。

重点聊几个个人感兴趣的议题，并最后附上10个议题ppt资料下载。

2PAC 2Furious Envisioning an iOS

科恩出品，分两部分：PAC绕过与基带研究，刚好在MOSEC上project zero的人讲了5种PAC绕过方法，议题名叫”A study in PAC”，涵盖了其中的方法，而基带研究部分也作为独立议题在MOSEC上分享过，介绍基带攻击方法、逆向分析固件的方法。

之前在MOSEC上，我对5种PAC绕过方法作了学习笔记，直接上图：

EL3 Tour - Get The Ultimate Privilege of Android Phone

盘古出品，拿华为P20开刀，应该是手工逆向分析TEE相关代码，挖到一个代码执行漏洞攻击EL3的过程。

通过VBAR_EL+0x400的异常处理例程来定位SMC处理例程：

漏洞代码：

对方的漏洞利用思路：

通过漏洞实现任意内存读写
布署 Shellcode 于地址 0x209F8000（EL1下可访问，属于共享内存）
篡改 Page Descriptior : 0x209F8627 => 0x209F8783（可执行）
TLBI ALLEL3：清除TLB缓存，保持数据一致，使页表修改可被CPU感知到
调用 0x209F8000，触发shellcode执行

最后演示如何利用该漏洞绕过华为手机的人脸验证，包括篡改人脸匹配分值、活体检测结果。

Adventures in Video Conferencing

Project Zero以前在其博客上分享过，看博文会更清晰一些，详见：

Adventures in Video Conferencing Part 1: The Wild World of WebRTC

Adventures in Video Conferencing Part 2: Fun with FaceTime

Adventures in Video Conferencing Part 3: The Even Wilder World of WhatsApp

Adventures in Video Conferencing Part 4: What Didn’t Work Out with WhatsApp

Adventures in Video Conferencing Part 5: Where Do We Go from Here?

Natalie Silvanovich 作为PZ的头牌女黑客，在此议题的厉害之处就是用了几行fuzz代码挖了包括浏览器、FaceTime、WhatsApp在内的主流应用10多个CVE远程漏洞。就是下面这段代码：

通过分析视频交互过程，找到外部数据传递的关键点，开源的改代码插入fuzz，闭源的写Hook去实现fuzz，相关的工具也已在GitHub上开源：https://github.com/googleprojectzero/Street-Party。之前看到国内也有人顺势搞到几个FaceTime的漏洞。

TEE Exploitation: Exploiting Trusted Apps on Samsung’s TEE

Blue Frost Security出品，举了几个三星漏洞的例子：

TA的栈溢出案例：由于只有NX(没有栈保护和ASLR)，所以直接上ROP搞定的
共享内存Double Fectch漏洞：TA在验证和使用命令数据的时间窗口内，可能被篡改数据，实现任意读写

由于缺乏一些常见的内存保护机制（仅有NX），在TA利用上反而更加容易。TA攻破后，对于厂商最大的影响可能是DRM版权与支付密钥等问题；而对于用户而言，主要是用户数据的窃取问题。

资料打包下载

下载链接：https://github.com/riusksk/SecConArchive/tree/master/Infiltrate2019

2019年哪些安全大会的议题值得学习

2019-05-11T02:19:22.000Z

“2019年哪些安全大会值得参加？”或者这更符合多数人心中的标题，但为何不这么写呢？

因为有些拥有好议题的大会一般都会公开PPT，尤其是国外会议，来回参会成本比较高，如果有现成的PPT供学习，自然不用每次都参加。当然，也有因作者拒绝公开的议题，这种只能现场听了。

评价安全大会的好坏，是多方面的，绝不是单纯的议题质量这一维度。但这里我主要想从技术者的角度来看评价，所以后面你发现很多知名大会未在此列，请不要惊讶。

即使是同一举办方，也无法保证每年的议题质量呈上升状态，有些会议也开始没落了，所以这里以2019年为时间点来点评。

下面来聊聊2019年哪些安全大会的议题值得学习，有些已经举办过，有些尚未开始。

那些未提及的知名大会

1、Defcon

很多时候，Defcon议题都是BlackHat挑剩的，有的人也会直接议题双投。上面的议题质量更是参差不齐，相对BlackHat要求更低，更开放。我很少看Defcon议题，偶而网上有人发才看。

2、RSA

RSA是一个充满商业气息的大会，如果你看过官网的PPT，就会发现里面充满诸多广告，有的议题可能就几页图片，所以从技术角度来看，是没有多少学习的价值。

但是，RSA有时也反应出的安全的风向标，虽有炒作的成分，但显然PR得甚是成功。比如当年的APT、数据可视化、威胁情报等等

RSA的创新沙盒是一项不错的活动，很多创业公司把他们研发的新产品拿出来比赛，从中可以反映出一些行业发展的方向。

所以，RSA比较适合管理者、创业者以及产品运营者。

3、XCon

以前国内安全会议很少，基本唯XCon为首。以前参加都是为了跟圈内朋友相聚聊天，有时场外比场内还热闹。

但这几年开始，XCon逐渐没落了。如果你参加过XCon2018，相信会有很大的体会，会场已经没几个人，有时在场人数可能达到个位数，找个同行聊天都难，且门票还是国内同类会议最贵的。

4、KCon

KCon应该算是国内比较有自己特色的会议，2018年的议题质量也还可以，中场休息的摇滚音乐很赞，场地与音效很好。

之前几届的议题质量忽上忽下，2019年的议题还没出来，大家可以关注下先。

若是在2018年，我还是会给个推荐的。

5、BlueHat

以前微软的闭门邀请制会议，从今年开始在上海举办国内版，议题列表已经放出，感觉质量一般。但跟MOSEC时间联着，可以考虑一并参加下。

6、RECON

因为多数议题自己不感兴趣，它比较偏向于逆向工程，以及系统底层、硬件、固件等方向，对此方向感兴趣的话，依然可以看看。

7、Syscan/Syscan360

官网已经打不开了，聊啥……

后话

评价一个会议的好坏真是很容易，但要举办一个好的会议却是不容易，影响的因素特别多，且非一人之力可以搞定。

无论最终质量如何，对于为行业提供沟通交流平台的一些会议，还是值得点赞的。

读《一本小小的蓝色逻辑书》：识别常见的逻辑漏洞

2019-05-03T01:46:24.000Z

最近读了一本书叫《一本小小的蓝色逻辑书》，算是逻辑推理入门书籍，觉得不错，推荐给大家。

这本书在微信读书上可以找到，大概需要4个多小时的阅读时间。

什么是逻辑推理

在生活、学习与工作中，我们总是要运用到逻辑推理能力，甚至我们自己也经常挂在嘴边，但若问什么是逻辑推理呢，估计没多少人能说清。

所谓”逻辑推理”，在广义上被定义为”我们评估信息的过程”。要想做出正确的决定，我们首先要占有充分的信息，而要想占有充分的信息，就必须提出正确的问题。所以那些擅长逻辑推理的人，往往也比较善于提出问题，搜集相关信息，用”正确的”方式对这些信息进行评估。最重要提，他们可以在不受他人干扰的情况下独立完成这一过程。

在我记忆中，整个学生时代，几乎没有过这门课程，大部分的逻辑推理能力都是基于以往的中学数学课程训练，比如真假命题、逆命题、证明题等等，本书中也有讲到这些。

也许我们的日常数学真的只需要加减乘除的运算，但以前的数学课程培养出来的逻辑思维，却可以运用一生。

推翻前提找答案

这里说的”推翻前提找答案”，其实是想说”水平思考法“，一种摆脱前提设想而进行创意思考的方式，不走寻常路，换个角度看待问题，而不是接受他人提出的前提条件。我们多数人一般都是使用“垂直思考法”，却沿着原定的逻辑路线思考下去，就是我们俗语常说的“直脑筋”，多少略带有点贬义。

下面是两种思考方法的对比表：

可能还是太抽象了，因此作者讲了一个故事：

许多年前，一个倒霉的商人欠了别人一大笔钱。由于没钱还债，商人很可能会被债主投进大牢。

债主是个脾气又坏又丑的糟老头，但他却看上了商人年轻貌美的女儿。于是他告诉商人：”我有个办法，不仅可以把你的债务一笔勾销，还能让你的女儿免于因为你入狱而流落街头。”

具体办法是：债主把一黑一白的小石头放进空袋子，让商人女儿摸一块。如果摸到白石头，则她父亲的债一笔勾销，她也无须嫁给债主；如果摸到的是黑石头，债务仍然可以一笔勾销，但她必须嫁给债主。如果她不答应这个游戏，那么她父亲会被立刻投进监狱。

商人父女别无选择，只好答应。

于是三人来到债主花园内铺满鹅卵石的小路上，债主俯身捡两块黑石头扔进袋子里，他自以为神不知鬼不觉，却不知这一切都被商人女儿看在眼里。

如果是个”直脑筋”的人，可能就想到下面两种做法：

当场揭穿糟老头的阴谋，然后商人进监狱；
女儿认命，抽到黑石头，嫁给糟老头，债务一笔勾销。

最后的结局是这样：

商人的女儿摸出一块石头，但故意把它掉到地上，跟一堆鹅卵石混到一起。然后一边假装寻找石头，一边若有所思地说道，”但没关系，只要看看袋子里的那块石头是什么颜色，就可以判断我刚才摸出的那块石头是什么颜色了。”

债主一时愣住了，不知道该说什么，只好让那个女孩拿出袋子里的石头，结果可想而知。

这就是水平思考法，我们可以回顾下这个故事，若要想免债的话，其中的”前提条件”是：

前提条件：从袋子中摸出白石头。

现在通过改变该前提条件来思考，比如这样：

从袋子中摸出黑石头：现场改变规则，摸出黑石头可免债。
摸出石头后，根据剩下的石头颜色来判断是否摸到的是白石头，正如故事中所做的。

日常生活中，阻碍我们进行创意思考的是，不假思索的程序性反应，就是不费脑子的事情，比如商店购物、开车等等，但有时遇到一些新情况，这些程序性反应就不灵了，这时就需要启动非程序性反应。

书中还给了一道训练”水平思考法”的题目，大家可以先试着做下，一开始我也没做出来（答案见文末附录）：

用最多4条直线(笔尖不离纸)把下面的9个点连接起来。

还有另一道题，是当年面试微信支付时被问到的类似题目，但微信的更难一点（拿3个桶倒出想要的重量），答案亦见文末附录：

马戏团老板派小丑去附近河边打水给大象喝。因为想在里面加入一种特殊健康浓缩剂。所以需要整整7加仑水，不能多，也不能少。他给了小丑两个水桶，一个5加仑，一个3加仑，让小丑去打整整7加仑水。请问小丑该怎么办？

效用概率做决策

如果大家经常逛知乎的话，会发现很多人在问：

做安全需不需要考研？

选择什么样的学校和专业好就业？

选择什么样的职业更适合自己？

其它…….

相信很多人做决策的时候，多会先分析出各项选择的优缺点再打分对比，选择出最佳方案，这叫利弊分析法。

有时，我们又会先列出在意的点，根据重要程度作个加权值，然后给个选择打分，根据分数高低来排序选择，这叫加权排序法。

还有决策法、矩阵分析法、概率树等等多种决策分析方法，在我们在决策时，能够给我们提供很大的帮助。

不过我在这里，重点是想介绍下效用分析法，即分析某个结果对我们的价值，通常跟概率一块使用。

打个比方，一名大四学生在规划自己的人生。摆在他面前的有三种选择：

成为旅行作家；
加入外交部；
成为公司销售人员。

这里肯定不能只从金钱回报来考虑这个问题，因为这名学生真正看重的并不是赚多少钱，而是自己从事这份工作时的内心感受。

若是以前，我可能会列出收入、职业前景、兴趣、工作环境等多个维度来考虑。但是某些场景下，我们常常忽略实现这一结果的概率，比如我想当皇帝，这种不是靠努力就能实现的。

因此这里最好的办法就是去计算每份职业的期望值（Expected Value, 简称EV）。EV计算公式：

EV = 效用(某种结果带给我们的心理满足度) x 出现这种结果的概率

根据上述公式，我们得到：

这里每种结果存在实现概率，是因为该结果要求一定的技能，而这名学生此时并不完全具备这些技能。

根据上面的分析，该学生选择加入外部部的期望值最高，所以理性地说，他应该选择这份工作。

五大常见推理漏洞

通常说的推理漏洞，大多是指那些跟我们所做假设相关的漏洞。书中列举出五大常见推理漏洞：

比较和类比假设漏洞：偷换概念

把两个虽然不同，但逻辑上却相等的事物进行对比。

比如拿橘子和苹果作比较。再比如说，医学院校经常拿小白鼠做实验，然后把在动物身上得到的实验结果当作参考，但是若因小白鼠身上实验某种药物时发生某种并发症，就认为人类在使用这种药物时也会出现同样的并发症，就是错误的。

代表性假设漏洞：以偏概全

不能拿特殊案例来代表整体，统计的样本要足够多才行，否则它就会弱化我们的论断。

比如《思考，快与慢》中曾举过一个例子：

最近，某大医院出生婴儿1000人，某小医院出生婴儿50人，问哪家医院生男婴的比例大于60%的可能性较大？

我们都知道生男生女的概率分别是50%，统计样本越多就越会接进这个数值，但如果你若去小医院，它的波动概率就很大，可能生男80%，也可以40%，所以小医院生男婴的比例就越有可能大于60%。

“好证据”假设漏洞：对相关证据视而不见

当我们不经验证就想当然地认为自己的证据有效时，就很容易犯此错误。那些比较客观、相关、精确、真实的证据有利于强化我们的论述；而主观、不具代表性、不精确的论据则只会弱化我们的论述。

比如，一个不愿意戒烟的人总是会看到吸烟有利的一面，而对那些支持戒烟的事实会视而不见。

因果假设漏洞：混淆因果关系

当我们错误地做出因果假设，或者在没有证据的情况下就认定一件事会导致另外一件事时，就会犯这种错误。

比如，每个活过百岁的人都喝过白开水，所以就认定经常喝白开水就能长命百岁，这显然是错误，它们不存在直接的因果关系。很多学术界的社会/生物健康调查相关的报导就经常出现这种错误。

实施假设漏洞：在执行计划时没有提前考虑可能出现的瓶颈

当我们没有预料到计划实施过程可能出一的瓶颈，或者盲目地相信自己的计划会轻而易举地得到落实时，我们就会犯这种错误。

比如，几年前，西方某旅行杂志曾登过一篇文章说：”因为如今搭乘飞机很方便，而且人们手头余钱也越来越多，所以很快大家都会去非洲看狮子了。”

这显然就是错误的，去不去非洲看狮子，并非单纯考虑金钱和交通就行，比如先问问你有没有年假再说吧！

识别常见的逻辑漏洞

根据书中列举的常见逻辑漏洞，我画了张思维导图：

附录

1、9点连线的答案：多数人会受限于前提条件：只能在9个点内形成的长方形之内画线，如果能够摆脱该前提条件，那么答案就会有很多种：

2、水桶题目的答案：先倒满5加仑的水桶，再把它倒进3加仑水桶，把3加仑水桶里的水倒掉，把5加仑水桶里剩下的2加仑水倒进3加仑水桶里，重新装满5加仑水桶（5加仑 + 2加仑 = 7加仓）。