Malicious exploitation of Unauthenticated Request submissions

During a recent penetration test on one of our client’s application, we came across a case of malicious file propagation through the application server. The attack does not require an authenticated session. The vulnerable section is accessible by unauthenticated users. The attack involves an attacker submitting a malicious request (a malicious file is uploaded by the attacker) on behalf of anyone (victim) whose email id is known to the attacker. Once the attacker targets a victim, the victim receives an email about the query made by the attacker. The victim, though puzzled(“When did I make such a request?”), clicks on the email and downloads the file uploaded by the attacker and the file does whatever evil actions it was meant to perform. Thus, it is a Malicious exploitation of Unauthenticated Request submissions.

The details of the attack, root cause, logical issue and remediation are explained in the later sections of the blog.

Scenario:

Suppose Andrew is the victim and Bill is the attacker and the affected domain is support.example.com. Bill visits the URL and submits a support request to the example application. The submission includes a malicious file (as there is no restriction on the type of file uploaded). The request subject says, “Thanks for the recent purchase and Bank account details submission” which will provoke the user to see the support request submission. The report details will lure the user into downloading the attached file by saying “I have a made a recent purchase of 50$ for a product at your store. And the same failed and hence I requested a refund of my amount. But there seems to be no transaction from your end and hence, I am uploading my bank account statement for the same. I have updated my account details in my user profile as well”. The attached file will be a malicious file say BankStatement.pdf. This file can be a web attack vector that might enable Bill to gain complete control over Andrew’s machine once Andrew has downloaded the file. The same method can be used to spread malwares using example’s server as a medium.

* Bill just needs Andrew’s email address to make this attack successful.

*Portions of the screenshot have been intentionally blurred following the practice of the Responsible disclosure.

Payload used in this attack

We have used a malicious PDF file created using Metasploit, a tool for developing and executing exploit code. A screenshot of the report of the malicious PDF done from an online scanner:

Root Cause: Unrestricted File upload

• Malicious file propagation through example portal
• Unauthenticated access to the Support request submission portal / anonymous report submission allowed on the domain

Logical issue with this bug

The application allows anyone to create a support ticket anonymously. To worsen the case, one can also create a support ticket on someone else’s behalf just by entering the email address of the victim in the support ticket form. An attacker may exploit this issue, by creating a ticket on victim’s behalf and attaching a malicious file (pdf/doc/exe) in the ticket. As per the working of the application, the victim will receive an email (provided by attacker while creating ticket) mentioning about the ticket details and a link of the uploaded file. Now, the attacker may form the text of ticket in such a way that it provokes the victim to download the file. 
This vulnerability also allows unrestricted file upload which allows arbitrary file upload to the server and the same to attack the end-users (victim). Unrestricted file upload is itself a discrete issue alongside the logical bug mentioned in the above paragraph. The combination of the two bugs allows this chain of attacks to happen.

Remediation

• Unrestricted file upload should not be present on the application.
  There should be restriction of file types that can be uploaded, maximum file size that can be uploaded, restriction on file uploads of null size and blocking dangerous extensions such as .exe or .sh, blocking double extensions, Preventing access to the upload folder with .htaccess, do not allow overwrite of existing files
• Also, the application should only allow posting the support request form after authenticating the user. This will prevent the attacker from posting support requests on the behalf of users(victim).
• A precautionary measure should be included in the e-mail: The mail containing the “submission” intimation should contain a cautionary message stating that “If it was not you, click to remove/review the submission”. This would trigger the genuine user to check for the malicious submission done on his behalf.