Flanker Sky

Fuzzing这个事物大概可以上溯到1950年，当计算机还在读取打孔卡作为输入的时候。那时候的工程师会从垃圾箱里随机检出一些废弃卡片，或者在卡上随机打孔作为输入来测试自己的程序。在1988年，Barton Miller在课堂上将Fuzzing这个名词正式确定，从此拉开三十年波澜壮阔的序幕。 广义上的fuzzing并不是漏洞挖掘中的专属内容，而是DevSecOps和Continous Integration质量保证中必不可少的一环，甚至可以延伸到完备图灵自动机的美妙梦想。在起初，人们通常以monkey testing来指代最原始的fuzz，就像著名的无限猴子定理一样：让一只猴子在打字机上随机地按键，当按键时间达到无穷时，几乎必然能够打出任何给定的文字，比如莎士比亚的全套著作，当然也有可能包含一套Nginx RCE。 但很显然，随机化的输入虽然终究能覆盖所有的输入空间，在人类未来可预见的算力水平下近乎天方夜谭。刘慈欣在《诗云》中有一个宏大的故事：宇宙神级文明为了写出最优雅的诗，而把整个太阳系的物质作为存储器，采用枚举遍历的办法把所有文字的排列组合全部生成并存储了下来。但最后神却发现，即使理论上这里存储了所有的诗句，他也无法在可接受的时间内找出目标来，因为美妙这个词本身就是主观而无法定量界定的。以神的算力尚且无法完成，以人的算力就更不可能了。随着软件复杂度大爆炸式的增加，dumb fuzzing的随机生成方式相当于在东方明珠上向下扔一只钉子，寄希望它能刚好掉进楼下某个人举着的酒杯里。 田园农耕时代 为了解决以上问题，在学术界，结合动态执行的symbolic execution在一段时间成为了主流，KLEE[1]即是其中的扛鼎之作。在Z3 Solver和LLVM bitcode infrastructure的加持下，KLEE能够自动解析各式各样的条件代码语句并生成输入，进而辅助fuzzing。 而在工业界，一般分两种做法： peach为代表的模版流派：研究人员通过XML等方法定义输入数据的格式，这种常见于文件格式和协议的fuzzer。 依赖于样本的收集和变异的样本流派：例如早年间IE和Flash的fuzzer很多依托于通过爬虫搜集的大量样本集合。整体来说，那个时代工业界的fuzz是各流派的独门秘籍，每个人都有自己的秘不外传的实现，热闹非凡但原理上大同小异。 虽然这些方案看起来都非常home brew，在早期的软件复杂度和质量的前提下，人们依然能够取得较好的成果。但随着软件复杂度的摩尔式增长和SDL开发流程的全面引入，停留在农耕时代的fuzzer们发现，自己开始跟不上软件发展的潮流了。 从越南战争到海湾战争 所有信息安全面临的问题都能在军事界找到类似的场景。美军在越战之中投放了前所未有的火力和军队，但依然遭受了惨重的伤亡乃至最后停战。越战的问题集中反应在火力杀伤效率的低下，面对防御严密的目标，攻击方只有两种选择 特种部队渗透或地面强攻。但这需要大量情报和兵力支持，并极有可能遭受大量伤亡。 提高航空兵和地面炮火火力密度，寄希望于火力扇面能够覆盖目标。但这只会进一步造成火力的浪费，同时仍然无法保证毁伤效率。 这和fuzzing技术后期面临的问题是类似的。针对越来越复杂的目标，纯粹堆计算资源的dumb fuzz效果已经可以忽略不计，但程序分析本身是一个NP-hard问题，符号执行的方法极易引起路径爆炸，对于复杂的软件最终会撞到资源墙上。而工业界的方法过于强调样本或格式指引而非程序指引，要么需要投入大量的前期精力编制模板，或者在缺乏context的情况下两眼一抹黑撞大运。 直至80年代末期，人们所设想的现代战争形式依然是拼消耗的钢铁洪流对撞，两伊战争的结果更是给这个理论增加了注脚。萨达姆在海湾阴云密布时，仍然充满了信心，仗百万精兵要让多国部队血流漂橹。 然平静之下，暗流涌动。针对以上问题，电子技术的发展和成熟及应用催生着新一代的军事革命，并最终在海湾战争中完美登台亮相。多国联军以摧枯拉朽之势击败了伊拉克军队，彻底颠覆了过往的战争形势，震撼了全球： 精确制导武器极大提升了火力发现和打击的效率 – 精准原则 C4ISR数据链指挥系统带来了从古至今所有军人梦寐以求的战场单向透明 – 敏捷原则 漫长的黑夜预示着黎明，更精准、更敏捷的划时代fuzzer即将登场。 横扫千军如卷席 随着LLVM工具链的成熟和计算资源的大发展，基于编译器插桩的coverage-feedback driven fuzzer渐渐成为了答案之一。正如美军在海湾战争展示的新军事革命一样，AFL的诞生则宣告着这个永恒的问题出现了一个高分答案。 AFL (Americal Fuzzy Lop，logo是美洲本地可爱的长毛兔) 由Michał Zalewski在2014年发布并开源，并迅速像AK47统治枪械市场一样成为了fuzzing系列工具的de facto standard，数年间斩获上万CVE。 基于编译时插桩和自定义bitmap的方法维护coverage信息，以简洁的方式巧妙地解决了以往获取coverage效率太低的问题 基于fork/exec的方式极大提高了fuzz效率 coverage导向的遗传进化算法简单但惊人地有效 在设计上即支持多进程甚至跨集群并联 在先驱者探明道路之后，后继者雨后春笋般涌现出来。LLVM也推出了自己的实现libfuzzer，以in-process mode取代了fork mode。基于AFL和libfuzzer的体系，结合protobuf定义，模版化fuzz也以structure-aware fuzzing的名义重返舞台。内核领域的对应者syzkaller也取得了极大成功。这类方法统称为Coverage-based greybox […]

