Sau Phần 1 mô tả APPROTECT Bypass , bài đăng mới này trình bày cách:
- khai thác sản phẩm thật dựa trên nRF52840 để bung Firmware và kích hoạt lại giao diện SWD.
- tái tạo cuộc tấn công vào các SoC nRF52 khác để xác nhận lỗ hổng trong tất cả các phiên bản nRF52.
Khai thác xác thực trên sản phẩm thật
Hãy bắt đầu bằng một tình huống cổ điển, trong đó hacker cần truy cập vào Firmware của sản phẩm. Nếu sản phẩm này dựa trên nRF52, nó có thể được bảo vệ để tránh việc đọc chương trình cơ sở nhằm ngăn chặn kỹ thuật đảo ngược.
Mục tiêu: Logitech G Pro
Để xác thực khai thác, mình đã chọn thiết bị đầu tiên mình có trong tay. Đó là Chuột Logitech G Pro của mình dựa trên nRF52840 .
Lưu ý: Mục đích của mình không phải là tấn công sản phẩm Logitech ở đây .
Nhận quyền truy cập
mình bỏ qua phần giới thiệu nhưng đối với những người quan tâm, đây là một video hay trên YouTube .
Thiết bị được tháo dỡ để truy cập vào bo mạch chính:
Các chân SWD (SWDCLK, SWDIO) được in lụa nên rất dễ nhận biết (khung màu đỏ).
Sau đó, một số tiêu đề pin được hàn để kết nối mục tiêu với đầu dò Gỡ lỗi Segger J-Link:
Mọi nỗ lực kết nối qua OpenOcd và GDB đều bị từ chối:
$ openocd -f /usr/local/share/openocd/scripts/interface/jlink.cfg -c "transport select swd" -f /usr/local/share/openocd/scripts/target/nrf52.cfg
$ arm-none-eabi-gdb
Tất nhiên, tính năng APPROTECT được bật trên thiết bị này.
Tái tạo đường vòng APPROTECT
Sự chuẩn bị
NRF52840 nằm ở mặt sau PCB và đóng vai trò là bộ xử lý chính của hệ thống.
Thiết kế PCB hoàn toàn phù hợp với thiết kế tham chiếu nRF52840 (có trong Bảng dữ liệu Bắc Âu). Nó giống như một thiết kế sao chép-dán.
Các tụ tách C5 và C15 được loại bỏ và đầu ra debug được kết nối với VDD_CPU (DEC1):
VDD_CPU (DEC1) được kết nối với debug thông qua đầu nối SMA. Dưới đây là hình ảnh của thiết lập tấn công đầy đủ:
Lỗi tấn công Thời gian
Cuộc tấn công lỗi được thực hiện bằng cách chạy tập lệnh python, tập lệnh này chịu trách nhiệm đồng bộ hóa hệ thống debug, máy hiện sóng và đặt lại thiết bị sau mỗi lần thử lỗi.
Ảnh chụp màn hình này hiển thị quá trình khởi động bình thường (hành vi cổ điển của thiết bị):
Sau đó, kết quả bạn muốn thấy sau khi thực hiện lỗi thành công:
Tín hiệu VDD_nRF trên bo mạch được sử dụng làm tham chiếu kích hoạt phạm vi. Sau một khoảng thời gian trễ cụ thể, lỗi được đưa vào sẽ làm gián đoạn quá trình khởi tạo bình thường của nRF52840.
Từ quan điểm của shell, trình gỡ lỗi bên ngoài giờ đây có thể kết nối với chuột:
Trích xuất phần mềm
Sau khi kết nối, bước tiếp theo là kết xuất Firmware và UICR:
#openocd via telnet
dump_image FLASH.bin 0x0 0x100000
dump_image UICR.bin 0x10001000 0x1000
#optional
dump_image FICR.bin 0x10000000 0x1000Dưới đây là phiên bản bộ tải khởi động và Tên thiết bị ở 0xE5CD8 trong bộ nhớ flash:
Sau đó, Phân tích mã tĩnh có thể được thực hiện để tìm các lỗ hổng (hoặc chỉ để hiểu cách thức hoạt động của nó).
Kích hoạt lại gỡ lỗi vĩnh viễn
Để kích hoạt lại liên tục giao diện gỡ lỗi, APPROTECT bị vô hiệu hóa (xem Phần 1 ) và flash lại với FLASH.bin và UICR.bin đã được trích xuất (tất nhiên là có APPROTECT được vá thành 0xFFFFFFFF):
Chuột quay trở lại “Chế độ phát triển” , trong đó Phân tích mã động là một lợi thế to lớn (đặc biệt là trong quá trình phát triển khai thác).
Gánh nặng gia đình
Cho đến nay, tất cả các kết quả đã thu được trên nRF52840.
Các SoC nRF52 dùng chung CPU Cortex-M4, cùng Cổng gỡ lỗi, cùng Bộ nhớ Flash (ngoại trừ mảng bộ nhớ) và cùng NVMC. Trong bối cảnh này, có khả năng lỗ hổng này phổ biến đối với toàn bộ dòng SoC dòng nRF52. Đây là tầm nhìn của mình về hệ sinh thái nRF52:
Sau lần xem xét nhỏ này, mình quyết định tập trung vào nRF52832 và nRF52833. Nordic cung cấp bộ công cụ phát triển cho hai nền tảng này.
Hai bộ công cụ phát triển đã được đặt hàng. Chi phí = 150$.
Kết quả trên nRF58232
Các thử đã đạt được trên nRF52-DK , dựa trên nRF52832 . Bo mạch phát triển được sửa đổi bằng cách loại bỏ tụ điện và dây hàn:
Lưu ý: chỉ có dây mỏng kết nối với DEC1 là đủ để thực hiện cuộc tấn công.
Máy hiện sóng được sử dụng để xác định mô hình thú vị.
mình đã cải thiện một chút cách theo dõi mức tiêu thụ điện năng trên dòng DEC1. Tỷ lệ nhiễu tín hiệu cao hơn.
Theo mức tiêu thụ điện năng được hiển thị bên dưới, hoạt động trong quá trình khởi chạy Bộ điều khiển Flash là như nhau:
Đây là một ví dụ về một debug thành công:
Gỡ lỗi SWD được kích hoạt lại:
Những kết quả này chứng minh rằng nRF52832 dễ bị khai thác APPROTECT.
Kết quả trên nRF58233
Một lần nữa, các thử tương tự cũng đạt được trên nRF52833-DK , dựa trên nRF52833 .
Sơ đồ và chế độ xem PCB để tham khảo:
Trên nRF52833, việc khởi tạo Bộ điều khiển Flash tương đương với các nRF52 được phân tích trước đó. Việc chèn lỗi được thực hiện trên CPU Power Line DEC1:
Tương tự ở đây, SWD được kích hoạt lại:
NRF52833 dễ bị khai thác APPROTECT.
Sau những thử này, chắc chắn tất cả các phiên bản nRF52 đều dễ bị tấn công.
Sự va chạm
Nordic đã xác nhận các vấn đề bảo mật trong thông báo gửi cho tất cả khách của họ vào ngày 12 tháng 6 năm 2020.
Theo mình, tính năng APPROTECT của nRF52 có thể bị đánh bại trong một khoảng thời gian ngắn và với ngân sách rất hạn chế.
Điểm CVSS là 7,6 (Mức độ nghiêm trọng = Cao) CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H .
Các phiên bản nRF52 Bắc Âu sau đây dễ bị tấn công :
- nRF52810
- nRF52811
- nRF52820
- nRF52832
- nRF52833
- nRF52840
và do đó, các Mô-đun dựa trên nRF52 cũng dễ bị tấn công.
Các mô-đun này có thể tận dụng tất cả các tính năng của kiến trúc Phần cứng và Phần mềm SoC của Nordic để tạo ra một ‘sản phẩm mô-đun duy nhất’ mà không cần thêm bộ vi điều khiển để chạy ứng dụng của bạn.
Nordic cung cấp tài liệu tham khảo về các mô-đun của bên thứ ba tại đây , chẳng hạn như:
- Tập đoàn Fantel
- lãnh chúa
- của mình
- Raytac
- Taio Yuden
- U-blox
- Điện tử Wurth
- Murata
- Dòng chảy
- Fujitsu
- …. và hơn thế nữa
Phần kết luận
APPROTECT Bypass đã được chứng minh trên một thiết bị thương mại, Chuột Logitech Pro G.
Các thử bổ sung đã đạt được trên nRF52832 và nRF52833. Kết quả cho thấy các nền tảng này cũng dễ bị tấn công. NordicSemiconductor xác nhận tất cả các phiên bản nRF52 của họ đều dễ bị tấn công.
Điều này hiện đang tác động đến một số lượng lớn thiết bị trên hiện trường, từ các sản phẩm dựa trên nRF52 đến Mô-đun của bên thứ ba (sử dụng nền tảng nRF52).
Lỗ hổng nằm ở Silicon. Không có cách nào để vá mà không sửa đổi CTNH.
