『功守道』软件供应链安全大赛·C源代码赛季录

　　我和小保姆软件供应链安全，这可以说是一个新近人造的概念热词。泛泛来讲，如今的软件系统中任何一方都不是孤立的；套用到企业的场景，就有了供应链的概念。

　　以典型互联网企业为例。线上生产所依赖的操所系统，配套的基础软件，是最基础设施，这方面RedHat、Linux的开原生态、Oracle等底层平台供应者是供应链上游，企业是下游；而每个企业都有大量的PC端、移动端等通过各式渠道分发的客户端软件，很多企业近些年开始有对开源界的贡献，这些软件、代码运行在终端设备上，这里企业是上游，客户是下游。类似的二元关系可以用来定义如今这个行业的所有链。

　　没有一条链，是我们能够自信完整掌控的；对此的隐忧，在之前或许只是杞人忧天，但如今却已真实来到面前。且看外部关注点，面对过去两年事件频发的看似的情况，在RSA上已经将软件供应链安全作为问题抛出。孤立的事件我们总可以依靠事件响应来应对，这样至少我们不会比别人更容易成为众矢之的；但沿着这个思考虑下去，我们还能不能相信RedHat、开源社区的那些作为基石的操作系统？能不能相信大量存在的Java三方包？能不能相信每个员工工作电脑上安装每一个任意渠道而来的软件？甚至于在互联网快速迭代的大下，那些开发者们从GitHub上借鉴来的代码是不是被埋入了源码级的特洛伊木马？

　　这一切都未知。隐患其实已经发展成了何种真实风险，未知。最致命的是问题完全发散，任何针对已知来问题的尝试都很可笑。没有任何一方在此中有任何优势。谁先捅开这个庞杂问题，都无异于打开潘多拉的盒子。

　　但盒子总会被打开；看热闹甚至先在软件供应链整体崩坏进程中闷声作大死的，都将自食其果；而阿里安全，就决定做这样的角色，振臂让大家知道黑盒子里的可能有多么的，然后在纠集起防护力量的同时，慢慢地打开盒子。

　　作为最先掌握对这个问题进行定义话语权的一方，阿里安全有责任登足够高，望足够远。结合我们的思考，将软件供应链安全的庞大、混沌，划分为“软件供应链生产者”与“软件供应链消费者”的两仪，并抽象出“四象”战场：C源代码，Java源代码，PE二进制，APK二进制。其中事关企业最攸关的三个场景——生产线上、产品开发生态、办公终端设备，我们选取对应的C源代码、Java源代码、PE二进制，设计了本次首届软件供应链安全比赛。

　　作为头阵，需要紧盯最攸关的角度，因此设计为C源代码赛季，背景场景围绕生产系统展开。诚然，我们不能仅仅从已经发生过的安全事件上谨慎地延展出问题域，但试图一步到位定义完整的未知，又容易让人对的真实性产生质疑。而恰逢发稿前，一例新鲜出炉的安全事件，“后知后觉”地向大家证明了问题的严峻，这事件是在Gentoo Linux发行版的GitHub代码仓库上爆出的（完整信息和进展请见页面Github/2018-06-28）：

　　身份未知的黑客获取了Gentoo组织GitHub的控制权，移除了Gentoo开发者的权限，并对代码仓库内容作了大量，其中最主要的恶意行为是替换恶意ebuild文件，以试图删除目标系统所有文件。Gentoo组织的GitHub被短暂冻结，在清除了已知被入侵的时间段内提交的代码后重新。

　　暂且不论该事件中恶意者是否可能有更隐蔽的方式、实践中Gentoo处理是否可能有所遗漏，仅仅该事件关键点本身，即可作为一种全新的类型。从一开始我们对比赛第一个赛季的设计场景，即恰好抽象、覆盖了这样的情形：

　　考虑一个私有的软件仓库，包含有二百余个Linux基础组件的代码项目，由所有者组织并存在大量二次开发。仓库历史上可能存在被入侵并成功隐藏，或存在可绕过的代码提交机制甚至内鬼，导致代码被投毒污染，植入有后门的可能。

