2017年度安全报告--平台漏洞

,360 Computer Emergency Readiness Team, February 2018,文中部分信息直接参考外部文章（见参考），如有侵权或异议请联系 ,2017 年度安全报告平台漏洞Platform VulnerabilitiesIntel ME 固件漏洞博通 wifi 芯片漏洞WPA2 KRACK（密钥重载攻击）BlueBorne 蓝牙漏洞,2017 年度安全报告平台漏洞,360 Computer Emergency Readiness Team, February 2018,2,平台安全是计算机安全体系中重要的组成部分。平台对上层应用，服务，功能提供支持，主要体现在硬件，固件，协议及协议实现等。这方面有许多攻击方法，比如边信道攻击，中间人攻击，旁侧降权攻击等。这些高级攻击方法，如果结合平台安全中的漏洞，将会十分危险。本文是 360CERT 对 2017 年平台安全的总结。,Platform Vulnerabilities,360 Computer Emergency Readiness Team, February 2018,3,Platform Vulnerabilities,2017 年度安全报告平台漏洞平台安全中的攻击方法边信道攻击边信道最早的实践是通过采集加密电子设备在运行过程中的时间消耗、功率消耗或者电磁辐射消耗等边缘信息的差异性进行攻击的手段。而随着研究的深入，也逐渐从加密设备延伸到计算机内部 CPU、内存等之间的信息传递等方面。近 年， 这 种 攻 击 方 法 最 典 型 的 案 例 莫 过 于 Linux 下 TCP 边信 道 安 全 问 题（CVE-2016-5696）。 为 了 减 少 CPU 和 带 宽 资源浪费，要限制 challenge ACK 发出的数量，所以引入了这里的ACK Throttling 机 制。 正 是 这 个 ACK Throttling 机 制， 带 来 了边信道攻击的可行性。利用边信道攻击方式，攻击者不需要处在“中间人”的位置，整个过程不需要与受害者进行互动，这种攻击手法在平台安全中应用广泛。降级攻击降级攻击主要应用在安全协议方面，比较典型的一个例子便是 4G LTE 攻 击。 利 用 了 3GPP 的 漏 洞 取 得 手 机 的 IMSI 码， 通过 DoS 攻击迫使手机接入黑客控制的虚假 GSM 网络中。或者把手机导入一个与运营商网络连接的受黑客控制的合法基站上，从而能够对手机通信进行窃听以及对上网流量进行嗅探。这种攻击方法的应用还有很多，比如 HTTPS 降级攻击，TLS 降级攻击等。,中间人攻击中间人攻击（Man-in-the-MiddleAttack，简称“MITM 攻击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。这种攻击方法通过拦截正常的网络通信数据，并进行数据篡改和嗅探，而通信的双方却毫不知情。MITM 由来已久，但在今天仍然活跃，如 SMB 会话劫持、DNS 欺骗等攻击都是典型的 MITM 攻击。2017 年 披 露 了 CVE-2017-0783 和 CVE-2017-8628，攻 击 者 利 用 这 两 个 漏 洞， 可 以 分 别 在 Android 设 备 和 windows设备上进行 MITM 攻击。其他其他情景的攻击方法同样适用于平台安全中，比如暴力猜解，重放，接口鉴权攻击等。还 有 许 多 不 常 用 的 攻 击 方 法， 只 能 针 对 特 定 的 环 境。 比 如2017 的 WPA2 密 钥 重 载 攻 击， 他 让 我 们 意 识 到， 消 息 可 能 丢 失的协议可能会变得特别脆弱，毕竟这些协议用设计用来重传帧时，就有可能密钥重载。,2017 年度安全报告平台漏洞,360 Computer Emergency Readiness Team, February 2018,4,Intel ME 固件漏洞Intel 公司公布了一个严重高危级别安全漏洞，攻击者可以在目标操作系统不可直接访问的区域进行加载 / 执行任意代码博通 wifi 芯片漏洞今 年 披 露 的 一 枚 名 为 BroadPwn 远 程 代 码 执 行 漏 洞， 影 响 Andriod 和 IOS 数 十亿台设备WPA2 KRACK（密钥重载攻击）针 对 WiFi+WPA2 网 络 的 攻 击， 名 为 KRACK 的 漏 洞 攻 击 方 式 被 披 露。 利 用802.11i 中 4 次握手中的漏洞来最终实现解密和伪造加密的 WiFi 流量BlueBorne 蓝牙漏洞armis 披露了一系列蓝牙的漏洞，只要手机开启了蓝牙，就可能被远程控制。所有Android 智 能 机、 平 板、 可 穿 戴 设 备 均 受 到 4 个 高 危 漏 洞 的 影 响， 其 中 有 两 个 是远程代码执行漏洞（CVE-2017-0781）,2017 年 5 月2017 年 7 月2017 年 9 月2017 年 10 月,Platform Vulnerabilities,2017 年度安全报告平台漏洞,360 Computer Emergency Readiness Team, February 2018,5,Intel ME 固件漏洞事件描述Intel 芯片中有一个独立于 CPU 和操作系统的微处理器，叫做英特尔管理引擎 Intel Management Engine，简称 ME。多种技术基于 ME，例如代码处理、媒体 DRM、可信平台模块 TPM 等。ME 是一个有别于 CPU 的独立系统，它可以在不受 CPU 管控下通过搭配 AMT（英特尔主动管理技术）来远程管理企业计算机。AMT 技术能够自动执行一个独立于操作系统的子系统，使得在操作系统出现故障的时候，管理员能够在远程监视和管理客户端、进行远程管理和系统检测、软硬件检查、远端更新 BIOS 、病毒码及操作系统，甚至在系统关机的时候，也可以通过网络对服务器进行管理操作。该漏洞主要存在英特尔管理引擎（ME ）, 英特尔服务器平台服务（SPS），英特尔可信执行引擎（TXE）。攻击者可以模拟 ME/SPS/TXE，来影响本地安全认定的有效性，在目标操作系统不可直接访问的区域进行加载 / 执行任意代码，具备极高的隐蔽性，常规方法无法检测到。,根 据 intel 官 方 公 告， 相 关 产 品 漏 洞 一 共 有 8 个 CVE：CVE-2017-5705、CVE-2017-5706、CVE-2017-5707、CVE-2017-5708、CVE-2017-5709、CVE-2017-5710、CVE-2017-5711、CVE-2017-5712。 酷 睿， 至 强， 凌 动 ， 赛 扬 等部分型号产品受到该漏洞影响。事 实 上， 这 并 不 是 英 特 尔 第 一 次 被 曝 出 产 品 存 在 严 重 漏 洞。IntelME 固件漏洞相对于操作系统，用户是完全透明的。操作系统的一切安全机制，漏洞缓解机制都是无用的。Intel ME 固件漏洞主要影响的是服务器，个人 PC 平台。巧合的是，今年的一枚博通 wifi 芯片漏洞影响数十亿台 Android 和 IOS 设备，移动设备在今年也被披露存在平台安全问题，未能幸免。,2017 年 5 月 份， Intel 公 司 公 布了 一 个 严 重 高 危 级 别 安 全 漏 洞，攻击者可以在目标操作系统不可直接访问的区域进行加载 / 执行任意 代 码， 具 备 极 高 的 隐 蔽 性， 常规方法无法检测到。酷睿，至强，凌动等部分型号均受影响。,2017 年度安全报告平台漏洞,360 Computer Emergency Readiness Team, February 2018,6,2017 年 披 露 的 一 枚 名 为BroadPwn 远 程 代 码 执 行 漏 洞，影响 Android 和 iOS 数十亿台设备。7 月初，谷歌，苹果陆续发布了安全补丁。未进行安全更新的设备， 一 旦 置 身 在 恶 意 WiFi 范 围 内就会被黑客捕获、入侵。当手机打开 wifi 时， 无 需 任 何 操 作， 攻 击者 便 可 在 我 们 毫 无 察 觉 的 情 况 下，完全控制手机，这是多么恐怖的事情。,博通 wifi 芯片漏洞背景及相关知识在过去的一段时间，Wi-Fi 的使用再移动设备上已经普及。逐渐地，涉及物理层，数据链路层的 Wi-Fi 已经发展成为一套健全的规范。为 了 拓 展 和 解 决 各 种 未 知 的 复 杂 问 题， 供 应 商 已 经 开 始 生 产 基 于“FullMAC” 的 Wi-Fi SoC。 这 些 是 小 的 SoC 执 行 所 有 PHY,MAC 和 MLME 数据处理。FullMAC 芯片容易集成，在固件中实现 MLME 处理，这种解决方案降低了主机端的复杂性，十分受厂商欢迎。但是引入这些新硬件，运行专有和复杂的代码库，可能会削弱设备的整体安全性，引入危及整个系统的漏洞。,技术分析参考 Google 的 Project Zero 团队对该漏洞的分析，问题出在内部通信渠道。上图是追踪处理事件框架（dhd_wl_host_event）的入口点的控制流程，我们可以看到几个事件接收，并被独立处理。一旦初始完成，帧就被插入队列。然后事件由内核线程出队列，其唯一用处是从队列中读取事件并将其分派到相应的处理函数。这种关联是通过使用事件的内部“event_type”字段作为处理函数数组的索引来完成的，采用的 evt_handler。,360 Computer Emergency Readiness Team, February 2018,7,2017 年度安全报告平台漏洞该漏洞太过复杂，一些先决条件我们不进行探讨，直接指出到漏洞关键点：处于 dhd_handle_swc_evt 函数的 total_count 字段。漏洞的逻辑可归结为： “ WLC_E_PFN_SWC ” 类型的事件处理 SWC。 通信中的每个 SWC 事件帧包含事件（wl_pfn_significant_net_t），总计数（total_count ）和数组中的事件数（pkt_count ）。 当接收到 SWC 事件代码时，触发一个初始处理程序来处理事件。处理程序在内部调用“ dhd_handle_swc_evt ”函数来处理事件的数据。 dhd_handle_swc_evt 处 理 函 数 无 法 验 证 total_count 和pkt_count 之间的关系。关键函数：,“event_data”是通信的事件中封装的任意数据，函数首先初始化一个数组来保存事件的总数（如果之前没有分配的话），然后在缓冲区中建立 results_rxed_so_far 与传入数据的联系。但是，处理程序无法验证 total_count 和 pkt_count 之间的关系！攻击者可以指定一个小的 total_count 和一个大的 pkt_count ，触发一个简单的内核堆溢出。之后可以通过一些堆溢出利用方法，实现远程代码执行。该漏洞影响 Android 和 iOS 数十亿台设备。我们使用的智能机，平板电脑，都支持 wifi 功能，如果使用了博通受影响芯片的设备，均在危险之中。wi-fi 芯片这种基本的元件存在的漏洞，如果被利用的话，那么会有杀伤力会很惊人。我们都知道现在的智能机都支持热点功能，如果将该漏洞做成蠕虫勒索病毒，感染后，开启免密热点吸引其他手机连接，通过无线网络进行传播，俨然一场低配版的 Wannacry。说 到 wifi 芯 片 漏 洞， 不 得 不 提 今 年 披 露 的 WPA2 KRACK（ 密钥 重 载 攻 击 ）， 不 止 我 们 使 用 的 设 备 不 安 全， 我 们 wifi 使 用 的WPA2 加密协议也存在问题。,2017 年度安全报告平台漏洞,360 Computer Emergency Readiness Team, February 2018,8,WPA2 KRACK（密钥重载攻击）,相关知识当客户端要连接 WiFi 网络，自动开始（互相）身份验证和连接。图 2 描述了连接阶段的握手。但是当第一次连接到网络时，是没有实际的身份验证。相反，使用了开放系统身份验证，对客户端进行身份验证。实际身份验证在四次握手中使用。但真正的身份认证仅在两个采用 fast BSS transition 握手协议的相同网络 AP 之间漫游时使用。在开放式身份验证之后，客户端连接到网络中。通过客户端向 AP 发送一个连接请求完成。这条消息包含客户端希望使用的成对的密码组。AP 回复一个连接响应，通知客户端连接是否被成功建立。四 次 握 手 提 供 相 互 身 份 验 证， 基 于 共 享 密 钥 技 术， 这 种 技 术 称 为成 对 的 主 密 钥 PairwiseMaster Key(PMK)， 并 协 商 一 个 新 的会 话 秘 钥 PairWise Transient Key（PTK）。 在 这 次 握 手 中，客 户 端 称 为 supplicant， 而 AP 称 为 authenticator，PMK 由个 人 网 络 中 的 预 共 享 密 码 生 成， 在 企 业 网 络 中 使 用 802.1x 身份 验 证 来 进 行 协 商。PTK 由 PMK，Authenticator Nonce,(ANonce),Supplicant Nonce (SNonce) 和 supplicant 和authenticator 使用的 MAC 地址派生而来。一旦生成，PTK 被,分割成确认 key(KCK), 加密 Key(KEK)，和临时 Key(TK)，确认 Key 和加密 Key 使用来保护握手消息，TK 和数据机密性协议 是 用 来 保 护 正 常 数 据 帧， 如 果 使 用 了 WPA2， 四 次 握 手 协 议也 传 输 现 在 的 Group Temporal Key 组 临 时 密 钥（GTK） 到supplicant。四次握手中的每一条消息都是使用 EAPOL 帧格式（如下图）。对 字 段 进 行 介 绍 首 先， 消 息 的 头 部 定 义 了 所 代 表 的 消 息 类 型， 我们 将 使 用 message n 和 MsgN 来 代 表 四 次 握 手 中 第 n 段 消息。Replay count（重放计数器）字段用于检测重放的数据帧：authenticator 在 发 送 一 个 帧 之 后 会 自 增 长， 当 supplicant 对authenticator 发 送 的 EAPOL 帧 做 出 应 答 时， 它 使 用 相 同 的replaycount。Nonce 字 段 是 一 个 随 机 的 nones 值， 这 个 随 机值是 supplicant 和 authenticator 在生成新的会话秘钥这一步骤产生的。接下来，如果 EAPOL 帧传输一个组密钥，RSC（接受序列）包含了 key 起始包号。组密钥是存储在 Key Data 字段，使用加密 Key(KEK) 加密。最后，使用消息确认 Key(KCK) 来进行完整性校验 . MIC（Message Integrity Check）。,2017 年 10 月 16 日，,针,对 WiFi+WPA2 网 络， 名 为KRACK 的漏洞攻击方式被披露。KRACK 主 要 是 利 用 802.11i ，4 次握手中的漏洞来最终实现解密和 伪 造 加 密 的 WiFi 流 量， 该 漏 洞由来自 imec-DistriNet 的 MathyVanhoef 和 KU Leuven 发 现。本 次 漏 洞 事 件 有 多 种 攻 击 型 态，AP 热点端，中继端，和客户端均受 到 影 响。 根 据 和 部 分 厂 商 发 布 的 安 全 公 告综 合 分 析， 包 括 Linux,Android,Cisco wireless products,OpenBSD, MacOS, Windows,iOS 等产品或平台受到影响。,360 Computer Emergency Readiness Team, February 2018,9,2017 年度安全报告平台漏洞四次握手中的第 N 条消息，重放计数器 replay count 为 r， 给定的 nonce, 在;之后的参数都存储在数据域中，也就是说会使用 KEK 加密。 Authenticator 通过发送 message 1 来初始化四次握手。包含 ANonce，是唯一一个没有 MIC( 完整性校验 ) EAPOL格式消息。 当 收 到 消 息 时，suplicant 生 成 一 个 SNonce 而 且 导 出,PTK，suplicant,发 送 message2,给 authenticator，,message2 包含了（SNonce）。 authenticator 收到 SNonce，也会导出 PTK。并且发送组密钥 GTK 给 supplicant。 supplicant 在 安 装 PTK 和 GTK 之 后 回 复 message4authenticator 收到 message4 之后也会安装 PTK，其中 GTK在 AP 启动时就已经安装。1,2 条消息使用来传输 nonces，最后两条消息是用来传输组密钥 而且使用抵御降级攻击注意：在已经存在的连接中，PTK 可以被刷新初始化新的四次握手。在密钥重载的过程中，所有的四次握手消息都是使用 PTK 完成数据机密性加密的。,360 Computer Emergency Readiness Team, February 2018,10,2017 年度安全报告平台漏洞技术细节802.11i 协议（即：WPA2 协议）通过两种独立的机制来保证数据传输的机密性。第一个是在记录层通过加密 WiFi 帧的方式，保证无法被明文读取或嗅探。该加密机制通常是通过 AES-CCM 的方式，当然也有部分启动 GCM 模式，还有部分老的 RC4-TKIP 方式。需要认真考虑的是 AES-CCM( 还包括 GCM, TKIP) 是一种流加密， 这 意 味 着 在 重 用 加 密 参 数 key 和 nonce( 即 : 初 始 向 量 ) 的情况下是可以被攻击的。802.11i 是基于包计数 (packet numbernumber) 的方式，其在会话建立后的初始值为 0，且会不停递增（当然 到 了 248 的 时 候， 会 触 发 更 新 key 操 作）。 这 样 一 来， 假 设在 包 计 数 不 被 重 置 的 情 况 下， 就 可 以 成 功 防 范 key+nonce 的 重用 攻 击。 第 二 个 机 制 是 AP 和 客 户 端（supplicant） 之 间 的 4 次握 手 流 程， 主 要 用 于 协 商 加 密 key。KRACK 漏 洞 会 直 接 利 用 到4 次握手中的 #3 包，#3 包可作用于客户端新 key 安装使用。,KRACK 的 主 要 漏 洞 在 于 #3 包 可 以 被 恶 意 阻 断。 当 这 个 情 况 发生 时，AP 端 会 重 发 这 个 消 息， 会 导 致 同 样 的 一 个 key 在 客 户 端中 被 重 装。 带 来 的 副 作 用 是 也 会 导 致 包 计 数 会 被 重 置 为 0（ 部 分客 户 端， 如 Android6， 会 把 key 重 置 为 0)， 最 终， 就 会 触 发key+nonce 的 重 用 攻 击 了。 攻 击 者 可 以 利 用 它 来 全 流 量 解 密，TCP 劫持等。此外，还有如下 2 种攻击 : 包括针对客户端的基于 GTK 的攻击； 针对 AP 端的 802.11 RFT 握手攻击；/vanhoefm/krackattacks-scripts目前公开 poc 都是只针对客户端，和服务器进行安全检测，但不排除已经有一键傻瓜式工具利用。,360 Computer Emergency Readiness Team, February 2018,11,2017 年度安全报告平台漏洞针对客户端的攻击类似中间人的形式，需要迫使无线客户端从 AP连接到攻击者伪造的 AP 上，所以漏洞利用需要在一个有限地域范围内进行攻击，漏洞利用需要有针对性；不需要与被攻击者产生任何交互，漏洞利用触发难度小，对于针对性的实战利用是很有意义的。漏 洞 存 在 于 linux，Android 到 windows 各 种 终 端， 可 以 对 一 些明文传输或者不正确配置的 https 网站进行嗅探，数据捕获，考虑到现阶段安全状况，利用效果较好。同时，WPA2 KRACK（密钥 重 载 攻 击） 并 没 有 从 根 本 上 打 破 WPA 系 列 密 钥 体 系 基 本 的 安全特性，暂时不存在更换加密方式，只需要针对特定客户端和 AP进行修复。考虑到无线设备更新修复难度，建议在需要高安全性环境时，进行无线连接时采取 vpn 等方式加密进行连接。,360CERT 建议广大用户： 及 时 更 新 无 线 路 由 器、 手 机， 智 能 硬 件 等 所 有 使 用 WPA2无线认证客户端的软件版本。 合理部署 WIPS（无线入侵防御系统），及时监测合法 WiFi区 域 内 的 恶 意 钓 鱼 WiFi， 并 加 以 阻 断 干 扰， 使 其 恶 意 WiFi无法正常工作。 无线通信连接使用 VPN 加密隧道及强制 SSL 规避流量劫持与中间人攻击造成的信息泄漏。 在 不 使 用 WiFi 时 关 闭 手 机 WiFi 功 能， 公 共 WiFi 下 不 要 登录 有 关 支 付、 财 产 等 账 号、 密 码。 如 需 登 录、 支 付， 将 手 机切换至数据流量网络。 及时更新官方补丁：Linux 的 hostapd 和 wpa_supplicant 补 丁 地 址：https:/w1.fi/security/2017-1/ 微 软 在 Windows 10 操 作 系 统 中发 布 补 丁 KB4041676 苹 果 在 最 新 的 beta 版 本 iOS、macOS、 tvOS 和 watchOS 中修复了无线网络安全漏洞,2017 年度安全报告平台漏洞,360 Computer Emergency Readiness Team, February 2018,12,BlueBorne 蓝牙漏洞2017 年 9 月 12 日，armis 披 露 了 一 系 列 蓝 牙 的 漏 洞， 手 机 开 启了蓝牙，就可能被远程控制。无接触无感知接管系统的能力有点可怕，而且基本上影响所有的蓝牙设备，危害不可估量。所 有 Android 智 能 机， 平 板， 可 穿 戴 设 备 均 受 到 4 个 高 危 漏 洞的 影 响， 其 中 有 两 个 是 远 程 代 码 执 行 漏 洞 (CVE-2017-0781 和CVE-2017-0782)，有一个可被利用来进行 MITM 攻击（CVE-2017-0783），还有一个会导致信息泄露（CVE-2017-0785）。Windos 设 备 中 Windows Vista 以 外 所 有 版 本 系 统 均 受“Bluetooth Pineapple” 攻 击（CVE-2017-8628） 影 响， 可使攻击者进行 MITM 攻击。微软已在今年 7 月 11 日发布安全更新，并 在 9 月 12 日 发 布 了 相 应 的 通 知。iOS 设 备 中 iPhone, iPad,iPod 在 iOS 9.3.5 及 以 下 版 本，AppleTV7.2.2 及 以 下 版 本 均 受RCE( 远程代码执行漏洞 ) 影响。,上述的三个漏洞和攻击方法分别分别属于处理器，固件，协议三个方 面 平 台 安 全。 此 外，2017 年 还有另外一些值得我们注意漏洞。,360 Computer Emergency Readiness Team, February 2018,13,2017 年度安全报告平台漏洞背景及相关知识首先给出 armis 的披露漏洞时，整理的蓝牙架构图：,图 上 把 蓝 牙 的 各 个 层 次 关 系 描 述 得 很 详 尽， 不 过 我 们 这 里 暂 时 只需 要 关 心 这 么 几 层：HCI，L2CAP，BNEP，SDP。BNEP 和SDP 是比较上层的服务，HCI 在最底层，直接和蓝牙设备打交道，,而承载在蓝牙服务和底层设备之间的桥梁，也就是 L2CAP 层了。每一层都有它协议规定的数据组织结构，所有层的数据包组合在一起，就是一个完整的蓝牙包（一个 SDP 包为例）：,虽 然 协 议 在 各 个 平 台 的 架 构 一 样， 但 具 体 实 现 方 式 有 所 不 同，Linux 用的 BlueZ，而 Android 用的 BlueDroid。 在 Linux 里， 用 的 是 BlueZ 架 构，l2cap_sock.c 通 过 注 册sock 协议的方式提供了针对 userspace 的接口。L2CAP 的 数 据 是 由 HCI 层 传 过 来 的， 在 hci_core.c的 hci_rx_work 函数里处理，当 L2CAP 层有 SDP 数据后，通 过 sdp-server.c 中 的 io_session_event 来 获 取 这 个 数据包，递交给 sdp-request.c 的 handle_request。 在 Android 里 用 的 时 BlueDroid 架 构。 这 个 和 BlueZ 架构 很 大 不 同 的 一 点 是：BlueDroid 将 L2CAP 层 放 在 了userspace。SDP 连 接 建 立 起 来 后， 在 收 到 SDP 数 据 包 之 后 呢，会 触 发 回 调 函 数 sdp_data_ind， 这 个 函 数 会 把 数 据 包 交 个sdp-server.c 的 sdp_server_handle_client_req 函 数 进行 处 理。BNEP 连 接 建 立 起 来 后， 再 收 到 BNEP 的 包， 和SDP 类 似， 会 触 发 回 调 函 数 bnep_data_ind， 这 个 函 数 包含了所有对 BNEP 请求的处理。,360 Computer Emergency Readiness Team, February 2018,14,2017 年度安全报告平台漏洞漏洞分析Armis 披 露 漏洞 时， 介 绍 了 细 节。360VulpeckerTeam 对 这 几个漏洞进行了深入分析，这里引用借鉴下。CVE-2017-1000251这个漏洞触发的思路如下： 建 立 和 目 标 机 器 的 L2CAP 连 接， 这 里 sock_type 的 选 择应 该 是 SOCK_RAW， 如 果 不 是， 内 核 会 自 动 帮 我 们 完 成sent_infomation_request , send_connection_request,send_configure_request 这些操作，也就无法触发目标机器的漏洞了。 建 立 SOCK_RAW 连 接，connect 的 时 候， 会 自 动 完 成sent_infomation_request 的操作，不过这个不影响。 接 下 来 我 们 需 要 完 成 send_connection_request 操 作，来 确 定 SCID,DCID。 完 成 这 个 操 作 的 过 程 是 发 送 合 法 的L2CAP_CONN_REQ 数据包。 接下来需要发送包含有 L2CAP_CONF_EFS 类型的数据，而 且 L2CAP_CONF_EFS 数 据 的 stype = L2CAP_SERV_NOTRAFIC 的 L2CAP_CONF_REQ 包， 这 一步 是 为 了 让 目 标 机 器 的 conf_state 变 成 CONF_LOC_CONF_PEND。 这里就到了发送 cmd_len 很长的 L2CAP_CONN_RSP包了。这个包的 result 字段需要是 L2CAP_CONF_PENDING。这个包发过去之后，目标机器内核就会栈溢出，要么重启了，要么死机了。,我 们 的 漏 洞 发 生 在 对 L2CAP_CONFIG_RSP（configresponse）的处理上。那么来看 l2cap_config_rsp:,15,2017 年度安全报告平台漏洞当 收 到 的 数 据 包 里， 满 足 result = L2CAP_CONF_PENDING， 且 自 身 的 连 接 状 态 conf_state = CONF_LOC_CONF_PEND 的时候，会走到 l2cap_parse_conf_rsp 函数里，而 且 传 过 去 的 buf 是 个 长 度 为 64 的 数 据， 参 数 len ， 参 数 rsp-data 都 是 由 包 中 的 内 容 来 任 意 确 定。 那 么 在 l2cap_parse_conf_rsp 函数里：,仔细阅读这个函数的代码可以知道，这个函数的功能就是根据传进来的包，来构造将要发出去的包。而数据的出口就是传进去的 64字 节 大 小 的 buf。 但 是 对 传 入 的 包 的 数 据 的 长 度 并 没 有 做 检 验，那 么 当 len 很 大 时， 就 会 一 直 往 出 口 buf 里 写 数 据， 比 如 有 64个 L2CAP_CONF_MTU 类 型 的 opt， 那 么 就 会 往 buf 里 写 上64*(L2CAP_CONF_OPT_SIZE + 2) 个 字 节， 那 么 显 然 这 里就 发 生 了 溢 出。 由 于 buf 是 栈 上 定 义 的 数 据 结 构， 那 么 这 里 就 是一个栈溢出。360 Computer Emergency Readiness Team, February 2018,360 Computer Emergency Readiness Team, February 2018,16,2017 年度安全报告平台漏洞CVE-2017-1000250这 个 漏 洞 是 BlueZ 的 SDP 服 务 里 的 信 息 泄 露 漏 洞。 这 个 不 像L2CAP 层的连接那么复杂，主要就是上层服务，收到数据就进行处理。那么我们也只需要关注处理的函数。BlueZ 的 SDP 收到数据是从 io_session_event 开始。之后，数据的流向是：io_session_event-handle_request-process_request。SDP 协 议 它 有 一 个 sdp_pud_hdr 的 头 部， 头 部 数 据 里 定 义 了PUD 命 令 的 类 型，tid， 以 及 pdu parameter 的 长 度， 然 后 就 是具 体 的 parameter。 最 后 一 个 字 段 是 continuation state， 当 一个包发不完所要发送的数据的时候，这个字段就会有效。对于这个字段，BlueZ 给了它一个定义：,对于远程的连接，PDU 命令类型只能是这三个 :SDP_SVC_SEARCH_REQ, SDP_SVC_ATTR_REQ, SDP_SVC_SEARCH_ATTR_REQ。这个漏洞出现在对 SDP_SVC_SEARCH_ATTR_REQ 命令的处理函数 service_search_attr_req 里面 , 其功能有这几点： extract_des(pdata, data_left, 解析 Attribute ID list,if (sdp_cstate_get(pdata, data_left, ,获取 continuation state 状态 cstate，如果不为 0，则将包里的continuation state 数据复制给 cstate.,360 Computer Emergency Readiness Team, February 2018,17,2017 年度安全报告平台漏洞漏洞发生在对 cstate 状态不为 0 的时候，这部分代码：,sdp_get_cached_rsp 函 数 其 实 是 对 cstate 的 timestamp值 的 检 验， 如 何 过 这 个 检 验 之 后 再 说。 当 代 码 走 到 第 五 行 处 的memcpy 时， 由 于 cstate-maxBytesSent 就 是 由 数 据 包 里的 数 据 所 控 制， 而 且 没 有 做 任 何 检 验， 所 以 这 里 可 以 为 任 意 的uint16_t 值。 那 么 很 明 显， 这 里 就 出 现 了 一 个 对 pResponse 的越 界 读 的 操 作。 而 越 界 读 的 数 据 还 会 通 过 SDP RESPONSE 发送给攻击方，那么一个信息泄露就发生了。,360 Computer Emergency Readiness Team, February 2018,18,2017 年度安全报告平台漏洞CVE-2017-0785这 个 漏 洞 也 是 SDP 的 信 息 泄 露 漏 洞， 不 过 是 BlueDroid 的。与 BlueZ 的 那 个 是 有 些 类 似 的。 我 们 也 从 对 SDP 数 据 包 的处 理 函 数 说 起。 SDP 数 据 包 会 通 过 sdp_data_ind 函 数 送给 sdp_server_handle_client_req。 与 BlueZ 一 样， 这 个函 数 也 会 根 据 包 中 的 pud_id 来 确 定 具 体 的 处 理 函 数。 这 个 漏洞 发 生 在 对 SDP_PDU_SERVICE_SEARCH_REQ 命 令的 处 理， 对 包 内 数 据 的 解 析 与 上 文 BlueZ 中 的 大 同 小 异， 不过 注 意 在 BlueDroid 中，cstate 结 构 与 BlueZ 中 有 些 不 同：关注漏洞处的代码：,， 中 代 码 可 以 看 出， 变 量 num_rsp_handles 的 值， 一 定 程度上可以由包中的 Maximu Attribute Byte 字段控制。中代码是对带 cstate 的包的处理，第一步是对大小的检查，第二 步 是 获 得 cont_offset， 然 后 对 cont_offset 进 行 检 查， 第 三步就到了rem_handles = num_rsp_handles - cont_offset可 以 思 考 一 种 情 况， 如 果 num_rsp_handles cont_offset += cur_handles;,cur_handles 是一个固定的值，如 果 这 个 下 溢 的 过 程， 发 生 很 多 次，p_ccb-cont_offset 就 会变得很大，那么在处，就会有一个对 rsp_handles 数组的越界读的产生。,360 Computer Emergency Readiness Team, February 2018,19,2017 年度安全报告平台漏洞下面的操作可以让这个越界读发生： 发送一个不带 cstate 的包， 而且 Maximu AttributeByte 字段设置的比较大。那么结果就是 rem_handles= num_rsp_handles，而由于 max_replies 比较大，所以 num_rsp_handles 会成为一个比较大的值。只要在中保证 rem_handles cur_handles，那么 p_ccb-cont_offset 就会成为一个非值 cur_handles。这一步是为了使得 p_ccb-cont_offset成为一个非值。 接收服务端的回应包，这个回应包里的 cstate 字段将会含有刚刚的 p_ccb-cont_offset 值，我们取得这个值。, 发送一个带 cstate 的包，cont_offset 指定为刚刚提取的值，而且设置 Maximu Attribute Byte 字段为。那么服务端收到这个包后，就会走到 rem_handles= num_rsp_handles - cont_offset 从而发生整数下溢，同时 p_ccb-cont_offset 又递增一个 cur_handles 大小。 重复和的过程，那么 p_ccb-cont_offset 将越来越大，从而在出发生越界读，我们提取服务端返回的数据，就可以获得泄露的信息的内容。,360 Computer Emergency Readiness Team, February 2018,20,2017 年度安全报告平台漏洞CVE-2017-0781BlueDroid 中 BNEP 服务对于接受到的数据包的处理也不复杂： 解析得到 BNEP_TYPE，得到 extension 位。 检 查 连 接 状 态， 如 果 已 经 连 接 则 后 续 可 以 处 理 非BNEP_FRAME_CONTROL 的包，如果没有建立连接，则后续只处理 BNEP_FRAME_CONTROL 的包。 去 BNEP_TYPE 对应的处理函数进行处理。, 对,于 BNEP_TYPE 不,是 BNEP_FRAME_,CONTROL 而 且 有 extension 位 的， 还 需 要 对extension 的数据进行处理。 调用 pan 层的回调函数。值 得 注 意 的 是，BNEP 连 接 真 正 建 立 起 来， 需 要 先 处 理 一 个 合 法的 BNEP_FRAME_CONTROL 数 据 包。CVE-2017-0781 正是 连 接 还 没 建 立 起 来， 在 处 理 BNEP_FRAME_CONTROL 时所发生的问题：,上 述 代 码 中，malloc 了 一 个 rem_len 的 大 小， 这 个 是 和 收 到 的数 据 包 的 长 度 相 关 的。 可 是 memcpy 的 时 候， 却 是 从 p_bcb-p_pending_data 开始拷贝数据，那么这里会直接溢出一个sizeof(*(p_bcb-p_pending_data) 大 小 的 内 容。 这 个 大 小 是8. 所 以 只 要 代 码 走 到 这， 就 会 有 一 个 8 字 节 大 小 的 堆 溢 出。 而 要走到这，只需要过那个 if 的判断条件，而这个 if 其实是对 BNEP_,SETUP_CONNECTION_REQUEST_MSG 命 令 处 理 失 败,后 的 错 误 处 理 函 数。 那 么 只 要 发 送 一 个 错 误 的 BNEP_SETUP_CONNECTION_REQUEST_MSG 命令包，就可以进入到这段代码了触发堆溢出了。,3