Backdoor chưa được đăng ký được phát hiện trong chip Bluetooth dùng trên hàng tỷ thiết bị
(bleepingcomputer.com)- Các lệnh Bluetooth không có trong tài liệu công khai đã được phát hiện trong ESP32, dòng chip được dùng rộng rãi trong thiết bị IoT; phạm vi ảnh hưởng lớn vì tính đến năm 2023, chip này đã có mặt trong hơn 1 tỷ thiết bị
- Tarlogic Security đã công bố 29 vendor-specific command trong firmware Bluetooth của ESP32 tại RootedCON, chỉ ra khả năng đọc/ghi RAM và Flash, giả mạo địa chỉ MAC, cũng như chèn gói LMP/LLCP
- Những lệnh này có thể dẫn đến việc giả danh thiết bị tin cậy, truy cập dữ liệu trái phép, di chuyển trong mạng và duy trì tồn tại lâu dài; vấn đề được theo dõi dưới mã CVE-2025-27840
- Khả năng khai thác từ xa trong thực tế phụ thuộc vào cách Bluetooth stack của thiết bị xử lý lệnh HCI, và liên quan nhiều hơn khi có firmware độc hại, bản cập nhật độc hại hoặc quyền root đã bị chiếm trước đó
- Espressif cho biết đây là lệnh debug dùng cho kiểm thử nội bộ và bản thân chúng không thể tạo ra rủi ro bảo mật cho ESP32, nhưng hãng dự định sẽ loại bỏ các lệnh không được tài liệu hóa trong các bản cập nhật phần mềm sắp tới
Các lệnh Bluetooth không được tài liệu hóa còn sót lại trong ESP32
- Microchip ESP32 của nhà sản xuất Trung Quốc Espressif có chứa các lệnh Bluetooth không xuất hiện trong tài liệu công khai
- ESP32 là vi điều khiển cung cấp kết nối Wi-Fi và Bluetooth cho thiết bị IoT, và tính đến năm 2023 đã được dùng trong hơn 1 tỷ thiết bị
- Các lệnh được phát hiện có thể được tận dụng cho những hành vi sau
- Giả mạo để trông như một thiết bị đáng tin cậy
- Truy cập dữ liệu trái phép
- Di chuyển sang các thiết bị khác trong mạng
- Khả năng duy trì tồn tại lâu dài
Phát hiện của Tarlogic và công cụ nghiên cứu
- Miguel Tarascó Acuña và Antonio Vázquez Blanco của Tarlogic Security, Tây Ban Nha, đã trình bày kết quả nghiên cứu tại RootedCON ở Madrid
- Nhóm nghiên cứu cho rằng sự quan tâm đến nghiên cứu bảo mật Bluetooth đã giảm, nhưng không phải vì giao thức hay các triển khai đã trở nên an toàn hơn
- Nhiều cuộc tấn công được công bố gần đây không có công cụ hoạt động được, không chạy trên phần cứng phổ thông, hoặc phụ thuộc vào các công cụ cũ không còn được bảo trì nên không phù hợp với hệ thống hiện đại
- Tarlogic đã phát triển một USB Bluetooth driver mới viết bằng C
- Độc lập phần cứng và hoạt động đa nền tảng
- Có thể truy cập trực tiếp phần cứng mà không phụ thuộc vào API riêng của từng hệ điều hành
- Cho phép truy cập thô vào lưu lượng Bluetooth
Quyền kiểm soát cấp thấp mà các lệnh cho phép
- Các vendor-specific command ẩn đã được xác nhận trong firmware Bluetooth của ESP32
- Opcode là
0x3F - Có thể kiểm soát chức năng Bluetooth ở mức thấp
- Opcode là
- Tổng cộng có 29 lệnh không được tài liệu hóa được phát hiện
- Các chức năng chính liên quan đến
- Thao tác bộ nhớ với RAM và Flash
- Giả danh thiết bị thông qua giả mạo địa chỉ MAC
- Chèn gói LMP/LLCP
- Vì Espressif không công khai tài liệu cho các lệnh này, có khả năng chúng không được chủ ý để có thể truy cập, hoặc đã bị để sót do nhầm lẫn
- Vấn đề này được theo dõi dưới mã CVE-2025-27840
Khả năng tấn công và các hạn chế thực tế
- Nhóm nghiên cứu cho rằng các lệnh này có thể dẫn đến rủi ro triển khai độc hại ở cấp OEM hoặc tấn công chuỗi cung ứng
- Khả năng khai thác từ xa phụ thuộc vào cách Bluetooth stack của thiết bị xử lý lệnh HCI
- Trong các điều kiện sau, khả năng khai thác từ xa có thể tăng lên
- Khi kẻ tấn công đã có được quyền root
- Khi mã độc đã được cài cắm
- Khi một bản cập nhật độc hại mở ra quyền truy cập cấp thấp được phát hành
- Khi có firmware độc hại hoặc kết nối Bluetooth rogue liên quan
- Nhìn chung, truy cập vật lý vào giao diện USB hoặc UART của thiết bị là kịch bản tấn công thực tế hơn
- Tarlogic cho rằng nếu chiếm được một thiết bị IoT có ESP32, kẻ tấn công có thể ẩn APT trong bộ nhớ ESP, điều khiển thiết bị qua Wi-Fi/Bluetooth và thực hiện các cuộc tấn công Bluetooth hoặc Wi-Fi nhằm vào thiết bị khác
- Các lệnh có thể sửa RAM và Flash có thể dẫn đến việc kiểm soát hoàn toàn chip ESP32 và đạt được khả năng tồn tại lâu dài ở cấp chip
Giải thích của Espressif và kế hoạch khắc phục
- BleepingComputer ban đầu đã yêu cầu Espressif bình luận nhưng không nhận được phản hồi ngay
- Sau đó, Espressif đã đưa ra lập trường chính thức về phát hiện của Tarlogic
- Công ty giải thích rằng các chức năng được phát hiện là lệnh debug phục vụ mục đích kiểm thử nội bộ
- Các lệnh này là một phần trong triển khai giao thức HCI (Host Controller Interface) được công nghệ Bluetooth sử dụng
- HCI được dùng bên trong sản phẩm để giao tiếp giữa các lớp Bluetooth
- Espressif cho rằng dù các lệnh debug tồn tại, bản thân chúng không thể tạo ra rủi ro bảo mật cho chip ESP32
- Tuy nhiên, hãng sẽ cung cấp bản sửa phần mềm để loại bỏ các lệnh không được tài liệu hóa
Chỉnh sửa thuật ngữ và cập nhật bài viết
- Trong bản cập nhật ngày 9/3/2025, tiêu đề và nội dung đã được chỉnh sửa để phản ánh lo ngại về cách gọi các lệnh không được tài liệu hóa là “backdoor”
- Ngày 8/3/2025, lập trường của Tarlogic đã được bổ sung
- Ngày 9/3/2025, CVE ID đã được bổ sung
- Ngày 10/3/2025, lập trường chính thức của Espressif đã được bổ sung
1 bình luận
Các ý kiến trên Hacker News
Tôi nghĩ tiêu đề hơi gây hiểu lầm. Nếu tôi đọc đúng thì backdoor được nói ở đây là thứ cho phép máy tính đọc và ghi bộ nhớ cũng như các chức năng cấp thấp của chính adapter USB Bluetooth của nó.
Có vẻ thứ này không thể bị khai thác qua mạng không dây. Những lệnh gỡ lỗi không được ghi tài liệu như thế này khá phổ biến; tôi từng thấy chức năng tương tự trên adapter WiFi và bộ thu GPS. Chỉ là người ta tìm ra bằng cách đảo ngược firmware chip hoặc driver của nhà cung cấp, chứ nó không được ghi tài liệu, và bản thân nó không phải vấn đề có tác động lớn. Nếu nó cho phép firmware không được ký, thì cũng dễ bị tổn thương tương tự.
Nếu có thể dùng nó từ nơi khác ngoài host thì lại là câu chuyện hoàn toàn khác.
Espressif gần như là ngoại lệ hiếm hoi trong lĩnh vực này về độ cởi mở. Họ đã đóng góp cho cả toolchain Rust mã nguồn mở dành cho chip của mình, và với modem stack không thể công khai vì mã có giấy phép, họ thậm chí còn công khai khuyến khích đảo ngược. Tôi không muốn cái giá phải trả cho việc tỏ ra cởi mở dù chỉ một chút lại là PR xấu và có hại.
“Tùy vào cách Bluetooth stack trên thiết bị xử lý các lệnh HCI, việc khai thác backdoor từ xa có thể khả thi thông qua firmware độc hại hoặc kết nối Bluetooth độc hại.”
Nói ngắn gọn, nếu bạn có một driver stack an toàn và tin tưởng toàn bộ mã cục bộ, thì các phần mở rộng HCI của nhà cung cấp không phải vấn đề.
Tuy nhiên, các phần mở rộng HCI rất dễ trở thành lỗ hổng bảo mật. Vấn đề là HCI trộn lẫn đầu vào do kẻ tấn công kiểm soát với một giao diện phức tạp và việc phân tích cú pháp khó nhằn. Như lỗ hổng BleedingTooth vài năm trước đã cho thấy, rất dễ mắc sai lầm.
Có những chức năng như vậy cũng khiến việc pivot từ các lỗ hổng khác trở nên dễ hơn, nhưng trên hầu hết hệ thống thì chuyện đó gần như là “quả treo thấp”.
[0] https://google.github.io/security-research/pocs/linux/bleedi...
Ngay cả bỏ qua trường hợp tệ nhất của web API, giả sử bạn chạy một phần mềm nửa tin nửa ngờ trong VM lồng nhau 3 tầng để tránh rủi ro. Phần mềm đó đưa ra lý do nghe hợp lý rằng nó cần truy cập Bluetooth, và bạn cho phép ngoại lệ. Bạn không thích kết quả nên xóa phần mềm và reset cả ba tầng VM. Trông như đã xong, nhưng thứ mà malware cài vào ESP khi còn có quyền truy cập có thể vẫn còn đó.
Truy cập không được ghi tài liệu vào thiết bị con của chính mình có thể trở thành chuyện thực sự tệ, đặc biệt khi có liên quan đến persistence.
Có thể hình dung tình huống ESP32 được dùng không phải như một SoC độc lập, mà như một “modem” WiFi/Bluetooth gắn với hệ thống host qua liên kết serial.
Về lý thuyết, kẻ tấn công có thể dùng các lệnh không được ghi tài liệu để quét, spoof hoặc tấn công các thiết bị Bluetooth xung quanh. Có khi còn làm được mà không cần lấy quyền root trên thiết bị đang host ESP32.
Chắc họ sẽ ngạc nhiên khi biết có thể ghi lại firmware ổ đĩa từ trong OS với quyền root.
Thứ các nhà nghiên cứu tìm thấy là một tính năng phần cứng không được ghi tài liệu, cho phép người đã có quyền thực thi mã truy cập cấp thấp vào WiFi stack của ESP32 sâu hơn dự kiến.
Gọi nó là “backdoor” thuần túy là clickbait.
Tôi thấy khó hiểu. Ý là có vài lệnh không được ghi tài liệu trong Bluetooth stack à? Nếu chỉ mã đã chạy trên thiết bị mới truy cập được thì có vẻ khó gọi là backdoor.
Nghe không giống thực thi mã từ xa.
Vì vậy có khả năng một chương trình user space, tệ hơn là chương trình WebBLE, thêm payload độc hại tồn tại lâu dài vào adapter. Một beacon theo dõi vẫn còn sau khi thay ổ đĩa thì đáng sợ, nhưng đó không phải thực thi mã từ xa.
Về lý thuyết, hẳn phải có khả năng truy cập cấp thấp vào chính chip vô tuyến Bluetooth được kết nối, nên tôi nghĩ chuyện này phần nào cũng nằm trong dự đoán?
Thiết bị có các giao diện cấp thấp như vậy thì tốt hơn. Vấn đề có thể không phải là sự tồn tại của nó, mà là thiếu tài liệu.
Trước đây, người ta từng dùng các lệnh đọc/ghi bộ nhớ qua USB trên chip vô tuyến Qualcomm để mở khóa các thiết bị bị khóa và giành quyền sở hữu. Đó là đọc/ghi hoàn toàn ngoài băng nên có thể không hay lắm, nhưng nếu thứ này chỉ truy cập được từ mã đã flash thì còn tốt hơn.
Slide tiếng Tây Ban Nha: https://www.documentcloud.org/documents/25554812-2025-rooted...
Tóm lại, họ đã reverse engineer firmware và tìm ra các lệnh HCI thực hiện những việc như đọc/ghi bộ nhớ, gửi gói tin, đặt địa chỉ MAC
Không hẳn là backdoor. Tôi không rõ các nhà nghiên cứu gọi nó như vậy, hay vì bài trình bày bằng tiếng Tây Ban Nha nên không biết, hoặc cũng có thể giới báo chí gọi là backdoor để câu thêm click
Để dùng các lệnh này, cần có quyền truy cập tùy ý để gửi lệnh HCI đến thiết bị. Nghĩa là bạn đã kiểm soát thiết bị và cách nó hoạt động rồi. Nó không bị khai thác từ xa qua liên kết không dây. Bất kỳ exploit nào cũng phải đã có quyền kiểm soát toàn bộ thiết bị, và đến thời điểm đó thì việc đổi địa chỉ MAC hay gửi gói tin không có gì đáng ngạc nhiên
Nghiên cứu thì thú vị, nhưng việc đóng gói nó thành “backdoor” thật sự làm mất hứng. Tôi không biết trách nhiệm dùng từ thuộc về ai, nhưng có lẽ là các nhà báo
Một phép ví von quen thuộc hơn: hãy tưởng tượng phát hiện ra bộ điều khiển Ethernet của một chip IoT phổ biến có thể đổi địa chỉ MAC hoặc gửi gói tin tùy ý theo chỉ thị của firmware. Chỉ khác là đây là Bluetooth, còn bản chất câu chuyện thì giống nhau
https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
Vì vậy mới có các công cụ Windows như https://macaddresschanger.com/ và bdaddr trên Linux. Phần lớn có vẻ là clone của thiết kế CSR, và lệnh đặt địa chỉ cũng đã được biết rõ. https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool...
Ở đây còn loại bỏ luôn yêu cầu phải có cáp Ethernet
Có thể lái một chiếc van trắng ghi “Free Candy / BLE Persistent Threats”, đi qua máy dò kim loại trên đường sang Trung Quốc và vét sạch thiết bị
Không dây, có thể lây lan như worm, gửi gói tin tùy ý, spoof thiết bị tùy ý, vậy mà bạn vẫn không thấy vấn đề à?
Tôi ghét kiểu bài viết giật gân như thế này. Giờ có lẽ Espressif sẽ cảm thấy bị áp lực phải khép kín hơn
Người ta vô tư cài các driver binary blob mù mờ chạy trong kernel space trên desktop và laptop, không có quyền root trên chính điện thoại của mình do cloud kiểm soát, nhưng vài lệnh cấp thấp ESP32 không được tài liệu hóa mà vốn đòi hỏi thiết bị đã bị xâm nhập lại trở thành một vector đe dọa đáng lên báo
Tôi thật sự tò mò không biết có gì bị thất lạc trong quá trình dịch không. Trước đây thì người ta chỉ thấy nó ngầu và tìm cách biến nó thành radio định nghĩa bằng phần mềm
Bản thân nghiên cứu thì tốt, nhưng tiêu đề thì tệ. Xét như một vector tấn công, nó cần truy cập vật lý, và trong hầu hết mọi trường hợp thì những việc này vốn đã có thể làm bằng cách khác
Tiêu đề tốt hơn nên là “Phát hiện các lệnh không được tài liệu hóa trong chip Bluetooth phổ biến”
Tiêu đề này là dối trá. Nếu là backdoor trong chip Bluetooth, nó phải cho phép kẻ tấn công qua không dây đạt được thực thi mã trên chip
Bài này nói về việc driver thiết bị trên thiết bị được kết nối có thể đạt được thực thi mã trên chip, điều này không vi phạm ranh giới bảo mật
Trong một hệ sinh thái báo chí vận hành đúng, cần có bài đính chính, và uy tín của cơ quan viết bài cũng phải bị ảnh hưởng nặng. Đáng tiếc là chuyện đó sẽ không xảy ra