18. 安全考虑 (Security Considerations)

ICE 系统中可能存在若干类型的攻击. 本节考虑这些攻击及其对策. 这些对策包括:

• 将 ICE 与安全信令技术结合使用, 例如 SIPS.

• 将 connectivity checks 的总数限制为 100, 并可选地限制在 offer 或 answer 中接受的 candidates 数量.

18.1. 对 Connectivity Checks 的攻击

攻击者可能试图破坏 STUN connectivity checks. 最终, 所有这些攻击都会欺骗 agent, 使其对 connectivity checks 的结果产生错误认识. 攻击者可能试图造成的错误结论包括:

False Invalid (误判无效): : 攻击者可以欺骗一对 agents, 使其认为某个 candidate pair 无效, 即便它实际上有效. 这可用于使 agent 偏好另一个 candidate (例如攻击者注入的 candidate), 或通过迫使所有 candidates 失败来破坏呼叫.

False Valid (误判有效): : 攻击者可以欺骗一对 agents, 使其认为某个 candidate pair 有效, 即便它实际上无效. 这可能导致 agent 继续会话, 但随后无法接收任何媒体.

False Peer Reflexive Candidate (错误的 Peer Reflexive Candidate): : 攻击者可以导致 agent 发现一个本不应发现的新 peer reflexive candidate. 这可用于将媒体流重定向到 Denial-of-Service (DoS) 目标或攻击者, 用于窃听或其他目的.

False Valid on False Candidate (错误 Candidate 上的误判有效): : 攻击者已经让 agent 相信存在一个地址实际上无法路由到该 agent 的 candidate (例如通过注入 false peer reflexive candidate 或 false server reflexive candidate). 随后它必须发起攻击, 迫使 agents 相信该 candidate 有效.

如果攻击者能够造成 false peer reflexive candidate 或 false valid on a false candidate, 它就可以发起 [RFC5389] 中描述的任何攻击.

为迫使 false invalid 结果出现, 攻击者必须等待某个 agent 发送 connectivity check. 当该 check 发送时, 攻击者需要注入一个带有不可恢复错误响应 (例如 400) 的伪响应. 但是, 由于该 candidate 实际上有效, 原始 request 可能到达 peer agent, 并产生成功响应. 攻击者需要通过 DoS 攻击, layer 2 网络破坏或其他技术迫使该分组或其响应被丢弃. 如果不这样做, 成功响应也会到达发起方, 提醒其可能存在攻击. 幸运的是, STUN short-term credential 机制完全缓解了此攻击. 攻击者需要注入伪响应, 而为了让该响应被处理, 攻击者需要 password. 如果 offer/answer 信令受到保护, 攻击者不会拥有 password, 其响应会被丢弃.

迫使 false valid 结果的方式类似. agent 需要等待来自每个 agent 的 Binding request, 并注入伪成功响应. 攻击者不需要担心破坏实际响应, 因为如果 candidate 无效, 实际响应大概无论如何都不会被收到. 但是, 与 false invalid 攻击一样, 该攻击通过 STUN short-term credential 机制结合安全的 offer/answer 交换得到缓解.

迫使 false peer reflexive candidate 结果既可以通过伪 requests 或 responses 完成, 也可以通过重放完成. 我们先考虑伪 requests 和 responses 的情况. 它要求攻击者向一个 agent 发送 Binding request, 并使用 false candidate 的源 IP 地址和端口. 此外, 攻击者必须等待来自另一个 agent 的 Binding request, 并生成一个带有 XOR-MAPPED-ADDRESS 属性的伪响应, 该属性包含 false candidate. 与这里描述的其他攻击一样, 该攻击通过 STUN message integrity 机制和安全的 offer/answer 交换得到缓解.

通过 packet replays 迫使 false peer reflexive candidate 结果则不同. 攻击者等待其中一个 agent 发送 check. 它拦截该 request, 并使用伪造的源 IP 地址将其重放给另一个 agent. 它还必须阻止原始 request 到达 remote agent, 可以通过发起 DoS 攻击使分组被丢弃, 或使用 layer 2 机制迫使其被丢弃. 重放的分组被另一个 agent 接收并接受, 因为 integrity check 通过 (integrity check 不能也不会覆盖源 IP 地址和端口). 随后会对其进行响应. 该响应将包含带有 false candidate 的 XOR-MAPPED-ADDRESS, 并发送到该 false candidate. 攻击者随后必须接收该响应, 并将其 relay 给发起方.

另一个 agent 随后会向该 false candidate 发起 connectivity check. 该验证需要成功. 这要求攻击者在 false candidate 上迫使 false valid. 通过注入伪 requests 或 responses 来实现这一目标会被 STUN 和 offer/answer 交换的 integrity 机制阻止. 因此, 该攻击只能通过重放发起. 为此, 攻击者必须拦截发往该 false candidate 的 check, 并将其重放给另一个 agent. 然后, 它还必须拦截响应并同样重放回来.

