智慧城市网

　　【安防展览网 访谈】 7月22日—23日，由盖世汽车主办、上海汽车城特别支持的“2020首届软件定义汽车高峰论坛”正式举办。本次论坛主要探讨软件定义汽车领域新的创新理念、技术趋势、现实挑战等热点话题，共谋行业未来发展之道。下面是腾讯安全车联网安全技术专家张康在本次论坛上的发言：
 

　　2018年5月9号是我第一次代表实验室去分享议题，当时发生了什么事情呢？奔驰车主高速刹车失控，120车速失控的例子。我当时拿这个例子作为一个开场，那个议题也是半个小时，我当时花了20多分钟的时间在告诉大家说车联网安全为什么很重要，当时放了我们2016年特斯拉的视频，视频里面演示到我们的研究员在10公里以外的地方通过4G的方式远程对特斯拉进行一个刹车的时候，那个时候大家的感受是非常真切的：车联网信息安全的问题真的是能造成功能安全的风险。
 

　　所以也是那几年我们在做的事情，我们一直在做行业教育。后来5月底的时候我们又发布了宝马的一个研究案例，当时是受影响超过1000万台的车。从2018年下半年开始我们再去跟车企聊的时候已经不需要做教育了，车企说我知道信息安全很重要，你告诉我应该怎么做？特斯拉和宝马都有这样的问题，那你们量产的时候肯定或多或少有这样的问题，那我们先做渗透测试，发现你们现有的问题，然后去解决问题。
 

　　这里需要澄清一下，虽然说我研究特斯拉和宝马存在安全问题，但是在看来他们的信息安全水平是TOP的：特斯拉不用提了，他们的安全团队都是从Google Apple过来的，宝马也有专门负责内部渗透测试的安全团队，所以我们交流完全是在一个频道上的；特斯拉是16年的平台比较早，宝马是2018年做的，代码是15、16年开发的平台，都已经是4,5年前的事情了，所以有安全问题也是可以理解的；当我们后来看两家厂商这两年的代码时，我们其实看到他们的安全性做的是相当好的。
 

　　过去两年我们做了超过20多家的车企，有些车企连续两年都在做，做得多了客户提出这样一个问题：车企都喜欢量化，也喜欢行业对标，但是安全本身该不该被量化的这件事情就值得讨论，而且我们收费也不便宜，那我怎么跟老板汇报我的钱是花在点子上了；另外一个就是我跟其他的对标，我处于什么样的状态。
 

　　所以基于这个东西我们做了一些思考，设计了一套安全测评的体系，横向是设计安全，设计安全就是从系统安全、开发安全、通信安全等等各个维度，每个维度有不同权重的检测项，可以理解为是一套checklist；纵向是实现安全，是指设计层面的安全需求是否都得到满足了，实现的过程当中是不是存在哪些逻辑漏洞。
 

　　这里列出来的点就是我们测过所有网联功能模块的打分，其中有些黄点是车企第一年做，绿点是他们下一代车型，可以看到整体安全性的确是有提高的。
 

　　所以今天后面整个议题都会围绕设计安全和实现安全两个角度来讲。
 

　　这张图和上午博世那张非常经典的EE架构图演变不太一样，这张是从攻击者视角车联网安全会关注的点。左边是车端，我们主要关注攻击入口，比如说车机是很主要的入口，WIFI、蓝牙、USB，然后还有Tbox，负责与云端后台通信，然后再往底层有一个网关，前几年可能还是传统的防火墙，现在可能会变成智能网关这样的概念，下面就是不同的域，基本走的是CAN协议，以及包括周边的一些设施，比如说充电桩、ADAS，V2X等等。
 

　　举些例子，车端的这些攻击面，特斯拉我们是做过了包括WIFI、OTA、4G、等等，宝马我们关注了一个新的攻击面，就是可以通过短信去开启车门；今年我们做了丰田，丰田是实现了蓝牙攻击面的利用。车端的攻击面一旦被利用了以后可以造成功能安全方面的一些影响，破解车机，T-Box，网关后，直接向CAN去发送一些恶意指令，会造成车辆的功能安全影响。
 

　　右半边就是传统的互联网安全，云端后台可能是OEM自己的后台，也可能是三方服务的后台，通过手机可以实现远程车控，或者是像蓝牙钥匙这样的功能。右边可能造成的风险相对以信息安全偏多，比如说财产损失或者是信息泄露这样的一些问题。
 

　　我们做了特斯拉、宝马、丰田，这两天基本所有人都在讲特斯拉，但我今天还是主讲特斯拉，为什么？因为这次是软件定义汽车大会，大家都不可否认，特斯拉其实是软件定义汽车的典范。
 