无论是否情愿，并不是每家公司都能像Google一样在办公体系中完全移除了域控的（大部分）存在感，域仍然是安全人员觉得微妙的存在。 一方面各种域策略、账户的可视化配置方便了大部分企业的IT桌面支持人员在初创阶段做无脑配置，然而另一方面，域控天生与新时代ZeroTrust理念是无法完美契合的。最大的槽点不在于认证源仅仅只有固定密码可选（据传新的Windows Server终于将开始引入OTP，以及Azure AD在某种程度上是支持的），此外其他域提供的各种管理功能在现代互联网企业Linux+开源组件定制化的大技术栈下同样显得格格不入。 但在ZeroTrust理念指导下，我们仍然可以对Windows认证体系进行加固和改造，极大提高其安全性。本系列文章将介绍可能用到的各类工具以及微软自身提供的mitigations，随后讨论如何基于这些手段和理念构建纵深防御。 在上面提到Windows密码认证所固有的缺陷后，我们自然会提出如下的问题：如何改造固有的静态域认证体系？在这个理念指导下，可以采取什么样的手段？ 一种显而易见的体系化改造是直接通过Windows Credential Provider提供的接入能力，改造认证源，取代Windows原有的认证能力，而本文将介绍的pgina就是其中的一个成熟的开源方案，pgina是一个开源的Windows Credential Provider认证框架，通过各种C#形式的插件，我们可以定制Windows的认证流程，取代传统的密码认证流程，与统一认证源完成打通，在某种程度上实现大一统SSO的梦想。 pgina架构介绍 pgina最早由David Wolff等开发并开源，借助Windows的Credential Provider体系，实现了ICrendtialProvider接口，实现了认证流程的定制。mutonufoai维护了一个fork版本，是目前比较活跃的分支。http://mutonufoai.github.io/pgina/ 简单来说，在安装了pgina之后，我们可以在认证流中插入自定义的环节，Pgina原生提供了多种开箱即用的插件，通过这些插件与外部认证源打通。例如，我们可以通过自定义的Radius认证服务器或者通过http auth插件，来实现对OTP登录的支持，甚至更细粒度的控制。 pgina配置 我们以pgina接入radius认证后端为例，展示pgina的用法。需要注意的是pgina并不是一个中心的域控插件，需要安装部署到所有具体的目标机器上。 pgina认证流程区分为Authentication – Authorization – Gateway三个阶段。其中，Authentication阶段用于证明该用户提供的认证凭据是否正确，而Authorization阶段则决定该用户在凭据正确的情况下，其是否可以登录（例如只有某一个特定组的用户可以登录），Gateway阶段则更类似于认证通过之后的回调。例如在众多插件中，LocalMachine代表了该机器上的native认证，如果其他插件认证通过的用户在本机上不存在，则LocalMachine插件默认会在Gateway阶段创建对应的用户。当然，这个行为都是可配置的。 通过pGina插件在Windows认证中支持OTP认证 在有了这些基础知识之后，我们就可以通过插件连接到自定义的radius server，来对Windows开启OTP认证支持。受到Windows UI限制，用户可将OTP追加在其原始密码之前或之后，整体的流程如下图所示。 根据以上设计，我们甚至可以在某种程度上，摒弃域控体系的存在，而把认证源完全转移到统一的认证体系中。通过插件中所携带的信息，甚至可以做到对特定机器限定特定权限登录，以及检测到用户存在风险时自动拒绝登录等等。 根据实际测试经验和遇到的问题，有如下建议可供参考： 内置插件可用于快速测试功能，但在可用性上没有太多考虑，radius插件本身在高频使用中存在一些问题，建议根据其架构自行实现插件，通过自定义的认证协议与远端认证接口进行联调和实现 开启了插件认证的机器在被远程桌面时（如果允许远程桌面），远程桌面客户端侧需要关闭默认的网络级别验证，因为Network Level Authentication并不支持自定义的credential provider。关闭NLA并不会带来认证方式上的安全问题（例如hash被抓取之类的） pgina原版具有调试功能，但调试功能较为难用，建议通过log形式调试，pgina.fork并不支持调试。插件主要为C#语言编写，需要对C#有一定的了解。 此外，一个显而易见的问题是，原账户的密码应当如何处理？LocalMachine插件当然支持对原账户的密码继续生效，但这会造成显而易见的短板。一种安全的做法是通过终端能力下发定制化脚本，对原有的账户密码进行定期全随机化，包括本地Administrator用户、域控体系下的域用户等。当然，出于灾备的考虑，对部分账户还需要通过一些方式保留原始认证能力供网络、存储等意外因素导致自定义认证服务不可用时排障使用，具体细节在此不在赘述。 总结 以上介绍了pgina认证体系及其插件化应用，同时以将OTP引入Windows认证为例，给出了一个案例。基于插件化的能力，我们可以摒弃域控认证体系部分固有的弱点，引入TOTP二次认证体系，统一认证后端。API接口的能力允许我们对认证权限做更统一的细粒度规划，而不是拘泥于Windows域所固有的体系，降低维护成本，提高安全性。 注：该文已授权首发于 跳跳糖：https://tttang.com/archive/1282/