CVE-2023-45866 蓝牙HID漏洞原理以及解决方案介绍

Wireless_Link

于 2025-02-13 19:41:51 发布

阅读量1.5k

点赞数 13

分类专栏： # 蓝牙协议栈精讲蓝牙协议栈文章标签： CVE-2023-45866 蓝牙HID漏洞蓝牙CVE

本文链接：https://blog.csdn.net/XiaoXiaoPengBo/article/details/145619061

版权

蓝牙协议栈精讲同时被 2 个专栏收录

96 篇文章

订阅专栏

蓝牙协议栈

4 篇文章

订阅专栏

选用移远蓝牙协议栈，完美避开风险

一. CVE漏洞简介

1. 背景

因为本人是做蓝牙的，所以最近频繁收到客户询问CVE-2023-45866, 所以针对CVE-2023-45866我来做个简单的总结！

2. 漏洞介绍

具体介绍，可以参考下以下链接：

CVE -CVE-2023-45866

Bluetooth HID Hosts in BlueZ may permit an unauthenticated Peripheral role HID Device to initiate and establish an encrypted connection, and accept HID keyboard reports, potentially permitting injection of HID messages when no user interaction has occurred in the Central role to authorize such access. An example affected package is bluez 5.64-0ubuntu1 in Ubuntu 22.04LTS. NOTE: in some cases, a CVE-2020-0556 mitigation would have already addressed this Bluetooth HID Hosts issue。

可以看到这份公告仅仅提出了Bluez的影响，但是影响不仅仅是Linux Bluez，目前看下来Android,MacOS, Windows都会都到波及。

3. 攻击方式

a. 环境搭建

整个环境的可以有很多方式，但是归根结底就是DUT作为HID Host角色，被连接。

b. 使用开源工程攻击

目前我是下载了网络上一个开源的基于Bluez python脚本做的，使用方式如下：

git clone GitHub - marcnewlin/hi_my_name_is_keyboard

pip install pybluez

python3 keystroke-injection-android-linux.py -i hci0 -t xx:xx:xx:xx:xx:xx

其中xx:xx:xx:xx:xx:xx修改成你要攻击设备的蓝牙地址，另外使用这个前提是bluez已经enable成功，并且有hci0节点。

攻击成功截图如下：

攻击的后会非常严重，大家可以脑洞大开，我列下我能想到的

安全类	后果	影响
键盘注入攻击	攻击者可以模拟键盘输入，向目标设备发送任意命令或文本	在目标设备上执行恶意命令（如打开终端、运行脚本）。输入敏感信息（如密码、信用卡号）。发送恶意消息或邮件。
权限提升	攻击者可以通过注入的命令提升权限，获取对设备的更高控制权	安装恶意软件或后门。访问或修改系统文件。控制设备的其他功能（如摄像头、麦克风）。
数据窃取	攻击者可以窃取目标设备上的敏感数据	获取登录凭证、会话令牌。窃取个人文件、照片、文档。监控用户的键盘输入（如密码、聊天内容）。
设备控制	攻击者可以完全控制目标设备	锁定设备，使其无法使用。删除或加密文件（勒索软件攻击）。远程执行任意代码。
隐私泄露	攻击者可以访问设备的隐私数据	获取联系人、通话记录、短信。监控用户的活动（如浏览历史、位置信息）。
拒绝服务攻击	攻击者可以通过恶意输入使设备崩溃或无法使用	设备重启或死机。蓝牙功能失效。系统资源耗尽。
跨设备攻击	攻击者可以利用漏洞攻击同一网络中的其他设备	在局域网内传播恶意软件。攻击其他蓝牙设备（如智能家居设备、耳机）。

c. 攻击原理

我们来点技术干货，说明下此漏洞是通过什么方式攻击的，在介绍攻击原理之前，我们来普及几个概念，有助于我们更好的理解攻击原理：

HID协议：可以参考下我这篇HID协议的介绍：蓝牙人机接口设备协议（HID）概念以及封包格式介绍_usb hid 蓝牙 hid-CSDN博客

MITM：Man in the middle,说白了就是配对的过程是否需要人为介入

IO capability：IO(input/output)的能力,说白了就是根据能力的交互来选择什么样的方式人为介入配对(如果需要人为介入)，比如输入pin嘛，显示YES/NO让你点击等，我们来说下MAP表

