That time of year is approaching for the annual goodness that is CarolinaCon. This year the conference will be held March 13 – 14th. CarolinaCon is essentially a weekend long party with some great talks about technology thrown on top. The hotel bar is just steps away from the rooms where the talks are held so that always makes for a good time. I also encourage others to submit a talk as they are always looking for good speakers but don’t take too long to submit your talk because submissions are due by January 15th. I’ll be heading down to Raleigh to check this conference out once again, hope to see you there.

My tool of choice when it comes to fingerprinting SSL is OpenSSL. There are other tools out there such as thcsslcheck and ssl digger but in my experience these tools tie your hands when you want granular detail. It’s best to get it straight from the horse’s mouth >> OpenSSL. This tutorial focuses on fingerprinting the ciphers and protocols supported by a SSL server, you can obtain tons of information from OpenSSL but this tutorial will not dig into all those aspects. Also this tutorial won’t go into the installation of OpenSSL on your OS just the usage thereof. The first step/command is to determine what kind of ciphers a SSL server may use. This is done by issuing the command

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

Security Compass has created a series of Firefox add-ons that aid in performing web application assessment. These tools are a great convenient way of finding vulnerabilities within web applications. I do want to point out that even though these tools are useful there is no guarantee all vulnerabilities will be found.

XSS-Me is one of the tools in the series that helps to find cross site scripting (XSS) vulnerabilities within web applications. The tool works by locating forms within a web page then tries various inputs into those forms to see if the inputs on that page are vulnerable. A screen shot of how the tool should look inside Firefox can be seen below.

Now all you have to do is click “Run all tests” and let XSS-Me do its thing. Keep in mind that XSS-Me will also find any hidden forms within a page as well. So this is how things are suppose to work but you’ll eventually come across a page that has forms but XSS-Me doesn’t detect them, this is because the page you are viewing has frames. A good example of this is Chris Rohlf’s site seen below.

From the screen shot you can see there is a search form at the top of the page but XSS-Me doesn’t detect its presence. This is because the search form is wrapped inside of a frame. A quick little tip to get around this problem is to open the frame in another tab/window. All you have to do in Firefox is right click on the frame then select “This Frame > Open Frame in New Tab”. A screen shot can be seen below.

Once you have the frame in a new tab XSS-Me will detect the form as normal. This can be seen in the screen shot below.

This same technique will apply to the SQL Inject Me tool from Security Compass as well because it also tries to search for forms within a web page.

This tip was passed along to me by Sahba Kazerooni who works at Security Compass. I have no affiliation with Security Compass but I met Sahba and some other Security Compass employees at a conference and they were all down to earth guys who had great knowledge and experience when it came to information security. So thanks for the tip Sahba and hopefully this tip will help others secure their web applications as well.

Well that’s not entirely true, they will still offer the “engine” for free just not all of the plugins (maybe?). The current but soon to be old model had two types of subscriptions,

1. Direct feed ($1,200 per year)
2. Registered feed (free but plugins were 7 days old)

Come the end of July they will switch to a different model,

1. Professional feed = Direct feed
2. Home feed (only personal plugins, whatever that means?)

The press release was some what cryptic and I couldn’t decipher what exactly this “Home feed” will be. It could be all the plugins minus the compliance stuff but the proof is in the pudding.

So it’s a sad day but I guess we all knew this was coming. In fact I’m all for Tenable getting paid for their valuable service I just hope they don’t go the next step and raise the price of the plugins feed to something outrageous. I think $1,200 is a reasonable price especially is you’re an independent contractor like I used to be. Let’s just hope the “Professional feed” remains a reasonable price. Tenable could always introduce a 3rd tier geared towards large organizations to get even more capital, but maybe that won’t be necessary with their new model. If for some reason the 2 tier model doesn’t work I hope they will entertain the 3 tier model, I can only hope (cross fingers). They could be shooting themselves in the foot with this move, which is essentially shooting their user base in the foot as well.

I’m not a hater, I like love Nessus and think it’s bottom line the best vulnerability scanner on the market period. I remember not too long ago (~ 4 years?) when Nessus had around 1,000 plugins, now there are over 21,000 so they have definitely grown over the years. I hope this move will help them to keep growing, just don’t forget the little guy.

This is the first time I have ever seen SQL injection this widespread and in an automated fashion. Before it’s all said and done this could be !!! HUGE !!!. News of this has been trickling out since the end of April with the first hint of it at the beginning of the year.

Basically what’s happening is attackers are using SQL injection, in some sort of automated fashion, to insert Javascript malware into databases of some popular websites, the United Nations for example. Once a user visits an infected website (un.org) they will unknowingly be sent to a malicious site where attackers try numerous exploits to see if they succeed. Keep in mind the user will remain on un.org as if everything is fine and dandy but in the background exploits are being launched.

What’s so scary about these widespread infections is that the Javascript malware will remain on the database until the webmaster removes it. Even then the websites will still be vulnerable to SQL injection so attackers could reinsert malware until the vulnerability is fixed. Also attackers could easily update the location of their malicious site through SQL injection. For example lets say attackers are using http://evilattacker.com for launching their exploits but this URL gets blacklisted, they could then update infected databases with a new URL, say http://maliciousattacker.com. So this type of widespread epidemic is the gift that keeps on giving.

I’ve seen these attacks come across the IDS (intrusion detection system) where users are visiting infected URL’s. Of course attackers could easily move their operations to different URL’s. Some exploit URL’s I’ve seen so far are nihaorr1.com, nmidahena.com, aspder.com, rirwow.cn, and wowyeye.cn. I performed searches to get an idea of the infection numbers, now doing a search for the offending URL won’t give you a 1 to 1 relationship but it will give you a ballpark figure. Take a look at the “Results” numbers in the following screen shots.

Also check out this screen shot from ririwow.cn, you’ll get a laugh from it.

So the ballpark infection just from these three URL’s is 500,000, scary isn’t it. Even if this number is 400,000 off that still leaves 100,000 sites infected. There’s no way at this point to verify the number but this is definitely the largest SQL injection campaign I have ever seen. It’s these URL’s along with others that are hosting the Javascript malware. It’s common to see the attackers use Javascript to open zero pixel iframes so the attack appears hidden. The Javascript files I’ve seen so far are short names with either a single letter or number (e.g. m.js, 1.js, jp.js, etc). So the request that happens in the background will look like http://ririwow.cn/jp.js. In order to see the request one would have to use a local web proxy. Without a proxy you would never see the request. So I’m going to keep my eyes peeled in the coming months to see how this epidemic plays out.

Below are some other good articles related to this topic

Internet Storm Center

Websense

ShadowServer