150万元重奖！阿里功守道-软件供应链安全大赛

报名官网：https://softsec.security.alibaba.com/index.html（请注明来自安全客）

 

活动简介

近些年，从棱镜门事件到XcodeGhost，再从惠普驱动键盘记录后门事件，到Xshell后门、python pip源欺骗性污染、VSCODE插件钓鱼。软件供应链安全事件不仅频繁发生，而且具有威胁对象种类多、极端隐蔽、涉及纬度广、攻击成本低回报高、检测困难等特性。针对于此，阿里安全宣布正式启动“功守道”阿里软件供应链安全大赛。本次赛事的官网（https://softsec.security.alibaba.com/index.html）也同步上线。

 

报名时间

报名时间：2018年2月-3月

软件供应链安全测试赛：2018年3月-4月

分站赛：4月-9月（具体时间请关注赛事详情的实时更新）

• C源代码专题分站赛比赛日程如下，报名网站（https://softsec.security.alibaba.com）：
• 05月19日 14:00-17:00 单点确定性恶意行为（新增报名截止时间：5月16日 24:00）
• 06月02日 14:00-17:00 二阶段恶意行为（新增报名截止时间：5月30日 24:00）
• 06月19日 14:00-17:00 复合恶意行为（新增报名截止时间：6月15日 24:00）

总决赛：10月份

为了吸引更多的优秀参赛者，本次大赛提供了高达150万元的奖金。无论是来自企业、高校，亦或是研究团体都可以参赛，而且无论是组队，还是“单枪匹马”，均可参加。

 

赛事详情

5月12日下午13时，紧锣密鼓筹备数月的攻守道·软件供应链大赛终于拉开序幕，首场测试赛吸引了包括来自北京大学软件工程国家工程研究中心、清华大学、香港科技大学、中科院信工所、FlappyPig、北邮天枢等多家知名高校和企业的安全团队报名参加。

在6小时的鏖战中，攻守双方选手就66个C语言开源工程载体和软件供应链安全风险点展开了激烈的斗智斗勇，最终共计62个安全风险点被防守方以自动化方式正确识别。比赛结束后，主办方邮件反馈了每队的正确答案和测试赛得分，以供选手进一步优化工具，备战即将到来的C源代码专题正式赛。

 

0.引子

安全行业向来讲究江湖风范，武功高者或攻城略地或华山论剑，有没有武林盟主之位倒还次要，这份“黑阔”的自尊是少不得的。而自家后院失火，残忍揭示其对拿手兵刃并未完全掌控，则是对这尊严的致命一击。
在高校与研究院所，也有广泛的安全学术“名门正派”一直在进行着全方位的基础研究，只不过相较于圈内层出不穷抓人眼球的安全事件、黑客炫技，门生的苦苦修炼往往难得赞许，似乎总蹚不进业界刀光剑影的池中。
软件供应链安全大赛，就是这样一个让所有从业者一道，重新审视我们自己的战场环境，在被人摆一道之前先破除再重建自信，并解放研究者功力的机会。如今，这个比赛刚刚击鼓，启动面向企业基础设施的“C源代码”赛季。

 

1 比赛全局闪回

软件供应链安全本是一个缥缈的概念，仅从近两年的若干看似独立的事件中，大家才似乎嗅到一点气味：XCodeGhost、XShell污染、CCleaner污染、pypi投毒等等。看似背后攻击者一时兴起的尝试行为，最终被行业发展规律证明：今天一个人无意间揭示了一个可能的新型攻击面，明天它就可能被破开成为一个新战场，你的意识决定你站在哪里。
结合阿里巴巴为代表的典型互联网企业的软件供应链环境与实践，我们尝试将这混沌的庞大命题，划分为“软件供应链生产者”与“软件供应链消费者”的两仪乾坤，并抽象出“四象”战场：C源代码，Java源代码，PE二进制，APK二进制。

比赛全程强调攻防对抗情态，阿里巴巴集团安全部联合中国信息产业商会信息安全分会、SecZone、百度安全、安天实验室等作为组织方，持中立立场、设计对抗形式和战局均衡，力求打造一场为期6个月的对抗升级大赛。

 

