BLUFFS - lỗ hổng trong Bluetooth cho phép tấn công MITM

Daniele Antonioli, nhà nghiên cứu bảo mật Bluetooth, người trước đây đã phát triển các kỹ thuật tấn công BIAS, BLUR và KNOB, đã xác định được hai lỗ hổng mới (CVE-2023-24023) trong cơ chế đàm phán phiên Bluetooth, ảnh hưởng đến tất cả các triển khai Bluetooth hỗ trợ chế độ Kết nối an toàn. " và "Ghép nối đơn giản an toàn", tuân thủ các thông số kỹ thuật của Bluetooth Core 4.2-5.4. Để minh chứng cho ứng dụng thực tế của các lỗ hổng đã được xác định, 6 tùy chọn tấn công đã được phát triển cho phép chúng tôi xâm nhập vào kết nối giữa các thiết bị Bluetooth đã ghép nối trước đó. Mã triển khai các phương thức tấn công và tiện ích để kiểm tra lỗ hổng được xuất bản trên GitHub.

Các lỗ hổng đã được xác định trong quá trình phân tích các cơ chế được mô tả trong tiêu chuẩn để đạt được bí mật chuyển tiếp (Bí mật chuyển tiếp và tương lai), chống lại sự xâm phạm của các khóa phiên trong trường hợp xác định khóa vĩnh viễn (việc xâm phạm một trong các khóa vĩnh viễn sẽ không dẫn đến để giải mã các phiên bị chặn trước đó hoặc trong tương lai) và sử dụng lại khóa phiên (khóa từ phiên này sẽ không được áp dụng cho phiên khác). Các lỗ hổng được tìm thấy có thể bỏ qua biện pháp bảo vệ được chỉ định và sử dụng lại khóa phiên không đáng tin cậy trong các phiên khác nhau. Các lỗ hổng này xảy ra do sai sót trong tiêu chuẩn cơ sở, không dành riêng cho từng ngăn xếp Bluetooth riêng lẻ và xuất hiện trong các chip của các nhà sản xuất khác nhau.

 BLUFFS - lỗ hổng trong Bluetooth cho phép tấn công MITM

Các phương thức tấn công được đề xuất triển khai các tùy chọn khác nhau để tổ chức giả mạo các kết nối Bluetooth cổ điển (LSC, Kết nối an toàn kế thừa dựa trên nguyên tắc mật mã lỗi thời) và kết nối Bluetooth bảo mật (SC, Kết nối an toàn dựa trên ECDH và AES-CCM) giữa hệ thống và thiết bị ngoại vi, như cũng như tổ chức các cuộc tấn công kết nối MITM đối với các kết nối ở chế độ LSC và SC. Người ta cho rằng tất cả việc triển khai Bluetooth tuân thủ tiêu chuẩn đều dễ bị ảnh hưởng bởi một số biến thể của cuộc tấn công BLUFFS. Phương pháp này đã được trình diễn trên 18 thiết bị của các công ty như Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell và Xiaomi.

 BLUFFS - lỗ hổng trong Bluetooth cho phép tấn công MITM

Bản chất của các lỗ hổng nằm ở khả năng, mà không vi phạm tiêu chuẩn, buộc kết nối sử dụng chế độ LSC cũ và khóa phiên ngắn (SK) không đáng tin cậy, bằng cách chỉ định entropy tối thiểu có thể có trong quá trình đàm phán kết nối và bỏ qua nội dung phản hồi với các tham số xác thực (CR), dẫn đến việc tạo khóa phiên dựa trên các tham số đầu vào cố định (khóa phiên SK được tính là KDF từ khóa cố định (PK) và các tham số được thỏa thuận trong phiên) . Ví dụ: trong cuộc tấn công MITM, kẻ tấn công có thể thay thế các tham số 𝐴𝐶 và 𝑆𝐷 bằng 1 trong quá trình đàm phán phiên và đặt entropy 𝑆𝐸 thành 1, điều này sẽ dẫn đến việc hình thành khóa phiên 𝑆𝐾 bằng một khóa thực tế entropy 7 byte (kích thước entropy tối thiểu tiêu chuẩn là 56 byte (XNUMX bit), có độ tin cậy tương đương với việc lựa chọn khóa DES).

Nếu kẻ tấn công cố gắng sử dụng khóa ngắn hơn trong quá trình đàm phán kết nối thì hắn có thể sử dụng vũ lực để xác định khóa vĩnh viễn (PK) được sử dụng để mã hóa và giải mã lưu lượng giữa các thiết bị. Vì cuộc tấn công MITM có thể kích hoạt việc sử dụng cùng một khóa mã hóa nên nếu tìm thấy khóa này, nó có thể được sử dụng để giải mã tất cả các phiên trong quá khứ và tương lai bị kẻ tấn công chặn.

 BLUFFS - lỗ hổng trong Bluetooth cho phép tấn công MITM

Để chặn các lỗ hổng, nhà nghiên cứu đề xuất thực hiện các thay đổi đối với tiêu chuẩn mở rộng giao thức LMP và thay đổi logic sử dụng KDF (Chức năng dẫn xuất khóa) khi tạo khóa ở chế độ LSC. Thay đổi này không phá vỡ khả năng tương thích ngược nhưng khiến lệnh LMP mở rộng được bật và gửi thêm 48 byte. Bluetooth SIG, cơ quan chịu trách nhiệm phát triển các tiêu chuẩn Bluetooth, đã đề xuất từ ​​chối các kết nối qua kênh liên lạc được mã hóa với các khóa có kích thước lên tới 7 byte như một biện pháp bảo mật. Việc triển khai luôn sử dụng Chế độ bảo mật 4 Cấp 4 được khuyến khích từ chối kết nối với các khóa có kích thước tối đa 16 byte.

Nguồn: opennet.ru

Thêm một lời nhận xét