Lỗ hổng tiêm phím Bluetooth trên Android, Linux, macOS và iOS

 (github.com/skysafe)
2 điểm bởi GN⁺ 2023-12-17 | 1 bình luận | Chia sẻ qua WhatsApp
  • CVE-2023-45866 là lỗ hổng bypass xác thực trong Bluetooth stack của nhiều hệ điều hành, cho phép kết nối bàn phím giả và tiêm phím mà không cần người dùng xác nhận
  • Kẻ tấn công ở gần có thể thử thực hiện các hành động như cài ứng dụng, chạy lệnh tùy ý, chuyển tiếp tin nhắn chỉ với máy tính Linux và adapter Bluetooth thông thường, không cần thiết bị đặc biệt
  • Điều kiện bị ảnh hưởng khác nhau tùy nền tảng: với Android, việc Bluetooth có bật hay không là yếu tố chính; với Linux/BlueZ là trạng thái discoverable/connectable; còn với iOS và macOS là việc Magic Keyboard đã được ghép đôi hay chưa
  • Android 11-14 được giảm thiểu bằng mức bản vá bảo mật 2023-12-05, nhưng Android 4.2.2-10 không có bản sửa; BlueZ từng có bản sửa từ năm 2020 nhưng mặc định bị vô hiệu hóa
  • Những tác vụ yêu cầu mật khẩu hoặc xác thực sinh trắc không thể được xử lý chỉ bằng tiêm phím, nhưng thiết bị chưa vá có thể bị phơi nhiễm trước tấn công Bluetooth cự ly gần

Tiêm phím Bluetooth không cần xác thực

  • CVE-2023-45866 là lỗ hổng cho phép tiêm phím Bluetooth không cần xác thực trên Android, Linux, macOS và iOS
  • Trong nhiều Bluetooth stack, kẻ tấn công có thể bypass xác thực để kết nối với một host ở trạng thái discoverable mà không cần người dùng xác nhận và tiêm phím
  • Kẻ tấn công ở gần có thể thiết lập kết nối Bluetooth chưa xác thực với thiết bị dễ bị tấn công và thực hiện các hành động sau bằng phím nhập
    • Cài ứng dụng
    • Chạy lệnh tùy ý
    • Chuyển tiếp tin nhắn
  • Cuộc tấn công không cần phần cứng đặc biệt, có thể thực hiện bằng máy tính Linux và adapter Bluetooth thông thường
  • Chi tiết khai thác đầy đủ và script PoC dự kiến được công bố vào ngày 12-14 tháng 1, trong tuần diễn ra ShmooCon

Điều kiện tấn công theo từng nền tảng

  • Lỗ hổng hoạt động bằng cách đánh lừa state machine của Bluetooth host để ghép đôi với bàn phím giả mà không cần người dùng xác nhận
  • Cơ chế ghép đôi không xác thực làm nền tảng vốn có trong đặc tả Bluetooth, và các lỗi theo từng triển khai đã khiến nó lộ ra thành bề mặt tấn công
  • Các điều kiện cần có trên thiết bị chưa vá khác nhau tùy hệ điều hành
    • Android: dễ bị tấn công nếu Bluetooth đang bật
    • Linux/BlueZ: Bluetooth phải ở trạng thái discoverable/connectable
    • iOS và macOS: dễ bị tấn công nếu Bluetooth đang bật và Magic Keyboard đã được ghép đôi với điện thoại hoặc máy tính
  • Sau khi kẻ tấn công ghép đôi với điện thoại hoặc máy tính mục tiêu, chúng có thể tiêm phím với quyền của nạn nhân
  • Những hành động yêu cầu mật khẩu hoặc xác thực sinh trắc không thể được thực hiện chỉ bằng tiêm phím

Lỗ hổng cũ được phát hiện sau MouseJack

  • Nghiên cứu MouseJack được công bố năm 2016 nhắm vào các giao thức không dây tùy biến của thiết bị ngoại vi, không phải Bluetooth
  • Nghiên cứu lần này bắt đầu trong quá trình xem xét Bluetooth và môi trường Apple, với đối tượng là Apple Magic Keyboard
  • Trên macOS và iOS, tiêm phím Bluetooth không cần xác thực đã được phát hiện, và cả hai nền tảng đều có thể bị khai thác ngay cả trong Lockdown Mode
  • Sau đó, các lỗ hổng tương tự cũng được xác nhận trên Linux và Android, khiến vấn đề trông giống lỗi ở giao thức hơn là lỗi triển khai đơn thuần; việc kiểm tra đặc tả Bluetooth HID cho thấy nó thuộc cả hai loại
  • Một số lỗ hổng còn cũ hơn MouseJack, và việc tiêm phím có thể được tái hiện tới tận Android 4.2.2