　　这张是2016年的架构图，和EE架构图不太一样，我们只列出了我们主要关注的模块。
 

　　2016年的时候它的中控屏车机，车机是Linux系统，它本身还承载了Tbox的功能和后台通信，车机和跟仪表盘和WIFI模块，还有网关走的以太网，网关是个RTOS系统。我们当时研究了两路CAN，包括车身控制CAN，还有高速CAN，就是ABS、ESP这些行车过程中造成的动作。16年的时候我们的攻击链是这样的：特斯拉有一个内置的WIFI，我可以通过恶意WIFI热点来进入特斯拉车内网络，车机显示页面是Linux自带的WebKit浏览器，当时这个浏览器的版本非常低，存在大量的已知漏洞，通过这些已知漏洞我们就拿了浏览器的权限，但特斯拉权限控制做的比较好，浏览器进程的权限有限。我们见过其他太多的车机系统所有的应用都跑在root/system下，拿到一个应用就直接拿到系统ROOT。
 

　　于是下一步我们去研究Linux内核，同样当时内核版本很低，存在很多已知漏洞，利用之后实现了提权，到这里我们完全控制了中控屏。
 

　　特斯拉是应该是第一个在量产车上实现OTA的公司,可以通过远程做包括中控屏，网关和底层ECU在内的系统更新，这在当时是很超前的。但16年的时候特斯拉OTA没有做签名校验，就意味着任意的攻击者可以构造任意恶意的固件去刷掉网关。后面就很简单了，通过分析CAN指令或者发送诊断指令，就可以实现一些非常规的车控效果。
 

　　所以可以看到16年的时候还是设计问题偏多，存在大量的已知漏洞，OTA没有做校验，这些都是设计层面的问题。
 

　　到了2017年的研究我们来看，首先浏览器之前的漏洞修复了，但版本仍然不是新的，我们利用当时较新的已知漏洞，再次获取了浏览器代码执行的权限。之后是内核，内核在当时已经升到了新版本，但我们通过深入研究后发现了一个内核驱动的未知漏洞，通过这个漏洞再次实现了提权的动作。内核这里就属于实现问题。
 

　　之后是网关，2017年的时候特斯拉OTA已经加了签名校验，但通过深入逆向分析我们发现了它在代码实现层面的逻辑漏洞，可以跳过签名校验，再次刷写了网关，之后的事情就基本一样了。这里也属于实现问题，设计层面上了安全措施，但代码实现上有缺陷导致被绕过。
 

　　2017年的时候我们还做了一件事情，通过深入分析特斯拉的ADAS模块APE，我们发现通过一个高权限的进程，外加一个名为m3-factory-deploy的函数，可以拿到APE模块的root权限。这里其实又属于设计问题了，从上面这个函数名字可以猜测，这应该是当时在还未上市的model3上预留的工程模式函数，但在量产版本上没有做删除。
 

　　拿到APE的root权限后，我们做了进一步的深入研究，并在2019年发布了成果。这是当时研究的发布视频，大家可以看一下。
 

　　大家可以明显看到，我们视频的预算增加了(笑)。其实从安全角度来说，安全是一个伴生属性，任何新技术的出现往往都伴随着信息安全的风险，这也是科恩实验室一直在关注的事情，我们一直在做前沿技术的安全研究。对于ADAS来说，我认为是安全有两个维度：
 

　　第一个维度，ADAS本身的系统模块，这个展开来讲的话，不只ADAS了，新架构下会有大量功能集中在一个域控制器上，这个系统本身的安全性是至关重要的，因为它可以直接发出车身控制，动力系统控制等高危操作，如果这个系统自身安全做得不好，那我一旦被破解之后就可以去实现车控，造成安全功能的影响。
 

　　第二个维度，自动驾驶算法引入了一个新的场景，特斯拉走的是图像识别这条线路，大家看到第一个雨刷的研究，它的雨刷是靠深度学习算法去做决策，判断当前的画面是不是下雨，我们在不清楚具体算法的前提下，构造了一个对抗样本的训练模型，通过纯黑盒的方式，端到端地生成了一个对抗样本，终实现了通过放一个干扰画面可以让自动驾驶的算法做出一个错误的判断，然后导致雨刷器启动。
 

　　车道辅助这一块，这个跟对抗样本没什么关系，通过测试我们发现在地面上部署几个随机的点，就可以让特斯拉识别出来这是一条新的车道，做出错误的判断，驶向错误的路线。实际测试的时候我们也遇到过，像是天桥上面洒下来的倒影，树荫等有时也会让特斯拉做出一些错误的判断。我们只是做了一个抛砖引玉，是想表明ADAS，自动驾驶的场景下，算法本身的安全问题也是需要值得大家考虑的。
 

