Khai thác Tesla Wall Connector: Lách qua cơ chế chống hạ cấp firmware

Khai thác Tesla Wall Connector: Lách qua cơ chế chống hạ cấp firmware

Trong bài viết trước, chúng tôi đã giới thiệu một cuộc tấn công vào bộ sạc Tesla Wall Connector Gen 3 được sử dụng trong cuộc thi Pwn2Own Automotive 2025. Chuỗi khai thác lúc đó dựa trên một thực tế đơn giản: thiết bị chưa có cơ chế chống hạ cấp (anti-downgrade). Khi có thể giao tiếp qua giao thức UDS trên dây cáp sạc, chúng tôi chỉ cần ghi một phiên bản firmware cũ, chứa lỗ hổng bảo mật vào slot thụ động, khởi động lại và mở được shell gỡ lỗi.

Để khắc phục, Tesla đã tung ra một bản cập nhật firmware thêm tính năng kiểm tra chống hạ cấp vào quy trình cập nhật. Mọi hình ảnh firmware giờ đây đều mang theo một giá trị "ratchet" bảo mật, và trình cập nhật sẽ từ chối bất kỳ hình ảnh nào có giá trị ratchet thấp hơn mức được lưu trữ trên thiết bị.

Bài viết này sẽ mô tả cách cơ chế chống hạ cấp hoạt động và cách chúng tôi đã vượt qua nó bằng cách lợi dụng thứ tự thực thi giữa việc ghi bảng phân vùng và việc xóa slot, từ đó tái hiện lại cuộc tấn công Pwn2Own gốc trên một bộ sạc đã được cập nhật đầy đủ.

Quy trình cập nhật nhanh chóng

Chúng tôi đã mô tả quy trình cập nhật đầy đủ qua Single-Wire CAN trong bài viết đầu tiên. Tóm lại:

1. Mở phiên UDS (loại 2).
2. Xác thực với Security Access (cấp độ 5, thuật toán XOR-0x35).
3. Chạy routine 0xFF00 để chuẩn bị và xóa slot thụ động.
4. Ghi giá trị 0x0E vào định danh 0x102 để đánh dấu slot là "có thể đặt qua UDS".
5. Đẩy firmware bằng lệnh Request Download / Transfer Data / Request Transfer Exit.
6. Chạy routine 0x201 để xác nhận hình ảnh firmware vừa ghi và chuyển đổi slot.
7. Chạy routine 0x202 để khởi động lại.

Như một nhắc nhở, AW-CU300 sử dụng hai slot firmware: một active (đang chạy) và một passive (mục tiêu cập nhật). Sau khi cập nhật thành công, hai slot sẽ đổi chỗ và firmware mới trở thành active trong lần boot tiếp theo.

Thay đổi trong phiên bản 24.44.3

Sau khi so sánh firmware cũ với phiên bản 24.44.3, chúng tôi tập trung vào hàm switch_to_new_firmware(), hàm xử lý routine UDS 0x201. Một hàm mới là check_image_and_antidowngrade() đã được thêm vào. Hàm này phân tích các đoạn firmware, tính toán lại CRC của chúng, sau đó gọi verify_firmware_segments_platform() để so sánh ratchet.

Nếu mọi thứ hợp lệ, hàm sẽ gọi part_write_layout(passive_firmware). Đây là nơi ta thấy một sơ hở logic quan trọng. Quá trình này bao gồm việc đọc mức gen_level hiện tại, tăng nó lên 1 cho slot mới, xóa và viết lại vùng bảng phân vùng 4KiB.

Khi khởi động, bootloader sẽ chọn slot có gen_level cao nhất. Do đó, để một slot trở thành active trong lần boot tới, bạn chỉ cần part_write_layout() thực hiện thành công một lần cho slot đó. Nội dung của nó sau đó không còn quan trọng.

Cách vượt qua (The Bypass)

Tóm tắt vấn đề: Routine 0xFF00 xóa slot thụ động vật lý dựa trên g_boot_flags (không thay đổi trong phiên làm việc), routine 0x201 xác nhận nội dung slot và ghi bảng phân vùng, trong khi bootloader tin tưởng bảng phân vùng mà không kiểm tra ratchet.

Với điều đó trong tâm trí, quy trình khai thác như sau:

