杨玚 朱科屹 宋娟
摘 要:车联网信息安全是车联网产业健康发展的重要环节,车载终端是智能网联汽车连接车内网与车外网,实现信息交互的重要子系统。文章在编制车载终端信息安全测评指标的基础上,对车载终端信息安全开展测试。文章从系统安全、应用安全、通信安全、数据安全各个方面介绍了检测工作中发现的若干典型信息安全风险,为车联网安全研究提供参考。
关键词:车载终端;车联网;信息安全;测试
中图分类号:TN915.08 文献标识码:A
Abstract: Cybersecurity plays an important role in the development of IoV, and the in-vehicle terminal is an important subsystem that connects the interior network to the broader V2X network. Based on the CSTC security evaluation specification for in-vehicle terminals, comprehensive cybersecurity tests were conducted by CSTC. This paper summarizes characteristic cybersecurity vulnerabilities of contemporary in-vehicle terminals, classified into system security, application security, communication security, and data security.
Key words: in-vehicle terminal; IoV; cybersecurity; testing
1 引言
近年来,随着国内车联网产业生态的逐步建立,车联网信息安全保障已正式提上日程。2018年年底,工信部《车联网(智能网联汽车)产业发展行动计划》要求2020年实现安全管理制度与安全防护机制落地实施,安全保障和服務能力逐步完善。以此为目标,汽标委、信安标委等机构积极地推进车联网信息安全标准规范的制定,研究从整个车到零部件的信息安全测试评价的方法。中国汽车工程学会、信通院、奇虎等单位也纷纷发布了车联网信息安全白皮书、年度安全报告等,从不同层面、不同角度展示了各自的关注领域和重点工作,表明了车联网的安全服务开始从布局转入实战。
车载终端是智能网联汽车的重要子系统。按照一般的定义,它是具备数据输入输出、计算处理、存储、通信等功能,可以采集车内相关的ECU数据并发送控制ECU的指令,集成定位、导航、娱乐等多种功能,是汽车网联化、接入移动互联网和车际网的功能单元[1]。举例说明,侧重于车内信息娱乐的IVI、侧重于远程服务的T-Box,都是典型的车载终端,二者还有融合的趋势。本文不严格限定车载终端的边界,而将其视为连接车内网与车外网,实现信息交互的抽象节点。在实际产品中,车载终端通常具有电话、蓝牙、Wi-Fi、GPS等无线通信功能。汽车安全黑客Craig Smith特别强调:“车载终端存在的远程攻击面,比车上其它任何组件都要丰富[2]。作为内外交通的咽喉要道,安全攻防的必争之地,车载终端的安全保障,无论对厂商还是用户都具有直接的现实意义”。
2018年发表的《车载终端信息安全测评指标体系研究》中,梳理了车载终端信息安全的关键测评指标,形成了包含整体安全、硬件安全、操作系统安全、应用安全、通信安全和数据安全各个方面的测评体系,为信息安全测评奠定了基础[3]。本文从第三方测评的角度,介绍在实际检测工作中发现的若干种信息安全风险。案例的选择不求丰富全面,而是注重典型实用,并适当加以讨论,以期见微知著。
2 车载终端信息安全基本要求
2.1 系统安全
系统安全要求操作系统具备符合车载终端应用场景的身份鉴别、权限管理、访问控制、安全审计等安全防护措施,防范针对操作系统的溢出攻击、暴力破解等威胁,实现了操作系统资源及文件的安全可用。
2.2 应用安全
应用安全要求安装在车载终端上的应用软件具备来源标识、数据加密、完整性校验等防护措施,可以对抗逆向分析、篡改、非授权访问等威胁,实现了应用软件在启动、运行、登录、退出、升级等环节处于安全状态。
2.3 通信安全
通信安全主要包括对内通信安全和对外通信安全。对内通信安全是指车载终端与车内总线以及电子电气系统之间的通信,根据对内通信场景要求采用安全的通信协议、身份认证、完整性校验、访问控制等措施,抵御重放攻击、拒绝服务攻击、报文篡改等威胁,实现外部威胁与内部网络之间的安全隔离,车载端与车内各个子系统间通信数据保密、完整、可用。车与外部通信安全要求通过安全协议、完整性校验、身份鉴别等措施,抵御报文破解、中间人攻击等威胁,实现车载终端与其他节点的安全通信。
2.4 数据安全
数据安全要求数据在采集、存储、处理、传输过程中安全可用,通过访问控制、异常处理等机制,保障了关键数据的机密性、完整性、可用性。
3 车载终端信息安全典型风险
3.1 系统安全
Android系统以其丰富的功能、完整的应用生态、较低的开发门槛,占据了目前车载终端操作系统的最大份额,但是Android碎片化严重的问题,也从手机向车机蔓延。出于降低资源占用、加快开发进度等考虑,一些厂商宁愿采用较低、较旧的系统版本。不同的是,一旦暴露系统安全漏洞,手机厂商可以在几个月内推送补丁,保障服务期内的大部分手机安全无忧。而车机系统的升级方式差别较大,安全更新的滞后时间较长,有的产品实际是“一次安装永不更新”,安全隐患会被持续暴露。
脏牛(Dirty Cow)漏洞是较常用的系统安全检测手段,不仅适用于Android系统,也适用于直接基于Linux内核开发的其它系统,覆盖了市面常见的大部分车机产品[4]。该漏洞由2007年9月发布的2.6.22版Linux内核引入,到2016年10月正式公布时,期间推出的所有Linux内核版本都被危及。测试所见的车机系统往往采用Android 4.4版左右,而7.0版之前的未更新版本均受脏牛漏洞影响。
脏牛漏洞的原理是利用Linux内核中写拷贝机制实现上的条件竞争漏洞,使只读内存映射区变为可写,进而得到了 /etc/passwd、/etc/group 等關键文件的修改权,直到取得Root权限。测试方法是下载脏牛漏洞的POC代码,编译为可执行程序,然后通过USB接口或无线连接将程序adb push接入系统,在adb shell中添加可执行权限后即可运行。该漏洞绕过了SELinux的防护,应用范围又相当广泛,例如可以注入shellcode到passwd、crontab等suid程序,是很实用的系统提权途径。
如果用户无法轻易接触系统内部,这种内核级漏洞是否还有必要进行修补。具体到脏牛漏洞,由于工程样品开放了ADB访问权限,才在测试中发现问题,设备上市前则会关闭调试模式,是否还会产生实际危害,这也是一些委托厂商的疑问。应该认识到,信息安全是一个系统工程,对于复杂度稍高的保护对象来说,可行的攻击路径就相当多样,单一的防护手段往往无法做到全面覆盖,防护机制本身还面临着被攻破、暂时失效的问题。因此,需要部署多种独立的安全机制,形成多层次防护体系,也就是“纵深防御”(Defense in Depth)的思想[5]。具体到脏牛漏洞,即使设备出厂时关闭了调试权限,在用户界面上也不允许开启,根据2018年公布的研究成果,仍然可能通过USB连接发送AT命令的方式启用[6];即使禁用了USB的访问,还可能会利用无线连接发现新的突破渠道。一般来说,越是系统底层的安全漏洞,可能造成的危害越大。所以应该尽量在合理的层次正面解决问题,而不是通过看似巧妙的手段回避问题。
车载系统售后升级是修复安全漏洞的常规方式。随着汽车软件化程度的提高,传统的4S店服务难以满足及时更新的需要,用户可以自主下载升级包手动升级,空中下载(OTA)也有望成为主流。对于升级包的共同要求是:重要的数据无法被窃取,关键的程序无法被破解,篡改的升级包无法被刷入。常规保护措施是使用对称加密算法(如AES)加密升级包文件,然后使用签名算法(如RSA)生成数字签名,分发至车端。开始升级前,车载系统先校验签名的有效性,确认升级包来源可信且未被篡改,然后解密出升级包文件,执行升级流程。既然升级包的安全性依赖于加密和签名两个手段,车载端对于解密密钥、验签公钥的安全管理就成为重中之重。一般来说,车载端会将验签公钥妥善存储于安全芯片或系统内部,作为厂商身份的可信标识。解密密钥则是根据升级方式的不同,采用类似的方式存储,或者通过与服务器端的动态交互进行获取。
工作中,大部分送测升级包确实采用了上述的防护策略,但是不少样本在实现方面较为简单,使加密和签名几乎形同虚设。例如,某升级包的解密密钥直接明文存储在车机系统的某个服务应用中,将该应用导出后,实现逻辑就一览无余,如图1所示。
从图1可得,加密采用了AES算法,密钥极其简单,就是从0到15的16个字节,初始化向量(IV)则是16个0字节。通过对临近代码的分析,很容易掌握升级包的存储结构,解密出升级包的所有内容,进而分析了其中的关键数据和程序,实现了较深层次的攻击。更有甚者,某车载系统将升级包的签名私钥也明文存储在某应用中,一旦被攻击者利用,将会导致升级包的信任体系崩溃,攻击者能够生成任意内容的伪造升级包,再诱使用户刷入,就获得了成千上万辆“肉车”的控制权。厂商不得不大规模召回,更换车载系统,付出的代价很惨重。还有的被测样本尽管采用了数字签名,但在升级时并未正确校验,从逆向代码可以看出,校验函数无论返回True还是False,系统升级都照常执行,攻击者就能任意篡改升级包的内容,通过试错了解升级包结构,进而向系统引入各种不可预知的危害。
3.2 应用安全
得益于移动互联网的安全实践,车载终端的应用安全大体可以沿用现有的成熟经验,测试方面也已经建立了较成体系的标准规范,例如中国软件评测中心制定的《移动应用软件安全测试规范(2.0版)》等。尽管如此,移动安全起步阶段常见的若干问题,仍然成为车载终端应用的典型症结。
测试Android车机应用时,首先通过ADB的方式将预装应用导出,然后提取清单文件,分析包名、显示名等信息,结合委托方的测试需求,排出测试的优先级。中国软件评测中心内部建有移动应用安全检测平台,能够批量扫描车载应用,自动生成包括应用权限、敏感行为、数据存储等检测项的报告。重点应用需要结合人工测试进行逆向分析,检查代码逻辑、数据内容、内外部通信等。大部分车载终端还需要测试能否向系统中安装第三方应用、经篡改的应用等。
根据经验,车载服务类应用往往直接与车载终端产品相匹配,对它们的分析往往可以获得不少高价值的线索。例如某应用以明文资源的形式保存了进入工程模式的拨号代码、内部服务的调用参数等资料,还有的应用直接将部分源代码打包进来,为攻击者提供了便利。在应用签名封装之前增加一道自动化扫描工序对敏感文件的特征进行匹配,一般就能有效地避免类似问题。
另一个典型的问题是关键代码缺乏保护。攻击者不仅能轻易分析敏感操作的执行步骤,有时还可以提取账号口令等机密数据,之前介绍的AES密钥存储就是一个例子。在与客户交流中,有些技术人员不太理解代码保护的基本概念,比如认为apk经过签名就可以防止篡改,对字节码加以混淆就无法分析,将关键代码用C语言实现就绝对安全等。还有被问到为何某些关键应用没有任何保护,连基本的混淆都没做时,回答竟然是它属于第三方开发,对方未提供源代码,所以无法混淆。这也表明,车载应用可能还处于车载终端“附属品”的阶段,尚未得到厂商的足够重视。它们可能包含高价值信息,攻击难度却不大易于自动化执行,也许会成为注重性价比黑客的首选目标。
3.3 通信安全
信息通讯是车载终端的核心功能。自从奠基性的“机动车安全攻击层面的实证性综合分析”[7]一文发表以来,研究者和黑客们纷纷将目光转向汽车信息安全,车载终端迅速成为攻防对抗的主战场。由于通信的方式多种多样,典型的例子不胜枚举,如蓝牙协议漏洞[8]、使用弱密码算法、车内通信缺乏身份认证等,测试方法大多可以借鉴PC互联网、移动互联网安全的经验。
本文仅介绍一个车机启动时芯片间双向认证的例子。与常见的通信安全问题不同,它不是具体实现的漏洞,而是通信协议设计的缺陷。两个芯片C1、C2的交互逻辑如图2所示。
车机出厂前,将生成的RSA公私钥分别封装入C1、C2的安全存储区。车机每次启动时,C1、C2彼此验证身份才进入正常的工作流程。這里采用一对公私钥就完成了双向认证,而常规的方式需要两对公私钥来标识双方身份。这里的私钥和公钥都必须保密存储,实际上都是“私钥”,并不具备字面的含义。
这个协议利用RSA算法[9]的对称性省去了一对公私钥,通过取反操作省去了C2本应独立生成的随机数M2,确实颇具巧思。然而,为了节省计算和通信,C1在认证过程中处于主导地位,C2只是接受请求、验签、返回新签名。一旦总线中植入了恶意节点,记录C1发送到C2的报文并进行重放,就可以伪装成C1的身份与C2通信。如果在现有的框架上补救,C2可能要用非易失性存储保存近期收到的签名S1,每次收到认证请求都检索一遍,并将新签名加入存储。即便如此,存储区装满后,重放攻击仍会生效,而存储介质的管理无论在成本还是实现上都颇具挑战。为了抵御重放,C1、C2应该独立生成随机数,在两个方向上进行挑战-应答,而不是一厢情愿的“自问自答”,使公钥私钥失去意义。建议将同一个对称密钥置入C1、C2的安全存储区,双方计算HMAC值即能实现双向认证。
3.4 数据安全
数据安全测试包含多方面的细致工作,往往与具体业务相关。若干内容在本文的系统安全、应用安全中已有提及,本节仅作补充性说明。
与手机系统相似,部分车载终端装有共享存储,允许大部分程序自由访问。由于其使用的便利性,不少程序直接将密码、私钥等敏感信息直接写入共享存储。测试时,使用简单的字符串匹配工具进行扫描,往往就能发现不少有价值的信息。
运行日志是另一个常见的问题。程序开发过程中,为了辅助调试,往往需要将一些运行信息输出到系统日志中。作为产品发布前,应该将不必要的日志关闭,否则攻击者可能借此分析程序的运行逻辑,进而发现突破口。测试中发现,不少运行日志包含丰富的信息,有加密参数、执行流程、系统状态等敏感内容。访谈后得知,有些程序并未采用glog等专用日志库,而是直接调用原始的fprintf函数输出日志,很难在合适的层次上一键关闭。
此外,不少的Android应用允许直接导出用户数据,这是在Android开发中熟知的安全问题。应用清单中如果没有将Android:allowBackup属性设为False,就能通过ADB导出该应用的私有数据,可能被攻击者直接盗用。
4 结束语
通过本文发现车载终端的信息安全基本要求并不复杂,之所以暴露出大大小小的问题,有的是设计时缺乏安全考虑,有的则是因为没有理解各种安全策略的作用,未能准确严谨地实现。另外,车载系统涉及的模块较多,可能由不同的团队甚至公司开发,模块间的调用与协作往往成为安全问题的高发区。
在汽车加速软件化的今天,车企应该向IT行业取经,借鉴从设计到测试的最佳实践,提高了技术人员的自主开发能力与信息安全水平,将开发流程正规化、安全思维常识化、测试手段多元化,并委托专业安全人员把关。据近期报道,一汽大众公司2020届的春季校招,一改机械、车辆为主的传统需求,大力向计算机专业倾斜,显示了可贵的决心。
现代汽车行业的信息安全,需要依靠计算机安全界与车企的齐心协作,就像计算机安全界与PC厂商的紧密合作[7]。汽车领域的信息安全正处于奋力起步的破晓期。回顾2002年的PC行业,微软公司毅然推行“可信计算”计划,将信息安全提到前所未有的高度。2011年前后的移动安全行业,尽管Android、iOS系统在设计之初就将安全置于首位,但是仍然经历了较多的探索,才逐渐实现从尝试到常规的过程。又一个九年即将过去,智能汽车的安全有幸借鉴前两个时代的经验,面临的问题又复杂得多,车载终端只是其中一隅。“世纪开新幕,风潮集远洋。欲闲闲未得,横槊数兴亡。”谨借梁任公的五律《壮别》,寄望于车联网的下一个九年。
基金项目:
国家重点研发计划资助(项目编号: 2018YFB0105204)
参考文献
[1] 中国汽车工程学会. 智能网联汽车车载端信息安全测试方法(征求意见稿)[S]. 2019.
[2] 朱科屹,宋娟,叶璐,路鹏飞.车载终端信息安全测评指标体系研究[J].工业技术创新,2018,05(06):7-13.
[3] Craig Smith. The Car Hacker's Handbook: A Guide for the Penetration Tester[J]. Chapter 9, No Starch Press, 2016.
[4] Dirty COW. CVE-2016-5195. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5195. [DB/OL] POCs: https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs.
[5] O. Sami Saydjari. Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time[M]. McGraw-Hill, 2018.
[6] Dave (Jing) Tian, Grant Hernande et al. ATtention Spanned: Comprehensive Vulnerability Analysis of AT Commands Within the Android Ecosystem[M].USENIX Security 2018.
[7] Stephen Checkoway et al. Comprehensive Experimental Analyses of Automotive Attack Surfaces[M]. USENIX Security, 2011.
[8] CVE-2017-0782. A remote code execution vulnerability in the Android system (bluetooth)[DB/OL]. https://www.cvedetails.com/cve/CVE-2017-0782/.
[9] Ronald Rivest, Adi Shamir, and Leonard Adleman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, Communications of the ACM[J]. 21:120-126, 1978. https://dl.acm.org/citation.cfm?id=359342.
作者简介:
杨玚(1980-),男,汉族,江苏人,中国科学技术大学,博士,高级工程师;主要研究方向和关注领域:网络信息安全。
朱科屹(1991-),女,蒙古族,内蒙古人,北京航空航天大学,硕士,工程师;主要研究方向和关注领域:智能网联汽车网络安全。
宋娟(1984-),女,汉族,陕西人,北京交通大学,博士,高级工程师;主要研究方向和关注领域:智能网联汽车网络安全。