标签: 安全漏洞

IOTA简介：IOTA 是一款功能强大的网络捕获和分析解决方案，适用于边缘和核心网络。IOTA 系列包括便携式 EDGE 型号、高速 CORE 型号和 IOTA CM 集中设备管理系统。IOTA 解决方案可为分支机构、中小企业和核心网络（如数据中心）提供快速高效的网络分析和故障排除功能。 问题描述 安全分析师和取证专家经常需要分析哪个客户端在什么时间与特定目标系统建立了连接。传统的外围防火墙可以记录来自广域网的连接尝试，但无法检测到内部网络的横向移动。因此，存在一个需要消除的 “盲点”。 下面的示例逐步概述了如何在发生安全事件后利用艾体宝 IOTA 分析连接设置。目标是识别受感染的主机或将恶意代码传播到网络内部文件服务器的主机。 准备工作 要想取得成功，IOTA 必须在事件发生前捕获网络流量，以便事后进行回顾分析。 第一步，准备物理接口。 为此，我们使用左侧菜单树导航到捕获页面，然后导航到接口配置部分。如下图所示，接口被配置为具有 10/100/1000 Mbit/s 自动协商功能的 SPAN（带外），这意味着两个物理接口都可以接收来自 SPAN 端口或 TAP 的待分析流量。 图1 物理接口的配置。在这种情况下，采用 SPAN 模式的 10/100/1000 Mbit/s 自动协商 IOTA 的部署或集成 交换机的上行链路可用作 SPAN 源，包括多个客户端 VLAN。如果要将 IOTA 内联集成到数据流中，例如在接入交换机和路由器之间或接入交换机和分配交换机之间，则必须勾选 “内联模式 ”旁边的复选框，并单击 “保存 ”按钮。这取决于 VLAN 网关的位置。如果要记录进出特定服务器的流量以便日后分析，也可以在数据中心的交换机和服务器之间进行内联操作。 图2 IOTA在数据包平均处理和后续安全事件分析中的位置 开始捕获 放置好 IOTA 并准备好物理接口后，我们连接适当的电缆，然后导航到捕获控制部分并单击屏幕底部的开始捕获按钮，启动捕获过程。或者，我们也可以按下 IOTA 设备上的物理 “开始捕获 ”按钮来启动捕获过程。这将加快整个过程，未经培训或没有权限的人员也可以进行操作。 图3 使用 “捕获控制 ”子菜单中的 “开始捕获 ”按钮启动捕获 仪表盘故障排除 要识别所谓的 “零号病人（patient zero）”，我们需要两种方法。第一种是确定哪个客户端连接到了命令和控制服务器 (C2) 或恶意软件分发服务器（如果已知）。第二种方法是将受影响的服务器或客户端作为基线，分析哪些其他系统与其建立了连接。 名词解释：在网络安全领域，“Patient Zero”（零号病人）是一个重要的概念，用于描述首次感染恶意软件或病毒的用户或设备。其识别和防御对于控制恶意软件的传播至关重要。 例如，如果这是一种已知的攻击，可以通过特定的勒索软件信息检测到，那么就有可能专门搜索通信模式，如特定的目标端口。我们也以此为例。我们假设一个文件服务器受到勒索软件攻击，该服务器通过网络上的服务器消息块（SMB）提供服务。服务器的 IPv4 地址是 192.168.178.6。 我们知道 SMB 通过 TCP 端口 445 运行，因此在概述仪表板上对该目标端口和之前提到的 IP 地址 192.168.178.6 进行了过滤。结果显示，在加密时间窗口内，只有 192.168.178.22 客户端与文件服务器建立了 SMB 连接。 图4 IP 地址 192.168.178.6 和目标端口 445 的过滤器 我们还可通过过滤器 “IP_SRC = 192.168.178.22 ”在 “概览 ”仪表板上检查客户端 192.168.178.22 在不久前建立了哪些通信关系，以确定是否发生了命令和控制流量或下载。 在仪表盘的底部，我们可以查看 “流量列表 ”中过滤后的流量数据。从中我们可以看到，之前只有一次通信尝试离开了内部网络。具体来说，这是一个目标端口为 443 的 TLS TCP 连接，即 HTTPS，目标 IP 地址为 91.215.100.47。 图5 基于概览仪表盘底部过滤源主机的通信关系 根据这些流量数据，我们可以通过屏幕右上角的导航菜单切换到 SSL/TLS 总览面板，查看与哪个服务器名称建立了连接。这可以在客户端 “hello” 中看到，或者更具体地说，在 TLS 扩展服务器名称指示（SNI）中看到。其中包含与客户端建立连接的主机名。 图6 通过导航菜单切换到 SSL/TLS 总览面板 在 SSL/TLS 总览面板的 SSL/TLS 服务器列表中，我们可以看到与客户端建立连接的服务器名称 “config.ioam.de”。 图7 SSL/TLS 概述仪表板，其中我们可以看到 TLS 客户端 hello 中的服务器名称 由于 TLS 加密意味着下载本身无法以纯文本形式识别，因此必须在日志文件中对客户端进行进一步分析。随后确定用户下载并安装了一个应用程序。这就通过分析的 SMB 网络共享执行了文件加密过程。这样，我们就掌握了导致攻击的 IP 地址、主机名和文件。不过，在某些情况下，下载恶意软件的服务器只是攻击者的 “前端服务器”，而这些服务器也会不时发生变化。 由于网络中的横向移动在攻击事件中经常被检测到，因此还应检查其他客户端，因为受影响的客户端也可能已经分发了恶意软件。如果在受影响的客户端上看不到任何外部通信关系，则应检查所有内部通信模式，以发现可能将恶意软件带到客户端 192.168.178.22 的异常情况。 如果我们需要检查哪些主机试图连接到似乎提供恶意软件的特定服务器，我们也可以使用 IOTA 进行检查。如果有已知的 FQDN 与这些服务器相关，我们可以使用 DNS 概述仪表板。 图8 通过导航菜单切换到 DNS 概述仪表板 我们切换到 “DNS 概述 ”控制面板，并使用 “搜索 DNS ”过滤器按名称进行搜索。我们使用了域名 akamaitechcloudservices.com，它听起来像是一个内容交付网络的连接尝试，但已知是一个在安全事件中使用的恶意服务器。 图9 通过名称 akamaitechcloudservices.com 进行搜索 搜索后，我们可以看到 DNS 在晚上 9:20 左右请求了该恶意服务器。要进一步调查哪个客户端试图连接到该服务器，我们可以进入 DNS 概述仪表板，查看请求 akamaitechcloudservices.com 的客户端 IP 地址。在图 10 的示例中，它是 192.168.178.22。现在我们知道是哪个客户端试图连接该服务器了。 图10 DNS查询/响应和相应的流量流表 IOTA 的优势 IOTA 提供多种选项，用于过滤相关通信模式和时间窗口，以进行安全分析。此外，与其他工具相比，它还提供了直观的仪表板，即使没有深入协议知识的人也能简化和加速分析。 了解 ITT-IOTA 更多信息，欢迎前往【艾体宝】官方网站！