2 C源代码赛季设计

本赛季，我们将来审视互联网企业赖以生存的基础软件系统设施安全。
在传统围绕“入侵-反入侵”展开的企业环境加固中，系统隔离和监控为本，及时漏洞响应修复为术；系统与基础开源软件组件、第三方开源应用或组件，往往被默认为是可信的，顶多存在程序不可避免的bug和漏洞。但通过软件供应链路的污染，下面的场景绝非虚幻，也许并未发生过，但只需点出，敏感的安全从业者自会发现，这些事情完全有可能存在——如果还不是已经存在了的话：
 针对生产环境，某基础软件当中被引入恶意代码，存在抓取系统敏感信息并泄漏、注入特权账户，或者面向web服务器环境插入webshell，或者从数据存储、缓存服务中偷取敏感企业存储数据，或者偷换用于加密认证的中间件留下后门，或者干扰作为云服务的基础设施；
 针对开发环境，某由开发者引入的随意渠道的开发辅助工具，存在本地源代码遍历甚至加密勒索的行为，或者针对代码仓库服务实施悄然的元数据拖取，或者针对代码审查与缺陷管理平台泄漏产品过程中缺陷信息，或者在持续构建、集成、发布、部署的全链路针对对应后台服务做窃取甚至偷天换日。
在以上的假定目标应用环境基础上，我们划定了几大类潜在可能的“恶意行为”，包括敏感信息异常采集、关键数据篡改、不可信数据传入/传出渠道、典型木马后门与破坏行为等，包含二十余类细分项；作为首次对这一问题域的定义，我们结合与高校、同行的前期探讨探索，详细对所有细分项进行了刻画，并针对在比赛中可进行难度区分与可考察的两方面考量，分别按照单点、二阶段和复合恶意行为对上述细分项做了明确分类，难度递进，分别在三轮分站赛中进行考察。

 

3 后记

在接下来的C源代码专题的三场分站赛中，攻守双方将逐鹿共计12.5万元奖金，其中专题总分第一名团队将直接晋级决赛，参与到50万元决赛头名奖金的争夺中。

• C源代码专题分站赛比赛日程如下，报名网站（https://softsec.security.alibaba.com）：
• 05月19日 14:00-17:00 单点确定性恶意行为（新增报名截止时间：5月16日 24:00）
• 06月02日 14:00-17:00 二阶段恶意行为（新增报名截止时间：5月30日 24:00）
• 06月19日 14:00-17:00 复合恶意行为（新增报名截止时间：6月15日 24:00）

分站赛每场将覆盖约180个C语言开源工程载体和软件供应链安全风险点，欢迎更多的安全侠士参与到本次的饕餮盛宴中，攻防相促，煮酒话安全。

 

规则介绍

出题者与答题者报名须遵循如下规则：
•      报名主体可以为安全行业公司、研究机构、高校，允许跨单位组队且队伍人数不限，但所有组队成员单位视同独立参赛单位的利益互斥原则；
•      由参赛团队的队长使用淘系账户在赛事主页上进行注册并创建队伍。组织者审核参赛资格，并依据队长的公司、机构、学校的域名邮箱，验证队伍的单位属性；
•      待队伍资格验证后，再次更新团队所属单位、队长信息等需要重新进行审核；
•      报名出题者角色的队伍，需向组织者提供出题构思、方案、期望解法等，便于组织者进行资格筛选；
•      答题者队伍名称一旦确认，不可更改。
•      一个队伍可同时报名出题者与答题者角色，但经过筛选后，只能选择其一角色参加比赛。

 

赛事介绍

据赛事负责人、阿里安全资深专家杭特介绍，本次大赛旨在“以武会友、攻守切磋”，以促进软件供应链安全技术的发展。通过“查缺补漏、杜隙防微”，保障软件供应链安全；“抽丝剥茧、码海寻踪”，发现软件供应链安全问题。

