apisix安全评估

admin 2022年6月14日07:49:55评论110 views字数 3555阅读11分51秒阅读模式

背景

有大佬已经对 apisix攻击面[1] 做过总结。

本文记录一下自己之前的评估过程。

分析过程

评估哪些模块?

首先我需要知道要评估啥,就像搞渗透时,我得先知道攻击面在哪里。

apisix安全评估

根据文档,可以知道apisix项目包括很多系统,包括:

  • 网关[2]
  • dashboard[3]
  • ingress控制器[4]
  • 各种sdk

sdk即使有漏洞,攻击场景也感觉有限,所以没有评估。

"ingress控制器"需要结合k8s中的网络来做评估,因为时间有限,所以只是粗略看了一下。

我主要看了网关和dashboard两个系统。

从文档上很容易看出来,网关有三个重要的模块:

  • 插件
  • admin api
  • control api
apisix安全评估

对于api来说,首先要检查的是"身份认证"和"鉴权"这两个安全措施。

apisix历史漏洞绝大部分都出现在插件中,所以插件属于"漏洞重灾区"。

评估api安全性:身份认证和鉴权

admin api实现如下:

  • admin api 使用token做认证,token是硬编码的。这个问题已经被提交过漏洞,官方应该不打算修复。
  • admin api 鉴权上,设计了viewer和非viewer两种角色。viewer角色只允许get方法。

靶场见 Apache APISIX 默认密钥漏洞(CVE-2020-13945)[5]

control api是没有身份认证的,但是有两个点限制了攻击:

  • 默认它只在本地监听端口
  • 插件无关的control api只有"读信息"的功能,没有发现啥风险点

插件创建的control api是一个潜在的攻击面,不过我没找到啥漏洞。

评估插件安全性

因为插件默认都是不开启的,所以虽然它是重灾区,但是我并没有投入过多精力去审计。

不过在这里确实发现了一个安全问题,报告给官方后,分配了CVE-2022-25757[6]

下面来说一下这个安全问题。

CVE-2022-25757

这个安全问题是什么?

request-validation插件可以检查HTTP请求头和BODY内容,当不符合用户配置的规则时,请求就不会转发到上游。

比如用户按照如下规则配置时,body_schema限制请求中必须要有string_payload参数,并且是字符串类型,长度在1到32字节之间。

 curl http://127.0.0.1:9080/apisix/admin/routes/10 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
 {
     "uri": "/10",
     "plugins": {
         "request-validation": {
         "body_schema": {
               "type": "object",
               "required": ["string_payload"],
               "properties": {
                   "string_payload": {
                       "type": "string",
                       "minLength": 1,
                       "maxLength": 32
                   }
               }
           }
         }
     },
     "upstream": {
         "type": "roundrobin",
         "nodes": {
             "192.168.2.189:8888": 1
         }
     }
 }'

但是恶意用户发送如下请求时,有可能绕过限制

POST http://127.0.0.1:9080/10
...
{"string_payload":"","string_payload":"1111"}

为什么会绕过限制?

request-validation.lua中使用cjson.safe库解析字符串为json对象,对于带有"重复键值"的json,它会取最后面的值。比如{"string_payload":"","string_payload":"1111"},request-validation插件会认为string_payload="1111"。

local _M = {
    version = 0.1,
    decode = require("cjson.safe").decode,
}

但是有很多流行的库,对于带有"重复键值"的json,它会取最前面的值,因此{"string_payload":"","string_payload":"1111"}会被认为string_payload=""。

因此request-validation插件和上游服务在解析json时可能存在差异性,所以会导致限制被绕过

哪些库和request-validation插件在解析"重复键值json"时存在差异?

根据 https://bishopfox.com/blog/json-interoperability-vulnerabilities 文章,可以知道最起码以下库和request-validation插件在解析"重复键值json"时存在差异。

apisix安全评估

选取其中的gojay库做了验证,程序打印gojay而不是gojay2

package main
import "github.com/francoispqt/gojay"

type user struct {
    id int
    name string
    email string
}
// implement gojay.UnmarshalerJSONObject
func (u *user) UnmarshalJSONObject(dec *gojay.Decoder, key string) error {
    switch key {
    case "id":
        return dec.Int(&u.id)
    case "name":
        return dec.String(&u.name)
    case "email":
        return dec.String(&u.email)
    }
    return nil
}
func (u *user) NKeys() int {
    return 3
}

func main() {
    u := &user{}
    d := []byte(`{"id":1,"name":"gojay","email":"[email protected]"},"name":"gojay2"`)
    err := gojay.UnmarshalJSONObject(d, u)
    if err != nil {
        //log.Fatal(err)
    }
    println(u.name);  // 取最前面的key的值,也就是gojay,而不是gojay2
}

总结

评估思路比较简单:

  • 识别攻击面
  • api关注身份认证和鉴权
  • 插件关注业务逻辑

openresty配置中的api也是攻击面,下一篇再写。

说一个题外话:apisix的插件机制提供了很好的扩展能力,再加上openresty的高性能,或许拿来做waf架构很合适。

参考资料

[1]

apisix攻击面: https://ricterz.me/posts/2021-07-05-apache-apisix-attack-surface-research.txt

[2]

网关: https://github.com/apache/apisix

[3]

dashboard: https://github.com/apache/apisix-dashboard

[4]

ingress控制器: https://github.com/apache/apisix-ingress-controller

[5]

Apache APISIX 默认密钥漏洞(CVE-2020-13945): https://github.com/vulhub/vulhub/blob/master/apisix/CVE-2020-13945/README.zh-cn.md

[6]

CVE-2022-25757: https://www.openwall.com/lists/oss-security/2022/03/28/2


原文始发于微信公众号(leveryd):apisix安全评估

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年6月14日07:49:55
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   apisix安全评估http://cn-sec.com/archives/1114185.html

发表评论

匿名网友 填写信息