　　比赛中，由出题方提供大量已知后门类恶意代码，巧妙混入载体开源代码中；解题方自行探索、归纳恶意行为的知识，并利用现有或针对性开发的静态代码扫描引擎，予以排查。

　　仅仅定义了战场还不够。如前文所述，软件供应链安全的风险，无论是面还是方式，是完全发散的，真正的永远来自未知。但完全天马行空，作为比赛无法进行，需要我们给定一个全局框架，划定攻防活动的范围，以及潜在可能的打击方式，供出题者（方）穷尽这个空间内所有可能的向量；进而，对应的解题方（防守方）才有迹可循，针对部分已知类型训练对更大未知的应对方式：无论是自行扩充专家经验知识库，还是基于行为自动学习的人工智能方案。

　　C赛季最终共实施3场分站赛。为了比赛当中，攻防双方逐步对抗升级，我们将比赛对于系统与基础软件代码的恶意行为嵌入检测，在恶意行为维度，按照行为组成，划分为如下三类，分别对应三场比赛：

　　* 5月19日第一场分站赛为单点恶意行为对抗。题目覆盖所有考点清单的恶意行为类型中，全部仅“单点即恶意”类型特征。例如，部分系统和应用的数据文件与配置文件，仅应当由特定的应用，或程序经由特定的API访问，直接访问这些文件即为足够判定非法。

　　* 6月2日第二场分站赛为二阶段恶意行为对抗。题目覆盖清单中，全部仅可以描述为二阶段联合的恶意行为，即从时间上看，可分为时序上的“上为”和“下为”。上下为之间一般应具有数据相关性，且数据相关性本身可作为出题点（如误报）的一部分考虑。

　　* 6月23日第三场分站赛为复合（多阶段与性）恶意行为对抗。题目侧重于不在之前两场分站赛所覆盖的范围内的题目，如需要更多阶段联合组成的恶意行为的定义与检测。更重要的是，本轮中添加了一部分进阶题目，即恶意代码充分结合载体的已有功能、API调用等进行混淆，并更结合载体代码逻辑完成恶意行为。

　　在以上定义之下，我们给出了如下的允许（基础）恶意行为分类清单，作为比赛对抗当中的基本设计原则。同时这些也是我们认为的潜在危害最大、存在可能性最高、扫描检出可行性最大的部分。*标注为单点确定性恶意行为，**标注为二阶段恶意行为中的上游或下为，#标注为复合恶意行为。显然有该三类行为，前者自动为后者。

　　* 信息异常采集。针对生产，最大的不是造成应用执行异常，而是在无形中泄漏关键数据，包括可能造成机器控制权的系统相关配置数据，关键的应用存储的用户数据等，包括：

　　* 关键数据。任何需要在生产上，修改、写入数据或代码从而实现恶意打击的行为，我们统一归纳到这一类里面，较为泛化，主要包括：

　　* 不可信数据传入渠道。以上两者重点考察了的软件供应链本地恶意行为。在涉及到网络和交互的场景下，通过从供应链上进行污染，一种比较直接且有持续后效的恶意行为就是撕开一个口子，供后续入侵进场，包括：

　　* 不可信信息渠道。对应于的传入。数据的采集后，需要搭配对应的下游传出才能形成完整恶意行为链，常规可能的渠道形式分为两类：

　　* 其它典型木马后门行为。在上述行为框架之外，在生产上具有非单纯效果的恶意行为，划分为此类，包括但不限于：

　　以上所列的无差别软件供应链潜在面，除Linux系统基础软件和应用之外，本次比赛还将若干类企业典型生产、开发测试集成的主流应用纳入到考察范围内；为了将发散的潜在源头、攻守方在比赛框架下的对等，比赛限定在以下假定的目标应用类型和实例。

　　重点需要强调的概念是，在作为软件供应链污染可以达成的恶意，污染者与面是两个的范畴：者完全可以将恶意行为污染嵌入到一个基础软件中，实现对另外一套系统的打击。以下应用，并非是指在这些基础应用自身代码中进行污染；而是指在应用代码中插入代码、以这些服务端基础应用面为对象的恶意行为。