众所周知，安全行业在当前的高速发展过程中，出现了一些亟待解决的“怪现状”。比如，行业普遍重视“攻”，而忽视“防”，造成防守人才极度匮乏，进而使得攻守失衡。再比如，业界普遍重视“人肉”， 而轻视“自动化”，让大量的安全工作都是低级重复性的，效率非常低下。另外，安全行业还存在着重视“攻防”， 轻视“数据”；重视“单点、破坏”， 轻视“体系、建设”；重视“技术”， 轻视“业务”；重视“反向能力”， 轻视“正向能力”等系列问题。

杭特表示，阿里软件供应链安全大赛是从“真正尝试解决上述业界痛点、提高安全行业防护能力”出发的，并且可以做到安全能力的沉淀，比赛也在赛制上有很大的创新，两种角色同台角力，引发激烈的能力对抗。

“这就是一场自动化软件供应链安全风险点检测的攻防对抗盛宴”，杭特总结说。

 

在今年，阿里安全尝试通过比赛的策划和组织，来阐述我们站在生态、企业和基础设施的角度，看待的软件供应链可能存在或将出现的安全威胁。划分了三个形式的赛季框架以使得比赛形成对抗，但根本着眼点是安全风险的两个大的维度：底层系统和最基础软件设施风险，落到Linux系统C源码基础软件的恶意代码片段挖掘；企业员工办公与接入企业网络的终端设备风险，落到Windows环境软件PE二进制可执行程序文件的恶意代码和行为判定。

近期软件供应链相关的一些新闻和反思，也在逐步佐证我们的顾虑。6月份，Gentoo Linux的GitHub被黑客控制，篡改了代码仓库的关键组件代码植入恶意破坏逻辑，所幸形式受限于采用新增提交的方式，所以方便进行回滚，但这种从系统基础软件上下手的威胁已浮出水面。9月，去年6月份NotPetya网络战的故事重新引起了公众注意，黑客通过财会软件M.E.Doc软件通过更新进行污染进一步扩大破坏，这种对特定目标受害者受众的办公软件进行攻击，也验证了针对终端执行攻击的末日场景。但是，直接针对互联网巨头服务进行污染乃至攻击的案例，到目前为止还没有被发现的迹象，却让人寝食难安。

在9月27日刚刚实施的最后一个赛季的唯一一场比赛中，我们结合阿里自己的场景、经验与外部视角，探讨了最后一块拼图：作为互联网企业，我们自身应用的安全，落到Java开发生态中三方组件、框架的扫描和检测的形式之上，以比赛论英雄。

 

本赛季将作为场景赛场设定为Java开发生态的企业应用环境：

具体分析，在企业场景下，认定风险主要有四类来源：

• 大量无条件信任的二方包、框架与源。这些外部基础组件，类似漏洞的风险，其在开发、分发环节也存在被攻破篡改的风险。
• 对外部存在二次开发和定制的基础组件。二次开发不止可能引入碎片化、历史漏洞问题，还会导致这些代码失去一致性安全保证。
• Ctrl-C和Ctrl-V引入的外部威胁。当前代码由GitHub等公开代码借鉴而来的情况在开发实践中不可避免，如果存在蓄意发布的暗藏恶意的代码可能被直接引入。
• 大量人员流动引入的代码隐患。快速迭代中人员流动，一方面不利于代码规范的维持，一方面也引入了“人”本身的不确定因素。

 

如之前两个赛季一样，比赛是由阿里安全作为中立策划与组织者，由红蓝双方对抗而成的比赛，其中蓝方设计攻击恶意与恶意行为，实现原始题目贡献；红方根据公开信息，针对性地实现自动化方法做恶意行为发现；而我们负责将有限且直接的恶意行为思路扩散、混淆形成接近真实风险问题规模的赛题，并引导、评定、评价恶意行为发现的方法与效果。

赛题形式

针对Java赛季，结合真实场景，具体题目形式介于前两个赛季之间：

·    类似于C源代码赛季，基于Java源代码工程作为载体，在其上直接插入“恶意”代码片段；题目从形式上，又分为两类：

• 常规题目。在这样的题目形式下，恶意代码与载体本身没有任何关联，不依赖于载体的逻辑，也不干预载体原本功能，因此恶意代码存在的位置可能是任意载体、任意代码上下文之间。
• 进阶题目。这种形式下，恶意行为本身与载体工程和代码具有交互性、关联性，并借用载体本身的逻辑、接口、库、函数调用序列等，因此有较强的真实攻击性、隐蔽性。