1. Gửi một bản firmware hợp lệ, cập nhật mới nhất vào slot thụ động. Gọi routine 0x201. Quá trình xác nhận passed; bảng phân vùng được ghi, do đó slot này hiện có gen_level cao nhất.
2. Không khởi động lại, gọi routine 0xFF00 một lần nữa. Vì g_boot_flags chưa đổi, cùng một slot vật lý được chọn là thụ động và firmware vừa xác nhận bị xóa. Tuy nhiên, bảng phân vùng không bị ảnh hưởng.
3. Gửi một bản firmware cũ, đã được ký ký hiệu nhưng có lỗ hổng vào slot đang trống đó.
4. Bỏ qua routine 0x201 (ta không cần nó, và nó sẽ từ chối hình ảnh này). Chỉ cần gọi routine 0x202 để khởi động lại.

Khi reboot, bootloader đọc bảng phân vùng, chọn slot có gen_level cao nhất (slot ta vừa ghi lại), xác thực chữ ký (vẫn hợp lệ, đây là firmware được ký đúng cách) và nhảy vào đó. Kiểm tra chống hạ cấp chưa bao giờ chạy trên hình ảnh firmware cũ.

Chi tiết khai thác

Mã khai thác là một phần mở rộng nhỏ của trình mô phỏng xe hơi Pwn2Own. Thiết lập Single-Wire CAN, chuỗi GPIO, kết nối UDS: tất cả đều không đổi. Chỉ có chuỗi cập nhật được nhân đôi:

# 1. Đẩy firmware hợp lệ, cập nhật mới nhất và để routine 0x201
#    ghi bảng phân vùng giúp ta.
client.routine_control(routine_id=0xFF00, control_type=1)
client.write_data_by_identifier(0x102, 0x0E)
data = open("firmwares/WC3_RELEASE_FLEET_24.44.3.prodsigned.bin","rb").read()
send_firmware_data(client, data)
client.routine_control(routine_id=0x201, control_type=1)  # ghi layout
sleep(1)

# 2. Chuẩn bị lại cùng một slot vật lý. Firmware hợp lệ bị
#    xóa; bảng phân vùng không bị thay đổi.
client.routine_control(routine_id=0xFF00, control_type=1)
client.write_data_by_identifier(0x102, 0x0E)
data = open("firmwares/WC3_PROD_OTA_08.58.bin","rb").read()
send_firmware_data(client, data)
sleep(1)

# 3. Khởi động lại. Bootloader sẽ boot firmware cũ vì
#    bảng phân vùng vẫn nói rằng slot này là active.
client.routine_control(routine_id=0x202, control_type=1)

Tổng thời gian chạy khoảng 30 phút trên kênh SWCAN 33.3 kbps: gấp đôi thời gian Pwn2Own gốc, do phải gửi hai hình ảnh firmware hoàn chỉnh qua cáp. Sau khi reboot, phiên bản 0.8.58 quay lại điều khiển, và phần còn lại của chuỗi gốc (rò rỉ thông tin đăng nhập Wi-Fi qua UDS, telnet vào debug shell, tràn bộ đệm trong trình phân tích tham số) hoạt động chính xác như trước.

Kết luận

Vì cơ chế chống hạ cấp chỉ tồn tại trong trình cập nhật và bootloader không kiểm tra ratchet, bất kỳ chuỗi thao tác nào xác nhận bảng phân vùng rồi ghi đè nội dung slot đều có thể vượt qua nó. Routine 0xFF00 cho phép ta làm đúng điều đó: xóa firmware sau khi layout đã được ghi, sau đó ghi bất cứ thứ gì ta muốn.

Việc ép buộc kiểm tra ratchet trong bootloader sẽ lấp đầy lỗ hổng này. Các phương án khác: buộc routine 0xFF00 vô hiệu hóa mục bảng phân vùng khi xóa một slot, để một slot bị xóa rồi ghi lại không bao giờ được chọn để boot. Hoặc đơn giản là ép buộc khởi động lại sau khi cập nhật thành công, hoặc từ chối bất kỳ phiên cập nhật mới nào sau khi routine 0x201 thành công.

Chúng tôi đã báo cáo lỗ hổng này cho Tesla và nó đã được khắc phục trong bản cập nhật firmware vài tháng trước. Như bài viết đầu tiên, Wall Connector thường nằm trên mạng gia đình hoặc doanh nghiệp, và một bộ sạc bị chiếm quyền qua cáp sạc sẽ trở thành bàn đạp để xâm nhập vào mạng đó. May mắn thay, tính năng triển khai OTA tự động của Tesla đến các bộ sạc kết nối có nghĩa là bản vá sẽ tiếp cận hầu hết thiết bị nhanh chóng, giảm thiểu nguy cơ thực tế.