　　整个比赛设置的基本形式是国内前所未有的攻防模式。通过对外公开招募，形成了具有红蓝对抗关系的两支队伍：出题队（蓝军）与解题队（红军）。

　　蓝军由高校CTF战队、业界安全公司、互联网企业安全团队等不同背景人员分别组队，共5支，出于目的，暂时不公开这些队伍的具体身份。蓝军在我们限定的面和恶意行为类型的粗放范畴之下，尽可能脑洞，从多种角度和维度，编写包含有恶意行为的代码片段，并将这些恶意代码片段插入到随机或选定的开源基础软件项目代码中。

　　红军主要由源代码安全扫描专业的公司、高校研究团队、高校CTF战队背景人员组队而来，实际参与比赛的约8到13支队伍。比赛中守方可使用任何方案，对拿到的一组题目进行分析，从近乎海量的代码当中定位到嵌入并巧妙隐藏的恶意代码片段。最主流、被提倡的方案为基于语法语义的白盒源码扫描，需要参赛队具有相关技术沉淀及工具研发与能力，并针对我们前期出的恶意行为考察范畴，自行补充专家知识库，定制扫描规则和方案。

　　当然仍需要说明的是，这些题目本身的合，是建立于这些恶意代码在庞大而的开源软件领域存在的可能性。而这些代码的引入有很多可能的渠道：恶意的上游代码贡献者引入；者在对上游开发甚至源码仓库入侵后巧妙隐藏了痕迹的源码污染；在私有源上对基础软件二次开发过程中的内鬼，等等。相比之下，前文提到的Gentoo GitHub入侵时间只能算作一次略显仓促的污染试水。这些渠道不在我们设计场景的考虑范围内，只需要知道这些情况的可能性，即可以意识到这些问题的严峻程度。

　　本节将从三轮共计约600道题目中，选取若干道（组）最具有代表性、新颖性甚至让人的题目，来展示出题队思维的冰山一角。

　　在此需要特别强调：本文中所列举的所有恶意代码，仅用于彰显那些当前有安全人员可能想到的恶意行为；考虑到真正的永远源于未知，这些题目所搭载的恶意行为类型，实质上在的同时就已经失去最大，但由于信息不对等，在真实场景仍然可能会被利用。所以所有读者需要在阅读同时，需要绝不会将这里的思，以及由此延展出的思维用于线：thttpd后门陷阱

　　从基础软件或应用入手，稳定可控的后门是最佳选择。而在一个无关应用中突兀地出现网络连接，隐蔽性总归很差；在thttpd当中，以很袖珍的代码实现稳定的后门，是这里首先要呈现的一个题目。

　　* 该后门的嵌入，新增代码量极小（共7行），巧妙借用了thttpd处理用户请求、cgi的原本逻辑，借用了execve的调用，没有任何新增的API调用等行为，可以有意识的行为特征匹配检测。

　　* 该后门在代码中的插入，分布在了存在逻辑关联的上下游两个，在源代码分析领域，属于过程间代码扫描问题，对于基于语义的源代码静态扫描方案也提出了很高的要求。

　　对生产上运行的任意程序获取控制、检查、按需泄漏的，很难做的轻量、了无痕迹，总会有鲜明的行为特征被人察觉；但是针对解释执行类型的语言，只需要在解释器上稍动手脚，就可以实现四两拨千斤的效果。本次比赛有两只出题队不约而同地采用了这个思，分别在Python和Lua解释器上实现了巧妙的污染来实现非性的定向，此处以Python为例展示。

　　恶意行为完整代码，嵌入到了Python/symtable.c文件中的多个，完整的新增内容如下：

　　Python应用代码中常见地通过定义一个名为connect函数，传入host\port\user\pwd或者协议字符串进行服务请求，如ssh或数据库连接，所以，在这个题目实例中，在Python解释器源代码层面进行污染，实现偷取名为connect函数调用时这些参数。

