Frida框架在Fuzzing中的应用

由于Fridahttps://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,出自同一人之手,用PythonJS写的,代码量不多:

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

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

####frida-js-afl-instr原理图

image-20191130121915743

frida-qbdi-fuzzer原理图

image-20191130122032208

总结

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

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

大清早起来就看到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文件解析。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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接口,以判断是否可能存在远程攻击的条件,但这种只能是半自动化辅助,还需要人工逆向确认。

模板示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
{
"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发的文章,里面有详解。

总结起来,模板支持:

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

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

1
2
3
4
5
6
7
8
9
10
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

运行效果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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里面的图是空的。如果有满足条件的代码,会得到类似如下的图:

visjs3

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

1
python3 gui/jandroid_gui.py

image-20191102103606311

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

image-20191102104919972

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

image-20191102104533888

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

漫谈网络安全应急要略

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

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

要略一:急则治其标,缓则治其本

Sep-07-2019 12-20-44

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

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

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

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

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

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

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

Sep-07-2019 12-16-48

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

Sep-07-2019 12-17-55

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

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

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

要略三:举一反三,触类旁通

timg

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

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

要略四:广开言路,以德服人

Sep-07-2019 17-33-27

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

Sep-07-2019 17-32-53

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

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

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

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

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

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

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

要略五:未雨绸缪,防范未然

timg2

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

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

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

要略六:犯罪者,虽远必诛

QQ20190907-194700

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

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

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

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

一句话:犯罪者,虽远必诛!

vulwar

安全研究的价值思考

【注】:纯属个人言论,与公司立场无关!

最近的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的人主要都在干啥:

image-20190818142847773

总结一下就是(主要指漏洞研究领域,估计很多人只干1、3、4的工作):

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

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

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

职责

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

  1. 挖掘主流系统/软件漏洞;

  2. 帮助安全产品提升检测能力;

  3. 为业务提供技术支持。

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

影响力价值

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

商业价值

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

image-20190818144822263

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

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

新型业务安全预防

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

行业贡献

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

  1. 挖到品相优秀的漏洞所花费的时间;

  2. 漏洞平均生存时间;

  3. 撞洞数量;

  4. 漏洞利用链的长度;

  5. 新型高质量的攻击面的发现概率。

个人保值防老

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

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

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

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

    http://lcamtuf.coredump.cx/afl/

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

    https://github.com/googleprojectzero/winafl

  3. AFLFast——加速版的AFL,Fuzzing速度确实会比原版快一些。

    https://github.com/mboehme/aflfast

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

    https://github.com/vusec/vuzzer

  5. PTfuzzer——Linux平台下的采用 Interl PT硬件支持的覆盖引导Fuzzer,所以它支持闭源程序。

    https://github.com/hunter-ht-2018/ptfuzzer

  6. afl-unicorn——采用Unicorn模拟指令的AFL,支持Linux闭源程序

    https://github.com/tigerpuma/Afl_unicorn

  7. pe-afl——通过静态插桩实现针对Windows闭源程序的覆盖引导的AFL Fuzzer,支持用户层应用和内核驱动

    https://github.com/wmliang/pe-afl

  8. kAFL——支持QEMU虚拟机下的系统内核Fuzzing的AFL,适用于Linux、macOS与Windows

    https://github.com/RUB-SysSec/kAFL/

  9. TriforceAFL——基于QEMU全系统模拟的AFL,借助系统仿真器实现分支信息跟踪,支持Linux内核Fuzzing

    https://github.com/nccgroup/TriforceAFL

  10. ClusterFuzzer——Google开源的可扩展的Fuzzing基础设施

    https://github.com/google/clusterfuzz

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

    https://llvm.org/docs/LibFuzzer.html

  12. OSS-Fuzz——基于LibFuzzer的开源软件Fuzzer集合,实现docker下自动下载、编译安装及运行

    https://github.com/google/oss-fuzz

  13. honggfuzz——Google开发的基于软硬件的覆盖驱动型Fuzzer,单纯暴力Fuzz的效果也挺好的,支持多平台,包括Linux\macOS\Windows\Android

    https://github.com/google/honggfuzz

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

    https://github.com/mwrlabs/KernelFuzzer

  15. OSXFuzzer——基于Kernel Fuzzer的macOS内核Fuzzer

    https://github.com/mwrlabs/OSXFuzz.git

  16. PassiveFuzzFrameworkOSX——通过Hook实现被动式的OSX内核Fuzzer

    https://github.com/SilverMoonSecurity/PassiveFuzzFrameworkOSX

  17. Bochspwn——基于Boch插桩API实现Double Fetches内核漏洞的检测

    https://github.com/googleprojectzero/bochspwn

  18. Bochspwn-reloaded——基于Boch插桩API实现内核信息泄露的检测

    https://github.com/googleprojectzero/bochspwn-reloaded

  19. syzkaller——基于覆盖率引导的Linux内核Fuzzer,需要基于其模板语法实现API调用模板,提供给syzkaller进行数据变异,也曾被移植到其它平台

    https://github.com/google/syzkaller

  20. dharma——基于语法模板生成的Fuzzer,由Mozilla开源的用于Fuzz Firefox JS引擎

    https://github.com/MozillaSecurity/dharma

  21. domator——Project Zero团队开源的DOM Fuzzer,用python实现基于模板生成的Fuzzer

    https://github.com/googleprojectzero/domato

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

    https://github.com/googleprojectzero/fuzzilli

  23. Razzer——内核竞争条件漏洞Fuzzer

    https://github.com/compsec-snu/razzer

  24. ViridianFuzzer——用于Fuzzing Hyper-V hypercalls的内核驱动,由MWRLabs公司出品

    https://github.com/mwrlabs/ViridianFuzzer

  25. ChromeFuzzer——基于grinder语法生成器改装的Chrome浏览器Fuzzer

    https://github.com/demi6od/ChromeFuzzer

  26. funfuzz——Mozilla开源的JS fuzzer工具集合,主要用于Fuzz SpiderMonkey

    https://github.com/MozillaSecurity/funfuzz

Infiltrate2019议题学习

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绕过方法作了学习笔记,直接上图:

image-20190629104044528

image-20190629104108330

image-20190629104158997

image-20190629104215919

image-20190629104249591

EL3 Tour - Get The Ultimate Privilege of Android Phone

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

image-20190629104554838

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

image-20190629104757284

漏洞代码:

image-20190629104832507

对方的漏洞利用思路:

  1. 通过漏洞实现任意内存读写

  2. 布署 Shellcode 于地址 0x209F8000(EL1下可访问,属于共享内存)

  3. 篡改 Page Descriptior : 0x209F8627 => 0x209F8783(可执行)

  4. TLBI ALLEL3:清除TLB缓存,保持数据一致,使页表修改可被CPU感知到

  5. 调用 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远程漏洞。就是下面这段代码:

image-20190629110057733

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

TEE Exploitation: Exploiting Trusted Apps on Samsung’s TEE

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

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

image-20190629112004922

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

资料打包下载

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

image-20190629114646339

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

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

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

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

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

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

推荐的安全会议

1、BlackHat

image-20190511125059375

官网https://www.blackhat.com

如果你不知道BlackHat,说明你不在安全圈混。

USA是主会场,议题质量和数量也是最高的,议题类型覆盖面也很广,除此之外还有欧洲和亚洲等分会场,质量相对次一些。

这次BlackHat USA的议题也陆续公开了:https://www.blackhat.com/us-19/briefings/schedule/index.html

早几年的议题水平参差不齐,很水的也有,打广告也有。最近几年反而议题质量提高,不少华人面孔出现,为了PR效果而竞争,促进大家都拿出干货来分享,这也是其有利的一面。

每年都有几千个议题投稿,竞争很大,但这很好地促进议题质量的提高。

每年会后,官方都会放出PPT与视频,非常开放地分享知识。

所以,首推BlackHat,自然无疑。

但如果你以为接下我会写Defcon,那我会告诉你:No!

2、OffensiveCon

offensivecon

官网https://www.offensivecon.org/

我之前还专门写了篇文章《今年的OffensiveCon大会议题质量不错》介绍2019年大会中一些不错的议题。

虽然OffensiveCon是从2018年才开始举办的,但议题质量一直保持不错,演讲者中包括Project Zero、Google syzkaller作者、Pwn2Own与Hack2Win获奖者等等。

会后,一般是由演讲者选择是否公开ppt,多数人是在Twitter上公开的,官网上我没找到资源(https://github.com/riusksk/SecConArchive/tree/master/OffensiveCon2019),所以之前收集的ppt都是从twitter上扒下来的。

3、HITB (Hack In The Box)

image-20190511133408850

官网:https://conference.hitb.org/

这几天HITB刚在荷兰阿姆斯特丹举办完,议题PPT也一并公开(https://conference.hitb.org/hitbsecconf2019ams/materials/)。

如果要说国内外安全会议中,哪个公开PPT最快的,一定是HITB,他们一般是现场演讲完,就直接扔官网下载。然后过一段时间,也同样发布演讲视频。

他们有时会同时搞两个演讲会场,一个是收费的主会场,议题质量高一些,一个是免费的,叫CommSec,用来提携新人,议题质量相对比较次,每个议题分享时间也比较短,最多半小时。

之前去新加坡参加过一次HITB,人数不多,场地也不大,但可以感受到与国内安全会议的区别:更注重技术交流,而非搞关系。

2018年开始,HITB也开始与京东合作,在北京举办分会场,没去过,不作评价,但国际会议本土化,总会产生一些差异的。

4、InfiltrateCon

image-20190511134410680

官网:https://infiltratecon.com

从2011年开始举办的,已经走过8个年头。

看了今年的议题,还是有干货的,但只有4个议题ppt在twitter上公开。

以前,会后都会在官网上公开PPT和视频,但目前官方还没公开。

今年的议题涉及Chrome RCE、iOS与Android提权、Pwn TEE、浏览器JS Fuzzing等等,只能坐等官方公开PPT了。

5、Chaos Communication Congress(C3)

image-20190511141920353

官网:https://www.ccc.de/

德国混淆黑客大会,常叫C3会议,常在C3前面加上第几届,比如今年第35届,所以叫35C3,历史非常悠久。

以前大多是聚焦在无线电安全,所以一些什么2G\3G\4G短信、电话窃听经常出自该会议。熟悉无线电安全的同学,应该都听过。2018年也有一些不错的软件安全相关的议题,这些在之前写的文章《推荐今年C3黑客大会上的几个议题》介绍过了。

除了大会议题,不得不提下他们的CTF,非常具有实战价值,比如2018年的题目,直接拿pwn2own漏洞当比赛,从safari代码执行到提权,还有VisualBox沙盒逃逸题目,需要利用到0Dday,出题者是ProjectZero的人,早就将其卖给ZDI,刷了不少VBox漏洞。这些CTF题目在网上都有相应的WriteUp可供学习。

这些议题只有演讲视频公开,没有PPT,官方会放在https://media/ccc.de,可在线或下载观看。

都是在每年的12月份举办,2019的还有半年呢……

6、CanSecWest

image-20190511143022033

官网:https://cansecwest.com

CanSecWest都是与Pwn2Own一块出现的,以前议题PPT都是放在https://www.slideshare.net/上分享,但从2018年开始又不搞了。

每年议题不多,但质量还是可以的,不过感觉这两年的质量略有下降。

今年3月的议题也没看到有下载,也是混Twitter找ppt的,只看了《vs com.apple.security.sandbox》这个议题,今年我感兴趣的议题没几个,大家根据自己喜好选择吧。

如果你各个议题PPT,也欢迎分享下。

7、MOSEC 移动安全技术峰会

image-20190511145201148

官网:http://mosec.org

MOSEC是从2015年开始举办的,由盘古与韩国POC联合举办,聚集移动安全领域,包括Android、iOS、IoT以及无线电等领域。虽然起步晚,但议题干货满满的,应该是目前国内最好的安全会议了。

今年的议题也已经陆续公开了,包括iOS越狱、Android提权、LTE、基带、卫星系统等等。

官网是不公开大会的议题PPT,由演讲者选择,所以想学习的同学,可能还是得去参会。

从2015年第一届我就开始参加,本月底还会去。去年参会,早上出酒店一辆车都打不到,又不在地铁口,最后骑了1个多小时的单车到会场,不容易啊……

8、POC

img

官网:http://powerofcommunity.net/

POC(PowerOfCommunity)起始于2006年,在韩国举办的。单从议题质量看,确实不错,大多漏洞研究领域的前沿技术,但它经常是”二手货”,也就是在其它安全会议讲过后,但去韩国观光旅游顺便讲下。

还有个意思的现象就是,每年的议题超过一半是中国人讲的。

所以,你推荐也对,你不推荐也没错。

不过,有个好处就是,POC议题PPT都是提供下载的。有时在其它会议找不到PPT时,到POC官网翻下,偶有小惊喜。

另外还有个会议叫ZeroNights,同一举办方,更多是面向老外的。

那些未提及的知名大会

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

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

后话

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

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

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

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

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

img

什么是逻辑推理

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

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

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

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

推翻前提找答案

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

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

image-20190503101519293

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

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

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

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

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

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

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

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

最后的结局是这样:

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

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

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

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

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

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

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

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

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

image-20190503105014426

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

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

效用概率做决策

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

  1. 做安全需不需要考研?
  2. 选择什么样的学校和专业好就业?
  3. 选择什么样的职业更适合自己?
  4. 其它…….

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

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

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

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

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

  1. 成为旅行作家;
  2. 加入外交部;
  3. 成为公司销售人员。

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

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

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

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

根据上述公式,我们得到:

image-20190503120444342

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

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

五大常见推理漏洞

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

  1. 比较和类比假设漏洞:偷换概念

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

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

  1. 代表性假设漏洞:以偏概全

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

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

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

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

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

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

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

  1. 因果假设漏洞:混淆因果关系

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

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

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

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

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

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

识别常见的逻辑漏洞

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

常见逻辑漏洞识别

附录

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

image-20190503110749773image-20190503113506286image-20190503113329718

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

RSS: 优秀的个人情报来源

早些年,关注了一些技术博客,但不知道它是否更新文章,就只好偶而去翻翻看。关注的博客量少的时候,还应付得来,一旦多了,就觉得甚是费时间。

后来才发现有RSS(聚合内容)这款神器,大大地节省时间,不用再不停地翻看别人的博客,一有更新,在自己的订阅网站或app上就可以查看到。

image-20190330095736471

以前用Google Reader,现在用Inoreader(https://www.inoreader.com),还提供手机APP,特别适合利用碎片时间查看和学习。

我现在基本保持每天翻看,一定要把未读消息消灭掉。

由于多年订阅源的收集积累,每天都有不少更新的消息,即使前天刚把失效的订阅源清理掉,也还有700多个。

以前曾看到某同事的RSS订阅,上千条未读消息,平时看得少,结果越堆越多,导致未能发挥RSS应有的价值。

我觉得RSS应该是每个想保持学习进步的人应该必备的工具。

对于我个人而言,RSS有以下作用:

  1. 应急响应:及时获取外部曝光的漏洞,包括公司产品漏洞,以及可能影响公司产品的第三方通用组件/开源项目漏洞,以便能够及时响应处理;
  2. 刷CVE:及时获知某些主流软件的攻击面,或者一些漏洞挖掘技巧,然后主动尝试去挖掘。以前有不少人在乌云上曝光某一通用漏洞,就经常有一大堆去刷SRC,或者在乌云上不停地刷别人的漏洞,这种行为我觉得挺无聊的。这里刷CVE主要是指Microsoft、Apple、Adobe等一系列主流厂商的产品的0day,而不是以往乌云上这种相同漏洞在不同平台刷洞的行为。
  3. 技术与工具的收集:包括技术文章和工具的收集与学习,对于好的工具,会下载学习其源码,并应用实践;对于好的文章,会保存到印象笔记,方便以后查询复习。
  4. 安全资讯:看看一些发安全界发生哪些安全事件,比如入侵事件、facebook信息泄露事件等等,也学习下别人如何就应对此类事件。除此之外,当然也包括安全界的一些八卦。
  5. 新书资讯:专门订阅一些出版社的相关博客/官网,以便能够及时获取即将出版的新书。
  6. 其它:更多的用途靠自己去挖掘,毕竟每个人的期望的目标不一样。

对于那些未提供RSS功能,又非常不错的网站,推荐使用Feed43(https://feed43.com/feed.html?action=new)自定义规则来生成RSS,可直接导入到Inoreader,使用教程参考:《利用 Feed43,将任意网页制作成 RSS 订阅源》https://sspai.com/post/34320

最后分享一下个人收集的RSS,共731个,Inoreader免费版最多支持500个,不想付费的可以找下其它免费RSS工具,或者选择部分订阅。

下载地址:http://riusksk.me/media/riusksk_RSS_20190330.xml

image-20190330103252935