作者： Shawn Prestridge ， IAR 资深现场应用工程师 / 美国 FAE 团队负责人 安全 一直都 是一个非常热门的话题 ， 似乎每 周 都会听到这样的消息：某某公司如何被入侵，数百万用户的数据被泄露。 我们看到这么多的安全问题，部分原因 在于 我们对待安全的方式： 安全 性 通常被认为是事后 考虑 的 问题 ， 是在 开发结束时 才 添加到 设备上的东西。然而，复杂的系统，尤其是嵌入式系统，有一个很大的攻击面，这让攻击者有机可乘，能够在 “ 盔甲 ” 上找到 破绽 。如果你 去 研究大部分黑客试图 入 侵系统的方式，你很快就会发现，在他们的武器库中，他们最喜欢的 手段就 是寻找和利用设备的软件漏洞。 如果软件漏洞是黑客 所利 用的 入口 ，那么我们就需要提高 自己 的代码质量来解决这个问题。但是，这个问题有多 严重 ，我们能做什么来解决它呢？ 代码漏洞容易成为黑客的目标 代码质量糟糕实际上是一个普遍 存在 的问题，而且有相当多的证据支持这样的说法：糟糕的 编码 直接导致了漏洞。虽然许多软件工程专家多年来一直在宣扬这一点，但人们第一次真正意识到这一点也许是在 2001 年，当时红色代码 （ Code Red ） 蠕虫 对 微软的互联网信息服务（ IIS ） 施加了 缓冲区溢出攻击 。 虽然第一个有记载的缓冲区溢出攻击发生在 1988 年，针对的是 Unix 的 finger 指令，但对普通人的影响十分有限，因此没有上头条新闻。 由于红色代码造成了大规模的互联网减速，并在新闻 报道 中铺天盖地 的传播 ，突然间，我们随处都能看到缓冲区溢出攻击的增加 ，看上去 安全研究人员和黑客都在各种系统 （ 包括嵌入式系统 ） 中到处 寻 找这些漏洞。利用缓冲区溢出攻击，黑客可以在受影响的系统上运行他们想要 运行 的任何代码，其目标是使用固定长度的缓冲区来保存文本或数据的一切代码。黑客将缓冲区空间填 充 到最大，然后在合法缓冲区空间的末端写下可执行代码。 然后， 被攻击的系统就会执行缓冲区末端的代码，在许多情况下， 这就可以使 攻击者为所欲为了。 这种类型的攻击之所以 成为紧急事件 ，是因为 当时 检查和执行缓冲区限制的编码并不普遍，但 现在 许多编码标准，如 mitre.org 的 通用缺陷列表 （ Common Weakness Enumeration ， C WE ） ，都建议检查缓冲区 是否存在 这种类型的漏洞。 遗憾 的是，开发 人员 在 编 写代码时普遍都不去 寻 找 这个 问题 ， 通常需要代码分析工具来发现这些问题，这样开发 人员 才会意识到问题的存在并加以修复。像这样一个简单的代码质量改进，就可以消除黑客最常使用的 手段 之一，从而大大提高代码的安全性。因此，检查并执行 代 码中 的 缓冲区长度，这样的编码才是好编码 。 不仅仅是缓冲区溢出 然而，问题不仅仅 在于 缓冲区溢出 ， 这 实际上是一个系统性问题， 草率 的编码 通常会 导致无数的安全漏洞，而黑客可以利用这些漏洞来入侵系统。美国软件工程学会（ SEI ）发表的一篇论文 将这一点 说得非常清楚： “ ...... 质量性能指标为确定高质量产品 、 预测安全 和 保障结果提供了依据。 通用缺陷列表 （ CWE ） 中的许多内容 ，如编程语言结构的不当使用 、 缓冲区溢出 、 验证输入值失败 等 ，都可能与低质量的编码和开发过程有关。提高代码质量是解决一些软件安全问题的必要条件。 ” 该 论文还指出，因为许多安全问题是 由 软件漏洞引起的 ，因此 可以像 处理 更普通的编码漏洞一样 处理安全问题 ，您可以应用传统的质量保证技术来帮助解决至少一 部分 安全问题。 既然正常的软件质量保证过程可以让我们估计系统中剩余的漏洞数量，那么 可以 对安全漏洞 做同 样的 事情 吗？虽然 SEI 没有确认代码质量和安全 性 之间的数学关系，但他们确实指出， 1% 到 5% 的软件漏洞是安全漏洞，并继续指出，他们的证据表明当安全漏洞被追踪时，他们可以准确地估计系统中的代码质量水平。 这最终表明，代码质量是安全的必要条件（但不是充分条件），真正 让“安全 性 可以被视为 开 发结束 时才 添加到 设备 上 的东西” 这一概念不攻自破。相反，安全 性 必须贯穿项目的 DNA ，从设计到编码，一直到生产。 编码标准 可提供 很大的帮助 许多最常见的安全漏洞都在 诸 如 mitre.org 的 通用缺陷列表等 编码标准中得到了解决，并指出了需要关注的其他 方面 ， 如除 零 错误 、数据注入、循环不规则、空指针利 用和 字符串解析错误 。 MISRA C 和 MISRA C++ 还提倡编码的安全性和可靠性，以防止安全漏洞渗入你的代码。虽然这些 编码标准 可以捕捉到许多常 见 的漏洞，但开发人员在编写代码时必须 考虑 得更 长 远：黑客 是 如何利用我刚刚 编 写的代码的？漏洞在哪里？我是否对输入会是什么样子以及输出会如何使用做了假设？一个好的经验法则是，如果你在做假设，那么这些假设应该变成代码，以确保你所期待的东西实际上 就 是你所要得到的。如果你不这样做，那么黑客就会 出手了 。 但是开源软件呢？在设计中使用开源组件的典型论点 依赖 于 “ 已 在使用中被 证明” （ proven in use ） 的论点：这么多人使用它，它一定是好的。 SEI 的 同一 篇论文 对 于这个问题 也有一些阐 述： “ 除了免费之外 ， 开源 所宣扬 的好处之一，就是认为 ‘ 有很多人关注源代码意味着安全问题可以很快被发现，任何人都可以修复漏洞 ， 不需要依赖供应商 ’ 。然而，现实情况是，如果没能有纪律地、一致地把 关注点 放在消除漏洞上，安全漏洞和其他漏洞将出现在代码中。 ” 换句话说， SEI 认为， “ 已 在 使用中被 证明”的论点 毫无意义， 并且在 将质量保证应用 于 开源代码 时 ， 会 让人想起 Anybody 、 Somebody 、 Nobody 和 Everybody 的故事。此外，你的测试并不足以证明代码是令人满意的。 SEI 表示 ，像 CWE 这样的代码质量标准可以发现你代码中的问题，而这些问题 往往 不会在标准测试中被发现，通常只有在黑客利用漏洞时才会被发现。 为了证明这一点， 2020 年 5 月，普 渡大学 的研究人员展示了 在 Linux 、 macOS 、 Windows 和 FreeBSD 中使用的开源 USB 堆栈的 26 个漏洞。 所以， 谈 及 安全 性时 ，代码质量是关键， 并且 所有 代码都很重要。 代码分析工具有助于遵守标准 在解决代码质量问题上，我们可以做些什么来提高 自己 应用程序的安全性呢？简单的答案 就 是使用代码分析工具，这些工具有两种基本类型：静态分析 工具 和运行时（或动态）分析 工具 ，静态分析只查看应用程序的源代码，而运行时分析则是对代码进行检测，寻找空指针和数据注入方法等漏洞。 I AR 可以同时提供这两种工具，包括静态分析工具 I AR C-STAT 和运行时分析工具 I AR C-RUN ，它们 都完全集成在 IAR Embedded Workbench 开发环境中。 高质量的代码分析工具包括对 CWE 、 MISRA 和 CERT C 的检查。 CERT C 是另外一 种 编码标准，旨在促进编码安全。这三个 规则集共同 构成了一个 优质组合， 有助于实现可提升 安全 性 的编码：一些 规则集 与其他规则 集有 重合 之处 ，但也提供了一些独特的功能， 可 以帮助确保你的代码具有高度的安全性。使用这些标准也有助于确保你 拥有最高 的代码质量，甚至可能发现代码中的一些潜在漏洞。 高质量的 代码就是 安全的代码 保证代码质量才能确保代码安全。不要把代码质量的责任推给别人，因为别人的漏洞很可能 给 你 带来 安全 性方面的 噩梦。但希望还是有的，因为代码分析工具可以 帮助 你在漏洞找麻烦之前迅速发现问题。通往安全的道路总是要经过代码质量这一关口。 参考资料 https://www.caida.org/research/security/code-red/ https://malware.wikia.org/wiki/Buffer_overflow https://cwe.mitre.org/data/definitions/121.html https://resources.sei.cmu.edu/asset_files/TechnicalNote/2014_004_001_428597.pdf https://www.techradar.com/news/usb-systems-may-have-some-serious-security-flaws-especially-on-linux