·    类似于PE二进制赛季，发布题目以插入了题目的代码工程编译后二进制jar包形式为准：

• 为了防止包含恶意代码的工程直接被进行源码层面比对、发现额外新增的题目代码，对题目进行一定程度混淆加花，编译为jar包。采用的混淆方案保证不以干扰jar包反编译为目的，所以解题队也仍然可以使用反编译后的源码扫描能力。

赛题环境

本赛季的题目载体，根据设计需要覆盖的风险来源，包含了服务端公开使用率比较高的Java二方包（开源应用/组件，其中可能有数量不等的非官方新增代码），以及其它来源的开源服务端应用/框架/组件，均为jar包形式。载体本身的功能无限定。

题目数量上，本次最终采纳的题目，包含90道常规题目，一对一嵌入到90个小规模jar包；以及在21个jar包上针对性嵌入的共计35个进阶题目。考虑到二者难度比例，常规与进阶题目每个点分别计1分、3分，所以二者数量上约3:1比例，分数上占90:105。比赛时长根据题目数量与业界自动化分析能力吞吐量水平进行核定，最终定为3小时。

赛题范围

根据赛季场景设计，Java源码题目和C源码题目有类似的地方，都是在服务器端执行应用中的污染，攻击目标也是服务端其它应用、敏感数据。但考虑到本次着眼于Java开发生态、互联网服务提供者场景，二者具有一定区分度，主要有：

• C源代码赛季假定的是Linux开源基础组件，运行在系统底层，攻击目标以系统自身数据、其它基础软件为主，以服务端场景后台应用为辅；而Java赛季以各类服务端应用为主。
• C源代码赛季基于的一个原则是，不可以使用漏洞类攻击行为；而Java应用安全很多围绕漏洞展开，题目本身也可能以历史或未知漏洞为关键、以语言特定的方式引入。
• C源代码当中限定的恶意行为较为严格，且以循序渐进的方式引导攻防双方能力逐步升级；Java赛季相关参与方基本具有成熟的扫描能力或人工分析专家经验，在划定范围之外鼓励进行脑洞发散。

恶意行为范畴

恶意行为范畴，指的是约束恶意代码可以接受的关键行为特征。针对Java应用，则结合了Java应用安全真实案例和潜在风险，强调从真实攻击场景出发，不细化到具体的行为点，仅进行分类，因此将恶意行为做如下划分：

• 摸排。采集目标环境、应用、输入输出等敏感信息并泄漏，为入侵做准备。
• 破门。渗透进入，拿到控制权或留下后续真正攻击的入口、跳板。
• 窃取。窃取关键数据（用户数据资产，内部代码）泄漏。
• 篡改。在尽量不被发觉的前提下修改关键配置、代码、数据。
• 破坏。类似NotPetya以战为目的，充分扩散后集中的最大破坏行为。
• 扩散。类似蠕虫行为，但还可能包含从服务端向终端的“逆向”横向移动。
• 潜伏。长期隐匿并断续侵害，或等待时机发起破坏。
• 清理。隐藏行为反侦察，破坏行为反分析。

其中，扩散、潜伏和清理三项，是辅助类型恶意行为，单独不足以判定恶意，也不单独出成题目；可选地与其它几类恶意行为组合。

假定目标应用环境

假定目标应用环境，即假设被污染代码执行的环境中，可能存在的其它软件环境，这些软件环境可被攻击。Java源代码赛季则选择完全发散，本赛季不限定这一列表。

注意，所谓目标应用环境，并非是指在这些基础应用自身代码中进行污染；而是指在某些任意的应用、二三方包代码中插入代码、以这些服务端基础应用攻击面为对象的恶意行为。

 

蓝方队伍组成

本次比赛，因各种客观原因，外部业界出题队有2支，分别是r1ng3以及DiDi；而在内部，本次出动了阿里安全团队的大量直接负责应用安全、漏洞分析和研究的专家、工程师全程参与了思路构成和题目集成，可以说是构筑了最贴近一线的攻击队伍。