Ảnh hưởng với Android và trạng thái bản vá

  • Các thiết bị và phiên bản Android được xác nhận là dễ bị tấn công trong thử nghiệm gồm:
    • Pixel 7, Android 14
    • Pixel 6, Android 13
    • Pixel 4a (5G), Android 13
    • Pixel 2, Android 11
    • Pixel 2, Android 10
    • Nexus 5, Android 6.0.1
    • BLU DASH 3.5, Android 4.2.2
  • Mức bản vá bảo mật 2023-12-05 giảm thiểu lỗ hổng trên Android 11-14
  • Không có bản sửa khả dụng cho Android 4.2.2-10
  • Lịch trình công bố như sau
    • 2023-08-05: Báo cáo lỗ hổng cho Google
    • 2023-12-06: Công bố
  • Google cho biết bản sửa cho vấn đề ảnh hưởng đến Android 11-14 được cung cấp cho các OEM bị ảnh hưởng, và tất cả thiết bị Pixel hiện còn được hỗ trợ sẽ nhận bản sửa qua bản cập nhật OTA tháng 12

Ảnh hưởng với Linux/BlueZ và bản vá

  • Các phiên bản Ubuntu được xác nhận là dễ bị tấn công trong thử nghiệm là 18.04, 20.04, 22.04, 23.10
  • Theo Google, ChromeOS không bị ảnh hưởng; dù chưa thử nghiệm trực tiếp, cấu hình BlueZ dường như đã giảm thiểu lỗ hổng
  • Lỗ hổng Linux đã được sửa vào năm 2020 với mã CVE-2020-0556, nhưng bản sửa đó mặc định bị vô hiệu hóa
  • ChromeOS được biết đến là hệ điều hành dựa trên Linux duy nhất đã bật bản sửa này
  • Bản vá BlueZ cho CVE-2023-45866 bật mặc định bản sửa năm 2020
  • Bản vá BlueZ liên quan:
  • Thông tin liên quan đến Ubuntu:
  • Thông tin liên quan đến Debian:
  • Thông tin liên quan đến Fedora:
  • Lịch trình công bố như sau
    • 2023-08-10: Báo cáo lỗ hổng cho Canonical
    • 2023-09-25: Báo cáo lỗ hổng cho Bluetooth SIG
    • 2023-10-02: Mở case với CERT/CC
    • 2023-12-06: Công bố