前言 蓝牙连线技术是一种用在两者装置之间近距离传输资料的无线通信技术，并且被广泛地应用在各种消费性电子产品及设备上，包括手机、笔电、平板电脑、耳机、音箱及智能型穿戴装置等，都可以看到蓝牙技术的身影。然而，随着蓝牙设备的普及及大众化，其相关的资安风险也逐渐浮现，本文将带您一一剖析蓝牙装置较常见的资安风险和攻击类型，以及相关的解决方案。 无线攻击 由于蓝牙设备的无线特性，黑客可以利用特定的无线攻击技术，从而进行远程控制、窃取设备资料。以下列出蓝牙设备近期较常发生的无线攻击类型： Bluesnarfing 蓝牙劫持 (Bluejacking) Bluebugging Car Whisperer 拒绝服务 （Denial of Service） 模糊攻击（Fuzzing Attacks） 配对窃听（Pairing Eavesd ropping） 安全的简单配对攻击（Secure Simple Pairing Attacks） 蓝牙协议安全漏洞 由于蓝牙协议本身就已存在一些漏洞，而这些漏洞都有可能遭到黑客利用，藉此入侵透过蓝牙连接的两端设备，导致敏感资料外泄或设备控制权被夺取。以下就会大家介绍蓝牙常见的漏洞攻击： KNOB 攻击 (Key Negotiation of Bluetooth Attack) KNOB攻击是一种针对蓝牙技术的安全漏洞攻击。此攻击主要是利用蓝牙设备在进行配对时，在建立安全连接时协商加密密钥长度过程中的一个安全漏洞。攻击者可以透过操纵密钥协商过程，将加密密钥长度降低到极低的水平 (例如1个字节)，从而使得密钥极易被破解。一旦密钥遭到破解，攻击者便能够任意窃听和篡改受害者设备之间的通讯。 蓝牙LMP（Link Manager Protocol）协议在这里扮演了一个重要角色。LMP用于管理蓝牙设备之间的连接，包括协商加密密钥长度。在KNOB攻击中，攻击者利用LMP协议中的漏洞，对加密密钥长度进行篡改。具体一点来说，攻击者在设备间插入自己，然后修改LMP协议中的加密密钥大小要求（LMP_encryption_key_size_req），使得设备协商出极低的加密密钥长度。这使得攻击者能够轻易地破解加密通讯，从而获得对受害者设备通讯的完全控制。 值得注意的是，KNOB攻击影响了许多蓝牙设备，包括蓝牙BR/EDR（Basic Rate/Enhanced Data Rate）设备。为了防止KNOB攻击，设备制造商和软件开发商应采取措施，例如强制使用较长的加密密钥长度和修复相应的漏洞。用户应保持设备软件更新，以便获得最新的安全修复程序。 BIAS (Bluetooth Impersonation Attacks) BIAS（Bluetooth Impersonation Attacks）是一种针对蓝牙技术的安全攻击，它允许攻击者伪装成已知的、已配对的蓝牙设备，以绕过蓝牙安全机制并取得对目标设备的未经授权访问。BIAS攻击影响了使用BR/EDR（Basic Rate/Enhanced Data Rate）的蓝牙设备。 BR/EDR是蓝牙技术的一个传输模式，它提供较高的数据传输速率。BR/EDR连接通常用于传输大量数据，如多媒体文件或纯文本文件。为了防止BIAS攻击，设备制造商和软件开发商应该修补相应的漏洞并强化蓝牙安全机制。针对BIAS攻击，Bluetooth SIG（蓝牙技术联盟）已经提出了安全建议和修复措施。例如在Bluetooth Core Specification的更新版本5.1、5.2，以及未来的版本中，都已经对这些漏洞进行了修复。 对此，设备制造商也应根据Bluetooth SIG的建议更新其韧体和驱动程序，以解决BIAS攻击相关的漏洞。同时，软件开发商应该在应用程序中实施像是强制使用安全配对机制等更严格的蓝牙安全策略。 BlueBorne BlueBorne攻击者可在不被察觉的情况下，操纵受影响的蓝牙装置，从而获取数据、窃取用户信息、植入恶意软件，甚至控制受害者的装置。此攻击不仅适用于个人用户的装置，也可影响企业环境中的蓝牙设备，进而导致网络安全风险或企业数据泄漏。 由于不需要进行配对或用户互动就可发动攻势，这使得BlueBorne具有极高的隐蔽性和危险性。为了防止BlueBorne攻击，用户应定时保持设备软件更新，以便获得对应的安全修复，设备制造商和软件开发商也应积极修复这些漏洞，并同时加强蓝牙安全机制。 SweynTooth SweynTooth是一系列影响蓝牙低功耗（Bluetooth Low Energy, BLE）装置的安全漏洞。它主要针对BLE技术中的蓝牙堆栈实现，其涉及的协议层包括： L2CAP（蓝牙逻辑链路控制与适配协议） – 负责在蓝牙装置之间建立连接并传输数据。 ATT（属性协议） – 是BLE中的一个核心协议，负责定义蓝牙装置之间如何互相发现和操作服务与特征。 HCI（主机控制器接口） – 是蓝牙协议中的一个界面，用于在主机与控制器之间传输数据和命令。 SweynTooth攻击可导致诸如无法使用蓝牙设备、装置当机、以及操纵受影响装置的行为等各种安全问题，包括：无法使用蓝牙设备、装置当机、以及操纵受影响装置的行为。这些漏洞影响了多个蓝牙芯片制造商的产品，包括许多消费性电子设备、工业设备和医疗设备。 为了防止SweynTooth攻击，制造商应该修复受影响的蓝牙堆栈实现，并提供相应的韧体更新。而用户本身也应保持设备软件更新，以获得最新的安全修复程序。同时，设备制造商和软件开发商应积极修复这些漏洞，并加强蓝牙安全机制。 BlueFrag BlueFrag是一种利用蓝牙协议中的L2CAP漏洞进行的攻击方式。L2CAP（逻辑链路控制与适配协议）是蓝牙协议中的一个层，全名为”逻辑链路控制与适配协议”。它的主要功能是在蓝牙装置之间建立连接并传输数据。BlueFrag攻击利用L2CAP的分片和重组封包长度计算出错，导致内存损坏。这使得攻击者可以利用这个漏洞在受害者的设备上执行任意程序代码，致使个人信息遭到泄露，或者让攻击者完全控制受害者的装置。 这种攻击主要影响运行Android 8.0至9.0版本的设备，因为这些设备的蓝牙堆栈实现存在漏洞。另一方面，由于Apple的iOS系统在蓝牙协议实现方面存在差异，因此它不受此漏洞的影响。 针对BlueFrag问题，Google已经发布了安全更新，而用户应该定期更新设备以获得最新的安全修复程序。此外，设备制造商和软件开发商应该持续寻找并修复潜在的蓝牙漏洞，以确保用户的安全。 蓝牙装置的相关应用已经成为日常生活中不可或缺的一部分，在享受着蓝牙带来便利性的同时，也使它们成为攻击者的目标。用户和企业应该意识到蓝牙装置的资安风险，并采取相对应的措施来保护自己的设备和数据，设备制造商更应该负起企业责任，维持该产品的信息安全。