　　实现逻辑如下： 1. 在Python表达式语法树遍历过程中，判断方法表达式Call_kind名称是否为connect，是的话进行标记，之后偷参数； 2. 取出该函数的参数个数，并且截取该函数传入的数字、字符串参数保存起来； 3. 当表达式语法树遍历结束后，利用事先准备好的Python源码模板，格式化得到完整Python代码； 4. 动态注入Python代码执行后续传出操作,使用项目原生PyRun_SimpleStringFlags函数。

　　* 恶意行为的嵌入基于对载体（Python）的充分了解，充分利用载体自有的逻辑和API功能来实现完整的行为，由此具有对人工审核和工具检测的绕过能力；

　　* 目标出其不意，具有极强的针对性，从源代码层面下手，一方面在此思上可以扩展出来的其它目标和方式很多，另一方面使得于载体的代码（如数据泄漏传出）可以很自然地得以执行。

　　接下来呈现的是两道的题目。在规则确保不同出题队完全互不通气、思保密的前提下，两支出题队伍不约而同地选取了php作为目标载体；但是切入点、方式、实现效果又完全不同，充分体现了在软件供应链安全这个范畴内，问题的发散和多样性。

　　在php脚本被加载到内存之后，zend引擎解析php脚本之前，修改php源码中代码设置mmap内存的属性为可写，然后窜改内存中的脚本代码，在脚本第一行插入一个一句话木马，POST的key是2live。

　　另一道思剑走偏锋，切入点选择在了默认扩展date中，处在文件ext/date/php_date.c：

　　部署后，若HTTP POST请求参数中存在“b4d00r”，用PHP内核的zend_eval_string函数执行b4d00r中的代码。这样的后门类型更难以被日常检测到；更重要的是，这里代表了一个类型的面，即各类应用框架下的插件体系：对于支持第三方贡献插件的部分主流系统，部分仍然存在有完全、缺乏审查或开发者鉴权的问题，这留下了很大的做文章的空间。

　　以上我们列举了针对生产上，主流服务端应用的本体进行污染、和的几个实例。这可能给读者留下这样的印象：虽然恶意代码本身会通过融入原有代码逻辑、调用项目自有API等方式来实现自身的隐蔽，但对于这些关键应用进行细致的审核检查，甚至于人工分析，只要其源码是可用的，那么总能够这些应用的可信。可惜，这样的乐观，不存在的。

　　在系统和所有基础软件都来源于不完全可信来源（没错，即便是开源软件贡献者也不能称为可信，没有人是）的假设下，对特定服务端应用的污染、窃取、和，完全可以从任意方面发起。以下不列举相关恶意代码和上下文，简单列举几个这样的实例：

　　* 通过在一个系统基础组件krb5当中，插入恶意代码实现IAT HOOK，针对OpenSSL系统组件，在目标调用栈中，劫持BN_rand方法使得生成的伪随机数恒固定为特定数值，且使得EC_KEY_generate_key方法与DH_generate_key方法生成始终可预测的椭圆曲线秘钥；这样进而达到OpenSSH的服务端sshd在接受客户端ssh连接时，握手秘钥可掌握，从而能够直接获取会话秘钥，辅以其它简单的方案，就能够使得所谓加密信道的数据完全可被泄漏。

　　* 针对处于后台的开发编译机器。先判断是否是真机Android源码编译开发，如果是虚拟机不执意代码，如果是真机，本地端口下载编译工具，进行编译链工具或开发标准库的替换，从而实现在源头进行软件供应链上游的持续、全面污染。

　　* 在任何可能存在目录遍历、文件操作的载体代码上下文中，搭车进行特定资产类型文件的遍历搜索，如特定的代码、文档、数据库类型文件，账户秘钥和系统信息相关的配置文件，特定服务端应用（如Nginx，git等，见上一节中所列举的目标面服务端应用列表）的关键配置和数据文件等，并予以。

