Bypass File Upload Restrictions: CVE-2019–13976

Product: eGain Chat (Version 15.0.3)

Vendor: eGain

Vendor URL: http://www.egain.com/products/live-chat-software/

Bug: Bypass the restrictions implemented on file upload functionality

Exploitable: Yes

Reported on: 11 October 2018

Vendor Fixed Issue: 21 November 2018

The environment where the product was tested:

eGain chat is the product developed by company eGain. The targeted customers of this company are small or large size organization which provides the customer support to their customers.

I was performing penetration testing for one of my clients in France. My client was one of the largest banks in France. When you look after the security of any bank, there is one rule, “No accepted business risk policy”. My client had implemented the best security policies when it comes to email exchange outside the organization, the best mechanism to check for malicious attachments coming via email from external sources to avoid all the kinds of malicious software (malware), viruses, remote code execution commands etc. However, if your organization is providing customer support and the software used by all the agents in customer support cannot guarantee the secure medium of communication, buying that product is useless.

What was the vulnerability?

eGain chat product comes with the facility of chat services where the employees (agents)of the organization working in customer support will communicate with the customers of an organization. There was an option where the customer can share the files with a chat agent. The eGain chat product had implemented the restrictions that a customer can share only text or pdf files. As an adversary, I was able to bypass that restriction and I was able to upload malicious files with all the extensions types that every organization is supposed to prevent from entering their premises. To my surprise, when I logged in as an agent, I was able to download those files on my machine with the same malicious extensions I had uploaded as a customer. It means there was only client-side validation implemented and no check was performed on the server-side or before serving that file in the chat agent’s window.

Malicious file was uploaded after bypassing the restrictions

How the bypass was possible?

1. Create a malicious file with an extension that is accepted by the application.
2. Upload that file and click on send.
3. Capture the request in any proxy tool, edit the file extension to the malicious extension that you want. In some cases, you might need to change the content type of a file.
4. Forward the request to the server.

Exploits:

The very first objection raised by Infosec assurance team was product was violating the policy implementation. The SOC was strong enough to make sure that no malicious attachment such as virus, time bomb, malware, files with formula in it (to protect attacker from executing machine level commands)should enter the organization via email attachments. All the software built-in bank premises were following the same policies. However, this product had given an opportunity to an attacker to send malicious files inside the premises. Some might think there is WAF to take care of this. But WAF works on the basis of signatures. Most of the times the WAF can be observed in the monitoring mode. Most of the times WAF checks for content type as per the request and passes the malicious file with whitelisted content types. In the best-case scenario, if everything is working fine, it is the best security practice as per OWASP to make sure the application has implemented whitelisting and blacklisting of file extension types as per the requirements.

NOTE: Below exploits are written and demonstrated in the closed environments as a grey box pen-testing.

Exploit: Try 1

As the web application was using JSP I created a JSP file using the Metasploit module.

Step 1: Send the test.jsp file to an agent chatting with you.

Step2: Run the Metasploit multi-handler on the local system.

Step 3: Open the test.jsp file in the browser.

Step 4: Obtain shell or in case of windows a meterpreter shell.

Exploit: Try 2

Step1: Write a code for a worm. (You will find many references online to write a code for invisible worm)

Step2: Send the worm to the agent using the customer chat window.

Step3: Considering WAF did not detect, as I was performing Grey box testing; the worm was delivered to a chat agent.

Step4: Log in as a chat agent and download the file. As soon as the agent executes it, the malicious code gets executed.

Exploit: Try 3

Step1: Create a file with a malicious formula in it.

Step2: Send the file to the agent as a .csv extension.

Step3: User opens the file after download and gets redirected to the malicious website.

Business Risks:

1. Direct access to the agent’s local machine using a reverse shell.

2. Infected computer systems of chat agents.

3. Remote command execution using CSV injection method.

Solutions offered and implemented by a vendor:

1. Whitelist and blacklist extensions type as per the business requirement. Disable all the malicious extensions types.
2. Implement client-side as well as server-side validation on file types, content type.
3. Change the files extensions types once the file is uploaded.

More detail is available on https://cve.mitre.org

Thank you!!!!