Incapsula Customers Protected From XSS Vulnerability Prior to WordPress 4.4.1

The latest upgrade of WordPress (4.4.1), released today, patches a cross-site scripting (XSS) vulnerability located in the error reporting section of the themes module.

With WordPress being used by millions of worldwide websites, the XSS vulnerability is particularly notable as it is located within the WordPress core build.

For Incapsula web application firewall (WAF) customers the good news is that you’ve been protected from XSS prior to this WordPress upgrade. Our research team has verified that our WAF blocks attacks attempting to exploit the vulnerability.

User Data Exposed

When an input is sent to a client without being verified by an application or the WAF, it may contain dangerous bits of code, such as a nefarious JavaScript routine. When automatically executed within the client’s browser, a hacker can then:

• Hijack session cookies and gain access to user sessions and accounts
• Operate a browser keylogger, which sends user keystrokes to the attacker
• Turn the user into a temporary bot to help execute attacks, such as DDoS, on other sites

Escaping the input in a WAF, which involves removing and replacing control characters, sanitizes the content and attempts to execute code are either blocked or deleted.

What’s Changed in WordPress 4.4.1?

Prior to the patch, the following PHP code was executed whenever a WordPress theme didn’t exist:

$this->errors = new WP_Error( 'theme_not_found', sprintf( __( 'The theme directory "%s" does not exist.' ), $this->stylesheet ) );

The actions performed by the code can be broken down as follows:

• $this->errors is a formatted error sent to the client browser.
• WP_Error class (a custom WordPress type) is created to display an HTML error message.
• The error name is set to ‘theme_not_found’, and the description is set using sprintf (a PHP function that formats text).
• The sprintf replaces the %s with the name of the stylesheet used to display the error message.

Note that the sprintf PHP function, like the C# String.Format function, or similar functions in other programming languages, is used to embed a given string within another. The function, however, does not sanitize or validate either of those strings.

The WordPress 4.4.1 patch adds the esc_html() function. As shown below, this  escapes the strings sent to the client, thus preventing cross site scripting:

$this->errors = new WP_Error( 'theme_not_found', sprintf( __( 'The theme directory "%s" does not exist.' ),esc_html( $this->stylesheet ) ) );

The remaining error messages that were not properly escaped are shown below:

$this->errors = new WP_Error( 'theme_no_parent', sprintf( __( 'The parent theme is missing. Please install the "%s" parent theme.' ), ) );

$_child->errors = new WP_Error( 'theme_parent_invalid', sprintf( __( 'The "%s" theme is not a valid parent theme.' ), ) );

$this->errors = new WP_Error( 'theme_parent_invalid', sprintf( __( 'The "%s" theme is not a valid parent theme.' ), ) );

The screenshot below shows how such non-sanitized requests can be used to execute a simple payload that displays a client’s cookies on screen. The same method can also be used to compromise the website in any number of different ways, including posting private cookie information on a remote site.

In this specific case, the payload is executed via the following string:

/wp-admin/customize.php?theme=PAYLOAD&return=%2Fwordpress%2Fwp-admin%2Fthemes.php.

Note that in order for this to work, the user has to be authenticated as an administrator of the WordPress system.

Flaws such as these exist in popular applications. It’s one reason why using a layered approach–with a WAF on top of the application layer validation–is crucial in securing your websites.