16. 安全考虑 (Security Considerations)
16.1. 针对协议的攻击 (Attacks against the Protocol)
16.1.1. 外部攻击 (Outside Attacks)
攻击者可以尝试修改传输中的 STUN 消息, 以导致 STUN 操作失败. 这类针对请求和响应的攻击可以通过消息完整性机制检测, 该机制可使用短期凭据或长期凭据. 当然, 一旦检测到, 被篡改的包会被丢弃, 从而使 STUN 事务实际失败. 此攻击只能由路径上攻击者发起.
能够观察但不能修改传输中 STUN 消息的攻击者 (例如位于共享接入介质上的攻击者, 如 Wi-Fi) 可以看到 STUN 请求, 然后立即发送 STUN 响应, 通常是错误响应, 以干扰 STUN 处理. 对于带有 MESSAGE-INTEGRITY 的消息, 此攻击也会被防止. 但是, 某些错误响应, 特别是与认证相关的错误响应, 无法由 MESSAGE-INTEGRITY 保护. 当 STUN 本身运行在 TLS 等安全传输协议上时, 这些攻击会被完全缓解.
根据 STUN 用法不同, 这些攻击的后果可能很小, 因而可能不需要消息完整性来阻止它们. 例如, 当 STUN 与基本 STUN 服务器一起使用, 以发现供 ICE 使用的服务器反射候选地址时, 不需要认证和消息完整性, 因为这些攻击会在连通性检查阶段被检测到. 但是, 连通性检查本身需要保护, 以便 ICE 整体正常运行. 如 Section 14 所述, STUN 用法会描述何时需要认证和消息完整性.
由于 STUN 使用带共享密钥的 HMAC 来进行认证和完整性保护, 它容易受到离线字典攻击. 使用认证时, 应该选择不易受到此类离线字典攻击的密码. 使用 TLS 保护信道本身可以缓解这些攻击. 但是, STUN 最常运行在 UDP 上, 在这些情况下, 强密码是抵御这些攻击的唯一防线.
16.1.2. 内部攻击 (Inside Attacks)
恶意客户端可能试图通过向服务器发送大量 STUN 请求来发起 DoS 攻击. 幸运的是, STUN 请求可以由服务器以无状态方式处理, 这使得此类攻击难以发起.
恶意客户端可以将 STUN 服务器用作反射器, 向其发送带有伪造源 IP 地址和端口的请求. 在这种情况下, 响应会被发送到该源 IP 和端口. 此攻击不会放大包数量 (STUN 服务器对客户端发送的每个包发送一个包), 但由于 STUN 响应通常大于请求, 数据量会有小幅放大. 入口源地址过滤可以帮助缓解此攻击.
通过 SOFTWARE 属性暴露代理的具体软件版本, 可能使攻击者更容易针对已知包含安全漏洞的软件发起攻击. 实现者应该将 SOFTWARE 属性的使用作为可配置选项.
16.2. 影响用法的攻击 (Attacks Affecting the Usage)
本节列出可能针对 STUN 用法发起的攻击. 每种 STUN 用法都必须考虑这些攻击是否适用于它, 如果适用, 则讨论对策.
本节中的大多数攻击都围绕攻击者修改 STUN 客户端通过 Binding 请求/响应事务获知的反射地址展开. 由于反射地址的使用取决于具体用法, 这些攻击的适用性和补救措施也与用法相关. 在最常见情况下, 路径上攻击者可以轻易修改反射地址. 例如, 考虑 STUN 直接运行在 UDP 上的常见情况. 在此情况下, 路径上攻击者可以在 Binding 请求到达 STUN 服务器之前修改其源 IP 地址. STUN 服务器随后会在 XOR-MAPPED-ADDRESS 属性中将此 IP 地址返回给客户端, 并将响应发回该 (伪造的) IP 地址和端口. 如果攻击者也能截获此响应, 它可以将响应重定向回客户端. 使用消息完整性检查来防御此攻击是不可能的, 因为消息完整性值无法覆盖源 IP 地址, 该地址必须可由中间 NAT 修改. 因此, 防止下列攻击的一种方案是让客户端验证获知的反射地址, ICE [MMUSIC-ICE] 中就是这样做的. 其他用法可以使用其他方式来防止这些攻击.
16.2.1. 攻击 I: 针对目标的分布式 DoS (DDoS) (Attack I: Distributed DoS (DDoS) against a Target)
在此攻击中, 攻击者向一个或多个客户端提供指向预期目标的同一伪造反射地址. 这会诱使 STUN 客户端认为它们的反射地址等于该目标的地址. 如果客户端分发该反射地址以便在其上接收流量 (例如在 SIP 消息中), 流量反而会被发送到目标. 此攻击可以提供显著放大, 特别是与使用 STUN 来启用多媒体应用的客户端一起使用时. 但是, 它只能针对满足如下条件的目标发起: 从 STUN 服务器到目标的包会经过攻击者, 这限制了攻击可行的场景.
16.2.2. 攻击 II: 使客户端静默 (Attack II: Silencing a Client)
在此攻击中, 攻击者向 STUN 客户端提供一个伪造的反射地址. 它提供的反射地址是一个不会路由到任何位置的传输地址. 因此, 当客户端分发该反射地址后, 它将收不到预期在该地址上接收的任何包. 对攻击者而言, 此利用并不特别有吸引力. 它影响单个客户端, 而这通常不是期望目标. 此外, 任何能够发起此攻击的攻击者都可以通过其他方式对客户端发起更有效的 DoS 攻击, 例如阻止客户端从 STUN 服务器甚至 DHCP 服务器接收任何响应. 与 Section 16.2.1 中的攻击一样, 只有当攻击者位于从 STUN 服务器发往这个未使用 IP 地址的包路径上时, 此攻击才可能发生.
16.2.3. 攻击 III: 冒充客户端身份 (Attack III: Assuming the Identity of a Client)
此攻击类似于攻击 II. 但是, 伪造的反射地址指向攻击者自身. 这允许攻击者接收原本发往客户端的流量.
16.2.4. 攻击 IV: 窃听 (Attack IV: Eavesdropping)
在此攻击中, 攻击者强制客户端使用路由到攻击者自身的反射地址. 随后攻击者将其收到的任何包转发给客户端. 此攻击会允许攻击者观察发送给客户端的所有包. 但是, 为了发起此攻击, 攻击者必须已经能够观察从客户端到 STUN 服务器的包. 在大多数情况下 (例如从接入网络发起攻击时), 这意味着攻击者已经能够观察发送给客户端的包. 因此, 此攻击只对位于客户端到 STUN 服务器路径上, 但通常不在路由到客户端的包路径上的攻击者观察流量有用.
16.3. Hash 敏捷性计划 (Hash Agility Plan)
本规范使用 HMAC-SHA-1 计算消息完整性. 如果未来发现 HMAC-SHA-1 已被攻破, 可以应用以下补救措施.
我们将定义一个 STUN 扩展, 引入使用新 hash 计算的新消息完整性属性. 客户端需要在其请求或指示中同时包含新的和旧的消息完整性属性. 新服务器会使用新的消息完整性属性, 旧服务器会使用旧属性. 在混合实现部署的过渡期之后, 旧的消息完整性属性将由另一份规范弃用, 客户端也将停止在请求中包含它.
还需要注意, HMAC 使用的密钥本身是使用 username 和 password 的 hash 计算出来的. 选择 MD5 hash 是为了兼容以这种形式存储密码的旧数据库. 如果未来工作发现使用 MD5 输入的 HMAC 不安全, 并且需要不同的 hash, 此计划也可用于该变化. 但是, 这将要求管理员重新填充其数据库.