本博客是该系列文章的一部分，我们将讨论与物联网/工业物联网生态系统及其安全性有关的基本概念。如果您还没有浏览过该系列以前的博客，我建议您先浏览这些博客。如果您只对CoAP感兴趣，请随时继续。

物联网安全-物联网介绍及其架构

物联网安全-2.物联网攻击面

物联网安全3.物联网10大安全漏洞

物联网安全-4.低功耗蓝牙BLE

物联网安全-5.ZigBee协议物联网安全-6.ZigBee安全物联网安全-7.物联网固件逆向

物联网安全-8.软件无线电（Software Defined Radio，SDR）简介

物联网安全-9.软件无线电简介（Software Defined Radio，SDR）:软件部分

物联网安全 – 10.MQTT 协议和安全简介

在这篇博客中，我们将介绍CoAP，一种用于受限环境的简单物联网协议，以及对CoAP协议及其实现的安全问题和攻击。CoAP的强大之处在于它与HTTP协议的简单性和可移植性，当我们讨论协议内部时，这一点将很明显。

1 引言

CoAP是Cons应变A应用P轮转的缩写。它是一个 IETF 标准，核心协议在 RFC 7252 中定义。在单独的 RFC 中定义了更多扩展。它非常适合在简单微控制器上运行的节点，ROM和RAM有限，并通过低功耗无线局域网（LPWAN）进行通信，例如6LoWPAN。它工作在 TCP/IP 堆栈的应用层，并利用 UDP 作为底层传输协议。2018年发布了一个新标准 - RFC 8323，它描述了基于TCP，TLS和WebSockets的CoAP。

| UDP (or TCP) Port | Communication Type | | —————– | —————— | | 5683 | Plain text | | 5684 | DTLS (or TLS over TCP)|

1.1 CoAP功能

1. 它提供了一个简单的发现机制

2. 与 Web 集成很容易

3. 它提供异步消息交换

4. 使用 URI 定义资源/服务

5. 使用类似 REST 的请求/响应模型

1.2 HTTP沿袭

CoAP被设计为受限环境的通用Web协议。它以压缩的二进制格式利用HTTP的一部分，更具体地说是REST架构。由于CoAP和HTTP之间的简单转换/代理，它可以很容易地与Web集成。把它想象成穷人的HTTP。如果你看一下HTTP协议，由于其基于文本的语义，它是相当广泛和Chatty的。使用受限设备时，聊天协议不是长电池寿命和处理能力的好选择。当我们讨论CoAP架构和通信时，您将获得更好的想法。

1.3 使用和受欢迎程度

根据我们在物联网设备方面的经验，CoAP功能在各种RF协议的RF端提供。对于基于以太网/WiFi的设备，它并不像MQTT那样受欢迎。但是，您最终仍可能找到使用 CoAP 通过 WiFi/以太网进行通信的产品。

2 CoAP 通信

2.1 协议概述

CoAP 使用客户端-服务器通信模型，其中节点发送请求并从其他节点接收响应。它使用两层通信方法，其中一层处理 UDP 协议，另一层处理应用程序数据：

1. CoAP 消息 – 这些消息定义 CoAP 数据包的类型并处理 UDP。

2. 请求/响应（类似于 HTTP）– 这些使用请求方法和响应代码封装实际的应用程序有效负载/数据。

如我们所见，CoAP 使用 UDP 进行消息传输，并将请求/响应、应用程序数据封装在消息中。由于它使用 UDP，因此它必须管理可靠性部分。它使用 ACK 消息执行此操作。

2.1.1 CoAP 消息

CoAP 标准定义了 4 种不同类型的消息：

1. Confirmable Message (CON)– 这种类型的消息要求接收方将确认消息发送回发送方，以确认收到此消息

2. Non-Confirmable Message (NON)– 不需要任何确认。当不需要确认时，即可靠性并不重要，则使用此方法。

3. Acknowledgment Message (ACK)– 此消息由接收方发送，作为从发件人收到的可确认消息的确认

4. Reset Message (RST)– 这是当接收方由于某些错误而无法处理可确认或不可确认消息时发送的消息。

每条消息都包含一个 16 位消息 ID，用于唯一标识消息并映射其相应的 ACK（如果有）。与其他协议一样，这通常用于消息的识别和重复数据删除。下面是一些解释基本消息交换的简单序列图：