可以看到如果不是OOB(out of band)配对，那么只有在双方都没有OOB，那么就走IO capabilities map来决定配对方式，下面我们来看下IO capability map表

说完了这个思路后，我们来为啥能攻击成功了

可以看到上图示我们虽然能io协商到数字对比

但是双方都没有MITM，所以导致中间人不需要介入，就自动回复了确认

后续就可以发送HID数据了·

所以就可以按照想要的为所欲为了！

二. 解决方案

1. 在访问security level profile建立l2cap的时候，拒绝临时bond连线连线

当IO cap交互的时候就auth是0的时候，是临时配对，并且不需要中间人介入

而此时如果访问需要security level的profile的时候拒绝连线

而Android最新的patch是这种解法

详细的内容如下：

From 25a7d9aaceea0f7d6cb4ae3da5aa66efb0bc7db8 Mon Sep 17 00:00:00 2001
From: Hui Peng <phui@google.com>
Date: Fri, 25 Aug 2023 17:15:38 -0700
Subject: [PATCH] Reject access to secure service authenticated from a temp
bonding [1]

Rejecct access to services running on l2cap

Backport of
Idef4ea28eb3d17b0807ab7dc6849433ddc5581b3

Bug: 294854926
Test: m com.android.btservices
Ignore-AOSP-First: security
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:232f4f81a9774196f688e956f50084514110798a)
Merged-In: Idef4ea28eb3d17b0807ab7dc6849433ddc5581b3
Change-Id: Idef4ea28eb3d17b0807ab7dc6849433ddc5581b3
---
system/stack/btm/btm_sec.cc | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/system/stack/btm/btm_sec.cc b/system/stack/btm/btm_sec.cc
index 4a83cde884..92ede3616a 100644
--- a/system/stack/btm/btm_sec.cc
+++ b/system/stack/btm/btm_sec.cc
@@ -207,6 +207,25 @@ static bool btm_dev_16_digit_authenticated(tBTM_SEC_DEV_REC* p_dev_rec) {
    return (false);
}

+/*******************************************************************************
+ *
+ * Function         access_secure_service_from_temp_bond
+ *
+ * Description      a utility function to test whether an access to
+ *                  secure service from temp bonding is happening
+ *
+ * Returns          true if the aforementioned condition holds,
+ *                  false otherwise
+ *
+ ******************************************************************************/
+static bool access_secure_service_from_temp_bond(const tBTM_SEC_DEV_REC* p_dev_rec,
+                                                 bool locally_initiated,
+                                                 uint16_t security_req) {
    +  return !locally_initiated && (security_req & BTM_SEC_IN_AUTHENTICATE) &&
    +    p_dev_rec->is_device_authenticated() &&
    +    p_dev_rec->is_bond_type_temporary();
    +}
+
/*******************************************************************************
  *
  * Function         BTM_SecRegister
@@ -1609,9 +1628,14 @@ tBTM_STATUS btm_sec_l2cap_access_req_by_requirement(
       }
 
       if (rc == BTM_SUCCESS) {
+        if (access_secure_service_from_temp_bond(p_dev_rec, is_originator, security_required)) {
+          LOG_ERROR("Trying to access a secure service from a temp bonding, rejecting");
+          rc = BTM_FAILED_ON_SECURITY;
+        }
+
         if (p_callback)
-          (*p_callback)(&bd_addr, transport, (void*)p_ref_data, BTM_SUCCESS);
-        return (BTM_SUCCESS);
+          (*p_callback)(&bd_addr, transport, (void*)p_ref_data, rc);
+        return (rc);
       }
     }
 
@@ -4430,6 +4454,13 @@ tBTM_STATUS btm_sec_execute_procedure(tBTM_SEC_DEV_REC* p_dev_rec) {
     return (BTM_FAILED_ON_SECURITY);
   }
 
+  if (access_secure_service_from_temp_bond(p_dev_rec,
+                                           p_dev_rec->IsLocallyInitiated(),
+                                           p_dev_rec->security_required)) {
+    LOG_ERROR("Trying to access a secure service from a temp bonding, rejecting");
+    return (BTM_FAILED_ON_SECURITY);
+  }
+
   /* All required  security procedures already established */
   p_dev_rec->security_required &=
       ~(BTM_SEC_OUT_AUTHENTICATE | BTM_SEC_IN_AUTHENTICATE |
-- 
2.42.0.820.g83a721a137-goog