　　刚刚讲了那么多特斯拉再讲讲别的，除了特斯拉之外，我们做了20多款车的网联系统测试，总结下来，车联网系统常见的安全问题有几类，首先从问题发现的难易程度来说，简单的问题是系统版本低存在已知漏洞、通讯不加密、小权限未满足等等设计层面的问题，这些是占很大一部分的，而且这些问题是好利用的，有些已知的漏洞，利用代码网上都可以搜到，这个就大大减少了攻击者的攻击成本。稍微难一点的比如说系统自带的安全缓解措施或者是多余的组件和服务没有被删除等，这个需要做一些进一步研究才能够发现；比较困难的多数是偏代码实现的逻辑漏洞，比如说刚才提到的特斯拉签名绕过的问题，以及虚拟化逃逸，自动驾驶算法安全等前沿技术的安全问题。所以越往左看是越偏向于设计安全，比如说版本旧，或者通讯没加密这些都是可以去通过给供应商和开发者提需求来解决的。
 

　　所以从技术角度有哪些建议呢？安全基本原则是永远不过时的，比如说小权限设计原则，或者攻击面收敛-没必要的接口或者组件直接删掉，不要留在那里；还有默认安全，就是系统原生的默认选项配好；还有纵深防御等等，这些安全基本原则是*过时的，而且往往是有效的。
 

　　我们再回到这张图，这些问题可以通过什么样的方式去发现呢？对于简单的问题来说，上面提到的安全基本原则可以，结合自动化工具，比如说应用代码审计工具等等，其实是可以基本全覆盖到的；中等难度的问题可能会需要配合一定的渗透测试；对于困难问题来说可能需要大量的渗透测试，就是偏实现安全的问题，我去深入理解你的代码逻辑才能发现这些漏洞，从很长远角度来说甚至还需要配合一些IDS实时监控手段。
 

　　除此之外应急响应/众测/漏洞奖励计划也能骑到查缺补漏的效果，特斯拉这里就做的很好，通过实际奖励，去鼓励安全研究员把问题直接报给你，而不是直接卖给黑产。
 

　　对于攻击者来说他永远是考虑投入产出比，我花费多少的代价，能获取多大的一个成果。所以从防御者的角度来说也是一样，我不用跑得比熊快，只要跑的比别人快就行了，对吧(笑)？其实我只需要把这些简单的问题在需求设计阶段规避掉，花很小的成本就可以把安全提升到一个还不错的level，差不多是这个概念。
 

　　sysAuditor是腾讯科恩实验室的一个嵌入式系统安全审计平台，科恩做的产品都是怎么来的？我们在渗透测试的过程当中，我们发现刚刚提到的一些安全基线的问题，可以通过自动化的工具来实现，然后我们就开始写一些自动化的脚本，然后就发现这些脚本为什么不把它生成工具卖给客户呢？这样我们把自动化的测试工具给到客户，让客户去用，可以提升自己的测试能力水平，然后更高级的测试让我们来做，是这样的一个思路。
 

　　几句话解释这个平台能够干嘛：首先会在目标系统上跑一个脚本，这个脚本可以理解为它会生成一个系统的快照，里面包含所有需要的信息，然后上传到后台，通过一定的规则引擎去做分析，这里的规则是科恩多年来车联网的渗透测试经验沉淀下来的，可以看到从系统、通信，权限等多个维度，这个和前文提到的设计安全的checklist是有对应的；扫描之后终出一个结果，列出系统对于车联网来说存在哪些风险，哪些是高危、中危的或者警告的等等。
 

　　这个打分系统说实话我们是抗拒的(笑)，但是厂商还是希望你可以再直观一点，给我一个打分，告诉我综合评分是多少。显然现在这个打分系统的算法还是有待优化，14分有点说不过去了(笑)。
 

　　刚才讲的是在技术层面，从流程层面来说，我们跟车企去聊的时候说你们该在设计层面去做什么，去提需求，那车企会问另外一个问题，我该如何制定一个详细的需求，后面该怎么验证需求被满足了？这个也是说明车企到了下一个阶段，就是对下一代开发平台的安全该做。
 

　　这里可以看，对于车企开发来说它是从传统的模型一直到现在软件定义汽车SOA的开发模式去做转变，安全来说也是一样的，开始时微软的SDL，安全开发生命周期，在设计阶段把需求提出来，然后在验证阶段进行测试，去验证需求是否满足，然后发布以后再进行应急响应，这是安全开发生命周期；将来随着软件定义汽车的普及，安全也是一样的会向DevSecOps去做转变，会更加强调自动化；其实我们在跟宝马合作的时候，宝马已经在往这种方向去转了，刚才的那个工具他们很感兴趣，这个工具可以集成到他们的CI流程里去，每做一个版本迭代都跑一次，确保我没有引入新的安全问题，进而保障安全的下限。
 

