Unrestricted Upload of File with Dangerous Type in cortezaproject/corteza-server
Reported on
Aug 20th 2021
✍️ Description
Hi team i found an Unrestricted File Upload on https://latest.cortezaproject.org/ which let me upload anything. File Extensions Such as .html , .svg and others should not be executed on the server side.
🕵️♂️ Proof of Concept
Step to Reproduce
1- Go to the Employees tab and choose an employee to change their photo
2- After click on clone to upload a file
3- Upload your shell saved as svg as profile picture.
4- After we click on save , we notice that the file is saved in the server with a svg extension
the svg file contains the following payload: which is allowed us to display cookies stored in the localstorage for example:
document.location="https://latest.cortezaproject.org/"+localStorage.getItem(localStorage.key(1));
******* Remaque : this vulnerability is present in all image upload tabs
💥 Impact
The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement.Here is the list of attacks that the attacker might do:
--Compromise the web server by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack
other servers, and exploit the local vulnerabilities, and so forth.
--Put a phishing page into the website.
--Put a permanent XSS into the website.
--Bypass cross-origin resource sharing (CORS) policy and exfiltrate potentially sensitive data.
--Upload a file using malicious path or name which overwrites critical file or personal data that other users access. For example; the attacker might ---
@admin any update for this vulnerability please !
Hey Belarchaoui, not yet I'm afraid. Sorry for the wait!
I'll send them a follow up for you. Thank you for your patience.
Hi, apologies for the delay.
A while ago (in a different huntr ticket) we've introduced CSP for file types that may be dangerous when viewed in the browser. Now when you try to open, a SVG for example, it is sandboxed and shouldn't cause much trouble.
I tried your reproduction steps with an evil.svg which should show an alert message and it successfully didn't do anything.
Can you see if the reproduction steps are up to date or record a quick screen capture to see if I missed something?
I'll sync internally if we wish to implement more restrictions in regards to file types.
Hello Tomaž Jerman
To show the impact of downloading a malicious file with the extension .svg for example I assure you that we can launch an ssrf attack via an svg file
***** POC:
I created a malicious SVG file (poc_ad2.svg) because the app has unlimited file download bug and does not filter the content, the code below can be saved with the file with the extension .svg and I used the payload below to trigger an ssrf attack:
1- Go to the Employees tab and choose an employee to change their photo 2- After clicking on clone to download a file 3- Download your shell saved in svg as a profile image to define the profile image and modify the xlink with your owner server. 4- After clicking on save, we notice that the file is saved on the server 5- if another user download the profile and open the svg file locally, he can see images from other server (my server)
**** to check if the attack was launched:
please check your server log (python -m SimpleHTTPServer).
from the server logs we noticed that we got an http 200 rest so all I can confirm is that this is indeed SSRF as the request is coming from the own server
****** Payload .svg file:
<? xml version = "1.0" encoding = "UTF-8" standalone = "no"?> <svg xmlns: svg = "http://www.w3.org/2000/svg" xmlns = "http://www.w3.org/2000/svg" xmlns: xlink = "http://www.w3.org/1999/xlink" style = "overflow: hidden; position: relative;" width = "300" height = "200">
<image x = "10" y = "10" width = "276" height = "110" xlink: href = "http://192.168.127.129:8000/test_ssrf.jpeg" stroke-width = "1" id = "image3204" /> <rect x = "0" y = "150" height = "10" width = "300" style = "fill in: black" /> </svg>
results: the platform does not check the content of uplaoded files this means that an attacker can inject codes to launch attacks like ssrf, or exploit other vulnerabilities if they exist in the platform.
screen capture of ssrf attack steps:
uplaod svf file :
https://i.ibb.co/yS2d0CQ/poc2.png
download svg file by other user :
https://i.ibb.co/THdgvMT/poc3.png
server logs of ssrf attack :
https://i.ibb.co/Smmsz0h/poc1.png
Due to lack of file content filtering it is possible to query any URL on any port with URL paramters regarding if it is image or not. It is required for external attacker to have significant amount of luck to find vulnerable service inside the infrastrucutre or have additional information about internal target.
We will be addressing this issue in the following weeks. We are not yet sure how we wish to approach this, so if you have any suggestions, feel free to share.
Thank you for disclosing the issue!
thank you for your collaboration yes well I will be available
@Tomaž Jerman , @admin Any update for this vulnerability please !
@belarchaoui - we will wait for a response from the maintainer!
@Tomaž Jerman , @admin Any update for this vulnerability please !
@belarchaoui - I just sent the maintainer a personal e-mail to see if there are any updates, or if there is anything we can do to help close off this report.
I will keep you updated on any response.
hello any bounbty for this vulnerability
hello any bounty for this vulnerability?
The disclosure bounty has already been awarded for this vulnerability.