2、车载网络安全威胁分析：攻击面分析（T-Box、IVI、网关、传感器）、常见攻击类型（重放、中间人、拒绝服务）、攻击树建模方法
各位同学，咱们接着聊。上一章我们把SOA架构的底子打好了，这一章得直面一个现实问题——车联网这东西，到底有多不安全？
说实话，我入行那会儿，车载安全还是个「边缘话题」。大家更关心功能能不能跑通，网速够不够快。直到有一次，我在实验室里亲眼看着一台测试车被远程控制了空调、车窗，甚至刹车信号都被篡改过……嗯，从那以后，我再也不敢轻视攻击面分析这件事了。
2.1 攻击面分析：黑客从哪里下手？
攻击面，说白了就是「能被攻击者摸到的入口」。在SOA架构下，车不再是封闭的铁盒子，而是一个移动的分布式系统。每个暴露的接口，都是潜在的风险点。
我个人习惯把攻击面分成四大块：T-Box、IVI、网关、传感器。咱们一个一个来看。
2.1.1 T-Box（远程通信终端）
T-Box是车与外界的「电话线」。4G/5G、Wi-Fi、蓝牙、V2X……这些通信方式全从它身上过。攻击者最喜欢什么？喜欢那些「默认开放」的服务端口。
典型攻击路径：
- 利用未加密的远程诊断端口（如UDS over TCP）直接注入指令
- 通过蜂窝网络劫持OTA升级包，植入恶意固件
- 利用T-Box的AT指令接口，发送非法短信控制车辆
我记得有个项目，T-Box的调试串口在生产时没关，结果被安全测试团队直接拿到了root权限。你想想看，一个能远程控制车辆核心通信的模块，居然连最基本的访问控制都没做好——这太危险了。
2.1.2 IVI（车载信息娱乐系统）
IVI是攻击面里最「热闹」的地方。因为它跑的应用多、第三方库多、用户交互多。说白了，攻击者最喜欢这种「复杂度高」的目标。
我曾经在IVI的Android系统里发现过一个第三方地图SDK，它居然在后台偷偷开了个HTTP服务器，监听所有本地请求。这意味着什么？意味着只要车机连上同一个Wi-Fi，任何手机都能往这个端口发指令——典型的中间人攻击入口。
避坑指南：我曾经见过一个团队，把IVI的ADB调试端口留在了正式固件里。结果呢？测试车在路试时被隔壁实验室的人用adb install装了个恶意APK。所以，所有调试接口必须在产线阶段彻底关闭，别想着「以后OTA再关」——你永远不知道谁会先连上来。
2.1.3 网关（Central Gateway）
网关是车内网络的「交通警察」。所有跨域通信——比如IVI想控制车身、T-Box想读取CAN数据——都得经过它。但问题来了：网关本身的安全策略够不够硬？
常见的攻击点包括：
- CAN ID白名单绕过：有些网关只检查源ID，不检查数据内容。攻击者可以伪造一个合法的CAN ID，但塞进去的是恶意数据。
- 路由表溢出攻击：通过发送大量无效路由请求，让网关CPU过载，导致合法报文被丢弃——这就是拒绝服务的一种。
- 固件刷写漏洞：网关的Bootloader如果没做签名校验，攻击者可以直接刷入篡改过的固件。
嗯，这里要注意：网关的防火墙规则不能只靠「静态配置」。我建议用动态行为基线——比如学习正常工况下的报文频率和时序，一旦出现异常模式，立刻告警并阻断。
2.1.4 传感器（Camera、Radar、LiDAR）
传感器这块，很多人觉得「物理层的东西，黑客够不着吧？」——大错特错。传感器是感知层的第一环，一旦被欺骗，整个决策链都会出问题。
举个例子：摄像头。攻击者可以用激光笔照射摄像头传感器，造成局部过曝，让目标检测算法失效。更高级的，可以用对抗性贴纸让AI把「停止牌」识别成「限速牌」。
我记得有个自动驾驶测试项目，工程师发现车辆在某个路口总是莫名其妙急刹车。查了半天，发现是路边的LED广告牌闪烁频率刚好干扰了摄像头的曝光时序——这不是恶意攻击，但原理一模一样。
2.2 常见攻击类型：三种「老面孔」
攻击手段千变万化，但核心套路就那么几种。我个人总结，车载环境里最常碰到的就是这三类：重放攻击、中间人攻击、拒绝服务攻击。
2.2.1 重放攻击（Replay Attack）
重放攻击，说白了就是「录下来，再放一遍」。攻击者先监听一段合法的CAN报文或以太网数据包，然后在关键时刻重新发送它。
比如，你按了一下解锁键，攻击者截获了这个报文。等你走远了，他再把这段报文重放一遍——车门就开了。
防御思路：
- 引入时间戳或随机数（Nonce），让每条报文都有唯一性
- 使用消息认证码（MAC），确保报文没有被篡改或重放
我曾经在网关的CAN通信里加过一个简单的「滚动计数器」——每次发送报文时计数器加1，接收方只接受比上次大的值。虽然简单，但对付重放攻击非常有效。
2.2.2 中间人攻击（Man-in-the-Middle, MITM）
中间人攻击，就是攻击者悄悄插入到通信双方之间，既能窃听，又能篡改。在车载环境里，最常见的场景是T-Box与云端之间的TLS隧道被劫持。
为什么会这样？因为很多车厂为了省成本，用了自签名的证书，或者干脆没做证书固定（Certificate Pinning）。攻击者只要在同一个Wi-Fi网络里，用ARP欺骗就能把流量引到自己机器上。
警告：千万不要在生产环境中使用自签名证书做车云通信！我见过一个案例，某Tier1供应商在量产车上用了测试证书，结果被安全研究员用中间人攻击拿到了所有OTA升级包的明文——那批车后来全部召回升级了安全固件。
2.2.3 拒绝服务攻击（Denial of Service, DoS）
DoS攻击的目标不是窃取数据，而是让系统「瘫痪」。在车里，DoS攻击可以发生在多个层面：
- 网络层：向网关发送海量无效CAN报文，占满总线带宽，导致合法控制指令无法传输
- 应用层：向IVI发送大量HTTP请求，耗尽CPU资源，让中控屏卡死
- 传感器层：用大功率激光照射LiDAR，使其接收器饱和，无法检测障碍物
你想想看，如果高速行驶时，ADAS系统因为DoS攻击突然失效——后果不堪设想。所以，车载系统必须设计资源隔离和优先级调度机制。比如，CAN总线上的安全关键报文（如刹车、转向）应该拥有最高优先级，并且有独立的带宽预留。
2.3 攻击树建模方法：系统化地「找漏洞」
前面讲了攻击面和攻击类型，但怎么系统化地分析一个具体功能的安全风险呢？我个人习惯用攻击树（Attack Tree）。
攻击树是一种树形结构，根节点是攻击者的最终目标，子节点是达成目标所需的子步骤。每个节点可以标注「AND」或「OR」关系——AND表示所有子步骤都必须完成，OR表示只要完成其中一个即可。
举个例子，攻击目标是「远程解锁车门」：
目标：远程解锁车门
├── OR 1: 通过T-Box远程指令
│ ├── AND 1.1: 获取T-Box的远程访问权限
│ │ ├── 1.1.1: 破解T-Box的登录密码
│ │ └── 1.1.2: 利用T-Box固件漏洞提权
│ └── AND 1.2: 发送合法的解锁CAN报文
│ ├── 1.2.1: 获取CAN总线访问权限
│ └── 1.2.2: 伪造或重放解锁报文
├── OR 2: 通过IVI应用漏洞
│ ├── 2.1: 在IVI上安装恶意APK
│ └── 2.2: 利用IVI的CAN接口发送解锁指令
└── OR 3: 物理接触OBD-II端口
├── 3.1: 连接OBD-II诊断工具
└── 3.2: 发送UDS诊断服务解锁车门
有了攻击树，你就能清晰地看到：哪些路径是「低成本高收益」的？哪些节点需要重点防护？
我的经验：做攻击树时，不要只盯着技术路径。我曾经在分析一个远程空调控制功能时，发现攻击树里有一条「通过客服中心重置T-Box密码」的路径——这根本不是技术漏洞，而是业务流程漏洞。所以，攻击树一定要覆盖「人」和「流程」，别只盯着代码。
最后，攻击树不是一次性的。随着新功能上线、新漏洞曝光，你得定期更新它。我建议每个SOA服务上线前，都跑一遍攻击树分析——这比事后补漏洞要划算得多。
好了，这一章的内容就到这里。下一章我们聊聊具体的防护手段——从密码学到防火墙，从入侵检测到安全启动，咱们一个一个拆解。