Multiple Plone Cross-Site Scripting Vulnerabilities

Plone is a free and open source content management system, and is ranked among the top 2% of all open source projects worldwide. More than 350 solution providers in more than 100 countries currently support it. The project has been actively developed since 2001, is available in more than 40 languages, and has the best security track record of any major CMS. The users (https://plone.com/about/they-use-plone) include the Federal Bureau of Investigation (FBI), the Central Intelligence Agency (CIA), the Intellectual Property Rights Center, and so on.

Earlier this year, FortiGuard Labs discovered two cross-site scripting (XSS) vulnerabilities and one cross-site request forgery (CSRF) vulnerability affecting Plone versions from 2.5.5 to 5.1rc1. The first cross-site scripting (XSS) vulnerability exists in the Plone login process and only works in conjunction with the CSRF issue, so Plone has addressed them together in their recent update. The second XSS vulnerability is caused by the home page member property.

Plone Login Form XSS & CSRF Vulnerability

The first XSS vulnerability is caused because the Plone login function incorrectly processes user requests. Combined with a CSRF issue in the login process, remote attackers could run malicious code in a victim’s browser and trigger a XSS attack. This could allow the remote attacker to gain control of the victim’s Plone account. If the victim has higher permission, like system administrator, the attacker could conceivably gain full control of the web server.

Analysis

When a user logs into Plone with a valid account (any permission), there are 9 parameters in the login request. The server then responds with a 302 redirection containing the value taken from the “came_from” params found in the request response. This is shown in figure 1.

Figure 1. Plone login payload

The issue here is that that attacker can control the value in the param “came_from”, and Plone doesn’t sterilize it in the response.

Figure 2. Param “came_from”

For example, when setting the “came_from” value toPlone will output the HTML tags in the response, as shown below.

Figure 3. Insert HTML tags

Modern browsers will not execute the body part in a 302 response. However, in Firefox (Windows version) we can bypass it by setting the value starts to mailto: — for example, setting the “came_from” value to  Firefox will then load this 302 response, try to open the default email program, and execute the HTML elements in the body.

Figure 4. Bypassing the 302 redirect in Firefox I

Figure 5. Bypassing the 302 redirect in Firefox II

Finally, there is no CSRF protection in the login process. So with this XSS vulnerability, a valid account (any permission), combined with the CSRF vulnerability and bypass issue in Firefox, an attacker could successfully trigger a XSS attack. The PoC codes are shown in figure 6, and the result is shown in figure 7.

Figure 6. PoC

Figure 7. XSS attack triggered

Plone Personal Homepage XSS Vulnerability

The second XSS vulnerability is caused because the Plone Personal Information Home page function incorrectly processes user requests. Just as with the first XSS vulnerability, remote attackers could run malicious code in a victim’s browser, gain control of the victim’s Plone account, and even gain full control of the web server.

Analysis

In the Plone Personal Information page, users can set their own information, such as name, email address, home page, and so on.

Figure 8. Personal Information page

The issue is that Plone doesn’t sterilize the home page value before sending it to the server. For example, attackers could set their home page value to “javascript:alert(1)”.

Figure 9. PoC

When the victim accesses the attacker’s personal information page, Plone will then display the home page value (the XSS codes) with If the victim then clicks the home page link, the XSS codes will be triggered.

Figure 10. XSS attack triggered

Solution

All users of Plone should upgrade to the latest version immediately. Additionally, organizations that have deployed a Fortinet IPS solution are already protected from these vulnerabilities with the signature Plone.Login.Form.XSS and Plone.Personal.Homepage.XSS that were issued as part of our zero day practice once the vulnerabilities were confirmed.

Reference

https://plone.org/security/hotfix/20171128

https://plone.org/security/hotfix/20171128/open-redirection-on-login-form

https://plone.org/security/hotfix/20171128/xss-using-the-home_page-member-property

https://fortiguard.com/zeroday/FG-VD-17-006

https://fortiguard.com/zeroday/FG-VD-17-007

Sign up for our weekly FortiGuard Labs intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.