蓝方题目赏析

相比之前两个赛季，Java赛季为尽量扩充有效题目数量，我们对出题设定了尽量少的思路、目标限制，完全依据所有队伍和人员对于安全风险与比赛的个人认知，因此题目的质量高低是一个非常主观的评价；同时，因为如开篇所述，Java赛季所反映的是目前还没有在野发现的新型威胁，作为题目贡献出来的攻击思路直接释放出来会面临一定程度的风险。基于以上两方面考量，我们本次的总结将不像系列前篇一样放出精选题目深入解析，仅做全局分析。

整体观察，在常规题目部分，因为要求“恶意行为”载荷能够具有载体无关性，且满足能够插入现有Java工程中任意函数的语法兼容性，所以对应于上一章所分类的恶意行为范畴，各支队伍提交的恶意行为的分布，主要集中在“窃取”和“篡改”两种类型，例如各类特殊目的的恶意代码执行，包括恶意代码作为载荷本身嵌入，如窃取秘钥、目标服务配置等敏感文件数据，挖矿，并与各种外传方式进行组合；远程获取真正恶意代码并以各种方式在本地注入或执行，包括系统层面生成crontab任务或JVM层面的注入；各类传统的web应用的后门、webshell植入；以及一定比例的从C赛季典型服务端恶意行为直接移植采用的题目。整体而言，在常规题目部分，所有蓝军队伍倾向于保证题目的充分数量，思路较为集中和单一，且部分赛前设计预想的恶意行为类型（如规模化基础设施破坏，双向攻击移动与扩散，攻击行为痕迹清理）很少或没有在本次题目中体现。这些题目虽然在保证真实性的前提下略显抽象，但是考虑到类似Gentoo代码库入侵篡改事件的场景，如果攻击者需要在获取代码权限的极短时间内完成批量化非定向恶意行为嵌入，那么这种简单、代码量极少的攻击载荷将是具有真实威胁且难以干净清除的渗透分子。

而观察进阶题目，组织方看到了各个出题队在真实的服务端应用安全的深厚经验积淀与对未知威胁思考的体现：

• 从植入恶意代码的目标载体来看，所有队伍均默认选择直接针对服务端Java后台服务应用或处理用户数据的关键组件，包括：mysql-connector, spring-webmvc, tomcat, Jetty, jedis, fastjson, spring-boot, Elasticsearch, javamail, jenkins, incubator-dubbo, OkHttpClient, nanohttpd。在这些目标上直接进行代码篡改，显然将具有最大的攻击面影响；从业务场景和攻击逻辑上讲，直接面向有针对性的数据和处理逻辑，能够形成真实且完整的攻击链路；从思路形成角度分析，针对这些开源应用和组件的攻击，反映了蓝方从攻击者角度，审视这些生产环境自用的外来代码时，最大的安全风险担忧。但是这样的选择也有弊端：选取的目标较为重型，往往受到更多关注和审计，植入代码问题较难实现隐藏；攻击思路与载体功能强相关，没能实现我们预判中，软件供应链上攻击的“顾左右而言他”的攻击移动效果。
• 从恶意代码形成的预期行为来看，多数题目选择了具有以小博大、持久化的思路，即植入的代码在正常的应用处理外部数据逻辑分支之余添加旁路，从而实现对恶意用户数据的解析和代码执行，这满足了攻击影响最大化、降低代码突兀度以规避检查的目的；其余题目则主要选取了保守的敏感数据（包括应用本身吞吐的待处理数据，和系统或外部应用的无关数据）窃取外传，以及释放webshell这两种思路。
• 从恶意代码本身的实现形式来看，存在部分题目充分利用了Java灵活的语言特性以及载体本身的功能与特殊性，巧妙地构造、实现攻击行为，实现了少量0解题率的经典题目，具有漏洞一般的隐蔽性。这部分出于对题目攻击性的传播控制不做举例说明。

 

本次比赛，参与的解题队同样迎来了一定程度的锐减。最终总参与外部队伍数量为5支，根据赛后排名，北大库博作为在源代码扫描深耕细作具有代表性的队伍，本次依然毫无疑问获得了第一名，但各支队伍的提交和分数具有很强的特征，反映出了一定的差异性和后续合作可能。最终排名如下：

