智能网联汽车漏洞挖掘之模糊测试

2020-01-19 18:26:41·  来源:Vector维克多  
 
2018年工信部发布《车联网(智能网联汽车)产业发展行动计划》,目标是到2020年,车联网用户渗透率达到30%以上,联网车载信息服务终端的新车装配率达到60%以上;
2018年工信部发布《车联网(智能网联汽车)产业发展行动计划》,目标是到2020年,车联网用户渗透率达到30%以上,联网车载信息服务终端的新车装配率达到60%以上;2019年工信部发布《新能源汽车产业发展规划(2021-2035年)》(征求意见稿),目标是到2025年,25%的新车将实现电气化,智能网联汽车销量占比达到30%。
 
智能、网联、新一代通信等技术的发展使汽车信息安全问题愈发突出,信息安全已经在智能网联汽车领域获得了广泛关注。OEM采取的安全措施是否足够还有待观察,但很明显,网络安全必须成为2020年绝对的优先事项,在黑客发现问题之前阻止其利用这些漏洞。考虑到软件定义汽车时代的到来,整车搭载的代码数量以几何级数增长,隐藏的漏洞会越来越多。网络安全将成为OEM、软件供应商的主要焦点,汽车行业有责任确保车辆不受网络攻击。
在标准方面,ISO和SAE自2016年起草ISO 21434(预计于2020年发布),主要面向Security开发流程体系,不涉及任何特定安全实现技术和测试技术,但会成为在Security开发验证方面类似功能安全ISO26262的强制标准。网络安全在开发方面逐渐引入签名、授权等加密技术;可信平台(如TPM、SHE和HSM等);入侵监测和入侵预防系统。对汽车行业来说,Security机制相关的测试可以参考IT领域或自定义全新的测试方法。模糊测试(Fuzz testing)和渗透测试(Penetration testing)都是安全测试的重要方法,在实际执行中都是借助相关的测试工具进行自动化或半自动化的测试,不同之处在于:渗透测试是模拟黑客恶意入侵的方式进行测试,需要了解被测对象存在的漏洞;模糊测试是一种随机测试,其数据具有不确定性,也没有明显的针对性,即发现的漏洞是测试人员无法预知的。
 
-Fuzz testing
-维基百科:Fuzzing或Fuzz是一种自动化软件测试技术,为软件程序提供无效的(invalid)、未定义的(unexpected)或随机(random)数据输入。用作系统安全性或鲁棒性的验证。
Fuzz testing由测试环境、模糊测试用例生成器和监控数据流三部分组成,需要易用的测试工具来实现各类攻击的挑战,即自动化生成模糊测试用例,从而为测试系统提供高收益。用于模糊测试的模糊测试器(Fuzzer)分为两类:
  • 基于变异的模糊测试器,通过对已有数据样本进行变异来创建测试用例;
  • 基于生成的模糊测试器,利用被测系统使用的协议或文件建模,基于模型生成输入并据此创建测试用例。
图2 Fuzz Testing示意图
 
通常模糊测试引擎是基于“黑盒”测试技术,然而在汽车电子行业开发验证系统中复用已有的配置工程(如网络通信协议和控制器逻辑状态功能)及工具可实现“白盒”测试技术。此外,当软件功能发生变更时,可结合持续集成环境实现验证的快速迭代。当前IT行业的Fuzzer无法为汽车行业直接使用,因此Vector在与汽车和安全行业的众多专家广泛交流的基础上,结合自身多年的Security经验,总结出实施Fuzz testing的关键要素:
 
OEM和供应商通常能够访问具体项目的通信数据库。标准的数据库DBC、LDF、FIBEX和ARXML中详细定义变量的取值范围、长度、时间属性和数据类型。这些数据库文件是自动生成模糊测试用例的关键性输入;
Fuzz测试系统必须支持执行过程中相关数据的记录,以便测试工程师复现问题,并与定义的测试用例和参数进行对比,也为研发工程师回放调试提供便利;
测试工具可自动生成报告,其对测试执行过程的详细描述为相关测试团队提供进一步定位问题的可行性。
图3 自动生成Fuzz test的系统结构
-基于CANoe和vTESTstudio
实现Fuzz testing
-CANoe结合vTESTstudio为嵌入式系统开发工程师提供攻击者视角的同类攻击注入,并通过复用已有配置工程数据生成模糊测试用例。CANoe的强大功能有助于强化汽车电子行业Fuzz test引擎环境:
  • 可适配不同OEM,不同网络协议和数据库;
  • 支持数据记录、数据回放,并提供详细的自动化测试报告。
图4 基于CANoe和vTESTstudio实现Fuzz testing
图5 vTESTstudio中Fuzz testing配置示例
 
CANoe提供“残余”总线仿真功能,确保其它控制器处于符合通信需求规范的收发状态,为Fuzz testing提供测试环境;模糊测试生成器vTESTstudio从4.0版本开始支持模糊测试用例的配置自动生成;Observer高度依赖实际项目需求,需在环境搭建时依据测试内容规划(例如,需在DUT中实现测试代码,上位机需配置相应软硬件监控相关信息等),以实际项目经验示例:
 
Crash监控:报文周期异常、电源异常、Counter反复reset;
DTC监控:通过Diagnostics实时检查;
资源监控:通过XCP实现特定Task对CPU资源的使用状态;
Code Coverage:确保无后门代码;
分享到:
 
反对 0 举报 0 收藏 0 评论 1
沪ICP备11026620号