除非攻击者本身由 false candidate 标识, 否则该攻击非常难以发起. 这是因为它要求攻击者拦截并重放由两个不同 hosts 发送的分组. 如果两个 agents 位于不同网络 (例如跨 public Internet), 该攻击可能难以协调, 因为它需要同时针对网络不同位置上的两个不同 endpoints 发生.

如果攻击者自身由 false candidate 标识, 该攻击更容易协调. 但是, 如果使用 SRTP [RFC3711], 攻击者将无法播放媒体分组, 只能丢弃它们, 实际上禁用该呼叫的媒体流. 不过, 该攻击要求 agent 破坏分组, 以阻止 connectivity check 到达目标. 在这种情况下, 如果目标是破坏媒体流, 直接使用相同机制破坏它会容易得多, 而不是攻击 ICE.

18.2. 对 Server Reflexive Address Gathering 的攻击

ICE endpoints 使用 STUN Binding requests 从 STUN server 收集 server reflexive candidates. 这些 requests 没有以任何方式认证. 因此, 攻击者可以采用多种技术向客户端提供 false server reflexive candidate:

• 攻击者可以破坏 DNS, 使 DNS queries 返回 rogue STUN server 地址. 该 server 可以向客户端提供伪 server reflexive candidates. 该攻击可由 DNS security 缓解, 尽管不要求使用 DNS-SEC 来解决它.

• 能观察 STUN messages 的攻击者 (例如位于共享网络段, 如 WiFi 上的攻击者) 可以注入一个有效且会被客户端接受的伪响应.

• 攻击者可以通过病毒破坏 STUN server, 使其发送带有错误 mapped addresses 的响应.

通过这些攻击学习到的 false mapped address 将作为 ICE 交换中的 server reflexive candidate 使用. 要让该 candidate 实际用于媒体, 攻击者还必须攻击 connectivity checks, 特别是要在 false candidate 上迫使 false valid. 如果 false address 标识的是第四方 (既不是 offerer, answerer, 也不是攻击者), 该攻击非常难以发起, 因为它要求攻击会话中每个 agent 生成的 checks; 如果它标识攻击者自身, 则该攻击会被 SRTP 阻止.

如果攻击者选择不攻击 connectivity checks, 它能造成的最坏结果只是阻止使用 server reflexive candidate. 但是, 如果 peer agent 至少有一个 candidate 可由被攻击的 agent 到达, 则 STUN connectivity checks 本身会提供可用于媒体交换的 peer reflexive candidate. peer reflexive candidates 通常优先于 server reflexive candidates. 因此, 仅针对 STUN address gathering 的攻击通常对会话完全没有影响.

18.3. 对 Relayed Candidate Gathering 的攻击

攻击者可能试图破坏 relayed candidates 的收集, 迫使客户端相信它拥有 false relayed candidate. 与 TURN server 的交换使用 long-term credential 进行认证. 因此, 注入伪 responses 或 requests 不会奏效. 此外, 与 Binding requests 不同, Allocate requests 不易受到修改源 IP 地址和端口的 replay attacks 影响, 因为源 IP 地址和端口不会用于向客户端提供其 relayed candidate.

但是, TURN servers 容易受到 DNS attacks, 或受到针对 TURN server 的病毒攻击, 使其成为 zombie 或 rogue server. 这些攻击可以通过 DNS-SEC 以及 TURN servers 上良好的主机和软件安全措施来缓解.

即便攻击者已导致客户端相信存在 false relayed candidate, connectivity checks 也只会在该 candidate 成功时才使用它. 因此, 攻击者必须按上文发起 false valid on a false candidate 攻击, 这是一种非常难以协调的攻击.

18.4. 对 Offer/Answer 交换的攻击

能够修改或破坏 offer/answer 交换本身的攻击者, 可以很容易地利用 ICE 发起多种攻击. 它们可以将媒体定向到 DoS 攻击目标, 可以将自己插入媒体流, 等等. 这些与 offer/answer 交换的一般安全考虑类似, RFC 3264 [RFC3264] 中的安全考虑适用. 这些要求为 offers 和 answers 提供 message integrity 和 encryption 技术; 使用 SIP 时, SIPS 机制 [RFC3261] 满足这些要求. 因此, 推荐将 SIPS 与 ICE 一起使用.

18.5. 内部人员攻击

除了攻击者作为第三方试图插入伪 offers, answers 或 stun messages 的攻击之外, 当攻击者是 ICE 交换中经过认证且有效的参与者时, ICE 还可能存在若干攻击.

18.5.1. Voice Hammer Attack

voice hammer attack 是一种 amplification attack. 在这种攻击中, 攻击者向其他 agents 发起会话, 并恶意地将 DoS 目标的 IP 地址和端口作为 SDP 中信令的媒体流量 destination. 这会导致显著放大; 单个 offer/answer 交换可以创建持续的媒体分组洪泛, 可能速率很高 (考虑视频源). 该攻击不是 ICE 特有的, 但 ICE 可以帮助提供修复.