2.1.2 CoAP 请求/响应

消息可以包含请求、响应，也可以包含空。请求/响应和消息类型之间没有任何关系，除了某些组合是不可能的或定义某些特定目的之外。让我们首先看一下请求和响应格式，然后深入研究数据包格式。

1. 请求使用方法代码，响应使用类似于 HTTP 但以二进制格式定义的响应代码。

2. CoAP 标准定义了四种请求方法 – 获取、放置、发布和删除。

3. CoAP 标准定义了类似于 HTTP 的响应代码 – 2.xx 表示成功，4.xx 表示客户端错误，5.xx 表示服务器错误。

4. 唯一的 0-8 字节令牌用于识别、映射请求和响应，就像消息 ID 用于识别消息和映射 ACK 的方式大致相同。

5. 对在 CON 消息中发送的请求的响应可以在 ACK 消息中搭载，也可以作为单独的 CON 或 NON 消息发送。

让我们看一些请求/响应通信的示例，以更好地了解应用程序如何交换数据。第一个图显示了可确认消息中的请求，响应捎带在确认消息中。

在下图中，当请求和响应在单独的可确认消息中发送且确认消息为空时，您可以看到消息 ID 和令牌的生存期和映射。

下图显示了在单独的不可确认消息中发送请求和响应的示例。

当然，消息和请求/响应的组合是标准不允许的或具有特定含义的。下表显示了什么是可能的，什么是不可能的。

| | CON | NON | ACK | RST | | ———— | ———————————– | —————————- | —————————- | —————————- | | Request | Yes | Yes | No | No | | Response | Yes | Yes | Yes | No | | Empty | CoAP Ping | No | Yes | Yes |

协议中建议的 CoAP ping 可用于服务器的检测信号/运行状况检查。CoAP ping 通信的工作方式如下：

1. 发件人发送一条空的可确认消息。

2. 接收方以空的重置消息进行响应。

2.1.3 CoAP 请求和响应代码

请求和响应由代码标识。响应代码派生自 HTTP。代码字段分为两部分：

1. 3 位类

2. 5 位细节

下表描述了代码，表示为格式，其中是类，是详细信息：c.ddcdd

请求代码

|Code|Description| |——–|—————-| |0.00|Empty message (Special Case)| |0.01|GET| |0.02|POST| |0.03|PUT| |0.04|DELETE|

响应代码

|Code|Description| |——–|—————–| |2.01|Created| |2.02|Deleted| |2.03|Valid| |2.04|Changed| |2.05|Content| |4.00|Bad Request| |4.01|Unauthorized| |4.02|Bad Option| |4.03|Forbidden| |4.04|Not Found| |4.05|Method Not Allowed| |4.06|Not Acceptable| |4.12|Precondition Failed| |4.13|Request Entity Too Large| |4.15|Unsupported Content-Format| |5.00|Internal Server Error| |5.01|Not Implemented| |5.02|Bad Gateway| |5.03|Service Unavailable| |5.04|Gateway Timeout| |5.05|Proxying Not Supported|

2.1.4 CoAP选项

您可能会认为我们已经讨论了很多关于请求/响应模型以及CoAP与HTTP的相似之处。但是除了请求和响应行之外，与HTTP仍然没有太多相似之处，对吧？本节讨论CoAP协议的“选项”字段，尽管采用二进制格式，但与HTTP标头有些相似。选项定义发送到其他终结点的元数据，与使用标头（如主机、内容类型等）发送的数据非常相似。每个选项字段定义由标准定义的选项编号、其长度和值。让我们看一下标准中定义的一些选项，这些选项听起来可能很熟悉：

| No. | Name | Format | Length(Bytes) | Description| | —- | ————– | —— | ————- | ———–| | 3 | Uri-Host | String | 1-255 | The hostname/IP address of the CoAP Server on which the resource is being requested | | 7 | Uri-Port | uint | 0-2 | The UDP port no. of the CoAP server | | 11 | Uri-Path | string | 0-255 | Each Uri-Path specifies a single segment of the absolute resource path of the URI | | 12 | Content-Format | uint | 0-2 | ID of the content format of Application data (IDs are defined by the standard) | | 15 | URI-Query | string | 0-255 | Each Uri-Query specifies single parameterized argument in the query part (query string) of the URI | | 17 | Accept | uint | 0-2 | Indicates which Content-Format is acceptable to the client. |