　　但是对于大部分的车企来讲，目前连SDL都还没有实现，所以我们现在也开始做转型，开始给车企做咨询规划，比如车企说我想成立自己的安全管理团队，那我们给集合具体的业务规划，去做一个安全的规划，需要招多少人、分3到5年，需要做什么事情，后面包括风险评估，应急响应流程等等的咨询，这是我们目前在做的事情。
 

　　后一页takeaway，从人的层面来讲，现在大部分车企还没有做到“有专门的团队负责信息安全”，先做这个，后面再考虑“信息安全是每个人的责任”；然后就是要找专业的人去做专业的事情，怎么样帮你做咨询规划，针对于你的方案该给供应商和开发提出怎么样的一个安全需求，再由谁去做风险评估，谁来去做渗透测试的验证，其实每个阶段一定要有专业的人来做这个事情。
 

　　技术层面大家可以看，车机趋势基本是安卓或者Linux，其他域控等也基本是Linux为主，大家的手机其实就是安卓，大家的主机就是Linux，这两个系统本身这已经是非常安全的产品了，所以对于车端来说需要做的就是将PC端和移动端非常成熟的技术，结合具体应用业务场景，按照优先级顺序应用到车联网当中；优先级顺序是很重要的，因为还是那句话，车企永远是考虑成本控制的，不可能说什么安全措施都要上，一定是有一个先后顺序的，这个一定要结合自己的应用场景，先上哪些技术再上哪些。举个例子有些车企说我们要不要做IDS或者CAN加密？我说有这些钱还不如把系统的基础安全性做好，先从20分达到60分，然后再去考虑怎么样达到80、90分的概念；
 

　　还有就是选择合适的自动化工具，应用到安全开发的流程中去，确保我每次的版本迭代都是有一定质量保证的。
 

　　流程层面就很简单了，首先是安全左移，大多数的安全隐患都是可以在需求设计层面解决的，而且越往左移的成本越低的，所以这是一个低成本*的事情。还有就是这个需求提给供应商也好，还是提给OEM自己的开发也好，还是要在验证阶段做测试，验证需求是否得到了满足，满足过程当中是不是也存在实现问题，终确保整个系统的安全。
 

　　差不多就是这样，谢谢大家！大家有什么问题吗？
 

　　提问：你好，我想问一下您这边的实验室有没有攻击过一些其他非Linux的系统？有没有成功的案例可以跟我们分享一下？比方说QNX之类的。
 

　　张康：我现在讲的都是可以在网上查到的信息，特斯拉和宝马这些都是公开的，是有研究白皮书的，我们看的Linux/安卓比较多，QNX也有，像宝马的车机就有一个QNX，其他的T-Box，网关也有QNX或者RTOS等系统，以及单片机这种，都有看，我们研究不分系统，还是具体攻击链上遇到什么系统就看什么。
 

　　提问：那也就是说一些号称安全的操作系统道高一尺，魔高一丈还是有这个？
 

　　张康：其实刚刚提到了，Linux和安卓其实也是安全的，你用的手机如果满分是100分，已经可以达到99分了，但车机上如果是同样的安卓能不能达到同样的效果，这个是要看具体实现的。
 

　　提问：你前面提到17年特斯拉你们用了一个0day漏洞，是你们自己找的还是？
 

　　张康：对，我们自己找的，本身早科恩就是关注Linux和Windows这样的操作系统，我们会去做0day，然后我们发现了以后会去报给厂商。
 

　　提问：因为这些代码都是开源的，如果整车厂的代码不是开源的话，是不是不容易去找？
 

　　张康：我们研究所有的安全漏洞都是黑盒测试，简单来说是把一个二进制的文件，比如安装包，逆向成汇编代码，再逆向成C/C++这种开发语言，然后再去分析其中的代码逻辑。所以为什么你在市面上没有做安全测试这么多，能达到我们这个成果是很少的，这个是有很高的技术门槛在里面的。此外，今天想给大家分享的17年特斯拉的Oday情况攻击成本是非常高的，是需要有我们这样的专业人才去做深入的研究才能发现问题，但事实是车联网系统其实存在更普遍的可以利用的已知漏洞，这些相对来说很容易被利用，所以一旦你把系统版本升到新，确保已知的安全漏洞都被修复，就可以达到一个比较高的安全水准了，谢谢。