All versions of the popular UI for ASP.NET AJAX RadEditor Control product by Telerik may be affected by a high-risk stored attribute-based cross-site scripting (XSS) vulnerability that is assigned CVE-2014-4958 by MITRE, NVD, by OSVDB as ID 112083, and covered in the news. This WYSIWYG rich text editor is “…what Microsoft chose to use in MSDN, CodePlex, TechNet, MCMS and even as an alternative to the default editor in SharePoint.”

Personally tested and confirmed are versions: 2014.1.403.35 (much newer) and 2009.3.1208.20 (much older) using Internet Explorer 8, version 8.0.7601.17514. However, all versions from Telerik at this time may be vulnerable and will continue to be until a patched is released. A workaround may be available.

What makes this discovery interesting are two parts:

1. It leverages attribute-based cross-site scripting to exploit the input validation vulnerability. This achieves the malicious objective without using JavaScript script tags. Instead it uses an inline style attribute of an HTML element.
2. The RadEditor exchanges the editor window’s mixed content containing elements, attributes, and text with the server in a double URL-encoded hexadecimal value format detailed below that is translated on the client-side dynamically by Telerik JavaScript into its unencoded form. For example, < first becomes %3C and then finally becomes %253C when the percent sign for the encoded character representation in the first processing round gets encoded again in a second round. This vulnerability is harder to detect than with a typical input vector due to this obfuscated communication protocol. Automated penetration testing tools and Web Application Firewalls (WAFs) may miss this, as might manual testers attempting to directly submit through a proxy an attribute-based exploit in its unencoded, or once-encoded form.

Let’s now look at the example payload as it needs to be submitted to the server from a proxy such as PortSwigger’s Burp Suite for this to work. Ensure that you place this payload somewhere within the parameter value used for the editor window’s contents:

%253cdiv STYLE=”background-image: expression(alert(‘XSS’))”%253e%253c%2fdiv%253e

… which is dynamically translated into the following form after client-side processing by Telerik UI JavaScript:

<div STYLE=”background-image: expression(alert(‘XSS’))”></div>

At the time of discovery the only available XSS protection on the server side was to use the RemoveScripts filter to strip out script tags, which is why attribute-based XSS is necessary here.

Carte blanche output encoding will not fix this issue, but instead may actually break the HTML that is rendered in the WYSIWYG editor window if the wrong encoding type is chosen. Troy Hunt explains the nuance of validating rich text input best by pointing out that markup is being stored in the data layer. Both data and HTML need to be handled by the same input vector here and so looking for script tags is irrelevant in this case because this problem is not that simple. Encoding everything would ensure that user input is displayed only as data and not executed as code by the web browser. However in this case some of the user-supplied content of the rich text editor needs to execute to achieve formatted text.

As an aside, double encoding is a type of attack used to bypass security controls. Double encoding may bypass Web Application Firewalls (WAFs).

Previous guidance on the general issue of XSS in the Telerik forums quietly placed the responsibility of sanitization on developers, but this is likely overlooked in most implementations. Further, the obscure nature of attribute-based XSS leveraging an HTML attribute to achieve execution instead of using the popular script tag route makes this harder to filter against. HTML sanitization involves inspection at a deeper level. Read more about HTML escaping.

Remediation: Telerik states: We have applied a patch to the editor that will be delivered with our Q3 edition of the controls that should be released towards the end of October. A blog post on the issue has been published here.

Additional credit goes to Tyler Hoyle and the rest of my team in CGI Federal’s Emerging Technologies Security Practice for their hard work. This is the original Bugtraq announcement.

Questions? Email me today: main at gsmcnamara dot com.

#RadEditor Web Editor Vulnerable To #XSS Attacks — http://t.co/MvtIDLONLa

— Threatpost (@threatpost) September 29, 2014

Researcher details nasty XSS flaw in popular web editor http://t.co/IApXxIorYO

— The Register (@TheRegister) October 1, 2014