以下是标准定义的内容类型及其各自的 ID：

| Type | ID | | ———————— | —- | | text/plain;charset=utf-8 | 0 | | application/link-format | 40 | | application/xml | 41 | | application/octet-stream | 42 | | application/exi | 47 | | application/json | 50 |

2.2 发现机制

与许多其他物联网协议一样，CoAP也具有发现机制。发现机制是m2m通信的一个非常重要的方面，它有助于自动化，而无需人工交互。CoAP 发现旨在识别 CoAP 服务器上可用的资源。它使用 Constrained RESTful 环境 （CoRE） 链接格式协议 RFC 6690 受支持。长话短说，CoAP 服务器支持资源的 CoAP 链接格式，并由客户端查询以识别服务器上可用的资源。这是通过在标准中指定的资源路径上发送 GET 请求来执行的。当服务器收到请求时，它会使用服务器上可用的所有资源 URI 的列表进行响应。/.well-known/core

下面给出的是标准本身的示例。响应包含服务器上可用的资源 URI 条目的逗号分隔列表。每个条目都有：

1. 尖括号中的资源 URI，例如。</sensors>

2. 用分号分隔的 URI 属性，例如、、。;titlertif

请求 GET coap://server:port/.well-known/core

响应

2.05 Content</sensors>;title="Sensor Index",</sensors/temp>;rt="temperature-c";if="sensor",</sensors/light>;rt="light-lux";if="sensor"

3 CoAP安全

现在我们了解了CoAP的工作原理，让我们从进攻和防御的角度关注CoAP的安全方面。以下所有信息均基于我们在CoAP安全研究以及物联网产品和基础设施渗透测试项目方面的经验。我们将尝试在此博客中保持简单。在以后的博客文章中，我们将深入探讨对CoAP的不同攻击的技术方面。下面我们将尝试回答在物联网渗透测试中遇到新协议时通常会出现的一些问题。

3.1 协议安全/认证

我们已经详细讨论了协议，但没有提到身份验证。惊讶？CoAP 标准未指定任何身份验证机制。它依靠 DTLS 来提供协议级安全性。该标准为预配后的设备定义了四种安全模式：

1. NoSec– 这意味着没有协议级安全性，即禁用 DTLS。

2. PreSharedKey– 在此模式下，DTLS 已启用，并且设备具有每个密钥的预共享密钥列表，包括可用于与之通信的节点列表。

3. RawPublicKey– 在此模式下，DTLS 已启用，并且设备具有没有任何证书的非对称密钥对。密钥使用 OOB（出界）机制进行验证

4. Certificate– 在此模式下，DTLS 已启用，并且设备具有非对称密钥对以及由通用且受信任的根 CA 签名的 X.509 证书。

协议标准在第 9 节（第 69 页）中明确提到——“CoAP 本身不提供用于身份验证或授权的协议原语;如果需要，它可以由通信安全（即IPsec或DTLS）或对象安全（在有效载荷内）提供“ 不过，还有另一个标准RFC 8613定义了对象安全性。

3.2 工具

是否有任何工具可以帮助CoAP分析和评估？值得庆幸的是，有一些选择可用：

1. 开源库、客户端、服务器实现。这里唯一的问题是它们是僵化的，没有安全角度的指导，您最终可能会编辑或编写自定义脚本来完成这项工作。可以在此处找到所有库和包的列表。

2. EXPLIoT 框架我们计划在未来几个月内发布用于CoAP评估的基本插件。

3.3 侦察

好的，所以我们有了工具，现在怎么办？我们从哪里开始？第一件事是在 CoAP 服务器上执行侦察，以获取尽可能多的有关服务器的信息。

1. 是否实施了任何身份验证机制？

2. 通过向 URI 路径发送 GET 请求来获取服务器上可用资源的列表。/.well-known/core

3. URI 表示什么？它们的名称是否表示与物理环境（传感器/执行器）相关的任何操作？是否有用于配置/设置更新的 URI？

4. 您是否能够读取 （GET） 任何敏感信息？

5. 您是否能够操纵（放置/发布/删除）任何敏感信息？

6. 哪些 URI 在物联网生态系统中很重要并使用？这也可以通过对设备固件或移动应用程序（如果它与传感器通信）进行逆向工程来找到。

7. 是否使用 DTLS？

8. 如何在云中使用从设备发送的遥测数据？