队伍排名	队伍昵称	队伍分数	正确题目数量
1	Sebot	112	84
2	SecID	81	29
3	holiday	76	62
4	G15	50	40
5	雷芒	35	35

全程参与了所有分站赛的SecID队伍，以几乎全部精力押在进阶题目部分，从而实现较大收益，总分81分位居第二名；但从提交历史来看，这样的策略不可避免地涉及较大比例的人工分析投入。而其余队伍则基本全部优先批量处理常规题目、稳扎稳打，其中Sebot战队具有代表性，利用自研工具和规则沉淀，对常规题目部分实现了极高的解题率。以下就以他们提供的赛后writeup，对这种利用到极致的自动化分析思路进行剖析。

典型源码扫描解题思路

解题思路，主要分成三部分：

• 第一部分，反编译并建立解析模型。
• 第二部分，根据解析模型，进行检测分析，并给出可能性优先级。在此部分，采用了三种假设，并对应三种策略，1）假设反编译并解析全部正确2）假设反编译部分正确3）假设不能反编译。由此，对三种情况都做了相应的检测器，即：基于AST的Checker,基于字符串的Checker以及基于class的Checker以防止出现PE比赛无法反汇编成功的情况。
• 第三部分，结果自动合并技术，针对两类检测针对某一项目的检测结果，进行打分评估，并给出优先级评价。

本次测试赛总得分为112分，纯自动化无人工参与的得分是85分，总用时12分钟。以下简单介绍一下，每一部分的解题思路。

反编译

由于目标题目为已编译jar形式，而现有的分析手段更多集中在java源码上，首先需要对目标题目自动化反编译。由于反编译存在失败的情况，选取了三个反编译软件对jar包进行反编译，并以函数为单位产生AST, 将获取到的三种反编译结果进行自动结果整合，在整合过程中计算解析失败的Binding个数，并选取失效最少的解析程序，以尽可能减少由于反编译失败导致的自动化提取问题。

检测器

对反编译后的java源码格式以函数为单位进行分析，可以通过简单的结构独立性分析先将可疑的目标代码段从工程中提取出来。之后根据目标库函数（文件读写，网络流，字符串拼接操作等），目标字符串(ip地址，网址，shell指令，需要转码的长乱码，etc/passwd等危险路径)等信息，对提取出的代码段进行正确性判定并排序。对于反编译可能导致独立性缺失的问题，另外设计了纯文本对恶意字符串匹配并打分的方式增加容错。

对于进阶题，整理了部分可能触发恶意行为的模式。首先对可疑的库函数，字符串等在全工程中搜索，对所有函数为单位进行纯字符串形式的初步打分并初筛。对初筛后的结果，通过抽象语法树，控制流图，数据流分析等分析手段，分析可疑变量的影响范围，进行语义结构上的打分。综合两次得分将找到的结果进行排序。

结果自动合成

对AST和字符串匹配两类检测器的结果，进行优先级排序，也就是每个Jar给出了1-10个优先级的结果，如果两个检测器同时认为是第一名，那么人工基本不再去做确认，如果不是，设定阈值15分，第一是10分，第二是9分，以此类推，最终累加两个检测器针对同一答案的总得分。低于15分的需要人工确认。

 

至此，我们已经完成了软件供应链安全大赛全部三个赛季、六轮分站赛，在此作一简单回顾：

• 系统环境与底层软件基础设施-C赛季，5月12日-6月30日，《上篇》，《下篇》
• 办公环境与开发运维终端软件-PE赛季，7月7日-8月18日，《上篇》，《下篇》；
• 线上环境与服务应用软件生态-Java赛季，8月25日-9月30日，《本章》。

在整个分站赛阶段中，感谢内外部的支持，同时我们也在和所有蓝军、红军的思路创意一起成长，截止到目前，正是一个回过头梳理深化的阶段。在此之后，就将迎来我们的百万奖金决赛阶段。希望能够获得大家的关注和帮助，对结果我们也共同期待。