Cатсн²² (in)sесuяitу / ChrisJohnRiley

Well I’ve held out long enough tweaking and playing, it’s time to hang my head in shame and release my UA-Tester Script for the world to laugh at and play with.

A few things before I run through what the tool does and why I thought it was worth writing.

• This is only my second attempt at Python scripting, so don’t expect quality smooth code (yet)
• It’s an Alpha release…. i.e. it will probably suck and never work.
• I wrote this because I want to improve my Python fu.
  • I’d love constructive criticism
  • Hints and requests are always well received… but may be ignored 😉
  • If you hate it, fail to see the point in it, or are just generally negative –> rm UAtester.py

So with that out of the way, what is UA-Tester?

UA-Tester was something I’ve been thinking of for a while due to the increase in mobile technology. A number of high-profile sites (twitter, facebook, google, and even Microsoft) offer mobile versions of their sites and functionality. Normally this wouldn’t be something you’d care about, but as a penetration tester or security researcher, you need to make sure you’re covering all the bases and getting full coverage when looking at web applications. I’ll give some examples in the following sections that should help clarify things I hope.

As you can see in the screenshot, UA-Tester will begin by connecting to the URL provided to it through the command line and returning some information about what response it receives. It does this initial connection using a standard (non-specific) user-agent string (in this case Mozilla/5.0). As you can see in the screenshot, the tool returns the final URL (in this case different from the one entered through the command line), as well as the initial response code (302 Found) and information such as Content-Type, Server header (if present) and the length/MD5 of the data portion of the response. I’m currently looking to expand this to also check and return headers such as X-XSS-Protection, cookie names and others that might be useful (cache, etc…).

The tool will then re-run the same request 3 times to ensure that the response are stable (to prevent false-positives in the event of advertising, rotating content, or general connection issues). Without stable responses, it’s hard to tell if the site is responding differently depending on the user-agent string used.

With the foundations completed, the tool will then check the URL provided using either a list provided by the user (-u at the command line, example .: -u ./useragents.lst) or a collection of default user-agent strings (and by default I mean, a random and interesting selection I’ve been using for testing) if no filename is given. It is also possible to pass the -s option and provide a single user-agent string to test (example .: -s googlebot/2.1).

A connection is made using each of the supplied/default user-agent strings in turn, and the differences between the original reference connection, and the new user-agent string are returned to the user. It is also possible to use verbose mode to see the entire dataset returned for use in manual data gathering or correlation.

The results of this are then returned to the user showing the User-Agent string being checked and any responses that differ from the reference connection (the one used to check the stability of the connection).

As you can see by the screenshot, using the user-agent string “jBrowser-WAP” the remote server (in this case http://www.microsoft.com) responds with a different final URL (forwarding the user to a mobile version of the site) and also shows that the version of IIS in use is now 7.0 instead of the originally reported IIS 7.5. This could offer a number of advantages for penetration testers as you can imagine. Not only are mobile versions of web applications commonly less secure (missing protections against things like click-jacking for example), but as can be seen here, may also offer a completely new Infrastructure that could be vulnerable when the main site isn’t.

Now, what this script does is nothing new. I’m sure most readers here are already aware that this can be achieved through the use of something like Burp Intruder. Hope fully though, you’ll find this tool at least mildly useful for initial checks and scoping. I know it’s something I’ll be using to make sure I’m covering 100% of the application and functionality and not just limiting myself to the homepage as seen from Internet Explorer or Firefox.

./UATester.py -h

This tool is designed to automatically check a given URL using a list of standard

and non-standard User Agent strings provided by the user (1 per line).

The results of these checks are then reported to the user for further manual

analysis where required. Gathered data includes response codes, resulting URL in

the case of a 30x response, MD5 and length of response body, and select Server headers

Usage .:

-u / –url Complete URL

-f / –file <Path to User Agent file> / If no file is provided, defaults will be used

-s / –single provide a single user-agent string (may need to be contained in quotes in specific circumstances)

-v / –verbose results

–debug See debug messages

Example .:

./UATester.py -u http://www.example.com -f ./useragentlist.txt -v

./UATester.py -u https://www.yourserver.com

./UATester.py -u http://www.defaultserver.com -v –debug

./UATester.py -u https://www.google.com -s “MySpecialUserAgent”

I’d like to thank all the Alpha testers who helped with the fine tuning and comments so far… @Digininja, @Markofu, @DaleaPearson, @Acanthephyra, and others. Much appreciated!

Todo:

• Sort the output… not happy with the current way data is returned to the user (confusing, too much data for a table)
• Output to a logfile for offline correlation (XML ?)
• Add proxy support
• Check and return information on additional headers, cookies and cache directives
• Possibly work on integration with W3AF (Already Python based)

Links:

• UATester –> Project Download
• C22.CC Tools/Scripts