具体而言, 如果使用 ICE, 接收恶意 SDP 的 agent 会在向媒体目标发送媒体之前, 先对该目标执行 connectivity checks. 如果该目标是第三方 host, checks 不会成功, 媒体永远不会被发送.

遗憾的是, 如果不使用 ICE, ICE 就无能为力; 在这种情况下, 攻击者可以简单地发送不带 ICE 参数的 offer. 但是, 在 client 集合已知且限于支持 ICE 的环境中, server 可以拒绝任何未指示 ICE 支持的 offers 或 answers.

18.5.2. STUN Amplification Attack

STUN amplification attack 与 voice hammer 类似. 但是, 被定向到目标的不是语音分组, 而是 STUN connectivity checks. 攻击者发送一个包含大量 candidates 的 offer, 例如 50 个. answerer 收到该 offer 并开始其 checks, 这些 checks 指向目标, 因而永远不会产生响应. answerer 将每 Ta ms (例如 Ta=20ms) 启动一个新的 connectivity check. 但是, 由于 candidates 数量很大, retransmission timers 被设置为很大的值. 因此, 分组会以每 Ta 毫秒一个的间隔发送, 随后以逐渐增加的间隔发送. 因此, STUN 发送分组的速率不会快于媒体发送速率, 且 STUN 分组只会短暂存在, 直到该会话的 ICE 失败. 不过, 这仍然是一种 amplification 机制.

不可能完全消除 amplification, 但可以通过多种启发式方法减少流量. agents 应该将其执行的 connectivity checks 总数限制为 100. 此外, agents 可以限制它们在 offer 或 answer 中接受的 candidates 数量.

希望避免此类攻击的协议通常会强制 initiator 在发送下一条消息之前等待响应. 但是, 对 ICE 而言这是不可能的. 无法区分以下两种情况:

• 没有响应, 是因为 initiator 正被用于对不会响应的无辜目标发起 DoS 攻击.

• 没有响应, 是因为该 IP 地址和端口无法由 initiator 到达.

在第二种情况下, 应在下一次机会发送另一个 check; 而在前一种情况下, 不应发送更多 checks.

18.6. 与 Application Layer Gateways 和 SIP 的交互

Application Layer Gateways (ALGs) 是 NAT device 中存在的功能, 它们检查分组内容并修改内容, 以促进应用协议的 NAT traversal. Session Border Controllers (SBCs) 是 ALGs 的近亲, 但透明度较低, 因为它们实际上作为 application layer SIP intermediaries 存在. ICE 与 SBCs 和 ALGs 存在交互.

如果 ALG 感知 SIP 但不感知 ICE, 只要 ALG 正确修改 SDP, ICE 就能通过它工作. 正确的 ALG 实现行为如下:

• 如果 m 和 c lines 或 rtcp 属性包含外部地址, ALG 不修改它们.

• 如果 m 和 c lines 包含内部地址, 修改取决于 ALG 的状态:

  如果 ALG 已经建立了一个 binding, 将外部端口映射到与 m 和 c lines 或 rtcp 属性中的值匹配的内部 IP 地址和端口, 则 ALG 使用该 binding, 而不是创建新 binding.

  如果 ALG 尚无 binding, 它会创建一个新 binding 并修改 SDP, 重写 m 和 c lines 以及 rtcp 属性.

遗憾的是, 许多 ALGs 已知在这些 corner cases 中表现不佳. ICE 不试图绕过损坏的 ALGs, 因为这超出其功能范围. ICE 可以帮助诊断这些情况, 它们通常表现为 candidate 集合与 m 和 c lines 以及 rtcp 属性之间不匹配. ice-mismatch 属性用于此目的.

当信令运行在 TLS 之上时, ICE 通过 ALGs 的效果最好. 这会阻止 ALG 操纵 SDP messages 并干扰 ICE 操作. 预期部署在 ALGs 后面的实现 应该提供 SDP 的 TLS transport.

如果 SBC 感知 SIP 但不感知 ICE, 结果取决于 SBC 的行为. 如果它作为合适的 Back-to-Back User Agent (B2BUA) 工作, SBC 会移除任何它不理解的 SDP 属性, 包括 ICE 属性. 因此, 对两个 endpoints 而言, 呼叫看起来就像对方不支持 ICE. 这将导致 ICE 被禁用, 如果 SBC 要求媒体经过它, 媒体就会流经 SBC. 然而, 如果 SBC 不加修改地传递 ICE 属性, 却修改媒体的 default destination (包含在 m 和 c lines 以及 rtcp 属性中), 这会被检测为 ICE mismatch, 并且该呼叫的 ICE 处理会中止. 让 ICE 作为 "绕过" SBCs 的工具超出了 ICE 的范围. 如果存在 SBC, ICE 将不被使用, SBC 技术优先.