3.4 分析

一旦我们收集了有关CoAP实施的基本信息，我们就可以利用它对设备或生态系统发起不同的攻击。生态系统是指物联网产品基础设施的所有组件，包括设备、网关、云和应用程序、移动应用程序等。我们将列出一些想法，让您的灰色细胞工作：

1. 使用不同的请求方法对所有 URI 进行暴力强制/模糊处理，以确定哪些 URI 响应哪些方法。但是，使用此方法存在损坏设备上的数据的风险。此外，有关查询参数和应用程序数据格式的更多信息将有助于定向模糊测试以获得有意义的结果

2. 如果实现了自定义身份验证，则需要对其进行反向工程以识别机制。

3. 反转固件或移动应用程序可能会为您提供敏感信息，例如

1. 资源 URI

2. 参数

3. 方法

4. 应用程序数据语义。

5. 在特定 URI 上交换和预期哪些数据，以及它如何影响组件的行为。

3.5 攻击

3.5.1 路径遍历（新瓶装旧酒）

在几年前的研究中，我们发现的一件事是，很少有CoAP实现没有（或错误地）解析或忽略URI中的双点“..”。这里的问题与Web相同，例如，如果URI绑定到文件，则有可能突破CoAP根并访问或操作其他文件。无文件 URI 中可能存在其他问题，研究人员将来可能会发现这些问题，谁知道呢。以下是标准中关于这些点的直接引用：

1. Section 5.10.1 page 54：“Uri-Path 和 Uri-Query 选项可以包含任何字符序列。不执行百分比编码。Uri-Path 选项的值不能是“.”或“..”（因为请求 URI 必须在解析为选项之前解析）。

2. Section 5.10.7 page 57– “每个位置路径选项指定资源绝对路径的一个段，每个位置查询选项指定一个参数化资源的参数。“位置-路径”和“位置-查询”选项可以包含任何字符序列。不执行百分比编码。位置路径选项的值不得为 “.” 或 “..”。

这里有一些重要的事情需要注意：

1. 不执行百分比编码。

2. 必须先解析请求 URI，然后再将其解析为选项。

3. 路径选项不得包含“.”或“..”

4. 任何符合 CoAP 的库/实现都应遵守标准中提到的内容。

5. 它没有提到如何处理接收数据包中选项的值为“.”或“..”的情况。

基于上述信息，让我们快速看一下我们检查双点的两个实现：

1. CaliforniumCalifornium是一个著名的基于Java的CoAP实现。Californium 的核心实现不会解析/忽略双点。这留给用户来实现。在他们的一个名为cf-simplefile-server的演示（示例）应用程序中，他们实现了一种方法来检测这种攻击。这意味着鉲的核心协议实现不提供任何安全性。我们于26年2019月<>日向Calicornium的核心开发人员之一发送了一封电子邮件。像往常一样，没有回应。我们没有进一步追究，如果有人提交了错误并设法获得了 CVE，请在信用:)中添加我们的名字。checkFileLocation()

2. libcoap– 也是 CoAP 协议的著名 C 实现。它们确实有过滤点的规定。他们在代码中实现了一个函数。但是，如果路径采用百分比编码，则会绕过检查。问题是负责执行此操作的函数首先检查点，然后将其传递给另一个函数，其中路径是百分比编码处理，如文件 uri.c 中的以下代码片段所示

dots()coap_split_path_impl()h()if (!dots(p, q - p)) {        h(p, q - p, data);}

一个例子是：我们在鉲的同一天向作者发送了一封电子邮件，即26年2019月<>日。在这种情况下，作者回答说，但是，回应是，只有当服务器实现被破坏时，它才会起作用。同样，我们没有进一步追究，因为作者不同意这是他们方面的问题。

GET coap://coap_server/foo/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

3.5.2 跨协议攻击

CoAP协议在许多方面与HTTP紧密耦合，包括请求/响应格式，缓存，代理等。这也为HTTP-to-CoAP转换/代理提供了机会，反之亦然。由于相似性，今天影响HTTP的一些传统攻击很可能适用于现在或将来的CoAP。正如我们在上述案例中已经看到的那样，我们在CoAP实现中发现了路径遍历问题，但是，它们最初是在HTTP中发现的。研究人员开始连接这些点并找到针对标头/选项、URI、请求/响应等的有趣攻击只是时间问题：

