近年来,随着现代车辆技术的快速发展,网联汽车的攻击面(Attack Surface)和车载网络结构(In-Vehicle Network)都变得更加复杂。目前,已出台多项网联汽车信息安全标准,包括WP29 R155e、ISO 21434以及一系列国标,但这些刚出台标准与法规仍处于起步阶段,需要在摸索实践中直面各种挑战并不断完善。在这样的背景下,我们展开了如下的研究来重新审视现在的网联汽车信息安全:
该研究由科恩实验室和香港理工大学罗夏朴教授团队及香港大学钱晨雄教授联合完成,且相关论文《Revisiting Automotive Attack Surfaces: a Practitioners’ Perspective》[1]已被安全领域四大顶会中的IEEE S&P 2024录用。
关于IEEE S&P会议。
IEEE S&P会议,全称IEEE Symposium on Security and Privacy,别名Oakland,是安全领域最具影响力的顶级学术会议之一。其常与USENIX Security, CCS, NDSS并称为安全领域的四大顶会。特别地,S&P由于其极高的录取要求和极低的论文录用率(常年低于15%),被公认为是安全领域含金量最高的会议。
我们一共邀请了以下15位来自不同企业,处于不同职位的网联汽车信息安全专家参加访谈:
在访谈过程,研究人员与受访者开放性地深入探讨了:
具体来说,我们通过质性分析的方法,将结果总结成了20个Key Points(详见Code and Supplementary Materials[2]),同时提出用一种结构化的方法来描述现有的网联汽车安全威胁,并基于访谈收集的数据建立了一套新的威胁数据库:
新的威胁数据库包含了所有现有法规和标准中的威胁案例,以及所有从访谈研究中补充的案例。该数据库一共包含有119条具体的威胁案例,而这些案例层次化地分布在一共28个Code和7个Theme下。每一威胁案例都从Attack Description (AD), Root Cause (RC), Security Testing Approach (STA), 以及Mitigation (MG)几个方面具体展开。与现在法规中的案例相比(比如WP29 R155e的附录),我们提出的新威胁案例库[2]从数量和质量上都有十分显著的提升。
以下是以车机安全(In-Vehicle Infotainment)为例的部分内容:
我们的访谈研究除了发现现有威胁案例的不足之外,还发现TARA流程往往是低效的,缺乏自动化的方法。相应的,我们提出了名为CarVal的基于Datalog的自动化的车载网络攻击路径推理方法:
CarVal将基于已有的威胁数据库(Vulnerability Set)以及车辆信息(Vehicle Configuration),并根据用户输入的攻击目标(Attack Goal)和攻击入口(Attack Entry),用Datalog的推理方法来自动化推理可能得攻击路径。此外,CarVal还将自动化地计算每条攻击路径的威胁值,实现自动化的威胁评估。
应用举例:下图一条由CarVal推理出的具体攻击路径,描述了攻击者能如何从IVI的Wi-Fi接口控制IVI,并进一步在车内网络的infoCAN上广播恶意消息。
CarVal基于IT网络的威胁推理工具MulVAL[3]开发。
基于CarVal的自动推理方法,我们在多辆实车上进行了深入的安全分析,并发现了众多高危漏洞。以下将以其中一辆车为例展示分析流程。下图为该车辆的车内网络拓扑:
基于车辆拓扑信息,CarVal可自动化推理出从TCU到BCM的攻击路径:
通过对App远程车控逻辑的逆向分析,我们还原出了其中BLE车控的具体逻辑,并发现其中存在潜在的密钥泄露问题。攻击者可通过窃取的密钥,执行重放攻击来实现车控:
负责任的披露流程。所有实车上发现的漏洞都已经详细报告给相关人员且得到了合理修复。关于更多的实车分析流程,见论文原文[1]。
现代车辆的复杂性以及网络安全威胁的不断演变为整个行业带来了持续的挑战,而为了促进网络安全文化并完善现有的标准和规定,汽车行业、监管机构和研究者都需要持续付出努力。
感谢所有参加访谈研究的专家,为本次研究中提出了大量高价值观点与建议。我们期望我们改进的威胁数据库和提出的自动化推理方法能助力规定完善,使TARA流程更加高效!
[1] Paper link: https://www.computer.org/csdl/proceedings-article/sp/2024/313000a080/1RjEaOV6EQE
[2] Code and Supplementary Materials: https://github.com/VehicleCyberSec/CarVal
[3]MulVAL:GitHub - risksense/mulval: A logic-based enterprise network security analyzer
Black Hat 2018议题解读|穿云拨雾:对特斯拉汽车网关、车身控制模块以及辅助驾驶(Autopilot)ECU的渗透测试
腾讯安全科恩实验室发布特斯拉Autopilot实验性安全研究成果
腾讯安全科恩实验室发布雷克萨斯汽车安全研究综述报告
在Tesla Model S上实现Wi-Fi协议栈漏洞的利用
腾讯安全科恩实验室:梅赛德斯-奔驰汽车信息安全研究综述报告
科恩实验室最新自动驾驶安全研究成果发布于安全顶会USENIX Security 2021-以人造扰动欺骗车道线检测系统
科恩嵌入式系统安全审计平台入选”2021工业信息安全优秀应用案例”!
科恩实验室自研二进制安全智能分析平台- BinaryAI技术分享:全新功能“二进制比对”的设计与实现。本文介绍了BinaryAI如何在大模型 BAI-2.0基础上叠加启发式算法,以函数粒度的语义匹配提高了复杂场景下二进制比对准确率及召回率。
体验地址:https://www.binaryai.cn
科恩实验室在2021年8月首次发布二进制安全智能分析平台—BinaryAI,BinaryAI可精准高效识别二进制文件的第三方组件及其版本号,旨在推动SCA(Software Composition Analysis,软件成分分析)技术在DevSecOps、威胁情报、安全研究等应用场景发展。
二进制可执行文件比对是计算机安全的经典问题,通过比对两个二进制文件的异同,即使源代码不可用,也能够进行程序版本变更分析及第三方组件识别等任务。但现有工具大多依赖于人工选定的特征,对函数语义理解不足,在跨版本或优化级别的复杂场景下识别效果不佳。
科恩实验室凝聚多年“AI+算法”研究成果经验,推出函数相似度匹配模型 BAI-2.0(BinaryAI全新代码匹配模型BAI-2.0上线, “大模型”时代的安全实践),并在此基础上叠加启发式算法,实现了BinaryAI最新的二进制文件比对功能,以函数粒度的语义匹配提高了复杂场景下二进制比对准确率及召回率。
该功能底层比对算法代码现已开源,欢迎复现:https://github.com/binaryai/bindiffmatch
平台比对功能体验传送门:https://www.binaryai.cn/
(1)比较新老版本软件功能变更
软件迭代代码变更有限,在面对新老版本时,可以迅速识别并排除相似的部分,从而集中精力在变更的函数上。
(2)识别组件库的使用情况及风险
分析大型程序时,处理集成的开源组件代码需要花费大量精力。手动构建带有符号信息的开源库程序,并借助二进制文件比对技术匹配函数以完成符号标注,可以快速理解程序的局部逻辑,形成对程序整体结构的认识,有助于进一步分析核心逻辑和组件可能引入的安全缺陷、许可证问题等。
(3)鉴定软件抄袭侵权
在无法获得源代码的场景下,通过二进制文件比对也可以判断待测程序是否与已知程序雷同,可以用于版权调查或者剽窃抄袭判定。
(4)分析恶意软件变体
同一家族的恶意软件在实现上会有一定的共同特征。通过二进制文件比对可以将相似的样本归类,有利于找到具有类似行为的恶意软件变体。
目前工业界和学术界有大量针对二进制比对任务的工具及研究,几个有代表性的工作如下:
BinDiff[1]是zynamics团队开发的产品,可以和IDA、Ghidra、Binary Ninja工具结合使用,对两个二进制文件执行细粒度的比对。BinDiff采用的是基于图结构(控制流图和调用图)的匹配以及若干启发式特征匹配技术。截至目前,BinDiff的最新版本为2021年发布的7.0版本,其特征导出模块BinExport已经开源。
Diaphora[2]是一款流行的开源二进制比对工具,目前仍在积极维护中,最新版本为上月发布的3.0版本。其分析过程分为两个阶段,第一阶段:作为IDA Script运行,导出文件和函数的各种特征存入数据库;第二阶段:可以作为IDA Script运行或者离线运行,在导出的特征上运行各种策略(heuristics),最终生成完全匹配、部分匹配、无法匹配的函数列表。匹配结果导入IDA后,能够以函数、伪代码、汇编、调用图等多种粒度展示。
Diaphora的核心能力在于其策略,这些策略大多是基于人为选定的特征,用于判断单个函数的匹配性,例如”Same KOKA hash and constants”、”Same nodes, edges and strongly connected components”等。此外,Diaphora还包含少量实验性质的文件级别特征,例如“Call address sequence”等。
这是发表于2020年的论文[3],特点是可以在整个二进制文件上执行基本块级别的比对。作者应用了机器学习自然语言处理技术,结合汇编指令和控制流图结构为每个基本块生成一个embedding向量,然后结合图结构,通过迭代寻找匹配的基本块。相比于先前的同类工作,DEEPBINDIFF取得了较大的效果提升,但缺点是它受编译条件影响较大,对于基本块和控制流结构敏感,对跨架构支持不足。
对以上工具/研究及BinaryAI最新比对算法进行简单的对比:
总的来说,目前现有的二进制比对工具/研究存在以下共性问题:
1.很大程度上依赖特征工程,这意味着人工介入较多。
2.在信息提取和嵌入方面主要关注汇编指令或控制流等低层次特征,对函数的语义逻辑体现不足。当架构、优化级别、版本相差过大时,将难以保证匹配效果。
两个二进制函数是否匹配,应当以它们的逻辑是否相同来定义。然而,现有的很多工具主要基于传统特征工程来判断函数的相似度,例如基本块、指令序列、字符串等低层次语义特征或者控制流图等函数内的结构特征。这些方法在分析局部代码微小修改方面较为有效,但涉及到不同编译器、优化选项、指令架构等情况时,即使是同一份源码,低层次特征也可能存在巨大差异,从而导致难以准确匹配。此外,当匹配范围从单一函数扩展到整个二进制文件时,函数内部的细节特征对全局的直接影响较小,而函数自身的相似性以及函数间的关系等宏观特征变得更为重要。
基于上述分析,科恩实验室将函数作为匹配的最小单元,以函数的语义相似度作为基础,同时结合函数间的关系,实现了BinaryAI的二进制文件比对功能。
判定两个函数是否匹配,可以从语法形态和语义逻辑两个角度考虑。基于语法形态进行判定简单直接,例如只有当两个函数具有相同的语句序列或控制流图时才会判定为匹配,虽然此类特征容易提取,但是由于编译过程对语法结构进行了大量变换,只有很少的情况能够保证两个函数的语法形态特征完全匹配;
基于语义逻辑进行判定则更接近本质,只要两个函数的功能一致就认定为匹配。在实际应用中,基于语义逻辑匹配具有更高的应用价值,但是语义逻辑等价本身是一个不可判定问题。
常见的二进制比对工具(例如Diaphora)通常是预先提取若干人工选定的函数特征(例如某些特殊的指令序列),然后运行一些启发式策略判定函数是否匹配。这些策略大都基于一个假设:两个函数如果具有足够的可匹配语法形态特征,那么它们的语义逻辑应该也是一致的。然而,编译过程的不确定性会导致相同的语义逻辑有无数种可能的语法形态,这个假设很多时候是无法成立的,因此此类工具在复杂条件下进行语义匹配的表现并不理想。
但是,基于AI大模型,我们可以绕开这层假设,直接将函数的语义是否相似作为原始信息提供给模型做训练。依靠大模型强大的内在特征提取能力,经过学习后模型产生的输出就能够直接蕴含函数的语义信息。具体应用到比对任务时,两个输出的embedding向量之间的距离即可反映函数的语义相似性。
BinaryAI后台有持续更新的海量C/C++开源项目数据作为语料,在此基础上训练得到的BAI-2.0大模型生成的embedding向量能够很好地体现函数在真实场景下的语义,为BinaryAI二进制文件比对功能提供了基础能力。
一个二进制文件可以看作多个函数的集合,文件匹配的目标是找出两个二进制文件中所有能够匹配的函数对。
在人工做函数匹配的过程中,通常需要在反编译器中打开两个文件,寻找具有明显特征的函数(例如带有特殊的字符串),如果它们的伪代码相似度也非常高,就先把它们标记为初始匹配。然后,从已经标记的函数开始,观察它们调用或被其他函数调用的情况,可以认为这些函数也是大概率匹配的。最后,剩余的函数需要依靠人工判断,是一个比较困难的任务。
整个过程结合了函数自身的相似性以及函数之间的关联关系。由于人工判断函数的相似性是一个比较困难的任务,所以第一阶段能找到的初始匹配往往很少或存在错误,这会阻碍第二阶段利用函数关系找到更多扩散匹配,并进一步导致第三阶段剩余更多难以判断的函数。
BinaryAI的二进制文件比对功能在流程上与人工匹配的过程相似,同样分为初始匹配、扩散匹配、剩余匹配三个阶段。
依靠BAI-2.0模型的embedding能力,我们可以为每个二进制函数生成一个向量作为函数特征的表征,通过直接使用两个向量间的余弦相似度即可判断两个函数之间的相似性。
在初始匹配阶段,需要保证高准确性的前提下尽可能找出更多的匹配函数。然而,简单的贪心策略容易出现重复选取和漏选的情况。因此,我们采用全局视角,将其转换为完全二分图的最大匹配问题。完全二分图的两组节点分别为两个文件的所有函数,边的权值为两个函数的向量余弦相似度。这可以确保匹配结果中不存在重复的函数,并且让相似度不是最高的函数也有机会被选中。
获得完全二分图的最大匹配之后,需要进行进一步的筛选。其中,筛选条件之一是两个函数必须都是有效函数,导入表、导出表、Thunk等包装函数以及过于简短的普通函数都被视为无效函数。筛选条件之二是相似度大于阈值。此阈值应设定为较高的值,以确保第二阶段的需要。筛选需要放在最后进行,这样二分图匹配才能具有一个文件的全局视角。
第一阶段只利用了函数自身的相似性找到置信度最高的匹配。第二阶段则利用一个文件内函数间的关系,继续扩展第一阶段的匹配结果集合。
一个二进制文件由多个函数组成,函数虚拟地址的排布顺序构成了位置关系, 函数之间的相互调用构成了调用关系。这两种关系在二进制文件比对中有重要作用。
调用关系的作用基于一个假设:如果两个函数逻辑相同,那么它们往往具有相近的数据流和控制流,甚至源代码实现可能也比较接近,它们各自调用的其他函数也大致相同。位置关系的作用基于一个现象:一个源代码文件作为一个独立的构建单元,其中的函数在二进制文件中通常会聚集并保持顺序。
实际情况下,位置关系的作用是否成立非常依赖于编译器的具体行为,例如,如果开启了链接时优化,编译器可以对函数做全局重排;同时,函数内联或者隐式生成的函数都会打破位置关系的假设等;这使得位置关系在跨编译器等更广泛的二进制比对场景中更难被利用。相比之下,调用关系主要基于函数逻辑假设,且二进制比对场景的两个输入文件通常会有相关性,因此调用关系相比位置关系更加稳定,适用范围更广。
所以,本阶段主要基于函数间的调用关系:以第一阶段的结果为中心,对每一对匹配的函数,找到它们各自在函数调用图上邻近的节点,在这两组节点中寻找最大二分图匹配,过滤掉相似度过低或无效的函数作为新的一轮结果。然后,以上一轮的匹配结果为新的中心,重复此过程,继续沿着调用图继续扩散寻找新的匹配节点,直到无法找到更多匹配为止。
在前两阶段完成之后,第三阶段将在剩余的未匹配函数上再次进行二分图最大匹配。由于剩余函数集合规模远小于全集,因此可以应用比第一阶段更宽松的相似度阈值进行过滤,这一阶段作为对前两阶段的补充,旨在提高整体的召回率。
下图是三个阶段的简单示例:假设两个文件各有三个函数,初始时两两之间的相似度分数已知。
统计评测数据集:选用DEEPBINDIFF论文的数据集[3],即coreutils、findutils、diffutils三个library,每个library分别在若干个不同版本、每个版本在不同的优化级别下编译,并去除符号表;然后,按照”相同library+不同版本+相同优化级别”和“相同library+相同版本+不同优化级别”分为两组,每组对同名的二进制文件做比对。
样例评测数据集:选用openssl库作为样例,分别选择1.1.1u版本以O0优化级别编译为arm架构、3.1.1版本以O3优化级别编译为x64架构,并去除符号表,将产出的openssl可执行文件做比对。openssl作为最成熟的加密算法库之一在各类项目中被广泛应用,而且不同环境下使用的版本、编译选项、指令集架构等有显著差异,这为二进制文件比对任务带来了更大的挑战。
本文将以下三类函数定义为无效函数:
(1) 无法被Ghidra正常反编译的函数(即使出现在函数表中)
(2) Thunk函数(无实际功能,只转移控制流到另一个函数)或者指向导入表的外部函数
(3) 反编译后伪代码行数小于等于7行的小函数(因为这些函数通常不会引起人们的过多关注,且它们包含的特征往往不足以做出有效的区分)
对于先前构造的groundtruth中的匹配,只有两个函数都是有效函数时才计入groundtruth_matches集合,作为后续统计的总量。
对于待测工具输出的匹配,如果两个函数都是有效函数且属于groundtruth_matches集合,则是正确的匹配,记为correct_matches集合;如果两个函数都是有效函数但不属于groundtruth_matches集合,则视为明确错误的匹配,记为wrong_matches集合;如果任何一个函数属于无效函数,则忽略此匹配结果,不计入正确或错误的统计。
基于上述定义,评测采用三个数值指标:precision、recall、F1
precision:准确率
recall:召回率
F1:precison和recall的调和平均
当某个库选入测试集后,首先对源代码修改编译选项以在构建产物中保留符号表,然后正常运行构建流程,得到原始的构建产物;然后对二进制文件进行符号剥离,得到对应的无符号二进制文件;下一步,将剥离前后的两个文件分别传入Ghidra反编译器,导出各自的函数列表文档;最后,从有符号二进制文件的文档中提取函数名,补充到无符号二进制文件的文档中。
后续进行任何比对都只在剥离符号的文件中进行,使实验更贴近真实场景,且避免比对工具利用函数名做辅助判断。做不同文件比对时,只要函数名称相同就标注为匹配。因为函数名通常是对函数功能的概述,相同名称的函数即使源代码不同,语义逻辑大概率也是相近的。
使用IDA Script加载Diaphora,评测时只额外开启relaxed_ratio选项,其他保持预设的默认值。因为比对任务的目标是找出匹配的函数,因此函数自身的微小改动不会被当做首要关注点。
构建过程分为三步。
1、使用IDA headless mode加载Diaphora script导出其特征sqlite文件;
2、使用离线Diaphora script对两个sqlite生成Diaphora匹配结果文件;
3、将结果文件转换为统一格式;
本文的测试数据使用IDA7.5+Diaphora3.0生成。
需要额外调用BAI-2.0模型为每个函数生成embedding向量,BinaryAI开源仓库 中已包含此数据。
(1) 统计评测:coreutils、findutils、diffutils,cross-version和cross-optimization-level汇总(去除符号)
(2) 样例评测[4],openssl-1.1.1u-gcc_arm_O0-openssl.strip和openssl-3.1.1-gcc_x64_O3-openssl.strip (去除符号)
下图分别是Diaphora和BinaryAI对这两个文件的部分匹配结果(注:为便于直观判定匹配的准确性,图示结果使用了保留符号的二进制文件,并在Diaphora的配置中选中”Ignore all function names”、”Relaxed calculations of different ratios”以及”Use slow heuristics”),可以看出Diaphora的匹配结果中函数名存在不一致的问题,即产生了误报。
通过两组评测可以总结出,以大模型BAI-2.0 embedding为基础能力的BinaryAI表现较稳定,优于Diaphora。
二进制文件比对在实际场景下具有重要的应用价值。现有工具无论是基于传统的启发式特征工程还是汇编语句级别的机器学习模型,在识别的准确率、召回率方面都尚未达到理想的状态。
科恩实验室多年来旨在实现各类技术的纵深融合,BinaryAI作为科恩将AI赋能安全的应用实践,本次依托自研BAI-2.0大模型,着重于语义匹配,实现了二进制文件比对更为优秀的解决方案。在处理跨架构、版本、优化级别等复杂场景下,能够取得更好的评测效果。
目前,BinaryAI的二进制比对功能已经全面发布。欢迎各位前往 https://binaryai.cn/选择“自定义比对功能“开启体验。此外,如有复现评测结果需求,请前往BinaryAI官方仓库https://github.com/binaryai/bindiffmatch获取相关资源。
BinaryAI的算法引擎核心能力已同步落地应用于腾讯安全多款产品,包括:
微信扫码或搜索并添加“keenlab”为好友
发送“BinaryAI交流群”获得入群链接
[1] BinDiff:https://www.zynamics.com/bindiff.html
[2] Diaphora:https://github.com/joxeankoret/diaphora
[3] DEEPBINDIFF:https://github.com/yueduan/DeepBinDiff
[4] BinaryAI示例文件
科恩自研二进制安全智能分析平台—BinaryAI带来重要功能更新:发布全新代码匹配模型BAI-2.0、准确率提升、数据集拓展及用户体验优化。体验地址:https://www.binaryai.net
科恩实验室在2021年8月首次发布二进制安全智能分析平台—BinaryAI,BinaryAI可精准高效识别二进制文件的第三方组件及其版本号,旨在推动SCA(Software Composition Analysis,软件成分分析)技术在DevSecOps、威胁情报、安全研究等应用场景发展。
BinaryAI本次发布产品重要更新,配备创新的算法模型和持续扩展的后台数据。科恩代码匹配模型BAI-2.0和配套算法引擎彻底革新了SCA的表现,配合业界领先的数据集和种种精彩新功能,BinaryAI实现了分析准确性及效率的大幅提升。
BinaryAI对上传文件进行自动化解包、解析后,基于自研SCA算法和后台GitHub全量C/C++库的开源组件数据集,对其进行软件成分分析、函数相似性检索,以业界领先的识别准确率匹配到文件所使用的开源组件,辅助用户完成软件成分分析和恶意软件分析的安全分析工作。BinaryAI算法引擎背后是各种AI算法和经典算法,其中核心的代码匹配模型在行业内具备显著优势。
科恩实验室持续深耕智能软件安全分析研究,联合多所高校和科研院所,在信息安全、软件工程和人工智能领域的多个顶级会议上发表十余篇文章。基于科恩智能软件安全分析的研究沉淀,BinaryAI不断提升其准确分析能力。
科恩代码匹配模型上线BAI-2.0,顺应了AI模型开发领域向大模型演进的趋势。大模型的出现不仅促进了技术的迭代,还衍生出一批备受关注的大模型应用,如AIGC图像生成应用、ChatGPT工具等。作为领域内的先行者,科恩通过在软件成分分析领域落地应用大模型,适配了该领域的细分场景,提升了BinaryAI的召回效果。
BinaryAI基于科恩自研的代码匹配模型BAI-2.0和复杂图的程序分析算法,对可执行文件中的二进制函数使用图算法分析,同时与AI算法相辅相成,在GitHub全量C/C++库中找到匹配的源代码函数。经过多次迭代,BinaryAI的算法引擎提升了算法的准确率,降低了误报,较上个版本更上一台阶。
BinaryAI已经支持全网主流开源C/C++语言项目,采集了数万代码仓库的百万级版本分支,累计百亿C/C++源代码文件特征数据,去重后包含亿级函数特征。数据能力和算法引擎使得BinaryAI的SCA能够准确定位二进制文件所使用的的开源项目的具体版本,满足查看软件成分清单的需求。数据集已经拓宽对其他开发语言的支持,共计三百多万个代码仓库,未来将支持BinaryAI在其他开发语言、应用场景发挥其成分分析能力。
BinaryAI功能更新布告|构建全量开源项目数据集
为改善过去BinaryAI提供的插件在客户端上网络请求结果慢、交互体验不佳的问题,BinaryAI在网页平台上新增“BinaryAI函数相似性检索”导出能力,用户可以在平台上传二进制文件并浏览分析结果后,下载结果导入到IDA或Ghidra等二进制分析软件中,继续安全分析工作,这一优化将大幅提升深度分析二进制文件场景的用户体验。
此外,平台增加科恩自研腾讯云二进制软件成分分析产品—BSCA的跳转入口,用户可一键跳转体验漏洞扫描、License审计等特有功能,适用于DevSecOps 制品扫描、软件上线前安全风险识别、检查上下游供应链安全问题等应用场景。
点击“BinaryAI函数相似性检索”,即可下载结果Json文件,获得插件的GitHub下载链接。
典型文件示例:
软件成分分析和函数识别:示例1、示例2
威胁情报(C2样本检测):示例3
威胁情报(挖矿样本检测):示例4
BinaryAI的算法引擎核心能力已同步落地应用于腾讯安全多款产品:
除此之外,科恩实验室始终以积极的姿态探索软件安全领域和前沿AI结合的科研落地,推动成果转化以解决产业痛点问题。
微信扫码或搜索并添加“keenlab”为好友,发送“BinaryAI交流群”获得入群链接
[1]腾讯安全科恩实验室推出首款免费在线SCA平台:BinaryAI
[2]科恩实验室最新NeurIPS-2020论文解读:基于跨模态检索的二进制代码-源代码匹配
[3]AAAI-20论文解读:基于图神经网络的二进制代码分析
为提升静态分析在二进制文件漏洞检测领域效率和可扩展性,科恩孵化并开源二进制文件静态漏洞分析工具BinAbsInspector项目。代码仓库地址:https://github.com/KeenSecurityLab/BinAbsInspector
随着信息产业的发展,网络安全问题日益严峻,软件漏洞对于互联网威胁极大,是网络安全中的核心问题。为了缓解漏洞所造成的危害,需要对软件进行安全检测,尽可能地发现并消除潜在漏洞。目前常见的自动化漏洞检测手段可以分为两类:动态分析测试和静态分析。
动态分析测试方法(如fuzzing等)在过去五年里吸引了研究者的广泛关注,相关系统在工业界中已经得到了大规模的部署和应用。相比于动态方法,静态分析通常具有更高的覆盖率,然而,现阶段对于静态分析的使用多依赖于人工经验规则,且精度和效率之间尚未找到一个合适的平衡点,这导致其在现实场景中的落地不尽如人意。
目前国际上较为成功的商业化分析工具有 Coverity[1] 、 CodeSonar[2] 、 VeraCode[3] 等,它们在代码质量保障上发挥了重要作用,相关产品也在Google等公司的DevOps流程中得到了广泛部署和使用。
包括开源及商业化产品在内,现有的静态分析方案多为源码级分析。面向源代码进行扫描,尽管可以在一定程度上满足软件安全需要,然而在真实安全场景中,待分析对象多为二进制文件,如嵌入式系统固件,商业软件等,研究人员难以获得相应的源代码,此时源码级静态分析方案不再适用。
值得一提的是,部分商业化产品(如CodeSonar等)也提供了对于二进制文件的分析能力,然而商业化路线所带来的封闭性,在很大程度上限制了普通研究者的使用和二次开发。与此同时,在开源社区中也涌现出一批知名的二进制分析工具,如 angr[4] 、 BAP[5] 、 cwe_checker[6] 。其中,angr和BAP逐渐往通用分析框架发展,并非专注于二进制漏洞扫描,因此其内部的分析算法较为庞杂,不利于进一步扩展和优化;cwe_checker的定位相对清晰,专注于安全漏洞扫描,但其精度和效率却不甚理想。目前业界亟需一种更为先进的二进制漏洞扫描工具,在开源的大前提下,其性能和可扩展性也要满足真实场景的需要。为此,科恩实验室基于自身在二进制领域丰富的研究与实践经验,同时结合业内相关优秀工具的设计理念,最终孵化出性能出色且自主可控的二进制漏洞静态扫描工具—BinAbsInspector。
BinAbsInspector的设计思想来源于上世纪70年代诞生的经典程序分析理论“抽象解释”,在具体实现上,BinAbsInspector的分析基于Ghidra[7]所提供的中间表示Pcode上。通过设计合适的抽象域,实现其上的多种运算,完成相关Pcode的操作语义,执行流敏感(flow-sensitive)和上下文敏感(context-sensitive)的过程间分析,同时加入静态污点分析的能力,完成对程序运行时状态的抽象估计。基于上述分析所得的抽象数据流信息对多种漏洞建模,最终实现对二进制漏洞的静态扫描。
对于程序的抽象方法,我们主要参考了经典论文《WYSINWYX: What you see is not what you eXecute》[8] 中的做法并加以改良、简化和提升。
具体来说,在BinAbsInspector中整个运行时环境被分为Local (抽象栈)、Heap(抽象堆)、Global(全局变量和数值)、Unique(对应Ghidra中产生的临时变量区)和Register(寄存器区)五种region。在这些不同的抽象区域上加上偏移数值offset,便可以组成一个抽象变量ALoc(Abstract Location/Variable)。因为在二进制程序中,变量并非全部显式表示,ALoc便是对实际程序中变量的一种估算和识别。
对应不同的程序点,需要记录此处可能存活的抽象变量和其对应的抽象值,称之为AbsEnv(Abstract Environment)。
因为是静态的抽象,那么对于一个程序点的一个抽象变量,它可能会包含多个抽象值,这些抽象值组成了一个集合。虽然这个集合可能会包含无穷多个元素,但是为了保证整个计算过程实践上可收敛,令此集合取一个上限K,这种集合称之为KSet。一旦其中包含的元素超过K,便将其变为一个Top,即包含所有抽象值。此方法与前人重要相关工作 Jakstab[9] 中的KSet较为相似。KSet支持多种算数和逻辑运算。此外每一个KSet对象也会包含一个污点的位图,用来跟踪多个污点的同时传播,从而实现静态污点分析。这样AbsEnv便可以认为是一个从ALoc到KSet的map。
由于BinAbsInspector的分析是上下文敏感的,对于被调用者的上下文 (Context),我们使用最近的call string(call site)来进行唯一标识。即对于同一个被调用者,不同的调用者会生成不同的Context,一般只记录最近的几个调用者。这样我们便把程序点处的AbsEnv记录在不同的Context中。
除此,对于过程内的不动点计算BinAbsInspector里使用了worklist算法,即把待处理的程序点不断地放入worklist中,直到其空为止。过程间分析主要在于不同的Context之间的转变,这是通过call/return指令的语义实现的。这样通过对整个程序指令的迭代计算值并加以Context的转换,Context及其附属的worklist得到逐一处理,直到所有的worklist计算结束,最后达到不动点。
通过这整个的计算过程,便会得到所有可能的Context以及对应的每个程序点的AbsEnv。这样相当于得到了一个对程序行为可靠的估算,有了这些抽象数据流的信息,我们便可以进行内存破坏漏洞、命令注入漏洞等多种漏洞的检测了。
下面我们通过一个包含Use-After-Free漏洞的简单样例来演示BinAbsInepector的运行情况和基本原理。
“CWE416_Use_After_Free__malloc_free_struct_01_bad”函数中首先调用“malloc”函数分配内存用于存放100个“twoIntsStruct”对象—>依次对这部分对象进行初始化操作—>直接释放内存—>释放内存过后再次调用了“printStructLine”函数访问已释放内存中的地址—>造成Use-After-Free漏洞。
1 | void CWE416_Use_After_Free__malloc_free_struct_01_bad() |
BinAbsInspector作为Ghidra Extension的形式进行开发,构建后安装在Ghidra中,支持GUI和Headless模式运行,用户也可以通过项目中提供的Dockerfile构建docker镜像体验功能,具体使用方法见 仓库README 。在此我们以GUI模式为例介绍使用步骤。
首先将BinAbsInspector安装在Ghidra,我们将编译好的样本程序(armv7)导入Ghidra,待Ghidra的分析完成,便可以运行我们的分析了。这时会弹出工具的分析选项框,将分析过程的配置参数暂时保持默认即可。
分析显示找到2处CWE告警,在下方命令行中会显示具体告警的地址。
标记1:触发告警的地址,即产生Use-After-Free访问的指令地址;
标记2:上下文调用记录,可以理解为函数的调用栈;
双击命令行中的告警地址可以在汇编窗口跳转到对应的指令,另外右边的反编译窗口也将同步展示对应的伪代码,可以看到两条告警的指令都位于“printStructLine” 函数的内部,都是访问已释放内存的LDR指令,结果符合预期。
原理上简而言之,在第6行“malloc”处创建了一个Heap region,data的抽象值为此Heap及偏移值0,这一信息被加入当前的AbsEnv中并继续向后传播,经过第17行的“free”,data的抽象值数值保持不变,其中的Heap region变成了一个相同数值但是为无效状态的新region,当前的AbsEnv也会同步更新这一变化并将这一改动向后传播,最后在19行“printStructLine”内部的LDR指令时,通过查询传播到此的AbsEnv,检测到data指向的是一个无效的Heap region,这样便可以查找出这个Use-After-Free的问题。
我们选取 Juliet[10] 这一较为权威的测试集,在x86、x64、armv7三个架构上进行测试,并与cwe_checker测试结果进行对照比较。 另外,BinAbsInspector也支持对aarch64架构样本的检测,这是cwe_checker目前不支持的。
下面表格展示的是在CWE415 (Double-Free), CWE416 (Use-After-Free),CWE476 (Null Poionter Deference), CWE78 (Command Injection) 4种核心漏洞检测能力与cwe_checker的对比结果。
结果表明,BinAbsInspector的测试结果在所支持的CWE类型上均取得较大幅度优势。
(BAI: BinAbsInspector, CC: cwe_checker, TP: True Positive正阳性, FP: False Positive假阳性, TN: True Negative正阴性, FN: False Negative假阴性)
科恩在二进制安全研究领域有着深厚积累,其中二进制软件成分分析平台 BinaryAI[11] 已免费开放,推动软件成分分析在DevSecOps、安全研究等场景的应用与发展。
在二进制静态分析方向,科恩孵化高效、准确的自动化二进制文件静态漏洞分析工具BinAbsInspector。经过内部应用实践及优化,BinAbsInspector已达到了较好的完成度。
BinAbsInspector未来将持续打磨算法及工程上的可提高之处,结合科恩二进制分析、算法等能力输出,赋能更多软件相关从业者,助力提升整体代码安全防治效率。关于更多的技术细节和代码实现,请移步我们的 开源仓库 。欢迎所有感兴趣的小伙伴一起参与协同开发,在实践中迭代优化,打造更优秀的二进制漏洞静态分析利器!
[1]https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html
[2]https://www.grammatech.com/products/source-code-analysis
[3]https://www.veracode.com/
[4]https://angr.io/
[5]https://github.com/BinaryAnalysisPlatform/bap/
[6]https://github.com/fkie-cad/cwe_checker/
[7]https://ghidra-sre.org/
[8]Gogul Balakrishnan and Thomas Reps. 2010.《 WYSINWYX: What you see is not what you eXecute.》 ACM Trans. Program. Lang. Syst. 32, 6, Article 23 (August 2010), 84 pages https://dl.acm.org/doi/pdf/10.1145/1749608.1749612
[9]http://www.jakstab.org/
[10]https://samate.nist.gov/SRD/testsuite.php
[11]https://www.binaryai.net/
2021年3月,由腾讯安全科恩实验室与国际二进制开源逆向工程框架Rizin联合举办的一场开源程序设计项目—Rizin Summer of Code 2021 正式开启报名申请。
报名申请回顾:RSoC-科恩编程之夏申请通道正式开启
7月初,RSoC最终参与者来到科恩实验室进行项目沟通规划,8月20日,在经过参与者们逐步项目推进后,RSoC落下帷幕。
参与RSoC的高校同学与Rizin核心成员Anton@akochkov以及科恩实验室研究员深度协作交流,以国际开源逆向工程框架Rizin为研究主体,在科恩实验室感受了别样的代码之夏。
Rizin是项类Unix的逆向工程框架和命令行工具集,是来自世界各地的优秀编程极客的思想结晶,由国际知名免费开源逆向工程框架Radare2提取分支而来。Rizin持有二进制文件分析,反汇编代码,调试程序…等等功能。
在这个暑假,我的项目内容是实现一个对IL相关的bug进行修复和重构,以及为Rizin实现一个基于位向量运算的中间语言支持。目是为了Rizin日后能在此基础上运用一些分析技术。通过这样次实践,我对开源项目的协作有了更深刻的体会,也拓展了我对这一领域的认识。于我而言,我借助这次rsoc接触到了不少与反编译相关的知识,这也是一个了解相关研究和技术实践的切入点。部分解决了我的一个疑惑:一个大型项目是如何组织和管理的。
科恩的氛围特别好,大家都对安全技术很有热情且大佬们很多,我在这里学到了不少东西。值得一提的是,科恩给我的感觉是一个很注意成员直接沟通的团队,大家能为了同一个目标去工作,在这样的团队里工作很愉快。
七月初,我怀着紧张又激动的心情,开始了科恩实习与RSoC 2021之旅。我在RSoC 2021中的主要任务是Type相关的工作。
在第一周,我与Anton合作修复了新的Type Parser中的一些bug,推进了项目的总体进程。之后,我相继完成了迁移Type Constraints、添加对Global variable的支持、重构PDB parser等工作。
在这一个多月的工作过程中,我感受到了社区成员间的良好氛围,社区成员都很乐于助人,有问必答,也许这就是开源社区的魅力,大家互帮互助,共同朝着一个美好的目标前进。同时,这一个多月我也是收获满满,不仅收获了相应的开发经验与能力,更锻炼了我适应环境的能力,还认识了一些志同道合的朋友。
在科恩实习期间,我感受到了科恩实验室的开放协作、朝气蓬勃的工作氛围,这里都是技术大牛,我也从中学到了不少实用的经验技巧。除此之外,科恩的格言“追求极致、主动担当”也激励着我不畏艰难,砥砺前进。祝愿RSoC可以长久的办下去,也祝愿Rizin和科恩实验室越来越好!
简历投递入口:腾讯招聘官网→ 实习生招聘/校园招聘
岗位类别:技术类→ 安全技术
意向事业群及部门:CSIG事业群→腾讯安全
注 请在自我评价处填写 “意向部门科恩实验室+你的意向岗位”
岗位参考:招聘推文
科恩期待与你探索安全技术更多可能~
]]>8月11日,腾讯安全科恩实验室正式发布在线软件成分分析平台——BinaryAI,第一次将软件成分分析(Software Composition Analysis,SCA)技术推广到日常安全研究。
伴随着开源软件的迅速成长,应用软件中使用开源代码的比重逐年持续增长。然而,开源代码中的安全问题也让软件市场面临软件供应链安全的挑战。
基于软件安全和人工智能领域的多年研究经验,科恩实验室积极布局软件成分分析方向,已落地并助力厂商修复软件安全问题,现在首次将SCA能力以平台型产品BinaryAI免费开放给用户,旨在推动软件成分分析在DevSecOps、安全研究等场景应用发展。
BinaryAI是二进制文件SCA的智能分析平台,自动化完成文件解析到输出分析结果全部使用环节,帮助研究人员高效实现SCA线上检查的需求。
开源代码安全问题不仅存在于源代码,在构建过程中也会引入问题,因此构建阶段的二进制产物有必要进行SCA分析。使用BinaryAI可以确认软件所使用的第三方组件及具体版本号,及时发现引入的问题第三方库,便于研发团队跟进修复。
用户可以打开BinaryAI官网,上传待分析文件获取SCA功能,现已支持200M以下常见CPU架构的可执行文件及包格式文件的检测。BinaryAI实现智能化文件解包或解析、软件成分分析等分析流程。
经过长期积累,BinaryAI后台具备10000余种第三方组件数据,内容覆盖组件基本信息、开源许可证使用情况等信息,能够全面提升软件成分分析的检测水平,并在持续不断扩大支持范围中。现在向用户开放的信息为组件的基本信息。
科恩实验室在近年发表了《Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection》、《CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source Code Matching》等论文,在传统安全研究中利用AI算法解决二进制程序函数相似性分析和二进制代码/源代码端到端匹配问题,奠定了软件成分分析的算法基础。BinaryAI通过科恩自研的SCA算法,可以实现组件以及版本号高准确率匹配。
基于上述能力,BinaryAI提供了网页版的使用途径。用户无需部署服务器,无需上传源代码文件,直接上传待分析的二进制文件,无需指定分析器,输出简洁、可读性高的报告,赋能用户开展安全分析。
访问BinaryAI 开始体验SCA技术吧!
填写使用反馈问卷,科恩将于8月18日抽取幸运儿送上腾讯视频季卡~优质反馈更有腾讯视频年卡赠送!
微信扫描二维码加入产品交流群或微信搜索添加“keenlab”为好友发送“BinaryAI交流群”获取入群链接。
微信搜索并关注腾讯安全科恩实验室官方公众号获得BinaryAI更多动态。
近年来,5G蜂窝网络被广泛应用。设备为了加入5G网络,都必须配备一个5G调制解调器,负责调制信号和执行无线电协议。该组件通常也被称为基带。这些组件非常重要,因为它们负责处理来自无线电网络的不可信数据。
在之前的工作中,科恩实验室研究了上一代网络(2G 3G 4G)的安全调制解调器,并实现了远程无接触的0-click代码执行。
本次Black Hat USA 2021,科恩实验室成员Marco与Xingyu Chen在北京时间8月5日凌晨以线上形式分享了议题《基带利用:远程5G智能手机代码执行》。该议题探讨了5G网络发生的变化以及安全性方面的改进,并证明了仍然有可能通过无线的方式攻击5G调制解调器完成远程代码执行。
议题完整白皮书下载见文末
Marco:
腾讯科恩实验室高级研究员,研究涉猎iOS、Safari、VMWare、基带等多个方向,多次作为核心成员参与Pwn2Own、Mobile Pwn2Own并获得冠军,多次在国际安全会议上进行演讲,包括Black Hat USA, DEF CON, CanSecWest, ZeroNights, Codegate, HITB and ShakaCon等。
Xingyu Chen:
腾讯科恩实验室安全研究员。主要研究虚拟化和移动安全,曾在不同的云产品和智能手机的低级固件中发现了许多关键漏洞。曾作为A*0*E联合战队选手参加多场CTF比赛,也是DEF CON 28 CTF 决赛总冠军队伍成员。多次在国内外安全会议上进行演讲,包括OffensiveCon、Zer0Con和Tensec等。
多年来,5G网络和基带的安全问题一直没有得到全面的讨论。我们之前的工作是研究老一代网络的安全性,并研究了市面上多款调制解调器的实现,安全研究员Amat Cama也发表了一项关于老一代网络的研究,展示了如何在pwn2own竞赛上成功地攻破三星Shannon基带。来自Comsecuris的研究分析了三星和英特尔基带的安全性。
建议读者将上述这些研究作为理解和熟悉本文的参考。我们也将对研究背景和5G网络的新概念进行简单描述。
我们购买了当时可用的几款5G智能手机,他们都支持5G中的“New Radio”。
5G设备区分:
经过一段时间的5G相关代码审计,我们发现了多处漏洞,在此我们选择了其中最稳定的一个来分享,希望您也会通过它对基带当前的安全状态有所认识。在审计调制解调器固件时,我们发现它仍然缺少Stack cookie保护。因此,考虑到在这种环境中缺乏调试功能,使用传统的栈溢出将使我们的利用更容易。
本文选择的bug是一个栈溢出。它不仅是栈溢出,而且是基带内部XML解析器中的栈溢出。此 XML解析器负责解析从网络到设备调制解调器的IMS消息。
IMS是4G和5G网络中的专用架构,常用的语音呼叫建立在其之上,稍后我们将看到为什么这对本研究很重要。基带是一个IMS客户端,负责处理VoLTE、VoNR消息,因此它必须能够处理SIP消息,IMS服务器使用这些消息与基带进行通信。
白皮书内查看INVITE消息示例
SIP 是一种基于文本的类似HTTP的协议,包括标头和内容。 接收方(在本文中为基带)需要解析来自服务器的消息。对于不同的消息,内容不仅可以是键值对,还可以是XML格式的文本。XML是一种复杂得多的数据格式,通常由专用库处理。 以上都为基带引入了一个新的攻击面。
我们的OTA RCE漏洞在基带的IMS模块。 在解析SIP协议消息的XML内容时,它会调用函数IMSPL_XmlGetNextTagName
。
由于我们的目标基带没有调试符号或信息,所以所有的函数名称、类型和函数签名,都是从日志字符串中提取,或是通过逆向工程手动恢复。
我们在这里提供了一个反编译版本,其中省略了一些代码。
1 | int IMSPL_XmlGetNextTagName(char *src, char *dst) { |
此函数将从src解析XML标记并将其名称复制到dst ,例如<meta name="viewport" content="width=device-width, initial-scale=1">
到目标缓冲区。接下来,我们展示反编译函数find_tag_end
(手动命名)并解释它是如何工作的:
1 | char **find_tag_end(char **result) { |
该函数通过跳过特殊字符来查找标签的结尾,例如空格、‘/’、‘>’、‘?’。在了解整个功能的工作原理后,我们注意到根本没有安全检查。该函数不知道目标缓冲区和源缓冲区有多长。 因此,该函数的所有调用者都可能被传统的缓冲区溢出所利用。通过交叉引用函数IMSPL_XmlGetNextTagName
,我们发现了数百个调用位置。
它们中的大多数都容易受到攻击,因为源缓冲区是从OTA 消息中获取的,完全由攻击者控制。
我们选择栈溢出是为了漏洞利用的便捷和可靠。正如我们之前所说,由于没有栈cookie,所以我们可以简单地溢出缓冲区,控制存储在栈上的返回地址,并获得代码执行。
我们终于通过逆向工程找到了一个很好的候选者:
1 | int IMSPL_XmlParser_ContactLstDecode(int *a1, int *a2) { |
我们可以很容易地确认变量v11是栈上大小为100的缓冲区。潜在的栈溢出可能发生在这里。 在临近的函数中也能发现类似的问题,例如IMSPL_XmlParser_RegLstDecode
,IMSPL_XmlParser_ContElemChildNodeDecode
。根据函数名,我们可以推断触发的标签应该在元素Contact List内。通过向上交叉引用函数来总结调用栈并不困难。
1 | IMSPL_XmlParser_RegInfoDecode --> IMSPL_XmlParser_RegInfoElemDecode --> IMSPL_XmlParser_RegLstDecode --> IMSPL_XmlParser_RegistrationElemDecode --> IMSPL_XmlParser_ContactLstDecode |
这些函数名称很容易理解。我们可以分辨出变异的payload可以通过SIP协议中的NOTIFY消息传递。 一个能让基带崩溃的简单PoC可以从普通的NOTIFY消息构造。
由于payload是以XML格式发送,因此对payload存在限制。
记得上面提到的find_tag_end函数,它会将标签名中的以下字符列入黑名单:"\x00\x09\x0a\x0d\x20\x2f\x3e\x3f"
。 因此,在编写ROP链和shellcode时我们不能使用所有可用的字符。除此之外,剩下的是ARM平台上的传统pwnable挑战。
白皮书内查看详细PoC
利用点为函数IMSPL_XmlParser_RegLstDecode
,为了避免在 ROP 执行后修复栈帧,并能让基带仍然正常工作,最好选择一个较深的地方来触发栈溢出。 所以registration中的一个元素标签是个不错的选择。
payload结构:
为了验证我们是否在目标设备上获得了RCE,我们可以检查手机的ADB日志。它将显示有关蜂窝处理器(CP)如何崩溃的信息。然而,这既不是一种方便的方式,也不是一种很好的视觉效果。因此,我们选择通过在基带内执行shellcode来修改设备的IMEI。按照设计,IMEI不应在手机分发后进行修改。当我们报告整个利用链时,这也被视为一个bug。NVRAM是Non Volatile Memory,用于存储与基带相关的持久化信息。IMEI是存储在基带NVRAM中的一项,但是要修改它的值,首先要知道它的索引。
白皮书内查看IMSSH_GetImei函数示例
基带中有多个地方调用函数获取IMEI。可以通过逆向函数GetImei来检索索引。在我们的例子中,IMEI1/2的索引分别是0x39a4/0x39a5
。有了索引,我们就可以通过在shellcode中调用API pal_RegItemWrite_File
来修改IMEI。
要触发这个 bug,我们需要先搭建一个提供 IMS 服务的网络,然后向基带发送格式错误的短信。 我们的测试环境至少需要一个LTE网络。 虽然它在技术上是一个影响4G和5G的漏洞,但在2020年初,5G的基础设施还没有成熟到足以支持像我们这样的独立研究人员测试其安全性。因此我们决定建立一个支持VoLTE的LTE网络来测试设备。
作为设置基站的首选硬件,我们选择了Ettus USRP B210,这是一种在研究人员中非常流行的SDR无线电设备。
我们使用了大量开源组件和硬件来完成我们的测试,以下是一些较为重要的:
UE能够在适当的LTE网络设置后连接到网络,然后我们可以继续进行IMS服务器设置。在我们的测试中,几乎所有不同厂商的基带对eNodeB的频率都非常敏感。您可以查看设备官方信息以获取其支持的频段,然后为srsENB选择合适的Downlink EARFCN参数。
由于该漏洞只能由提供VoIP服务的恶意IMS服务器触发,因此基本的LTE网络不足以触发该漏洞。不幸的是,满足这种需求的基础设施还远未成熟。现有的开源项目Kamailio满足了我们的需求,但还没有在各种设备(包括我们使用的)上进行很好的测试。 需要付出巨大的努力才能使其工作并成功发送有效payload。
VoLTE服务器的基本组件是Rtpengine、FHOSS、P-CSCF、I-CSCF和S-CSCF。 以下是网络拓扑:
1 | SUBNET=172.18.0.0/24 |
IMS(SIP)消息通过TCP或UDP套接字以IP数据的形式承载。因此,客户端会首先选择IPSec来进行消息传输。XML payload只能通过NOTIFY消息携带,因此我们的客户端必须成功REGISTER和SUBSCRIBE。
在进行初步的搭建后,一加6(non-IPSec)、Google Pixel 3(IPSec)可以成功注册VoLTE服务,这意味着我们的环境在高通的芯片上能够很好地工作。但是在使用三星芯片的手机上,整个流程会在注册时失败。
但是这些设备能够使用当地运营商的普通SIM卡注册VoLTE,这让我们对修改Kamailio配置和代码充满希望。 首先要做的是在电话上捕获成功的注册流量。 幸运的是,三星的Sysdump Utility中有一个内置的IMS调试工具IMS Logger,它允许我们查看来自应用程序的IMS流量。 下面是一个正常的注册消息及其响应:
Kamailio和本地运营商之间存在一些差异。 我们并不真正知道哪个字段是注册失败的关键。 我们方法是让它们看起来尽可能相似。
在对Kamailio进行了一些更改后,我们取得了一点进展,我们收到了第二条注册消息。 那么问题就到了服务器端,它并没有提供STATUS 200响应。
经过调查,我们发现服务器和客户端之间的IPSec不一致。 我们决定从服务器端强制禁用IPSec。以下是我们打的补丁:
VoLTE/IMS Debugging on Samsung Handsets using Sysdump & Samsung IMS Logger
Reverse Engineering Samsung Sysdump Utils to Unlock IMS Debug & TCPdump on Samsung Phones
一旦UE注册并订阅到SIP服务器,服务器将发送NOTIFY消息以提供网络中的基本信息,比如其他UE的联系方式等。而payload会以XML的格式存在于NOTIFY消息中。该消息的负责模块是S-CSCF。这是要修改以生成任意有效payload的函数:
1 | str generate_reginfo_full(udomain_t* _t, str* impu_list, int num_impus, str *explit_dereg_contact, int num_explit_dereg_contact, unsigned int reginfo_version); |
在这项研究中,我们展示了下一代Android设备配备的5G基带安全状态。尽管在网络功能方面已经发生了演变,但我们看到在安全性方面仍然没有过多进步。正如我们实际上已经展示的那样,一些基带缺乏最基本的安全措施,例如栈cookie保护,这让攻击者能够使用缓冲区溢出等简单攻击无线攻击它们。我们在三年前进行过安全研究,但是至今情况似乎没有太大改善。 我们希望在三年后我们可以再次展示一些研究,在一个更加严格的环境中。
]]>科恩实验室在2019年发布了对Telsa Autopilot的研究 [1],其中一项研究成果实现了对车道线系统的攻击。具体来说,我们在路面部署干扰信息后,可导致车辆经过时对车道线做出错误判断,致使车辆驶入反向车道。然而这种攻击依赖于人工调试,让攻击不够高效,不够自动化且不够隐蔽。
为完善该攻击方法,以及进一步测试现有车道线检测系统的安全性,我们基于黑盒测试和优化算法设计了一种自动化的攻击方法来找到人眼难以察觉,但却可以欺骗车道线检测系统的扰动。在实验阶段,这些扰动被布置在物理世界中,而处于自动驾驶状态的车辆成功被引入了逆向车道(如图.1所示)。
该研究由科恩实验室和香港理工大学罗夏朴教授团队及宾州州立大学王挺教授联合完成。
且相关论文: 《Too Good to Be Safe: Tricking Lane Detection in Autonomous Driving with Crafted Perturbations》发表于安全领域四大顶会中的USENIX Security 2021。
Presentation link: https://www.usenix.org/conference/usenixsecurity21/presentation/jing
预发布论文下载见文末。
USENIX Security会议是安全领域最具影响力的顶级学术会议之一,多年来的论文接受率均低于20%。其常与Oakland S&P, CCS, NDSS并称为安全领域的四大顶会。USENIX Security 2021会议将于2021年8月11日-13日在线上举行。
本次研究中Tesla 具体车型为Model S 75,其Autopilot硬件版本为2.5,软件版本为2018.6.1。基于对抗样本的思想,我们期望找到 1.人眼不容易发现,2.且可以欺骗系统的扰动。找到该种扰动的Two-stage攻击的框架如图.2所示:我们先基于黑盒测试和优化算法在数字图像层面找到最佳扰动 (Stage.1),然后再将该扰动布置到物理世界 (Stage.2)。
Stage.1: 找到digital层面的最佳扰动
首先,基于从Model S中提取的camera image(该图像后续将被用于车道线检测),我们以指定的参数对该图像加入形如车道线的扰动,然后将被篡改的图像送进车道线检测系统。同样,被篡改图像对应的lane image(车道线检测的结果)也将被从车内提取出来。基于1.加入扰动的可见度和2.被检测到的车道线强度,我们运用优化算法来找到1.最隐蔽,且2.有最好攻击效果的扰动。
Stage.2: 在物理世界布置扰动并检测攻击效果
在Stage.1中,加入扰动的参数是基于物理世界的坐标进行设计的(包括扰动的长宽,以及与车的相对坐标等)。因此,这些扰动能很方便地被布置在物理世界。在Stage.2,这些扰动被布置在车的前方。通过观察车道线检测的结果,以及自动驾驶系统是否对这些扰动进行相应,攻击的有效性得以证实。
具体来说,图.3展示了如何对这些扰动进行定义:我们采用一个多维向量来表征形似车道线的扰动,该向量中包括扰动的形状,相对车载摄像头的坐标,角度,数量等参数。一组扰动将由一组物理参数唯一决定,然后基于这些物理参数,通过摄像头的针眼模型和去畸变算法,这些扰动被加入到数字图像中并应用于后续的优化算法。
我们采用了一共5种启发式算法来寻找最优的扰动,这些算法的表现如图.4所示。其中PSO(粒子群算法)拥有最好的综合性能。
实验表明,在行驶过程中,检测模型的确将这些扰动视为真实的车道线,并且对其响应。具体来说,处于自动驾驶状态的车辆在十字路口被我们添加的扰动成功引入了逆向车道:
1.在十字路口场景下,车辆以自动驾驶模式在道路右侧行驶(此为正确的行驶方向):
2.在即将要通过十字路口时,车辆将地面上的扰动视为真实的车道线,并且随着这些扰动开始转弯:
3.通过十字路口时,车辆跟随被检测到的假车道线驶入逆向车道:
4.车辆保持在逆向车道上行驶:
该过程中,对应的逐帧图像如下视频所示:
本次发布的研究成果在Autopilot的2018.6.1版本上得到验证,研究团队未对Autopilot其他更高版本进行测试Tesla是否通过升级其模型来防范该攻击。但无论何种情况,为保证安全,建议即使在Autopilot辅助驾驶开启的情况下,车主也应该全神贯注于驾驶,且随时准备接管车辆的控制。
自2018年起,腾讯安全科恩实验室积极布局人工智能安全研究,并在”安全+AI”交叉领域结合应用场景研究探索。基于对抗样本生成、二进制分析等问题的研究,先后在多个顶级期刊与会议上发表了特斯拉Autopilot的实验性安全研究、基于图神经网络的二进制代码分析、基于跨模态检索的二进制-源代码匹配等论文。同时,在AI安全研究与能力建设的方向上,科恩始终秉持开放合作的态度,通过各类研究合作项目与广大研究学者进行深入学习交流,和香港科技大学、香港理工大学和中科院信息工程研究所展开合作科研。
科恩也将持续对这一前沿领域进行探索将其应用在安全领域中,近期科恩也将对外开放更多能力,敬请期待!
腾讯安全科恩实验室自研的面向攻击面的Android应用自动化检测系统ApkPecker,正式上线自动化APK脱壳能力!线上ApkPecker系统提供高成功率的自动化脱壳服务,扩大漏洞扫描的覆盖面。限时扫码加入ApkPecker技术交流群,体验更高效的Android应用检测服务。
为避免Android应用程序被轻易逆向暴露程序逻辑,Android平台APP加固技术也不断发展。加固服务能一定程度提高Android应用程序被逆向的难度,但仍无法避免和防止应用程序自身的安全问题和漏洞。除此之外,恶意程序还能利用加固服务隐藏恶意行为逻辑。因此,通过研究Android应用程序通用自动脱壳方法,能客观评估加固的有效性,还能及时发现应用本身存在的安全问题,并为恶意应用程序的发现扫清障碍。
经过多年的发展和对抗,Android平台APP加固技术已经相当成熟,防护粒度从DEX整体加密开始,细化到方法级别和指令级别,不断增加逆向分析的难度和工作量来保护客户端代码。相应的,针对这些加固技术,也出现了很多通用的脱壳方法和工具。这些工具通过内存dump在运行时获取壳释放的APP原始代码,来实现DEX层通用脱壳。然而厂商也发展出了定制化的加固方法来对抗通用脱壳,DEX虚拟化(DEX-VMP)便是其中之一。DEX虚拟化加固使得常见的基于内存dump的通用脱壳工具不再适用,增加了自动化分析的难度。为帮助厂商进一步提升应用安全检测覆盖面,ApkPecker推出自动化DEX-VMP脱壳服务。
DEX-VMP是一种基于虚拟机的DEX加固方案。DEX-VMP在加固阶段将App受保护的方法native化,抽取原始字节码并转换成自定义格式的字节码;在运行阶段,DEX-VMP使用自定义的Dalvik解释器来解释执行转换后的自定义字节码。表1展示了DEX-VMP加固前后的代码对比。
1 | // DEX-VMP 加固前App代码 |
图1展示了正常Dalvik代码和DEX-VMP保护的代码在执行时的区别。正常Dalvik代码由Android ART运行时执行,而被DEX-VMP Native化的方法在运行时通过JNI进入厂商解释器入口。厂商解释器可以进行各种定制化修改,例如使用自定义的Opcode映射表和指令格式,增加还原难度。DEX-VMP在厂商解释器中解释执行自定义的字节码,不释放原始Dalvik字节码,从而能够对抗通用脱壳技术。
1 | while (1) { |
表2展示了一个自定义Dalvik解释器的伪代码片段。pc指向待执行的指令,xor_key用来在执行前解密指令的opcode,registers数组代表寄存器。该例子中opcode 0x00对应的语义是add-int
,0x01对应const-string
,与Dalvik标准中opcode编号不同,并且使用了自定义的字符串索引,而不是DEX常量池中的字符串索引。
为了将自定义的字节码转换成符合Dalvik标准的字节码,需要从解释器中提取字节码的解密逻辑和自定义的常量池数据,同时也要需要识别opcode handler的语义。Dalvik 标准中有两百多条Opcode,人工从厂商解释器的二进制代码中识别这些handler对应的语义十分繁琐。
腾讯安全科恩实验室研发的ApkPecker,是一款全自动的Android应用漏洞扫描工具,能够输出高质量漏洞扫描报告,提供高品质漏洞信息以及漏洞触发完整路径,精准定位漏洞并提供修复建议,帮助移动安全人员解决现有痛点,提升应用安全性。 在现有漏洞扫描的基础上,ApkPecker提供了自动化APK脱壳服务,针对市面主流加固厂商,以高成功率自动化脱壳,为移动安全分析人员解决了障碍,扩大漏洞扫描的覆盖面。
ApkPecker支持恢复常见的DEX加密和指令抽取等类型的加固,同时,针对厂商的DEX虚拟化保护(DEX-VMP), ApkPecker也进行了针对性脱壳和恢复。
ApkPecker在确定厂商字节码格式的基础上,通过AI学习厂商解释器二进制中opcode handler的运行时行为,从而自动化恢复出厂商解释器的opcode语义,还原出原始Dalvik字节码,并重写DEX文件。ApkPekcer的脱壳方案解决了opcode handler识别的难点,自动化还原被DEX-VMP保护的代码,提高了脱壳的完整度和自动化程度。图2展示了ApkPecker对指令抽取和DEX-VMP的脱壳效果。
整体来看,ApkPecker的脱壳能力可以通过以下几个关键指标体现:
● 支持的加固方法 :DEX加密,指令抽取,DEX虚拟化
● 大规模测试下的脱壳成功率 >= 85%
ApkPecker脱壳功能适配主流的DEX加密、指令抽取和DEX虚拟化等加固方法。我们在主流App市场的测试发现,超过60%的的加固App受到不同程度的DEX-VMP保护,而ApkPecker对加固App的脱壳成功率高于85%。
限时扫描二维码进入ApkPecker技术交流群,获取更多脱壳以及应用自动化检测技术资料,更有不定期福利放送。
浏览器中体验面向攻击面的Android应用自动化检测系统ApkPecker:ApkPecker在线地址。
CCF-腾讯犀牛鸟基金(以下简称犀牛鸟基金)于2013年由腾讯公司和中国计算机学会(CCF)共同发起,致力于面向海内外青年学者搭建产学研合作及学术交流的平台。
9年来,犀牛鸟基金为全球范围内最具创新力的青年学者提供了解产业真实问题,接触业务实际需求的机会,并通过连接青年学者与企业研发团队的产学科研合作,推动双方学术影响力的提升及研究成果的应用落地,为自主研发技术的探索和创新储备能量。
腾讯安全科恩实验室自2018年起积极布局人工智能安全研究,并在”安全+AI”交叉领域结合应用场景研究探索,在研究AI算法自身安全性方向获得突破性成果的基础上,持续探索如何将AI算法应用到传统安全研究当中。
在AI安全研究与能力建设的方向上,科恩始终秉持开放合作的态度,通过各类研究合作项目与广大研究学者进行深入学习交流。自2019年起,科恩深度参与腾讯公司高校合作项目CCF-腾讯犀牛鸟基金,与香港科技大学、香港理工大学、中科院信工所等多所院校在AI安全能力研究方向展开合作,并取得诸多成果。
为进一步深耕深度学习与软件安全研究领域,在2021年CCF-腾讯犀牛鸟基金项目中,腾讯安全科恩实验室继续开放“深度学习在软件安全领域的应用研究”课题方向申请。科恩期待与更多在“安全+AI”领域深入研究的高校青年教师合作,碰撞出利用AI算法解决安全实际场景问题的更多火花。
本年度犀牛鸟基金继续以人工智能技术为主要研究方向,强调其在医疗健康、能源保障、材料研发、信息安全等民生领域的技术融合与应用,并涉及多源信息融合、博弈论、密码学等领域前沿课题。
腾讯安全科恩实验室在本次犀牛鸟中启动“深度学习在软件安全领域的应用研究”课题方向申请,相关信息如下:
随着软件复杂度的不断提升,大规模源代码和二进制软件的漏洞挖掘工作面临新的机遇和挑战。本命题希望把深度学习相关技术(例如自然语言处理、图神经网络、深度强化学习等)应用于软件安全研究中,其成果可以对传统的逆向工程、模糊测试、漏洞挖掘等有较大促进。
本基金将面向符合如下条件的海内外高校及科研院所青年学者展开:
申报截止时间:2021年6月15日 24:00(北京时间)
申报方式:点击2021年CCF-腾讯犀牛鸟基金介绍主页查看《2021年CCF-腾讯犀牛鸟基金项目申报指南》,填写并上传《申报表》提交申请。
注意事项:
更多申报主题信息请关注腾讯高校合作官方网站。任何针对项目申报的问题,请联系基金项目负责人邸欣晨。
电子邮箱:xinchendi@tencent.com。
欢迎广大青年学者关注并申报本年度犀牛鸟基金。
[1]https://www.ccf.org.cn/Media_list/ccf/2021-05-14/728588.shtml
[2]https://ur.tencent.com/
[3]https://keenlab.tencent.com/zh/2019/03/29/Tencent-Keen-Security-Lab-Experimental-Security-Research-of-Tesla-Autopilot/
[4]https://keenlab.tencent.com/zh/2019/12/10/Tencent-Keen-Security-Lab-Order-Matters/)
[5]https://keenlab.tencent.com/zh/2020/11/03/neurips-2020-cameraready/
腾讯安全科恩实验室遵循白帽黑客准则对梅赛德斯-奔驰汽车智能互联系统进行信息安全研究。在对其最新车载信息娱乐系统MBUX的软硬件进行全面深入的研究后,科恩实验室发现多个相关漏洞并成功在车载信息娱乐系统(Head Unit)和车载通讯模块(T-Box)的部分攻击面上实现利用。科恩实验室第一时间向戴姆勒报告本研究中发现的所有漏洞技术细节并协助进行漏洞修复。
MBUX是梅赛德斯-奔驰最新的车载信息娱乐系统,自2018年A级车中首次推出后,陆续在梅赛德斯-奔驰E级、GLE、GLS、EQC等车型搭载上市。
在本次研究中,我们对MBUX的硬件以及软件做了深入和全面的分析。通过收集技术资料并搭建测试环境,我们分析了多个攻击面并进行相关安全测试。
现代信息娱乐系统比以往更强大、复杂和安全,梅赛德斯-奔驰的MBUX也不例外。目前,未有任何公开资料对现代车载娱乐系统进行全面的安全性分析。因此,本次研究的定位是进行更广泛的安全性评估,而非单个安全性渗透测试。我们详尽地研究了包括无线电等组件的多个攻击面。
经过研究测试,我们在MBUX上发现多个相关漏洞,并成功在车载信息娱乐系统(Head Unit)和车载通讯模块(T-Box)的部分攻击面上实现利用。在实验环境中,我们首先通过物理接触获得车机权限,以此为前提实现车载信息娱乐系统(Head Unit)远程控制。继而我们能够远程控制车辆的某些功能,例如更改内部氛围灯的颜色,在信息娱乐屏幕上显示图像等。同时,在调试版本的车载通讯模块(T-Box)上,我们能够入侵T-Box上的内部芯片,可以实现发送任意CAN数据。
腾讯安全科恩实验室在第一时间向戴姆勒报告了本研究中发现的所有漏洞技术细节,目前所有漏洞细节和攻击方法均已得到戴姆勒官方确认。科恩实验室感谢戴姆勒对我们漏洞报告的及时响应以及对漏洞修复积极负责的态度。在整个过程中,科恩与戴姆勒保持紧密高效地合作。
考虑到潜在的安全风险,本次披露隐去漏洞详细信息,以下是戴姆勒确认的CVE漏洞列表:
腾讯安全科恩实验室在本次对梅赛德斯-奔驰汽车的信息安全研究项目中,严格遵守全球软件和互联网行业公认的“负责任的漏洞披露原则”, 并协助戴姆勒及时修复本次报告中涉及的漏洞。
整个漏洞披露流程涉及的具体时间节点如下所示:
2020年3月:科恩实验室内部启动了梅赛德斯·奔驰研究项目。
2020年11月:在实验环境中,科恩实验室验证所有发现的漏洞及相应攻击链。
2020年12月21日:科恩实验室向戴姆勒发送了第一封电子邮件。
2020年12月24日:科恩实验室以安全的方式向戴姆勒安全团队报告了所有研究结果。
2021年1月7日:科恩实验室和戴姆勒首次通话。
2021年1月15日:戴姆勒安全团队确认了科恩实验室报告的全部漏洞。 戴姆勒表示这些漏洞的一些修复程序已经可用,并且正在发布中。
2021年1月21日:戴姆勒安全团队申请了5个CVE。
2021年1月30日:戴姆勒安全团队确认并开始推出新的修复程序。
2021年2月/3月:准备联合发布。
2021年5月:此报告向公众发布。
戴姆勒团队对于此次研究的官方回复请参考如下链接:
https://media.daimler.com/marsMediaSite/ko/en/49946866
戴姆勒团队充分认可腾讯安全科恩实验室在安全领域国际一流的专业度和技术实力。为感谢科恩在梅赛德斯-奔驰汽车相关信息安全研究中取得的优异成果,戴姆勒股份公司首席信息安全官Daniel Eitler及梅赛德斯-奔驰乘用车车辆信息技术安全负责人Adi Ofek为科恩实验室颁发签名致谢函。
如果想进一步了解科恩实验室对梅赛德斯-奔驰汽车信息安全研究项目,可以通过以下链接查看本次研究技术白皮书:
Mercedes-Benz MBUX Security Research Report.pdf
科恩暑期开源程序设计项目-RSoC(Rizin Summer of Code)是由腾讯安全科恩实验室与国际二进制开源逆向工程框架Rizin联合举办的一场开源程序设计项目,旨在为有能力的高校学生提供大型项目参与机会。
通过线上笔试(micro-tasks)的各大高校参与者将有机会被录用为科恩实验室暑期实习生,以国际开源逆向工程框架Rizin为研究主体,在七月中旬开始以线下的形式进行一场为期三个月的程序设计项目。
期待一个跃跃欲试的你加入科恩大家庭,与小伙伴们一起玩转二进制黑魔法。
导师阵容:
Anton Kochkov(@akochkov):科恩实验室成员、开源框架Rizin核心成员
leonxlfang:科恩实验室成员
davendu:科恩实验室成员
**micro-tasks内容**:
围绕Rizin开展轻量issue任务
a. 22届及之后高校生
b. 熟悉C语言,掌握开发workflow,例如:git,CI/CD
c. 加分项:有扎实的逆向基础
在报名周期内(3.4-5.1),选择官方博客所列初审micro-tasks项目作为笔试题目,备注所选项目名投递简历至腾讯招聘官网。
简历投递入口:腾讯招聘官网→ 实习生招聘 → 实习生
岗位选择: 安全技术
简历填写须知:除个人信息外,请注意以下几点:
ps: 请注意简历填写的4点须知,填写信息不完整我们将有可能错失你的简历。
科恩会在收到投递简历后进行初步审核,审核通过后科恩将发起笔试邀约。
笔试题目为你所选择的micro-tasks任务,micro-tasks围绕Rizin开展轻量issue任务,预期在两周内完成。
参与同学需独立完成micro-tasks题目,并在截止日期(截止日期以官方招聘通知为准)之前提交笔试内容,大致包括:
科恩将在笔试提交后2周左右给出评审结果,面试有micro-tasks笔试+hr面两道流程,通过的候选人将有机会获得腾讯科恩实验室暑期offer,进行后续暑期项目。
ps: 此专项笔试和集团统一笔试互不影响,仅作为RSoC项目选拔方式。
通过面试的同学将以科恩正式实习生的身份与导师共同开启以Rizin为主体的项目研究现场实习。
入选的同学需要在7月15号前启动项目,且项目持续时间不少于两个月。
项目研究同学享受腾讯正式实习生待遇,根据项目表现情况有机会获取转正资格。
科恩将在9月初举办RSoC项目中期汇报,根据汇报情况作出评价,发放奖励。中期汇报结束后,参与者可根据自身情况继续实习或参与线上跟进项目,当项目完成,科恩将组织一场总汇报为RSoC2021画上句号。
你将获得参与国际开源项目编程的经验,与国际优秀coder共同为开源项目做贡献。
你将收获科恩实验室导师一枚,与导师一起研究炫酷二进制黑魔法。
你将有机会斩获腾讯科恩实验室实习生录用offer,在腾云大厦与实验室小伙伴学习交流,获得一份不错的实习经历。
腾讯科恩实验室
腾讯科恩实验室作为腾讯集团云与智慧产业事业群旗下一支国际一流的信息安全团队,技术实力和研究成果处于国际领先水平。近年来,更是在IoT安全、网联汽车与自动驾驶安全、云计算和虚拟化技术安全等领域取得突破性成果。随着更多新技术进入产业互联网,腾讯科恩实验室继续保持领先的前沿技术研究能力,同时向智能网联汽车、安卓应用生态、IoT等行业开放核心技术能力和行业解决方案。护航各行业数字化变革,守护全网用户的信息安全是腾讯科恩实验室的使命。
Rizin
Rizin是项类unix的逆向工程框架和命令行工具集,是来自世界各地的优秀编程极客的思想结晶,由国际知名免费开源逆向工程框架Radare2提取分支而来。Rizin持有二进制文件分析,反汇编代码,调试程序…等等功能,致力于为使用者提供一个可用性强、稳定性高的优秀工具。
项目答疑讨论QQ群:181504148
与常规实习招聘的区别是什么?
本次招聘与腾讯官方暑期实习招聘性质相同,offer将区分应届生与非应届发送,你也有机会获得转正资格。
本次招聘流程简化为一次笔试+一次hr面。
本次招聘的本质还是暑期项目程序设计,你将与导师协作完成项目,不做大厂螺丝钉。
初审评审依据是什么?
导师会根据学生的实际开发情况、开发任务难度综合考虑。
可以以小组的形式提交初审吗?
不能,该项目以个人形式进行,我们希望你能真诚独立完成测试~
我将以什么形式获得结果告知?
下发笔试、初审结果、hr面试都将以邮件形式告知,请注意邮件消息哦~
我可以线上跟进项目吗?
参与最终项目的同学将获得腾讯科恩实验室的实习生offer,为了你能获得更多经验,我们建议你来到上海腾云大厦与大家共同学习。
我需要什么基础才能通过初审?
RSoC是以Rizin项目为核心,为其解决缺陷,贡献代码,而Rizin是C写的开源项目,所以你需要懂整体的开发workflow,比如git, CI/CD。与此同时,Rizin本身是一款逆向工具,所以,你也需要对逆向方面的理论支持,总体偏底层硬核架构方面。一句话概括就是主开发,懂逆向。
由于本次项目主体为国际开源框架,为了确保项目对接顺利,笔试(micro-tasks)以及暑期项目都将以全英文形式进行。
Implementing the support for any new file format counts as a microtask. See New File-Format label for pending issues.
Rizin parses a lot of information about the ELF but doesn’t print everything.
Thus, the improving the output of i*
commands and rz-bin
tool is important to match up with readelf
:
iS
command)iSS
command)The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin’s analysis engine.
See these issues or the “Analysis” project on our GitHub dashboard.
There are plenty of external scripts and plugins for finding the most probable base for raw firmware images. Opening raw firmwares with rizin is a common use case, so it makes sense to implement it as a part of rizin core.
Analysis classes, accessible under the ac
command, is a relatively new feature of rizin.
They provide a way to both manually and automatically manage and use information about classes in the binary.
Consider the following call: call dword [eax + 0x6c]
Let’s assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method.
So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination.
It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset.
When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek.
Vb
Vb
already supports browsing bin classes. The same thing should be implemented for classes from
analysis.
Rizin has a good support for loading and creating signatures, but it is not yet complete, thus some
problems remain, for example: #272.
As Rizin supports FLIRT signatures loading from IDA Pro, not all of them are supported yet - e.g. version 5 compression.
Currently, Rizin’s source code is rife with calls to rz_core_cmd()
-like functions, that run the Rizin command. While it is a useful shortcut for developer, it makes a good source of the potential bugs in case of the command syntax or behavior change. If these changes happen they are invisible to the compiler, so it cannot warn on the changed syntax. It isn’t the case of changed function arguments count or type.
Thus, all these calls eventually should be substituted with direct calls to the corresponding API
functions. If there is no corresponding API funciton, then one should be created.
Good examples of such cases are:
In general you can just search for rz_core_cmd
pattern in any place inside librz/
.
Rizin has its own intermediate language - ESIL, but not yet support it for all architectures. So
the task is to add ESIL support to any architecture, which doesn’t has it yet.
It is required to solve numerous issues, along with improving parallel execution and performance.
Good example is to allow better filtering of the test types to run, for example to ignore debug tests.
The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - cce.
Another important part of the improving test suite is to cover more different formats and cases with
expanding it. See the #114 issue with more details on how it can be done.
There are many small issues in the decompiler output:
pdgsd
commands showing incorrect P-codeSome of these issues might be related on how Rizin and RzGhidra integrate and might require changes
in the Rizin side.
Also note, that most of these issues should be paired with the test to verify it will not break in
the future.
在NeurIPS 2020中,腾讯安全科恩实验室使用AI算法解决二进制安全问题的《CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source Code Matching》论文成功入选。本论文首次提出了基于AI的二进制代码/源代码端到端匹配算法,与传统算法相比效果非常出色,准确率大幅提升。本论文成果为逆向分析领域提供了新的思路,大大提升工业部署效率。最新论文研究成果也将应用于腾讯安全科恩实验室研发的代码检索工具BinaryAI,使用体验请关注:https://github.com/binaryai/sdk。
机器学习和计算神经科学领域的NeurIPS会议是人工智能领域最具影响力的顶级学术会议之一,备受学者们的关注。国际顶级会议NeurIPS 2020将于2020年12月7日-12日在线上举行。据统计,NeurIPS 2020收到投稿9454篇,创历史最高纪录,接收论文1900篇,论文接收率仅有历史最低的20.1%。
论文链接:CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source Code Matching
在人工智能顶级学术会议AAAI 2020中,腾讯安全科恩实验室利用图神经网络解决二进制程序函数相似性分析问题的技术得到了广泛关注。在此基础上,本次研究方向扩展到二进制代码与源代码的交叉领域,进一步实现腾讯安全科恩实验室在AI+安全新兴方向中的全新探索与突破。
二进制代码-源代码匹配是信息安全领域的重点研究方向之一。在给定二进制代码的情况下,逆向分析研究人员希望找到它对应的源代码,从而提升逆向分析的效率和准确率。但由于源代码和二进制代码的差异性,在此领域的研究较少。B2SFinder[1]和BinPro[2]等传统算法提取源代码和二进制代码的字符串、立即数等特征进行匹配。然而,函数级别的源代码与二进制代码的特征非常少,匹配准确率不高。另一方面,设计合适的特征需要大量的专家经验。
图1展示了一个函数的源代码与二进制代码。从图1中可以看出,除了字符串和立即数特征,代码中隐藏的语义特征也很关键。因此,本文希望设计一种端到端模型,可以自动提取代码间的语义特征,从而提升匹配的准确率。
这是一个二进制代码-源代码间的检索任务,我们把两种代码当作两个模态的输入,即可类比到图文互搜等跨模态检索场景。因此,我们设计了如图2所示的CodeCMR框架,在跨模态检索领域中,这是一种比较常见的结构[3, 4]。在计算最终向量之前,两个模态之间没有信息传递,因此在实际应用时可以预先计算向量,可以节省大量的线上计算时间以及存储空间。
模型的输入有源代码特征和二进制代码特征两个部分。其中源代码特征是字符级别的源代码、从源代码中提取的字符串和立即数;二进制代码特征是控制流图、二进制代码的字符串和立即数。首先将三个输入(语义特征、字符串特征、立即数特征)分别用不同模型计算得到向量,再用拼接+BatchNorm的方式得到代码向量,最后用triplet loss[5]作为损失函数。
在这个基础框架上,有许多可以改进的创新点,例如使用预训练模型做语义融合、使用adversarial loss对齐向量等,对此我们将在后文讨论。
如图3所示,对于字符级源代码,我们使用的是DPCNN模型[6];对于二进制控制流图,我们使用的是端到端的GNN模型。在函数级别,字符级源代码的输入通常在4096以上,DPCNN的效果远优于TextCNN和LSTM。对于控制流图,我们没有使用BERT预训练的node embedding作为输入[7],而是采用了端到端训练的方式,取得了更好的效果。
在这个阶段,本文使用的是DPCNN和GNN,但ASTNN等树模型也同样值得尝试。由于输入是函数级别的代码,缺少#define、#include等重要信息,需要设计合适的编译工具将源代码转化为AST。相比之下,我们直接将文本作为输入的优点是无需额外的专家经验,健壮性强。
对于源代码与二进制代码的立即数和字符串,我们同样设计了模型进行匹配。
对于立即数,我们设计了一种Integer-LSTM。它的输入有integer token和integer number两个。integer number作用在LSTM的输入门和输出门,从而控制信息流动。
对于字符串,我们使用的是层次模型,先用LSTM模型得到每个字符串的向量,再使用sum pooling的方法得到字符串集合的向量。
在得到源代码与二进制代码的向量后,我们设计了一种采样方法。在metric learning领域中,损失函数和采样方法是十分重要的两个模块。为了解决hard样本在训练早期收敛到局部极小值的问题,[5]提出了semi-hard采样方法。然而,[8]指出这种采样方法可能会在某个时间段停止训练,从而提出了distance weighted sampling采样方法解决这个问题:
distance weighted sampling可以在分布中选择各个概率的样本,而semi-hard、hard、uniform等采样方法只能选择特定分布的样本。在此基础上,本文提出了一个改进,即增加一个超参数s,帮助调整概率的分布,从而适应不同的任务和数据集。
本文分别用gcc-x64-O0和clang-arm-O3作为两种组合方式,制作了两个30000/10000/10000的训练/验证/测试集,并使用recall@1和recall@10作为评测指标。数据集已公开在https://github.com/binaryai。
如表1所示,本文提出的方法与传统方法相比有巨大提升,这一发现符合我们的预期,说明代码间隐含的语义特征十分重要。在语义模型中,DPCNN+HBMP取得了最优的效果,说明在二进制侧端到端训练优于预训练的node embedding。与随机采样和distance weighted采样方法相比,norm weighted采样效果更好。图4的train/valid loss曲线也证明了这一点,当s=5时norm weighted sampling的train loss更高但valid loss更低,这表示采样到更合适的样例pair。
基于CodeCMR框架,有很多值得尝试的创新。
本文针对二进制代码-源代码匹配任务提出了CodeCMR框架,成功地利用了源代码与二进制代码间的语义特征。与传统方法相比,取得了很大的突破。
[1] Yuan Z, Feng M, Li F, et al. B2SFinder: Detecting Open-Source Software Reuse in COTS Software[C]//2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2019: 1038-1049.
[2] Miyani D, Huang Z, Lie D. Binpro: A tool for binary source code provenance[J]. arXiv preprint arXiv:1711.00830, 2017.
[3] Wang H, Sahoo D, Liu C, et al. Learning cross-modal embeddings with adversarial networks for cooking recipes and food images[C]//Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2019: 11572-11581.
[4] Wang B, Yang Y, Xu X, et al. Adversarial cross-modal retrieval[C]//Proceedings of the 25th ACM international conference on Multimedia. 2017: 154-162.
[5] Schroff F, Kalenichenko D, Philbin J. Facenet: A unified embedding for face recognition and clustering[C]//Proceedings of the IEEE conference on computer vision and pattern recognition. 2015: 815-823.
[6] Johnson R, Zhang T. Deep pyramid convolutional neural networks for text categorization[C]//Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics. 2017: 562-570.
[7] Yu Z, Cao R, Tang Q, et al. Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection[C]//Proceedings of the AAAI Conference on Artificial Intelligence. 2020, 34(01): 1145-1152.
[8] Wu C Y, Manmatha R, Smola A J, et al. Sampling matters in deep embedding learning[C]//Proceedings of the IEEE International Conference on Computer Vision. 2017: 2840-2848.
CCF-腾讯犀牛鸟基金(以下简称犀牛鸟基金)于2013年由腾讯公司和中国计算机学会(CCF)共同发起,致力于面向海内外青年学者搭建产学研合作及学术交流的平台。
8年来,犀牛鸟基金为全球范围内最具创新力的青年学者提供了解产业真实问题,接触业务实际需求的机会,并通过连接青年学者与企业研发团队的产学科研合作,推动双方学术影响力的提升及研究成果的应用落地,为自主研发技术的探索和创新储备能量。
自2018年起,腾讯安全科恩实验室积极布局人工智能安全研究,并在”安全+AI”交叉领域结合应用场景研究探索。2019年3月,科恩实验室发表“特斯拉Autopilot的实验性安全研究”[1],即利用AI领域的对抗样本生成算法,精准误导特斯拉Autopilot的图像识别深度学习算法,成为首个实现对抗商用自动驾驶系统图像识别功能的研究案例。
科恩在研究AI算法自身安全性方向获得突破性成果的基础上,也积极探索如何将AI算法应用到传统安全研究当中。科恩此前发布的论文《Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection》[2],核心为利用AI算法解决大规模二进制程序函数相似性分析的问题。此论文作为国内该领域最新研究成果被人工智能顶级学术会议AAAI-20会议收录。
在AI安全研究与能力建设的方向上,科恩始终秉持开放合作的态度,通过各类研究合作项目与广大研究学者进行深入学习交流。2019年7月,科恩参与腾讯公司高校合作项目CCF-腾讯犀牛鸟基金,与香港科技大学就相关研究课题展开深入合作。
为进一步深耕深度学习与软件安全研究领域,在2020年CCF-腾讯犀牛鸟基金项目中,腾讯安全科恩实验室再次参与并开放“深度学习在软件安全领域的应用研究”课题方向申请。科恩期待与更多在“安全+AI”领域深入研究的高校青年教师合作,碰撞出利用AI算法解决安全实际场景问题的更多火花。
本年度犀牛鸟基金继续以人工智能技术为主要研究方向,强调其在医疗健康、能源保障、材料研发、信息安全等民生领域的技术融合与应用,并首次涉及多源信息融合、博弈论、密码学等领域前沿课题。
腾讯安全科恩实验室在本次犀牛鸟中启动“深度学习在软件安全领域的应用研究”课题方向申请,相关信息如下:
随着软件复杂度的不断提升,大规模源代码和二进制软件的漏洞挖掘工作面临新的机遇和挑战。本研究项目希望把深度学习相关技术(例如自然语言处理、图神经网络、深度强化学习等)应用于软件安全研究中,其成果可以对传统的逆向工程、模糊测试、漏洞挖掘等有较大促进。
本基金将面向符合如下条件的海内外高校及科研院所青年学者展开:
申报截止时间:2020年6月15日24:00(北京时间)
申报方式:点击2020年CCF-腾讯犀牛鸟基金介绍主页查看《2020年CCF-腾讯犀牛鸟基金项目申报指南》,填写并上传《申报表》提交申请。
注意事项:
更多申报主题信息请关注腾讯高校合作官方网站。任何针对项目申报的问题,请联系基金项目负责人邸欣晨,电子邮箱:xinchendi@tencent.com。
欢迎广大青年学者关注并申报本年度犀牛鸟基金。
[1] https://keenlab.tencent.com/zh/2019/03/29/Tencent-Keen-Security-Lab-Experimental-Security-Research-of-Tesla-Autopilot/
[2] https://keenlab.tencent.com/zh/2019/12/10/Tencent-Keen-Security-Lab-Order-Matters/
雷克萨斯从2017年开始已经为多款车型(包括NX、LS、ES等系列)配备新一代的信息娱乐系统,也被称为AVN视听导航设备。与一些智能网联车载系统相比,如特斯拉中控系统和宝马ConnectedDrive系统,雷克萨斯AVN系统会显得更加传统一些。从安全的角度来看,它能够很大程度上降低被潜在的网络安全问题攻击的可能性。但是一个新的系统往往会带来新的安全风险。科恩实验室[1]对2017款雷克萨斯NX300车型进行安全研究后,在该车型的蓝牙和车辆诊断功能上发现了一系列安全问题,并能够危及到AVN系统、车内CAN网络和相关车载电子控制单元(ECU)的安全性。通过结合利用这些安全问题,科恩实验室能够在无需任何用户交互的情况下,通过无线方式破解并控制汽车的AVN系统,将恶意CAN指令发送到车内CAN网络,从而实现对存在漏洞的车辆执行一些非预期的物理操作。
目前,丰田公司正在推进车辆安全问题修复的解决方案。因此本次报告内容只对研究成果做简要分析,而不是全面的细节披露。如果一切顺利的话,我们将在2021年某个适当的时间点发布完整的漏洞技术报告。
基于对2017款雷克萨斯NX300车辆的硬件分析和CAN网络测试,汽车内部的基本架构如下图所示(涉及到AVN、DCM数据通信模块、电子控制单元和CAN网络等)。
DCM是一个运行在高通MDM6600基带芯片上的远程信息处理设备,又称为T-Box。它可以通过USB以太网接口为AVN设备提供3G网络来支持远程信息服务。DCM还可以通过CAN总线查询ECU (比如汽车引擎和车门) 的状态信息,并将查询结果上传到云端后台。
作为车载信息娱乐系统,雷克萨斯AVN设备主要为用户提供无线电广播、多媒体和导航功能。实际上,它由两部分组成:DCU显示控制单元和MEU地图多媒体扩展单元。DCU是AVN单元的关键部件,DCU的主电路板模块暴露了一些常见的攻击面,如Wi-Fi,蓝牙和USB接口。通过DCU uCOM电路板模块,DCU系统能给通过CAN消息与汽车内部ECU进行间接通信。MEU地图多媒体扩展单元功能非常透明,它只负责提供地图导航数据。在DCU和MEU之间,还连接了USB以太网线用于消息通信。
通过拆解DCU硬件,我们发现它主要包含两个电路板模块。如下图所示,根据电路板位置,顶层为DCU主电路板模块,底层为DCU uCOM电路板模块。
DCU主电路板模块集成了一些常规芯片,包括瑞萨R8A779x SoC芯片[2], 博通BCM4339 Wi-Fi蓝牙芯片,2块512MB的SDRAM内存芯片,1块8GB的eMMC NAND Flash储存器和1块8MB的SPI NOR Flash储存器。SoC芯片拥有两个ARM-CortexA15核,用于运行各种代码,包括芯片启动代码(bootrom)、NOR Flash中的U-Boot固件代码以及eMMC Flash中的Linux系统。
在DCU主板背面有一块独立的SPI NOR Flash储存芯片。根据芯片的数据手册,该存储器总容量为64M-bits。将存储芯片的引脚焊接到通用存储芯片编程器后,并在flashrom软件[3]中选择对应的芯片型号,可以将SPI储存芯片中的所有数据提取出来。通过对提取的数据进行逆向工程后,基本上可以推测出如下图所示的数据存储布局。由于为了支持A/B系统备份更新,Flash存储器中还保存一部分固件镜像和配置数据的副本,比如U-Boot config配置数据、U-Boot Image镜像和BSP Boot config启动配置数据。
DCU主板还集成了一块8GB的eMMC NAND Flash芯片用来存储AVN单元的主要代码和数据,包括Linux内核镜像、设备树数据、ramdisk镜像和Ext4文件系统。同时为了实现AVN系统的快速引导启动,Flash中也保存了一份Linux系统的快照镜像。而为了支持A/B系统更新, Flash中还需要储存Linux内核镜像和ramdisk镜像的副本。整个eMMC Flash的存储布局如下图所示。
TDCU uCOM电路板模块的用途是管理电源和一些外部设备,如DVD播放器、空调、触控板和电子时钟。而为了与这些外部设备通信,uCOM电路板上配备了两个CAN总线微控制器(SYSuCOM与CANuCOM),每个微控制器都和uCOM电路板上独立的CAN总线收发器进行连接。
CANuCOM是DCU显示控制单元中的一个CAN总线控制器。它使用的是瑞萨R5F10PLJL芯片(如图5所示),通过连接一个CAN总线收发器,CANuCOM可以直接访问汽车的娱乐CAN总线,并且能给与一些车载ECU(如网关和Main Body ECU)交换CAN消息。
SYSuCOM是一个基于松下MNZLF79WXWUB芯片的CAN总线控制器。通过CAN总线收发器,它可以和位于专用CAN网络域中的触控板和电子时钟进行CAN消息通信。SYSuCOM通过UART串口直接连接了CANuCOM和DCU主电路板,它能给为主电路板和外部设备完成不同类型的消息数据转换。
中央网关是一个重要的汽车ECU,它将车载CAN网络划分为不同的CAN域,包括娱乐CAN、车身CAN、OBD诊断CAN、底盘CAN和动力CAN等。另一个必不可少的ECU是Main Body ECU,也被称为车身控制模块(BCM)。Main Body ECU管理了一组用于处理车身相关功能的ECU。DCM模块和AVN属于娱乐CAN域。为了传输CAN消息,DCU uCOM电路板上设计了2个不同的CAN总线(即CAN-1和CAN-2)。通过uCOM模块,DCU主板模块可以向网关传输特定的CAN消息来查询车辆状态。
CAN-1. CANuCOM 微控制器的CAN总线,它直接连接到车内的娱乐CAN总线。通过UART串口与SYSuCOM通信,CANuCOM可以往娱乐CAN总线间接传输来自DCU主板的CAN消息。
CAN-2. SYSuCOM微控制器的CAN总线,它是一路专用CAN总线,用来连接DCU、触控板以及电子时钟等设备。该CAN总线与车载CAN网络在物理上是隔离的。
为了发送CAN消息,DCU主板模块与SYSuCOM建立了两路UART串口(/dev/ttySC1和/dev/ ttysc9)。DCU系统可以将定制的CAN消息发送到/dev/ttySC1串口,这些消息会被中转到CAN-1总线。通过类似的方式,发送到/dev/ttySC9的消息会被转发到CAN-2总线。
以下表中所有的安全研究发现在2017款雷克萨斯NX300车型上验证是有效的,并且在我们向丰田公司提交完整的技术报告及合作交流相应的技术细节之后,丰田也确认了这些安全问题。
我们利用车载蓝牙服务中的两个漏洞实现在DCU的Linux系统中以root权限远程执行代码。第一个是堆内存越界读漏洞,第二个是堆内存的缓冲区溢出漏洞。这两个漏洞都存在于建立蓝牙连接的过程中,并且是在蓝牙配对之前,这使得针对蓝牙漏洞的利用是完全无需用户接触和交互的。而为了获得受影响车辆的蓝牙MAC地址,如果DCU系统曾经与移动电话配对过,我们就可以用 “Ubertooth One”[4]设备进行无线嗅探到DCU系统 的MAC地址。
此外,DCU系统并不支持安全启动,这意味着整个系统可以被篡改,例如按照惯例替换掉系统启动动画。在完全控制DCU系统之后,我们发现想要任意发送CAN消息并不容易,因为在DCU uCOM模块中已经实现了CAN消息的过滤机制。但幸运的是,DCU的Linux系统是负责uCOM的固件升级。
通过逆向uCOM固件及其固件更新逻辑,我们能够将一个恶意固件重新刷写到uCOM电路板模块中,以此来绕过CAN消息验证,从而可以实现向车辆娱乐CAN总线发送任意CAN消息。
根据车载诊断系统的实验测试结果,我们确认了被破解后的DCU系统是被允许通过发送未经授权的诊断CAN消息来控制车辆的诊断功能。Main Body ECU会被恶意诊断从而造成汽车在缺乏认证的情况下执行物理操作。
通过结合蓝牙和车载诊断功能中的安全发现(见表1),我们可以实现如下图所示的从蓝牙无线到车内CAN网络的远程无接触式的攻击链。
步骤-1. 因为车载蓝牙服务是以root权限运行在DCU系统中,一旦DCU系统被蓝牙漏洞攻击破解,恶意代码将会通过无线方式部署并永久驻留在系统中。
步骤-2. 恶意代码可以设计成让被破解后的DCU系统自动连接到我们创建的Wi-Fi热点,并反弹一个远程可交互的系统root shell。
步骤-3. 接着可以利用Wi-Fi网络下的root shell,通过 SYSuCOM和CANuCOM将任意的CAN消息传输到车内CAN总线。
步骤-4. 此外通过利用CAN诊断消息,位于车内CAN网络的一些ECU会被欺骗执行诊断功能,从而使得汽车触发非预期的物理动作。
雷克萨斯汽车安全研究是一项道德的安全研究项目。科恩实验室遵循了全球软件和互联网行业公认的负责任的漏洞披露原则,同丰田公司一起合作修复本报告中列出的安全漏洞和攻击链。
以下是详细的漏洞披露时间线:
丰田对于此次研究的官方回复请参考如下链接:
https://global.toyota/en/newsroom/corporate/32120629.html
[1] https://keenlab.tencent.com/en/
[2] https://www.renesas.com/us/en/solutions/automotive/soc/r-car-m2.html
[3] https://www.flashrom.org/Flashrom
[4] https://greatscottgadgets.com/ubertoothone/
[5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5551
腾讯安全科恩实验室正式加入致力于推广开源车载信息娱乐系统(IVI)软件的非营利汽车联盟GENIVI。作为联盟新成员,科恩将在后续的合作中,输出在智能网联汽车领域安全能力,推动GENIVI联盟在智能网联汽车设计标准、开源软件、系统平台等方面的安全能力建设。
GENIVI作为一个非营利性的汽车联盟[1],致力于发展和支持车载信息娱乐系统(IVI)的开源开发平台。自2009年成立以来,该协会拥有超过100名成员,覆盖汽车制造商、一级供应商、半导体供应商、软硬件开发商和服务提供商。基于行业趋势以及开发解决方案的一致需求,GENIVI联盟成员合作制定可采用的标准和开放源代码。近年来,GENIVI进一步扩展联盟核心能力,积极助力汽车制造商集成集中式和互联驾驶舱中的多个操作系统。
腾讯安全科恩实验室作为腾讯CSIG旗下一支国际一流的信息安全团队,在桌面端安全、移动终端安全等研究领域有十多年的积累,技术实力和研究成果达到了国际领先水平。近年来,科恩在智能网联汽车信息安全领域屡次取得突破性成果[2,3,4]。通过持续深入的独立安全研究项目以及与众多国内外汽车厂商的安全合作,科恩实验室在网联汽车信息安全渗透测试,安全解决方案,最佳实践等方面积累了丰富的经验和技术沉淀。
腾讯安全科恩实验室作为国内首个加入GENIVI联盟的安全团队,也将在后续的合作中,利用科恩在车联安全方向的能力积累为GENIVI联盟的车联安全建设提供能力输出。科恩始终开放自身核心技术能力,并根据产业实际痛点和研究推出智能网联汽车信息安全产品与行业解决方案。护航各行业数字化变革,守护全网用户的信息安全是腾讯科恩实验室的使命。
[1] https://www.genivi.org/about-genivi/
[2] https://keenlab.tencent.com/en/2016/09/19/Keen-Security-Lab-of-Tencent-Car-Hacking-Research-Remote-Attack-to-Tesla-Cars/
[3] https://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/
[4] https://keenlab.tencent.com/zh/2018/05/22/New-CarHacking-Research-by-KeenLab-Experimental-Security-Assessment-of-BMW-Cars/
在过去的两年里,腾讯科恩实验室对特斯拉汽车的安全性进行了深入的研究并在Black Hat 2017与Black Hat 2018安全会议上两次公开分享了我们的研究成果。我们的研究成果覆盖了车载系统的多个组件。我们展示了如何攻入到特斯拉汽车的CID、IC、网关以及自动驾驶模块。这一过程利用了内核、浏览器、MCU固件、UDS协议及OTA更新过程中的多个漏洞。值得注意的是,最近我们在自动驾驶模块上做了一些有趣的工作。我们分析了自动雨刷和车道识别功能的具体实现细节并且在真实的世界中对其中的缺陷进行了攻击尝试。
为了更深入的了解特斯拉车载系统的安全性,我们研究了无线功能模块(Model S上的Parrot模块)并在其中找到了两个漏洞。一个存在于无线芯片固件当中,另一个存在于无线芯片驱动当中。通过组合这两个漏洞,攻击者可以在Parrot模块的Linux系统当中执行任意命令。
本文会揭示这两个漏洞的细节并介绍漏洞的利用过程来证明这两个漏洞是可以被攻击者用来通过无线协议远程攻入到特斯拉车载系统当中的。
Tesla Model S上的Parrot模块是一个第三方模块,型号是FC6050W,它集成了无线及蓝牙功能。Parrot通过USB协议与CID相连。Parrot运行着Linux系统并使用了USB Ethernet gadget,因此Parrot与CID在USB协议基础之上实现了以太网连接。当Tesla Model S连接到无线网络时,实际上Parrot模块连接到该无线网络中。这时,网络流量被Parrot从CID路由到外部网络。
从一份公开的资料[1]中,我们找到了Parrot模块的硬件组成。
Parrot模块的引脚定义也在这份datasheet中。Linux系统的shell可以通过Debug UART引脚得到。
其中的reset引脚连到到CID的GPIO上,因此CID有能力通过下列命令重置整个Parrot模块
1 | echo 1 \> /sys/class/gpio/gpio171/value |
Marvell 88W8688是一款低成本、低功耗、高度集成的支持IEEE802.11a/g/bMAC/基带/射频集无线和蓝牙于一体的基带/射频系统级芯片[2]。
Marvell官方网站[3]提供了一份该芯片的设计框图。
Marvell 88W8688包含了一个嵌入式高性能Marvell Ferocean ARM9处理器。通过修改固件,我们获得了Main ID寄存器中的数值0x11101556,据此推断88W8688使用的处理器型号可能是Feroceon 88FR101 rev 1。在Parrot模块上,Marvell 88w8688芯片通过SDIO接口与主机系统相连。
Marvell 88W8688的内存区域如下:
固件的下载过程包含两个阶段。首先是辅助固件”sd8688_helper.bin”的下载,然后是主固件”sd8688.bin”的下载。辅助固件负责下载主固件及验证主固件中每个数据块是否正确。主固件中包含了很多的数据块,每个块的结构定义如下。
1 | struct fw_chunk { |
88w8688固件的运行基于ThreadX实时操作系统,该实时操作系统多用于嵌入式设备。ThreadX的代码存在于ROM内存区域,因此固件”sd8688.bin”实际上作为ThreadX的应用运行。
在特斯拉上,固件”sd8688.bin”的版本ID是”sd8688-B1, RF868X, FP44, 13.44.1.p49”,本文的所有研究均基于此版本。
在逆向识别出所有的ThreadX API之后,各个任务的信息便可以得到。
同时,内存池的相关信息也可以得到。
芯片固件没有实现Data Abort、Prefetch Abort、Undefine和SWI等CPU异常向量的处理过程。这意味着,固件崩溃后处理器会停止工作。我们不知道固件在哪里因何崩溃。
所以我们修改了固件,并自己实现了这些异常处理过程。这些处理过程会记录固件崩溃时的一些寄存器信息,包括通用寄存器,系统模式及中断模式下的状态寄存器和链接寄存器。通过这种方式,我们可以知道崩溃时系统模式或中断模式下的一些寄存器信息。
我们将这些寄存器信息写到末使用的内存区域,例如0x52100~0x5FFFF。这样,这些信息在芯片重置后仍然可以被读取。
在实现了undefine异常处理过程及修改一些指令为undefine指令后,我们可以在固件运行时获取或设置寄存器的内容。用这种方式,我们可以调试固件。
将新的固件下载到芯片中运行,可在内核驱动中发送命令HostCmd_CMD_SOFT_RESET到芯片。随后芯片会重置,新的固件会下载。
88w8688芯片支持802.11e WMM (Wi-Fi Multimedia)协议。在这个协议中,STA会通过Action帧来发送ADDTS request给其他设备。请求中包含有TSPEC信息。然后其他设备同样通过Action帧返回ADDTS response。下面是该Action帧的具体格式。
ADDTS的整个过程如下:当系统想要发送ADDTS请求时,内核驱动会发送HostCmd_CMD_WMM_ADDTS_REQ命令给芯片,然后芯片将ADDTS请求通过无线协议发送出去。当芯片收到ADDTS response后,将该回复信息去掉Action帧头部复制到HostCmd_CMD_WMM_ADDTS_REQ结构体,作为ADDTS_REQ命令的结果在HostCmd_DS_COMMAND结构体中返回给内核驱动。内核驱动来实际处理ADDTS response。
1 | struct _HostCmd_DS_COMMAND |
漏洞存在于将ADDTS response复制到HostCmd_CMD_WMM_ADDTS_REQ结构体的过程中。函数wlan_handle_WMM_ADDTS_response在复制时,需要复制的长度为Action帧的长度减去4字节Action帧头部。如果Action帧只有头部且长度为3。那么复制时的长度会变为0xffffffff。这样,内存将会被完全破坏,导致稳定的崩溃。
在芯片与驱动之间,有三种数据包类型通过SDIO接口传递,MV_TYPE_DATA, MV_TYPE_CMD和 MV_TYPE_EVENT。其定义可在源码中找到。
命令处理的过程大致如下。驱动接收到用户态程序如ck5050、wpa_supplicant发来的指令,在函数wlan_prepare_cmd()中初始化HostCmd_DS_COMMAND结构体,该函数的最后一个参数pdata_buf指向与命令有关的结构,函数wlan_process_cmdresp()负责处理芯片返回的结果并将相关信息复制到pdata_buf指向的结构中。
1 | int |
漏洞存在于函数wlan_process_cmdresp()处理HostCmd_CMD_GET_MEM的过程中。函数wlan_process_cmdresp()没有检查HostCmd_DS_COMMAND结构体中的成员size的大小是否合法。因此在把HostCmd_DS_COMMAND结构中的数据复制到其他位置时发生了内存溢出。
很显然,固件中的漏洞是一个堆溢出。为了利用这个漏洞实现芯片内代码执行,我们需要知道memcpy()函数是怎样破坏内存的,以及芯片是怎样崩溃的,在哪里崩溃的。
为了触发这个漏洞,action帧头部的长度应该小于4。同时我们需要在Action帧中提供正确的dialog token,这意味着memcpy()接收的长度只能是0xffffffff。源地址是固定的,因为该内存块是从内存池pool_start_id_rmlmebuf分配的,并且这个内存池只有一个内存块。目的地址是从内存池pool_start_id_tx分配的,所以目的地址可能是四个地址中的某一个。
源地址及目的地址均位于RAM内存区域0xC0000000~0xC003FFFF,但是内存地址0xC0000000到0xCFFFFFFF都是合法的。结果就是,读或写下面这些内存区域会得到完全一样的效果。
因为内存区域0xC0000000到0xCFFFFFFF都是可读可写的,所以复制过程几乎不会碰到内存的边界。在复制了0x40000个字节后,整个内存可被看作是整体移位了,其中有些数据被覆盖并且丢失了。
88w8688中的CPU是单核的,所以复制过程中芯片不会崩溃直到有中断产生。因为这时内存已被破坏,在大多数情况下,芯片崩溃在中断过程中。
中断控制器给中断系统提供了一个接口。当一个中断产生时,固件可从寄存器中获取中断事件类型并调用相应的中断处理过程。
中断源有很多,所以漏洞触发后,芯片可能崩溃在多个位置。
一个可能性是中断0x15的处理过程中,函数0x26580被调用。0xC000CC08是一个链表指针,这个指针在漏洞触发后可能会被篡改。然而,对这个链表的操作很难给出获得代码执行的机会。
另一个崩溃位置在时钟中断的处理过程中。处理过程有时会进行线程的切换,这时其他任务会被唤醒,那么复制过程就会被暂停。然后芯片可能崩溃在其他任务恢复运行之后。在这种情况下,固件通常崩溃在函数0x4D75C中。
这个函数会读取一个指针0xC000D7DC,它指向结构TX_SEMAPHORE。触发漏洞后,我们可以覆盖这个指针,使其指向一个伪造的TX_SEMAPHORE结构。
1 | typedef struct TX_SEMAPHORE_STRUCT |
如果伪造的TX_SEMAPHORE结构中的tx_semaphore_suspension_lis指针刚好指向伪造的TX_THREAD_STRUCT结构。那么当函数_tx_semaphore_put()更新TX_THREAD_STRUCT结构中的链表的时候,我们可以得到一次任意地址写的机会。
我们可以直接将”BL os_semaphore_put”指令的下一条指令改成跳转指令来实现任意代码执行,因为ITCM内存区域是RWX的。困难在于我们需要同时在内存中堆喷两种结构TX_SEMAPHORE和TX_THREAD_STRUCT,并且还要确保指针tx_semaphore_suspension_list指向TX_THREAD_STRUCT结构。这些条件可以被满足,但是利用成功率会非常低。
我们主要关注第三个崩溃位置,在MCU中断的处理过程中。指向struct_interface结构的指针g_interface_sdio会被覆盖。
1 | struct struct_interface |
结构中函数指针funB会被使用。如果g_interface_sdio被篡改,那么就会直接实现代码执行。
这是当函数interface_call_funB()中的指令”BX R3”在地址0x3CD4E执行时的一份寄存器日志信息。此时,g_interface_sdio被覆盖成了0xabcd1211。
1 | LOG_BP_M0_CPSR : 0xa000009b |
函数interface_call_funB()在地址0x4E3D0处被MCU中断的处理过程使用。
当复制的源地址到达0xC0040000时,整个内存可被看作是做了一次偏移。当复制的源地址到达0xC0080000时,整个内存偏移了两次。每次偏移的距离如下。
1 | 0xC0016478-0xC000DC9B=0x87DD |
在多数情况下,漏洞触发后再产生中断时,这样的内存偏移会发生3至5次。所以指针g_interface_sdio会被来自下列地址的数据所覆盖。
1 | 0xC000B818+0x87DD*1=0xC0013FF5 |
地址0xC0024FAF、 0xC00237AF和0xC0021FAF刚好位于一个巨大的DMA buffer 0xC0021F90~0xC0025790之中。这个DMA buffer用于存储无线芯片接收到的802.11数据帧。所以这个DMA buffer可以用来堆喷伪造的指针。
为了堆喷伪造的指针,我们可以发送许多正常的802.11数据帧给芯片,其中填满了伪造的指针。DMA buffer非常大,因此shellcode也可以直接放在数据帧中。为了提高利用的成功率,我们用了Egg Hunter在内存中查找真正的shellcode。
如果g_interface_sdio被成功的覆盖。Shellcode或egg hunter会非常的接近0xC000B818。我们所使用的伪造指针是0x41954,因为在地址0x41954+0x24处有一个指针0xC000B991。这样,我们可以劫持$PC到0xC000B991。同时,指针0x41954可被作为正常的指令执行。
1 | 54 19 ADDS R4, R2, R5 |
用这种方法有25%的成功率获得代码执行。
内核驱动中的漏洞可通过由芯片发送命令数据包给主机系统来触发。命令HostCmd_CMD_GET_MEM通常由函数wlan_get_firmware_mem()发起。
这种情况下,pdata_buf指向的buffer由kmalloc()分配,所以这是一个内核堆溢出。在真实环境中函数wlan_get_firmware_mem()不会被用到,并且堆溢出的利用较复杂。
然而,一个被攻陷的芯片在返回某个命令的结果时可以更改命令ID。因此漏洞可以在许多命令的处理过程中被触发。这时,根据pdata_buf指向的位置,漏洞即可以是堆溢出也可以是栈溢出。我们找到了函数wlan_enable_11d(),它把局部变量enable的地址作为pdata_buf。因此我们可以触发一个栈溢出。
函数wlan_enable_11d()被wlan_11h_process_join()调用。显然HostCmd_CMD_802_11_SNMP_MIB会在与AP的连接过程中被使用。固件中的漏洞只能在Parrot已经加入AP后使用。为了触发wlan_enable_11d()中的栈溢出,芯片需要欺骗内核驱动芯片已经断开与AP的连接。接着,驱动会发起重连,在这个过程中HostCmd_CMD_802_11_SNMP_MIB会发送给芯片。于是,为了触发重连过程,芯片需要发送EVENT_DISASSOCIATED事件给驱动。
当在芯片中触发漏洞并获得代码执行之后芯片不能再正常工作。所以我们的shellcode需要自己处理重连过程中的一系列命令并返回相应的结果。在命令HostCmd_CMD_802_11_SNMP_MIB来到之前,唯一一个我们要构造返回结果的命令是HostCmd_CMD_802_11_SCAN。下面是断开连接到触发内核漏洞的整个过程。
SDIO接口上事件和命令数据包的发送可直接通过操作寄存器SDIO_CardStatus和SDIO_SQReadBaseAddress0来完成。SDIO接口上获得内核发来的数据可借助SDIO_SQWriteBaseAddress0寄存器。
Parrot的Linux内核2.6.36不支持NX,所以可以直接在栈上执行shellcode。同时结构HostCmd_DS_COMMAND中的size是u16类型,所以shellcode可以足够大来做许多事情。
在触发栈溢出并控制$PC之后,$R7刚好指向内核栈,所以可以很方便的执行shellcode。
在shellcode中的函数run_linux_cmd调用了Usermode Helper API来执行Linux命令。
在漏洞触发后,芯片中的内存被完全破坏无法继续正常工作。同时内核栈已损坏,无法正常工作。
为了让Parrot的无线功能可以重新正常工作,我们做了如下事情:
1 | *(unsigned int *)0x8000201c|=2; |
在shellcode的函数fun_ret()中调用内核函数rtnl_unlock()来解开rtnl_mutex锁。否则Linux的无线功能会无法正常功能,导致Parrot被CID重启。
在shellcode的函数fun_ret()中调用do_exit()来终止用户态进程wpa_supplicant并重新运行,这样就不需要修复内核栈。
杀掉进程ck5050并重新运行,否则稍后ck5050会因芯片重置而崩溃,导致Parrot被CID重启。
为了远程获取shell,我们强制让Parrot连入我们自己的AP并修改iptables规则。之后,便可通过23端口访问到Parrot的shell。
最终拿到shell的成功率在10%左右。
攻击者发送DEAUTH帧给附近的所有AP。
当Tesla重连至AP时,攻击者可以嗅探到特斯拉的MAC地址。
堆喷伪造的指针,然后发送Action帧来触发固件中的漏洞。
函数memcpy()会一直工作直到有中断产生。
在芯片内成功执行任意代码。
第一阶段shellcode发送EVENT_DISASSOCIATED事件给驱动。
第一阶段shellcode处理一系列命令并等待命令HostCmd_CMD_802_11_SNMP_MIB。
第一阶段shellcode通过SDIO接口发送payload来触发内核栈溢出。
第二阶段shellcode执行并调用call_usermodehelper()函数。
成功执行Linux系统命令并尝试修复Parrot的无线功能。
攻击者搭建自己的AP热点及DHCP服务器。
通过Linux命令强制Parrot加入攻击者建立的AP热点并修改iptables规则。
攻击者可通过Parrot的23端口获得Parrot的shell。
在这篇文章中,我们展示了Marvell无线芯片固件及驱动中漏洞的具体细节,并演示了如何利用这两个漏洞仅通过发送无线数据包的形式远程在Parrot系统内部实现命令执行。
本文所提到的两个漏洞已于2019年3月报告给Tesla,Tesla已经在2019.36.2版本中对该漏洞进行了修复。同时,Marvell也修复了该漏洞并针对该漏洞发布了安全公告[4]。漏洞研究报告的披露已事先与特斯拉沟通过,特斯拉对我们的发布知情。
你可以通过下列链接来跟踪本文提到的漏洞。
http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201911-1040
http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201911-1038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13581
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13582
腾讯科恩实验室作为腾讯集团云与智慧产业事业群旗下一支国际一流的信息安全团队,技术实力和研究成果处于国际领先水平。近年来,更是在IoT安全、网联汽车与自动驾驶安全、云计算和虚拟化技术安全等领域取得突破性成果。随着更多新技术进入产业互联网,腾讯科恩实验室继续保持领先的前沿技术研究能力,同时向智能网联汽车、安卓应用生态、IoT等行业开放核心技术能力和行业解决方案。护航各行业数字化变革,守护全网用户的信息安全是腾讯科恩实验室的使命。
[1] https://fccid.io/RKXFC6050W/Users-Manual/user-manual-1707044
[2] https://www.marvell.com/wireless/88w8688/
[3] https://www.marvell.com/wireless/assets/Marvell-88W8688-SoC.pdf
]]>腾讯安全科恩实验室《Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection》论文入选人工智能领域顶级学术会议AAAI-20。研究核心是利用AI算法解决大规模二进制程序函数相似性分析的问题,本文将深入对该论文进行解读,完整论文可以通过访问以下链接获取: Order Matters: Semantic-Aware Neu for Binary Code Similarity Detection
论文:Order Matters: Semantic-Aware Neural Networks for Binary Code Similarity Detection
单位 | 腾讯安全科恩实验室
二进制代码分析是信息安全领域中非常重要的研究领域之一,其中一类目标是在不访问源代码的情况下检测相似的二进制函数。同一份源代码在不同编译器,不同平台,不同优化选项的条件下所得到的二进制代码是不相同的,我们的任务目标是把同一份源代码所编译出的不同的二进制代码找到。传统算法使用图匹配算法解决此问题,但图匹配算法的速度较慢,且准确率较低。随着近年来深度学习算法的发展,学者们尝试在控制流图(CFG)上使用图神经网络算法,取得了不错的效果。
论文[1]提出了名为Gemini的基于图神经网络的算法,它的输入是两个二进制函数的pair,输出是这两个二进制函数的相似度得分。首先,将二进制函数的控制流图作为输入,并使用人工设计的特征提取方法将每个block表示成低维的向量(如图1所示);然后使用Structure2vec算法计算graph embedding;最后使用siamese网络计算相似度得分并使用梯度下降算法降loss训练模型(如图2所示)。与传统方法相比,Gemini的速度和准确率都大幅提升。
虽然上述方法取得了很大的进步,但仍有一些重要的问题值得研究。一方面,如图1所示,每一个block被表示成一个低维向量,这个特征提取的过程是人工设计的,在Gemini中block特征只有8维向量,这个压缩的过程会损失很多语义信息。另一方面,在二进制代码中节点的顺序是一个很重要的特征,而之前的模型没有设计特殊的算法提取这一特征。图3是函数“_freading”在不同平台x86-64和ARM上编译出的二进制代码的控制流图。这两个控制流图的节点顺序是非常相似的,例如node1都与node2和node3相连,node2都与node4和node5相连,而这种相似性可以体现在它们的邻接矩阵上。经过观察,我们发现许多控制流图的节点顺序变化是很小的。为了解决以上两个问题,我们设计了一种总体的框架,包含semantic-aware模块、structural-aware模块以及order-aware模块。
整体结构:模型的输入为二进制代码的控制流图,模型的整体结构如图4所示,包含semantic-aware 模块、structural-aware模块、order-aware模块。在semantic-aware模块,模型将控制流图作为输入,使用BERT[2]对token embedding作预训练,得到block embedding。在structural-aware模块,使用MPNN算法[3]得到graph semantic & structural embedding。在order-aware模块,模型将控制流图的邻接矩阵作为输入,并使用CNN计算graph order embedding。最后对两个向量使用concat和MLP得到最终的graph embedding,如公式1所示。
Semantic-aware 模块:在semantic-aware模块,可以使用BERT、word2vec等常用模型提取语义信息。本文中使用BERT对控制流图作预训练,从而获得block的语义信息。BERT原用于NLP领域中,对词语与句子作预训练。我们的任务与NLP任务相似,控制流图的block可以看作句子,block中的token可以看作词语。如图5所示,训练过程中BERT有4个任务:Masked language model(MLM)、Adjacency node prediction(ANP)、Block inside graph(BIG)和Graph classification(GC)。
其中MLM和ANP是和BERT的原论文中相似的两个任务。MLM是一个token-level的任务,对block中的token进行mask操作并进行预测,和语言模型的方式相同。ANP任务是一个block-level的任务,虽然控制流图没有NLP领域中的语言顺序,但控制流图是一个有向图,也有节点的拓扑顺序,我们将控制流图中的所有相邻节点提取出来,当作相邻的“句子”。这些相邻的block pair作为ANP任务的正例,并随机选择同图内不相邻的block pair作为负例。
为了获得更多的graph-level的信息,我们加入了两个辅助的graph-level任务BIG和GC。BIG和ANP的方式类似,区别是pair的正负例选择方式不同。BIG任务的目的是让模型判断两个block是否在同一个图中,希望模型可以尽可能地学到此信息,从而对我们的graph-level task有帮助。因此,在BIG任务中同图的block pair为正例,不同图的block pair为负例。GC为graph-level的block分类任务,在我们的场景中,在不同平台、不同编译器、不同优化选项的条件下,得到的block信息有所不同,我们希望模型可以让block embedding中包含这种信息。GC对block进行分类,判断block属于哪个平台,哪个编译器,以及哪个优化选项。
Structural-aware 模块:经过BERT预训练后,使用MPNN计算控制流图的graph semantic & structural embedding。MPNN有三个步骤:message function(M),update function(U)以及readout function(R)。具体步骤如公式2-公式4所示。
其中G代表整个图,v代表节点,N(v)代表v的邻居节点。在本文的场景中,节点即是控制流图中的block,图即是经过预训练后表示成block向量的控制流图。本文在message步骤使用MLP,update步骤使用GRU,readout步骤使用sum,如公式5-公式7所示。
Order-aware 模块:
本模块希望可以提取节点顺序的信息,本文中使用的是CNN模型。为什么使用CNN模型呢?首先考虑图6中的三个图(节点中无语义信息),以及它们的邻接矩阵。这三个图非常相似,每个图中都有一个三角形特征(图a的节点123,图b的节点234,图c的节点134),这个特征体现在它们的邻接矩阵中。首先对比图a和图b,与图a相比,图b加入了节点1,节点顺序依次后移一位,但三角形特征中三个节点的顺序还是连续的,这个特征在邻接矩阵中可以看到,这个1-1-0-1的2*2矩阵仍然存在。CNN在训练集中看过很多这种样例后,可以学习到这种平移不变性。再看图c,加入了节点2,打破了原有三角形的节点顺序,但在邻接矩阵中我们可以看到它实际上是把原来的2*2矩阵放大成了3*3矩阵,当我们移除第二行和第二列时,仍然可以得到一个1-1-0-1的2*2矩阵。这与图像中的image scaling类似,CNN在训练集中包含足够多样例的情况下,也是可以学到这种伸缩不变性的。
本文中使用的模型是11层的Resnet结构[4],包含3个residual block,所有的feature map大小均为3*3。之后用一个global max pooling层,得到graph order embedding。在此之前不用pooling层,因为输入的图的大小不同。具体如公式8所示。
本文在两个任务上进行实验。任务1为跨平台二进制代码分析,同一份源代码在不同的平台上进行编译,我们的目标是使模型对同一份源代码在不同平台上编译的两个控制流图pair的相似度得分高于不同源代码pair的相似度得分。任务2为二进制代码分类,判断控制流图属于哪个优化选项。各数据集的情况如表1所示。任务1是排序问题,因此使用MRR10和Rank1作为评价指标。任务2是分类问题,因此使用准确率作为评价指标。
表2和表3分别对应任务1和任务2的实验结果。表中第一个分块是整体模型,包括graph kernel,Gemini以及MPNN模型。第二个分块是semantic-aware模块的对比实验,分别使用了word2vec[5],skip thought[6],以及BERT,其中BERT2是指原始BERT论文中的两个task(即MLM和ANP),BERT4是指在此基础上加入两个graph-level task(BIG和GC)。第三个分块是对order-aware模块的对比实验,基础CNN模型使用3层CNN以及7、11层的Resnet,CNN_random是对训练集中控制流图的节点顺序随机打乱再进行训练,MPNN_ws是去除控制流图节点中的语义信息(所有block向量设为相同的值)再用MPNN训练。最后是本文的最终模型,即BERT+MPNN+Resnet。
整体结果:本文提出的模型与Gemini模型相比,在任务1和任务2上的评价指标分数均大幅提升。semantic-aware模块使用NLP模型(word2vec,BERT等)均优于使用人工提取的特征。只使用order-aware时模型也取得了不错的效果。与其它所有模型相比,本文提出的模型均取得了更优的效果。
Semantic-aware:只看表中第二个分块,BERT的结果优于word2vec和skip thought,因为BERT能在预训练过程中提取更多的信息。加上BIG和GC任务后的BERT4效果略微提升,说明在预训练过程中加入graph-level的任务有所帮助。图7中是4个控制流图的block(左上,左下,右上,右下),我们使用K-means对预训练后的block embedding进行分类(K-means的类别数定为4),不同的类别颜色不同。从图7中可以看出,同一个控制流图中的block颜色大体相同,不同的控制流图的block的主颜色大体不同。
Order-aware:观察表中第三个分块,CNN模型在两个任务上都取得了不错的效果。Resnet11优于Resnet7和CNN3。与MPNN_ws相比,CNN效果更优。随机打乱节点顺序后,CNN模型效果大幅下降,这表示CNN模型确实可以学到节点顺序信息。图8是控制流图pair的例子,这个函数为“ZN12libfwbuilder15RuleElementRGtw13validateC-hildEPNS8FWObjectE“,左边是在gcc&x86-86上编译的控制流图,右边是在gcc&ARM上编译的控制流图。可以看到,左图的节点3在右图中被拆成节点3和节点4,除此之外其它节点的顺序与边的连接方式均相同。经过CNN模型的计算,这两个图的cosine相似度为0.971,排序rank的排名为1。这表明CNN模型可以从邻接矩阵中学到控制流图的节点顺序。
本文提出了一个新的模型,用于解决二进制代码分析的问题。本文的模型中包含semantic-aware模块,structural-aware模块以及order-aware模块。我们观察到语义信息和节点顺序信息都是控制流图重要的特征。我们使用BERT预训练模型提取语义信息,并使用CNN模型提取节点顺序信息。实验结果表明,本文提出的模型与之前最优的模型相比,取得了更好的效果。
腾讯科恩实验室作为腾讯集团云与智慧产业事业群旗下一支国际一流的信息安全团队,技术实力和研究成果处于国际领先水平。近年来,更是在IoT安全、网联汽车与自动驾驶安全、云计算和虚拟化技术安全等领域取得突破性成果。随着更多新技术进入产业互联网,腾讯科恩实验室继续保持领先的前沿技术研究能力,同时向智能网联汽车、安卓应用生态、IoT等行业开放核心技术能力和行业解决方案。护航各行业数字化变革,守护全网用户的信息安全是腾讯科恩实验室的使命。
[1] Xu, X.; Liu, C.; Feng, Q.; Yin, H.; Song, L.; and Song, D. 2017. Neural network-based graph embedding for crossplatform binary code similarity detection. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, 363–376. ACM.
[2] Devlin, J.; Chang, M.-W.; Lee, K.; and Toutanova, K. 2018. Bert: Pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805 .
[3] Gilmer, J.; Schoenholz, S. S.; Riley, P. F.; Vinyals, O.; and Dahl, G. E. 2017. Neural message passing for quantum chemistry. In Proceedings of the 34th International Conference on Machine Learning-Volume 70 , 1263–1272. JMLR. org.
[4] He, K.; Zhang, X.; Ren, S.; and Sun, J. 2016. Deep residual learning for image recognition. In Proceedings of the IEEE conference on computer vision and pattern recognition, 770–778.
[5] Mikolov, T.; Sutskever, I.; Chen, K.; Corrado, G. S.; and Dean, J. 2013. Distributed representations of words and phrases and their compositionality. In Advances in neural information processing systems , 3111–3119.
[6] R.; Zhu, Y.; Salakhutdinov, R. R.; Zemel, R.; Urtasun, R.; Torralba, A.; and Fidler, S. 2015. Skip-thought vectors. In Advances in neural information processing systems, 3294–3302.
随着人工智能技术的快速发展,高级辅助驾驶相关技术正在汽车领域逐步落地,高级辅助驾驶相关安全也吸引了大众的广泛关注。
腾讯科恩实验室作为国际一流的前沿安全研究团队,也对高级辅助驾驶安全技术保持着高度关注。在2018年Black Hat USA大会上,科恩实验室发表相关议题,面向全球首次公布了针对特斯拉Autopilot[1]系统的远程无接触攻击(相关攻击链已经被特斯拉修复)[2]。
在后续的高级辅助驾驶安全研究中,科恩实验室重点关注在视觉AI模型对抗研究、Autopilot系统架构与网络安全等方面。以特斯拉Model S(软件版本2018.6.1)为对象,针对其搭载的Autopilot系统进行安全研究,科恩实验室取得了以下三个研究成果。
特斯拉Autopilot系统借助图像识别技术,通过识别外部天气状况实现自动雨刷功能。科恩实验室通过研究发现,利用AI对抗样本生成技术生成特定图像并进行干扰时,该系统输出了“错误”的识别结果,导致车辆雨刷启动。
特斯拉Autopilot系统通过识别道路交通标线,实现对车道的识别和辅助控制。科恩实验室通过研究发现,在路面部署干扰信息后,可导致车辆经过时对车道线做出错误判断,致使车辆驶入反向车道。
利用已知漏洞在特斯拉Model S(版本2018.6.1)获取Autopilot控制权之后,科恩实验室通过实验证明,即使Autopilot系统没有被车主主动开启,也可以利用Autopilot功能实现通过游戏手柄对车辆行驶方向进行操控。
对于此次研究的成果展示,请参考下方视频,或点击此处播放视频。
对于此次研究的技术细节,可以通过访问以下链接获取: Experimental Security Research of Tesla Autopilot.pdf
特斯拉关于科恩实验室“雨刷的视觉识别缺陷”(成果一)的反馈:
“This research was demonstrated by displaying an image on a TV that was placed directly in front of the windshield of a car. This is not a real-world situation that drivers would face, nor is it a safety or security issue. Additionally, as we state in our Owners’ Manual, the ‘Auto setting [for our windshield wipers] is currently in BETA.’ A customer can also elect to use the manual windshield wiper setting at any time.”
特斯拉关于科恩实验室“车道的视觉识别缺陷”(成果二)的反馈:
“In this demonstration the researchers adjusted the physical environment (e.g. placing tape on the road) around the vehicle to make the car behave differently when Autopilot is in use. This is not a real-world concern given that a driver can easily override Autopilot at any time by using the steering wheel or brakes and should be prepared to do so at all times.”
特斯拉关于科恩实验室“遥控器操控车辆行驶”(成果三)的反馈:
“The primary vulnerability addressed in this report was fixed by Tesla through a robust security update in 2017, followed by another comprehensive security update in 2018, both of which we released before this group reported this research to us. In the many years that we have had cars on the road, we have never seen a single customer ever affected by any of the research in this report.”
腾讯科恩实验室作为腾讯集团云与智慧产业事业群旗下一支国际一流的信息安全团队,技术实力和研究成果处于国际领先水平。近年来,更是在IoT安全[3]、网联汽车与自动驾驶安全[4,5,6]、云计算和虚拟化技术安全等领域取得突破性成果。随着更多新技术进入产业互联网,腾讯科恩实验室继续保持领先的前沿技术研究能力,同时向智能网联汽车、安卓应用生态、IoT等行业开放核心技术能力和行业解决方案。护航各行业数字化变革,守护全网用户的信息安全是腾讯科恩实验室的使命。
[1] https://www.tesla.com/autopilot
[2] https://www.blackhat.com/us-18/briefings/schedule/#over-the-air-how-we-remotely-compromised-the-gateway-bcm-and-autopilot-ecus-of-tesla-cars-10806
[3] https://keenlab.tencent.com/zh/2017/04/01/remote-attack-on-mi-ninebot/
[4] https://keenlab.tencent.com/en/2016/09/19/Keen-Security-Lab-of-Tencent-Car-Hacking-Research-Remote-Attack-to-Tesla-Cars/
[5] https://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/
[6] https://keenlab.tencent.com/zh/2018/05/22/New-CarHacking-Research-by-KeenLab-Experimental-Security-Assessment-of-BMW-Cars/
宝马网联汽车研究是一项遵循白帽黑客准则的安全研究项目。在这个研究过程中,腾讯科恩实验室对多款宝马汽车的车载信息娱乐系统(Head Unit)、车载通讯模块(T-Box)和车载中心网关(Central Gateway)的硬件以及软件做了深入和全面的分析,并遵循“负责任的漏洞披露”的流程,向宝马报告了漏洞和攻击链的详细细节,并提供技术分析及相关修复建议。研究过程中,我们重点分析汽车暴露在外部的攻击面(包括GSM网络,BMW远程服务,BMW互联驾驶系统,远程诊断,NGTP协议,蓝牙协议,USB以及OBD-II接口)。
通过一年多的深入研究,腾讯科恩实验室实现了对宝马多款车型的物理接触和远程非接触式攻击,科恩研究员证明可以通过远程破解车载信息娱乐系统、车载通讯模块等,获取CAN总线的控制权。
在对宝马汽车的电子控制单元进行深入透彻的安全分析后,腾讯科恩实验室已经在宝马多款不同车型上发现14个通用的安全漏洞,这些漏洞可以通过物理接触和远程无接触等方式触发。
腾讯科恩实验室在第一时间提交完整研究报告到宝马集团德国安全团队,目前所有漏洞细节和攻击方法均已得到宝马官方确认,考虑到潜在的安全风险,在这里隐去了所有漏洞的详细信息。
在完成破解车载通讯模块和信息娱乐系统后,经过进一步分析,我们组合利用这些安全漏洞实现了完整的本地攻击链和远程攻击链。本地和远程攻击链的最终目的都是实现从车载网关向不同CAN总线 (例如: PT-CAN, K-CAN)发送诊断命令来影响车上的电子控制单元(ECU), 进而影响车辆功能。
本次研究中涉及的漏洞主要存在于宝马车载信息娱乐系统(Head Unit)、车载通讯模块(T-Box)和车载中心网关(Central Gateway)三大模块中,基于我们的实验经验,车载信息娱乐系统中的漏洞可以影响宝马多款车型,包括i系、X系、3系、5系、7系等,而车载通讯模块中的漏洞影响自2012年以来的所有搭载该模块的宝马车型。
下表是科恩实验室在研究过程中实际测试过受影响的车型列表,其中包含对应的汽车组件型号和固件版本。
考虑到不同宝马车型可能搭载不同版本的零部件,即使相同版本的零部件也有可能使用不同版本的固件,所以科恩实验室无法给出具体受影响的车型列表,但理论上搭载了以上提到的受影响组件的车型都在本次影响范围内。
科恩实验室通过与宝马沟通,宝马确认这些被发现的漏洞确实存在于车载影音娱乐系统和车载通信系统中,相关车主可以通过宝马官方渠道咨询自己的车辆是否在本次影响范围内,以及是否已经有可用的软件安全更新。
本次宝马安全研究为纯粹的白帽黑客行为,科恩实验室遵循“负责任的漏洞披露”这一业界最佳实践, 并和宝马共同讨论修复本次报告中涉及的漏洞和攻击方法。
整个漏洞披露流程涉及的具体时间点如下所示:
2017年1月: 科恩实验室内部发起宝马安全研究项目。
2018年2月: 考虑到潜在安全风险,科恩实验室在受控的实验环境下,论证了所有已发现漏洞和攻击方法的可行性。
2018年2月25日: 科恩实验室提交完整的安全研究报告至宝马。
2018年3月9日: 宝马确认了科恩报告中提到的所有漏洞和攻击方法。
2018年3月22日: 宝马和科恩实验室开始共同讨论后续漏洞修复和缓解措施。
2018年4月5日:宝马为本次研究中的多个漏洞申请CVE编号,考虑到潜在安全风险,目前所有漏洞细节处于保密状态。 (CVE-2018-9322, CVE-2018-9320, CVE-2018-9312, CVE-2018-9313, CVE-2018-9314, CVE-2018-9311, CVE-2018-9318)
2018年5月22日: 科恩实验室和宝马双方共同确认后,对外发布宝马安全研究综述报告。
2019年(计划): 科恩实验室正式对外发布完整的宝马安全报告(包含所有漏洞细节)。
在本次安全研究综述报告发布时,宝马就修复进展与科恩实验室确认:
所有可以通过蜂窝网络发起的攻击,宝马已于2018年3月开始实现修复措施,这些措施已在4月中旬通过宝马配置文件更新功能对外推送更新。其余的安全缓解措施宝马正在研发中,后续会通过可选的软件安全补丁方式,车主可以通过宝马官方维修渠道获取。
宝马集团认为,此项研究是迄今为止由第三方机构对宝马集团车辆进行的最全面、最复杂的测试。为感谢腾讯科恩实验室出色的安全研究工作,宝马集团为科恩安全实验室颁发了“宝马集团数字化及信息技术研究奖”。
https://www.press.bmwgroup.com/china/article/detail/T0281334ZH_CN
如果想进一步了解该研究项目,可以通过以下链接查看科恩安全实验室的研究综述报告:
Experimental Security Assessment of BMW Cars by KeenLab.pdf
作为腾讯集团旗下一支国际一流的信息安全团队,腾讯科恩实验室[1]在PC安全、移动终端安全等研究领域有十多年的积累,技术实力和研究成果达到了国际领先水平;近几年来,更是在智能网联汽车信息安全[3,4]、IOT安全[2]、云计算和虚拟化技术安全等领域取得丰富硕的成果。随着更多互联网新技术进入大众视野,腾讯科恩实验室也正在积极布局如人工智能算法和技术框架的安全研究、机器学习在信息安全研究领域的应用研究和区块链技术应用的安全研究等新纬度上的能力。
[1] https://keenlab.tencent.com/
[2] https://keenlab.tencent.com/zh/2017/04/01/remote-attack-on-mi-ninebot/
[3] https://keenlab.tencent.com/en/2016/09/19/Keen-Security-Lab-of-Tencent-Car-Hacking-Research-Remote-Attack-to-Tesla-Cars/
[4] https://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/
]]>