Ảnh hưởng với macOS và iOS

  • Các thiết bị macOS đã được thử nghiệm và xác nhận là dễ bị tấn công gồm:
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • Lockdown Mode của macOS không chặn được cuộc tấn công
  • macOS Sonoma 14.2 đã sửa lỗ hổng
  • Lịch trình công bố của macOS như sau
    • 2023-08-01: Báo cáo lỗ hổng cho Apple
    • 2023-12-06: Công bố
  • Thiết bị iOS đã được thử nghiệm và xác nhận là dễ bị tấn công là iPhone SE chạy iOS 16.6
  • Lockdown Mode của iOS cũng không chặn được cuộc tấn công
  • Lịch trình công bố của iOS như sau
    • 2023-08-04: Báo cáo lỗ hổng cho Apple
    • 2023-12-06: Công bố

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-17
Các ý kiến trên Hacker News

  • Tôi đã phải tìm hiểu một chút để kiểm tra việc này; để an toàn thì trên Android, tốt nhất là tắt Bluetooth khi không dùng. Tuy nhiên, trong lúc đang dùng thì vẫn dễ bị tấn công
    Pixel của tôi đã nhận bản cập nhật bảo mật 2023-12-05 và vấn đề này đã được sửa, nhưng với thiết bị không phải Pixel thì tôi không rõ
    Trên Linux, hãy mở /etc/bluetooth/input.conf và đặt ClassicBondedOnly=true. Trường hợp của tôi không cần thêm mới, chỉ cần bỏ chú thích là được. Trong phiên bản bluetoothd tiếp theo, giá trị mặc định sẽ là true, nhưng hiện giờ bạn có thể tự đặt và sau đó cần khởi động lại dịch vụ Bluetooth
    macOS hoặc iOS thì tôi không biết vì không có thiết bị tương ứng

    • Tôi luôn khó chịu vì sau khi cập nhật iOS, Bluetooth lúc nào cũng tự bật lại. Tôi đã thắc mắc mãi vì sao lại như vậy trong khi thực tế chẳng dùng đến
      Wi-Fi cũng ở tình trạng như pho mát đầy lỗ, không thể tắt hoàn toàn từ Trung tâm điều khiển
    • Trên bluez v5.70-4 của Fedora 38, có vẻ từ ngày 7 tháng 12 giá trị mặc định đã là true
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • Thật tiếc là trên iOS việc tắt Bluetooth quá phiền phức. Android chỉ cần vuốt rồi bấm, còn iOS thì phải vuốt, nhấn giữ hai lần, bấm hai lần
      Sau khi chuyển từ Android sang, tôi đã cố một thời gian nhưng cuối cùng cũng bỏ cuộc
    • Nhìn trang đó thì thấy nói rằng nó chỉ hoạt động với những thứ không yêu cầu mật khẩu hoặc xác thực sinh trắc học
      Khi không dùng điện thoại thì cứ chủ động khóa lại, còn nếu đang dùng mà có phím được gửi tới thì sẽ thấy trên màn hình, nên việc để Bluetooth bật cũng không có vẻ kinh khủng đến vậy
    • Tôi tự hỏi liệu có cách nào kiểm tra GrapheneOS đã sửa lỗi này trên nhánh sunfish(4a) chưa. Vì là Pixel 4a nên tôi bị kẹt ở Android 13, và cần Bluetooth để mở cửa xe
      Nếu GrapheneOS đã sửa thì cuối cùng đây sẽ là lý do để chuyển sang, nhưng điện thoại hiện tại vẫn hoạt động tốt nên khó biện minh cho việc mua máy mới

  • Tôi thắc mắc vì Windows hoàn toàn không được nhắc tới. Nhìn bề ngoài thì nghe như tin tốt, nhưng cần biết vì sao Windows thực sự không bị ảnh hưởng để đánh giá mức độ rủi ro
    Ví dụ, nếu biết trong Bluetooth stack của Windows có cấu trúc tương ứng với ClassicBondedOnly=false của BlueZ hay không, thì trong môi trường cần gia cố có thể theo dõi xem giá trị đó có phải là true hay không
    Hoặc có thể stack hoạt động hoàn toàn khác, nên những điều cần cân nhắc cũng hoàn toàn khác
    Tôi mong chờ video có nhiều PoC và demo, nhưng Windows có thị phần lớn và cũng có nhiều quản trị viên hệ thống sẽ bối rối, nên nếu có thông tin thì tốt. “Chưa thử tấn công Windows” cũng là thông tin hữu ích

    • Có thể Windows không dễ bị tấn công bởi kiểu tấn công cụ thể này
      Nhưng nếu dùng Flipper Zero để tạo một thiết bị Bluetooth, ngay khi máy khách Windows kết nối, nó có thể được nhận diện là bàn phím và chạy lệnh PowerShell tùy ý. Cá nhân tôi chỉ từng dùng để mở YouTube và RickRoll, chưa thử gì bất hợp pháp
      Giờ tôi đã tắt hết Bluetooth, nhưng không biết cách gỡ bluez mà không làm hỏng Linux
    • Có lẽ vì trên Windows, Bluetooth bình thường cũng hiếm khi hoạt động tử tế
    • Bạn nói Bluetooth stack của Windows tương ứng với ClassicBondedOnly=false của BlueZ; có phải ý bạn là ClassicBondedOnly=true không?
    • Tôi nghĩ là vì họ chưa thử việc này trên Windows

  • Thật tuyệt khi tin như thế này xuất hiện vào lúc ngành công nghiệp đã loại bỏ kết nối âm thanh vật lý trên điện thoại và thúc ép dùng không dây. Làm tốt lắm

    • USB-C DAC rẻ và có thể mua rộng rãi
    • Lỗ hổng này là vấn đề tiêm phím bấm vào bàn phím và chuột không dây đã kết nối.[1] Việc ngành điện thoại chuyển sang USB-C khiến kết nối có dây trở nên dễ dàng hơn bao giờ hết
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • Lỗ hổng này hoạt động bằng cách đánh lừa máy trạng thái của Bluetooth host để ghép đôi với bàn phím giả mà không cần người dùng xác nhận. Cơ chế nền tảng là ghép đôi không xác thực được định nghĩa trong đặc tả Bluetooth, còn lỗi theo từng triển khai đã phơi nó ra cho kẻ tấn công
    Nhưng tại sao lại muốn cho phép ghép đôi âm thầm như vậy? Tôi muốn biết chi tiết hơn về mục đích dự kiến của cơ chế gặp vấn đề này

    • Theo đặc tả Bluetooth thì là vì nhiều thiết bị không phải máy tính. Ví dụ, khi ghép đôi tay cầm đầu tiên với PlayStation, nó giúp bạn không phải cắm chuột USB để bấm “cho phép ghép đôi”
      Còn vì sao trên các thiết bị thực tế bị ảnh hưởng họ lại để như vậy thì tôi không biết
    • Đó chỉ là một thiết kế cũ từ thời ngây thơ hơn. Đặc tả mới không cho phép, nhưng các Bluetooth stack đã tắt hành vi mới để tối đa hóa khả năng tương thích

  • Vấn đề này đã được sửa trong macOS 14.2 và iOS 17.2
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • Trên Arch Linux, lỗi này đã được sửa từ bluez 5.70-2 [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • Đoạn “lúc đó Bluetooth trông đáng sợ nên cứ mặc định là nó an toàn” thật sự gây đồng cảm. Có vẻ huyền thoại rằng ở đâu đó phía trên một stack công nghệ phức tạp sẽ có những người thật sự hiểu rõ, và họ sẽ không chống đỡ một lâu đài xây trên cát bằng vài cây gậy, đã sinh ra từ chính cảm giác choáng ngợp đó

  • Tôi nghi ngờ liệu việc này có thực tế khi nhắm vào điện thoại hay máy tính hay không, nhưng nếu ở vị trí phải quản lý kiosk sao cho không ai táy máy được, thì đời có vẻ đã thú vị hơn một chút

    • Khoảng 10 năm trước, tôi từng vô tình để lộ ra Internet một máy Linux có VNC không đặt mật khẩu. Chỉ sau vài phút đã có người kết nối vào và cố chạy thứ gì đó bằng nhập phím tự động, nhưng hành vi đó rõ ràng là nhắm vào Windows
      Chỉ cần cài thành công một backdoor là từ đó có thể tiếp tục thao tác
      Nếu là tấn công có chủ đích, chỉ cần gửi phím Shift mỗi phút để màn hình không bị khóa, rồi sau đó trực tiếp đến trước máy làm gì đó cũng có thể là đủ
    • Trên máy tính, có vẻ cũng có thể giấu một sudo hoặc su bị cài bẫy ở đâu đó rồi thêm vào $PATH

  • USB cũng tương tự. Cắm bàn phím vào cổng “chỉ sạc” thì nó hoạt động. Tôi đã tự thử trên Android, và ở đây từng bị mắng rằng chuyện này về thực chất không thể bị khai thác

    • Cổng Android chỉ dùng để sạc thôi sao? Nó cũng rất hữu ích cho HDMI và có thể dùng cho thiết bị ngoại vi nữa
      Dù vậy tôi không xem đây là lỗ hổng. Nó chỉ là một tính năng hữu ích. Vấn đề ở đây là ai đó có thể làm việc này mà người dùng không nhận ra, kể cả trong lúc đang thực hiện thao tác nhạy cảm
      Dự án tuyệt vời được đăng hôm qua https://mitxela.com/projects/smsc cũng có thể được dùng trên điện thoại theo cách này
    • Tôi tò mò không biết thiết bị Android nào có cổng “chỉ sạc” về mặt vật lý

  • Lỗ hổng trên Linux đã được sửa vào năm 2020 (CVE-2020-0556), nhưng bản sửa đó vẫn bị vô hiệu hóa theo mặc định. Được biết chỉ ChromeOS bật bản sửa này, dù Ubuntu, Debian, Fedora, Gentoo, Arch và Alpine đều đã ra thông báo

    • Chỉ mất 30 giây để kiểm tra xem nó đã vào NixOS chưa[1]. Thêm 30 giây nữa thì thấy nó đã được vá vào 2023-12-08 08:23 GMT+13, một ngày sau khi bài viết được đăng
      Nhưng nếu thông báo của bản phân phối nói rằng chỉ cần nâng cấp là sẽ được sửa[2], thì tôi không hiểu “bản sửa bị tắt theo mặc định” nghĩa là gì. Có phải sau khi nâng cấp vẫn cần thay đổi cấu hình thủ công không? Bản sửa của NixOS có vẻ là đảo ngược giá trị mặc định
      Nếu ý là những người dùng đã đặt rõ ClassicBondedOnly=false cần phải đổi lại, thì đáng ra có thể viết rõ hơn nhiều
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1