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, the “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 "man ciphers" for additional options when it comes to listing ssl ciphers.

The command you’ll use the most is “openssl s_client“, 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.

openssl s_client -ssl2 -cipher EXP-RC4-MD5 -connect travisaltman.com:443

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.

openssl s_client -ssl2 -cipher EXP-RC4-MD5:EXP-RC2-CBC-MD5 -connect travisaltman.com:443

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.

openssl s_client -cipher AES256-SHA -connect thepiratebay.org:443

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

openssl s_client -cipher EXP-RC4-MD5 -connect thepiratebay.org:443

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

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.

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.

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

1. mount cifs or mount smbfs
2. smbclient

I prefer the “mount cifs” option because smbfs is no longer supported and smbclient gives you the awkward command prompt look and feel like ftp via the command line. An example of how you would connect to a share via “mount cifs” can be seen below.

prompt:~$ mount -t cifs //machine/folder /mnt/windows -o username=travis

Keep in mind “machine” = machine name and “folder” = shared folder. Also I created the “windows” directory inside the “mnt” directory so that I would have a mount point. If the directory requires authentication you will be prompted for a password. In a medium to large organization this will more than likely be your Active Directory username and password. I’ve been using CIFS since 2007 and I’m never going back to smbfs or smbclient. I know CIFS has been around a while and I’m some what behind the times but I didn’t have a real need for it until last year. CIFS was definitely one of my top finds of last year. If anyone knows of a better solution please hit me up.

================ FYI ================

• Windows uses the CIFS protocol to share folders
• You may see it referred to as CIFS/SMB
• Samba is a free implementation of SMB (both client and server)
• Smbclient is a client program that comes with the Samba suite
• CIFS is the latest “variant” of the SMB protocol
• CIFS/SMB is probably the majority of network traffic in an organization (Windows environment that is)

It’s taken me a couple of days to recover from Carolina Con. I knew it was going to be a riot with all the alcohol in walking distance. Now that I have my equilibrium I can post my presentation on Layer 7 attacks. My laptop and the projector weren’t working well together so I had to borrow Nick Fury’s laptop which didn’t have all the tools I needed for the presentation, so I wasn’t able to present the second half of my talk. I’m hoping this video will compensate. Keep in mind that my total presentation was going to include this video (scenario 1, cross site texting) and my previous video post of analyzing cookies (scenario 2). One thing you won’t see in this screen cast is that during the presentation I used a volunteer from the audience to prove that an attacker could text himself the username and password of an unsuspecting victim. Luckily apples from the HTS crew let me spam his phone with my demo and all he got was a t-shirt, a kick ass Carolina Con t-shirt that is. Well I had a great time and I’ll definitely make it back next year. As always I would love to hear your comments and feedback.

travis:~$ cat BigUpsMuchRespect

1. nc2600
2. txs
3. wxs
4. Deral Heiland
5. Sahba & Dan @ Security Compass

This video is a follow up on my written documentation of using Webscarab to analyze session ID’s. This video walks through the Altoro Mutual web application, demo application set up by WatchFire, showing which cookies are weak and which cookies are strong. It’s very important to have strong cookies because cookies keep information about your account on that particular application. If an application has weak cookies then your account could be compromised revealing sensitive information about yourself. Hopefully this video will show you how to analyze the strength of cookies for an application that you use. As always please let me know if I screwed up somewhere in the video or if you have an idea for a better approach, I’d love to hear from others.

I have finally gotten around to posting a video tutorial of Webscarab. This tutorial merely covers the basics on Webscarab and is a mirror reflection of my written tutorial, Webscarab Tutorial Part 1 (learning the basics). I plan on continuing this video series as I did with my written tutorials. I have always been a fan of video tutorials because they cut right to the chase and show the exact steps how something is performed. I have always frequented the videos on Iron Geek and Milw0rm which have been great resources as well. Don’t forget to maximize the video in the bottom right hand corner of the player, otherwise the video is pointless because you wouldn’t be able to see anything.

The video seems to have some background noise from the audio recording, if anyone has a suggestion for making a better recording I’m all ears. I recorded the screen cast with CamStudio but I also tried Record My Desktop in Linux.  I wanted to use Record My Desktop but it was even worse.  It could have been my cheap Logitech microphone that was the root cause of the problem? Please post feedback and let me know if these videos are useful, your feedback will determine what content I post in the future.

]]> http://travisaltman.com/intro-video-tutorial-for-webscarab/feed/