　　以上类型不胜枚举，且均具有两个特征：功能实现代码体量很小，方便隐藏；对载体项目上下文基本不挑剔，所以可以嵌入到任何有被执行条件的开源载体工程中。这些行为甚至可以是看上去“很low”的行为，即便不针对源代码扫描的各种方案进行有目的性的反检测，一旦混入庞杂的开源项目代码中，就完全无从分析——毕竟若假定全部基础软件和组件都不可信的话，那么即便是针对少数几种已知的恶意行为类型，使用源代码扫描工具编写特定的检测规则、全量扫描，也是一件很难高准确率、低误报率的工作，更何况请不要忘记在第一篇文章中我们提出的前提：最致命的是问题完全发散，任何针对已有知识来问题的尝试都很可笑。

　　安全行业从来不是一个攻守双方旗鼓相当的领域，技巧相对于防守体系而言始终拥有很大的杠杆。从这一角度讲，本次比赛中思夺人的蓝军固然是明星，而参与解题的红军破题者，更是代表出和希望。

　　整体而言，通过后台对各个参赛队提交答案的规律统计和分析，这样的解题结果超出预期，又引人思考：

　　* 研究方向覆盖静态源代码分析的高校与科研机构，在比赛公布考察范围后能够迅速构建起响应的知识库，过程中始终领跑全场比赛，并获得了及格线以上分数。作为源码分析的解决方案，即便是针对非软件供应链后门类型的其它新问题门类，考虑到普遍较高的误报率等固有问题，这样的分数足以判定为优秀。

　　* 在校学生与感兴趣的个人参赛者，在不具备充分的背景和资源的前提下，仍然获得了1/3以上题目分数。通过对提交历史的分析，我们初步判断这几支队伍在初期尝试进行人工分析积累经验后，也针对这一类问题进行了工具自动化发掘的实践，这达到了我们“业界思考”的初衷。

　　* 尽管如此，在第三轮所设置的进阶题目（具有更强的安全背景考察，逻辑隐蔽性更强；形式上多采用跨函数、跨过程的代码插入方案）面前，所有队伍均无抢眼表现，这似乎表明软件工程方与安全知识的结合努力仍有空间，这也是长远看的发力点。

　　想必业界对于这些参赛队伍的思、工具和，都有着浓厚的兴趣。此处先卖个关子：这些红军队伍的思，我们将在8月22日的，阿里巴巴2018网络安全生态峰会的分论坛——软件供应链大赛研讨会暨决赛阶段启动仪式上，邀请这些胜出队伍代表进行分享，敬请期待！

　　未来已来：PE二进制赛季开战至此，我们完整的『功守道』软件供应链安全大赛，在预选赛阶段，刚刚完成约1/3。大赛完整的时间线月开始，我们将马上实施大赛第二赛季——Windows PE二进制程序赛季（简称PE赛季）。

　　相比C源代码的攻防，PE二进制的安全风险与对抗，历史安全事件更多、更触目惊心，不论是XShell污染，还是CCleaner投毒，抑或针对集成开发插件生态的污染，都是领域内耳熟能详，却又缺乏系统性关联分析的热点，也更能够起安全从业者和爱好者的兴趣。针对这些繁杂的事件，我们对主要风险做了抽象，该赛季由此设置场景如下：

　　IT企业员工工作电脑复杂且无法收口：安装软件来源往往跳出白名单，而鱼龙混杂的下载服务往往包藏祸心；遑论即便是软件的提供商，也可能存在被入侵并在二进制文件层面植入恶意代码的情形，导致潜在的不可信，亟需二进制审查，或源码-二进制等价证明。

　　对于给定的二进制文件，你将采用静态还是动态的方法去扫描或测试?针对对照组是否有能力通过同源性判断察觉异样?这是道题目。

　　在这个更贴近每个互联网企业从业者实际，符合安全圈从业者的兴趣口味的题目设计赛季，我们将期望能够收获更广泛的关注、影响力，更多让人拍案叫绝的恶意代码思，以及更让人叹为观止的防守者解题方案。这里欢迎所有安全技术兴趣者持续关注到该赛季的过程中；也希望对于比赛的赛制形式和细节有见解的同学能够协助我们将比赛的价值发挥到极致。

　　文章由325棋牌提供发布