Even our great-grandmothers know they shouldn’t log into their bank account while on open wifi, right? But what about your Google/gmail account, Facebook, Twitter, etc? The login credentials for these sites are becoming more and more valuable as they connect to more and more of our lives. Most offer some form of secure login, but they don’t make it terribly obvious.
For instance, you can go directly to https://www.twitter.com/ and you’ll get a completely HTTPS login page, including a HTTPS submit button for sending your credentials. The same goes for Facebook…however, nobody knows to use the https urls. Rather than redirecting http traffic to the https front end (and making everybody warm and fuzzy), most of these sites have simply used a https submit button so that your credentials are submitted securely. Some banks even do this, and it is infuriating. I’ve even seen FAQ links right next to the https submit buttons explaining that the site is secure even though you don’t see https at the top of the screen. You’d think it would save them a lot of customer support time and trouble by simply encrypting the entire page…but I digress.
There is an obvious problem with https submit buttons: it is far from obvious that the operation is secure. Browser developers have put a great deal of effort into making it clear when you are or are not on a properly-certified https site…change the color of the address bar, etc. So you’d think that maybe this lack of apparent security would be something the “bad people” would take advantage of? You would be correct. Sam Bowne (of samsclass.info … NOT one of the “bad people”) demonstrated a typical man-in-the-middle attack of this variety using SSLStrip (created by the great Moxie Marlinspike of thoughtcrime.org). Simply put, the targeted user is unknowingly accessing Facebook through the attacker’s proxy. The proxy replaces the HTTPS submit with a standard HTTP and then captures the submitted data when the user attempts to log in. The entire transaction is completely transparent to the targeted user.
Sam Bowne also demonstrated his own spin on SSLStrip: The Wall of Stripped Sheep. The WoSS is a nifty play on the famous Defcon “Wall of Sheep” which displays the usernames and partial passwords of people who are using the Defcon network to login to non-secure email systems/twitter/etc. In the case of the WoSS, it is a nifty little web interface that will display captured usernames and passwords (using SSLStrip) for 4 popular sites.
While it is possible to spoof SSL certs and truly pull off a sinister man-in-the-middle attack for https sites (see Moxie’s incredible Defcon talk from this year), it is much more difficult to pull off and considerably more rare in the wild. Attacks like SSLStrip are much easier for the average scumbag to use to gain access to your email account, which, as we all know, is the doorway to every other site/service you use. Even if some baddie doesn’t use this as a jumping off point for full-on identity theft, do you want somebody farting around in your Facebook account?
So what do you do? When possible, go directly to the https version of the site rather than the default http. When that isn’t possible, and you absolutely MUST sign into some site, try a nifty little (experimental) Firefox plugin called “Safe” from the Mozilla addons site.
As the description says, Safe makes SSL and extended SSL more visible to the user. The most obvious thing that Safe does is to add a green or blue border to https sites depending upon whether they have a Extended Validation (EV) cert (which makes the border green) or a normal cert (which makes the border blue). I didn’t feel like looking around for an expired cert site, but I believe it gives you a red border if that is the case. See the following examples:
The next thing Safe does for you is to make you aware of https submit buttons. Brilliant. Down at the bottom of your browser, it adds a little key icon which looks like this:
However, when you hover your mouse over a button that submits via https, it looks like this:
This functionality should really be built into Firefox. Until it is, I recommend installing this addon and keeping an eye on the little key. I probably don’t have to explain this, but just in case, here is the jist:
If you don’t see that key light up when you are about to submit credentials for some website, it is much easier for somebody to intercept them.
If you are reading this blog, I gotta figure you know how common this threat is, but I figured I’d say it anyway.
If you would like to protect yourself even more, check out this nifty tool from Irongeek (brought to my attention by Sam Bowne). It is called DecaffeinatID and, among other things, it gives you an alert if the MAC address associated with a gateway IP changes (this is a clue that somebody is doing some ARP spoofing and probably lining you up for a man-in-the-middle attack).
Good luck protecting yourself…
Why, oh why, did you have to make this so difficult?
If you’re running Cisco WCS and would like to use a non-self-signed SSL certificate, you probably did what I did. Note: The following steps *look* right, but are not:
1) Dig through the WCS directories until you find the Apache SSL configuration files (in ./webnms/apache/ssl/ssl.conf).
2) Modify ssl.conf to point to your RSA Keys, Intermediate Certificate, and Signed Certificate files.
3) Restart WCS.
Yeah, that doesn’t work. Turns out WCS overwrites the contents of all of the Apache configuration files, including ssl.conf, with the files from the local “backup” directories (there are no less than 17 backup directories in WCS.)
[root@wcsbox WCS184.108.40.206]# du -a | grep backup | wc -l
So, here is the actual working procedure. For this example, I’ll be using the free .edu certificates from my pals over at ipsca.com (you guys rock!).
1) Generate a CSR and have your favorite CA sign it. When complete, you will have three files: Your key (server.key), the signed cert (server.crt) and the CA’s intermediate (intermediate.crt).
2) Edit /opt/WCS_version/webnms/apache/ssl/backup/ssl.conf and set the following directives:
I like to keep these files outside of the WCS directory so that I can re-use this config file after an upgrade. I also store a backup copy of ssl.conf in this directory. Ironically, WCS doesn’t make backup copies of these for you.
3) Restart WCS and *poof* enjoy your new signed SSL experience.