1、产品介绍
影响斯柯达和大众集团车辆的漏洞最初是在 2022 年生产的斯柯达速派 III (3V3) - 2.0 TDI 中发现的。
整车特点：
MIB3 信息娱乐系统，带触摸屏显示------Preh公司制造，用于斯柯达和大众汽车。
SmartLink功能使汽车能够通过Android Auto、Apple CarPlay、MirrorLink以及其他可能的通信技术与车主的便携式设备进行通信。
通过蜂窝网络实现E-Call功能的TCU
该车使用TCU和蜂窝通信通道保持在线、接收OTA更新以及与OEM后端通信。
车主可通过适用于安卓和IOS系统的应用与汽车通信。
该应用可交互车门与灯光、车门开关锁、车窗等功能。
2、硬件信息
MIB3信息娱乐系统具有以下特征：
零件编号：3V0035820J
硬件版本：H22
固件版本：0304
图中硬件组成：
1、R-Car M3 主 CPU(ARM)运行主操作系统。他有一个专用核心CARCOM，运行RTOS，负责处理CAN总线通信。
2、搭载Linux文件系统eMMC。
3、带有底层固件的SPI存储芯片。
4、无线局域网和蓝牙芯片。
5、电控芯片（PWC），ARM32
概况
PCAutomotive发现了多个低危、中危等漏洞，攻击者可通过这些漏洞访问MIB3信息娱乐系统的某些调试，并通过WI-FI进行DOS，此外斯柯达和大众的OBD接口也存在问题，可利用该问题进行UDS认证。
OBD接口安全控制集中的另一个漏洞运行发送UDS命令，导致车辆在高速行驶时发动机和其他零部件关闭。但因访问OBD且存在利用限制被评为中危。
最后斯柯达在云端发现了两个安全问题，攻击者只需要知道车辆VIN码即可获取用户昵称和一些车辆数据。
细节披露
CVE-2023-28893：信息娱乐ECU存在SWD调试接口。
IVI PCB包含由NXP制造的S9KEAZN64A电控芯片（PWC），该芯片在其引脚上提供工作SWD调试接口。
由于该调试接口受到保护，在调试芯片前，必须擦除存储芯片内部存储器中的固件和配置。尽管如此，擦除操作完成后，仍可使用固件更新包中的固件重新编程PWC，从而获取PWC的调试访问权限。
可使用JTAG适配器连接SWD接口。
其实这里的操作就是把原来带保护的芯片擦除内容，然后从开源途径获取到PWC的固件然后重新刷到芯片。
CVE-2023-28894：电控芯片上的调试控制台
CVE-2023-28895：PWC内存访问的硬编码密码
描述：信息约了单元的PWC芯片向单元的外部插座公开了一个UART接口，该接口存在调试命令。
这里我是没想到的，现在UART已经非常少见了，即便使用也会设置登录密码。
看一下他的调试命令都有什么，这套调试命令大概区分了一下，主要功能是作用于诊断操作，T：打印温度、P1/P0：电源开关，R1/R0：CPU复位相关开关、PWC配置等、还有于CARCOM交互，m...：伪造发往CARCOM消息，M...：把调试输入发给CARCOM。
该调试口的利用场景及其影响就是能够物理接触到信息娱乐单元的潜在攻击者可通过CARCOM核心和PWC芯片之间的UART线路发送以下命令解锁PWC芯片的调试UART控制台。
0xF1 0x1D 0x01 0x01 <CHECKSUM 2 bytes> 0xF2该命令是解锁命令，与UART调试对应的关系是PWC：命令（切换回PWC接收模式）、Q（切换UART隧道模式）、m.../M...（向CARCOM发假消息/调试输入）、fx...（从CC发假消息）等。0x1D大概率是解锁调试模式或进入debug UART专用指令。
通过调试控制台，可访问PWC固件更新功能（u），该命令允许读取和修改PWC内存，从而提取固件并将任意二进制代码写入内存。从而受硬编码到PWC固件中的密码保护（CVE-2023-28895）。
攻击链猜测：
物理接触信息娱乐单元
在CARCOM核心与PWC之间的UART线上发送解锁帧0xF1 0x1D 0x01 0x01 0xF2
解锁PWC调试UART控制台（？/h）
使用命令u(固件更新/内存操作)
修改固件，植入二进制代码，从而绕过密码保护
获得对PWC内存读写权限
CVE-2023-28896：UDS服务重密码编码强度不足
CVE-2023-28897：UDS服务的硬编码密码
描述：
信息娱乐系统的UDS认证流程：
1、IVI发一个Seed种子
2、发送静态密码值与随机值的算术和结果
如果CAN总线流量包含成功的身份验证尝试，则可通过简单的算数减法从而检索有效密码（CVE-2023-28896）。此外密码值还硬编码在信息娱乐单元的固件中。
这里其实就是白盒审计了，从上面的漏洞能得知已经拿到了固件并且对27算法进行逆向，并且找到了硬编码的值。
CVE-2023-28898：通过Apple CarPlay服务导致车载主机DOS
当客户端通过CarPlay连接车辆的HU时，端口7000/tcp上的HTTP/HTTPS服务可用，但该服务无法正确处理制定了id参数的/logs场景下的请求。
连接到同一无线网络的攻击者可发送特质请求，如：
ANY /logs?id=0 RTSP/1.0
Host: 10.173.189.1:7000在某些情况下需要发送两次，如果车载WI-FI网络与另一台设备建立了CarPlay接口，则潜在的攻击者可以对车载WI-FI网络发起DOS攻击。
详细分析
当iPhone通过无线CarPlay连接车机（HU，主机后），车机会在局域网内开放一个监听7000/tcp的HTTP/RTSP服务，当该服务处理/logs接口带id的参数的请求时存在缺陷，同一WI-FI网络内攻击者发送一两天畸形请求，即可让CarPlay服务崩溃、主机重启从而形成DOS。
背景
无线CarPlay底层服用了AirPlay协议体系，手机与车机通过WI-FI组网，用RTSP，也就是实时传输流协议进行协商和控制音频流，语法和HTTP相似，TCP 7000正是AirPlay/CarPlay传统控制端口。10.173.189.1是AP模式下的网关地址，车机。
ANY------方法名。实时传输流标准方法有OPTIONS/DESCRIBE/SETUP/PLAY等，但该服务对方法名校验宽松，写任意字符串照收，真正触发的是后面的URL。
/logs？id=0------车机里的一个日志/诊断类接口（原文场景是scenario的直译，理解为接口/处理分支）。漏洞店在于程序对指定id参数的该类请求缺少校验和异常处理，直接走入崩溃路径（如对无效值解引用、越界访问）/
RSTP/1.0------协议表示。是HTTP/RTSP混合风格，也是描述中写"HTTP/RTSP service"的原因。
疑惑点：关于为什么需要连续发送两次
这类崩溃通常是状态相关的：第一次请求可能只是中断当前CarPlay会话或把服务置于中间状态，第二次请求才真正命令未处理的异常导致崩溃。
漏洞总结：
其实这个漏洞利用场景很困难，因为需要通过WI-FI认证，本身就需要过一层认证，并且CarPlay建立也需要近距离操作车机。
CVE-2023-28899：通过ECU重置服务发起的DOS
描述：
向车辆的OBD端口发送特定的UDS广播消息会导致车辆中的某些组件重置。
利用场景：
需访问OBD-II端口，获得对OBD-II端口的短期访问权限，即可安装无线（蜂窝、WI-FI或蓝牙）接口设备，从而获得车辆诊断接口的访问权限。
这里UDS是存在两种寻址功能，一种是物理寻址，就是发特定的ECU的ID（0x7E0~0x7E7），只有那一台ECU处理并在自己的响应ID（0x7E8~0x7EF）。
功能寻址就是广播，请求发送功能寻址ID 0x7DF,CAN是共享线，所有挂在网段上的ECU都会受到这条报文，并且要处理他。
被滥用的服务有0x01
CVE-2023-28900：后端汽车服务器中的昵称泄露漏洞
CVE-2023-28901：主机fal-3a.prd.eu.dp.vwg-connect.com的行程数据泄露
攻击者可通过任意VIN码获取Škoda Connect的用户昵称和其他表示符（CVE-2023-28900），访问控制漏洞。
如果主用户已在车辆上注册，攻击者可通过斯柯达车辆的VINV码获取行程详情。
远程攻击者可以通过向斯柯达后端 API 端点发出特定请求，泄露斯柯达车辆用户的数据，包括用户名和最近的行程信息。
看一下之前的接口信息，云端的接口。
该流程是抓包mySkoda安卓App->API形态->改VIN重放。
看一下第二张图（CVE-2023-28900）：VIN->车主身份
这里攻击思路猜测：
1、免费注册一个斯柯达账户，登录拿到合法JWT
2、获取目标VIN
3、重放请求，替换VIN，其实就是一个越权操作