CVE-2019-11016: Open Redirect Vulnerability

Jyoti Raval

elgg logoEarlier this year the Qualys Web Application Scanning team discovered and reported an open redirect vulnerability (CVE-2019-11016) in Elgg, an open source rapid development framework for socially aware web applications, which the Elgg team promptly fixed.

Versions of the Elgg framework before 1.12.18 and 2.3.x versions before 2.3.11 are vulnerable to open redirect via the $url parameter. An attacker could abuse the functionality by entering a particular path that triggers an open redirect to an attacker-controlled website.

Because this type of vulnerability is not uncommon, QID 150051 in Qualys Web Application Scanning (WAS) was improved to report if this type of open redirect vulnerability is found in a scanned web application.

Understanding Open Redirect

Web applications return a 301 or 302 response code to instruct web browsers to redirect to another URL. An open redirect vulnerability can exist when a web application leverages unsanitized user-supplied data (intended or not) to determine the destination of the redirection.

A vulnerable application allows an attacker to craft a link having a destination URL that causes users to be redirected to the attacker’s choice of sites. The link would appear to be benign to most people and when clicked, the redirection occurs seamlessly so users likely won’t even notice it happened.

Given that redirection is functionality present in many web applications it is important for us to pay attention to the possible exploits. It may seem like a normal situation where a user decides which page she wants to go next, but if exploited, this vulnerability can have serious impacts, especially when used in conjunction with other attack techniques such as phishing or cross-site-scripting.

For more information about this vulnerability, refer to OWASP’s Unvalidated Redirects and Forwards Cheat Sheet.

Exploiting Open Redirect for Phishing Attacks

Web applications use different techniques to redirect users to the next page. Apps may use URL query parameters, header values, with JavaScript code, or it may be backend code. In case of the Elgg framework, the value of the “Referer” header was used to redirect to next page.

Original Request:

Modified Request:

Successful Redirection:

As depicted above, the web application using Elgg sent a 302 response to redirect to www.google.com. An attacker might use this technique to redirect to phishing web sites and the user might end up thinking she is still on the legitimate website.

How Referer manipulation for phishing/XSS might work in the real world

Given that Elgg framework uses the value in referrer header to redirect, it is very possible for an attacker to manipulate the header to execute a phishing or XSS attack.

  1. User visits a website which has link like evil.example.com/?alert(123);
  2. The malicious website above will redirect to the vulnerable page – victim.example.com/elgg/action/
  3. The malicious website evil.example.com/?alert(123); will be preserved as the “Referer” value when the victim is redirected to the vulnerable page. As a consequence, the JavaScript code/malicious URI in the referrer value will be executed/redirected.

Finding Open Redirects with Qualys WAS

QID 150051 is reported by Qualys WAS if an open redirect vulnerability is found in a scanned web application. If you have vulnerable version of Elgg installed in your environment, expect to see QID 150051 flagged by the scan.

Remediation and Prevention

If your organization uses Elgg in your environment, be sure to upgrade to version 1.12.18 (or higher) or version 2.3.11 (or higher).  For general remediation information, refer to OWASP’s Unvalidated Redirects and Forwards Prevention Cheat Sheet.

Share your Comments

Comments

Your email address will not be published. Required fields are marked *