1. 发现使用传统攻击攻击 CoAP 是可行的

2. 寻找将攻击从一个协议转移到另一个协议的方法。注意：跨协议攻击是指攻击协议，而不是我们在以下场景中讨论的高应用程序。

3.5.3 通过恶意输入攻击应用程序

在 CoAP 应用程序体系结构中，服务器通常驻留在传感器上，您可以发现服务器上可用的资源/服务并发送请求。我们可以在两个地方攻击应用程序：

1. Server即在传感器上运行的应用程序 – 这只是意味着向它发送带有恶意应用程序有效负载的请求。您可以通过模糊有效负载来盲目地做到这一点，或者更好的方法是对固件进行逆向工程，更好地了解正在使用的应用程序数据格式、URI 查询的外观，然后手工制作恶意输入。

2. Client即在云/移动上运行的应用程序 – 这背后的想法与我们之前关于 MQTT 的博客文章（第 4.4.4 节）中讨论的内容非常相似。如果您还没有阅读它，我们建议您至少阅读第 4.4.4 节（如果不是完整的博客文章）。这种攻击的前提是，云/移动应用程序开发人员可能不会过滤来自传感器的输入以查找已知的应用程序攻击，这可能导致使用SQLi，XSS等传统攻击来利用这些应用程序。

3.5.4 通过请求访问和操作设备

使用上述各种技术，如果可以通过任何请求方法读取敏感数据和/或将所选数据写入敏感资源，则可以完全控制设备。例如，可以通过向设备发送预期从网关/用户接收的特定命令来控制设备。控制或关闭执行关键操作的物联网设备本身就是游戏结束！

3.5.5 克隆或迁移服务器（传感器）

根据是否实施身份验证/安全性以及您对密钥、证书、身份验证凭据（如果有）的访问权限，您可以让恶意设备伪装成传感器并发布合法传感器上的所有可用资源，您可以向客户端发送错误或恶意数据。

3.5.6 使用 CoAP 的分布式拒绝服务

CoAP在UDP上运行的事实使其成为攻击者在网络内以及Internet上的目标节点或机器上造成DDoS的完美选择。事实上，恶意行为者利用互联网上可用的 CoAP 设备进行 DDoS 已经是众所周知的事情，攻击者正在这样做。这背后的科学非常古老和普遍 - 攻击者欺骗受害者的IP，并将UDP数据报（在这种情况下为CoAP请求）发送到服务器，然后服务器响应受害者IP。如果您向网络/互联网上的所有可用服务器发送大量请求（欺骗性 IP），它们将依次响应受害者并使其内核过载，从而导致受害者拒绝服务。

3.6 缓解措施

CoAP中的漏洞和问题与其他协议，缺乏身份验证，访问控制非常相似。在尝试实施安全的 CoAP 服务时，应考虑以下几点：

1. 使用 DTLS。

2. 不希望实现自定义身份验证/加密机制。历史告诉我们，自定义安全实现很少按预期:)工作。

3. 更喜欢利用所有 8 字节为请求生成随机令牌。最好利用令牌的最大长度来生成尽可能多的随机性，因为大小越小，更容易进行暴力破解/猜测和欺骗。

4. 过滤 Uri 路径中的双点和单点（和 ），以防止路径遍历攻击。"..""."

5. 在设备上正确保护密钥材料/证书等。

6. 在服务器（设备）端筛选输入（请求应用程序有效负载）。

7. 在云端筛选输入（响应应用程序有效负载）。即使设备正在发送简单的遥测数据，也最好对其进行筛选以查找已知/传统攻击。

8. 实施适当的访问控制和身份验证机制，以访问执行关键操作或提供关键信息的资源。

9. 记录所有活动。

10. 有一种方法可以通知云/用户有关未经身份验证/恶意的请求。

11. 不要在设备固件中对凭据/敏感信息进行硬编码。

4 结论

我们希望这篇博文能为您提供有关CoAP协议，其工作原理，如何使用以及如何对基于CoAP的IoT / IIoT生态系统进行安全评估的良好高级概述。博客中提到的一些攻击可能没有被野外利用或作为协议报告给供应商，这些技术是相当新的。这是您找到尽可能多的漏洞和新攻击媒介的机会。上述工具、攻击和技术将提高评估效率，并为您提供对任何 CoAP 实施进行更深入的检查和安全研究的方向。