Credential theft, mitigations thereof

It was with some interest that I read an Infosec Island post about forcing transport security whilst connecting to various websites, but I want to counter-recommend some advice given.

The information on STS is correct, so far as I know – I don’t use the plugin myself – but it was with a bit of horror that I noted the author recommended using a VPN as partial mitigation against this attack.  We considered and rejected this advice for our own advisory (my own nearly identical blog post on it is here) when discussing Firesheep.

A VPN may be configured with a split tunnel – that is, traffic destined for the organisation hosting the VPN goes through the secure tunnel, but other traffic does not.  In other words, a split tunnel VPN does nothing to protect you against credential theft of the sort being discussed.

Our own VPN will be configured in such a manner, which is counter to the practise at many large companies, but which we believe is the only workable way when scaling out to thousands of users with uncontrolled access points.  The last thing we want is for our VPN to be hammered by BitTorrent traffic the instant somebody forgets, or for people to complain to us that their home network stops working as soon as they fire up the VPN.

Before following Mr. Coates’ advice, find out how your VPN works.  The illusion of security is worse than none at all.

Firesheep: black hats for the masses

The following will also be used as part of my day job.  To ITSec types, it’s likely old hat, but it may be new to some of my readers.  Some terminology in here is my-job-specific, but I did try to generalize it as much as possible.

What is it?

Firesheep is a readily-available and easily-installed add on for Firefox, a commonly-used web browser.  It allows the person using it to, within certain parameters, steal web cookies used for authorization on many common websites, mostly social networking but also, most notably, Hotmail.  This is a form of attack commonly known as sidejacking.  Note that while this document largely talks about uw-wireless, everything about that network applies equally to any open or unsecured wireless network, such as uw-guest or those commonly found in coffee shops, restaurants, and other places offering free service to customers.

Please note that discussing a tool does not condone its use.  In particular, the use of Firesheep on a campus network is a violation of the principles laid down in the Guidelines on Use of Waterloo Computing and Network Resources and, as noted by these Guidelines, is subject to discipline under the appropriate University Policy or Policies.  Use of Firesheep here, or anywhere else, may furthermore violate local laws and regulations on privacy, mischief, or wiretapping.

What does it mean?

Firesheep makes it easy for anybody who can click a mouse to be able to access these websites as if they were the person whose credentials they’ve stolen – and that person may not even be aware of the accesses.

How does it work?

The victim has to be on the same wireless access point, using the same wireless network, as the attacker.  That implies a certain physical proximity.  The wireless network must be open, and the victim must be using the network at the same time as the attacker, and must be accessing these sites (but see below, the victim may not necessarily know they were using a particular website, embedded content can cause problems).

When Firesheep is started, the attacker’s computer starts passively watching the network for authentication credentials.  When it sees such, it saves them and presents an icon for the attacker to click; this allows the attacker to easily access the website as the victim.

It should be noted that a user may inadvertently access a website.  Many websites will have badges to follow the site’s author on Twitter, or link to them on Facebook.  Sometimes the simple act of loading that website can cause your browser to send and receive authentication cookies, and therefore expose this information to the attacker.

I don’t use social networks.

Firesheep doesn’t only work on social networks, so you still may not be safe.  Web services as varied as Evernote, Cisco, eBay, Amazon, and Slicehost have had Firesheep handlers written for them.

Why doesn’t the University stop it from happening?

This attack takes advantage of two weaknesses in the way victims might access vulnerable websites.

The first weakness is that open networks are precisely as the name implies.  All clients transmit all data unencrypted using their wireless radio.  Like any radio, anybody can listen in.  This means that unless the client takes extra precautions to encrypt data, such as using TLS/SSL encryption on the data stream itself, that data is exposed for anybody within range who’s listening.  This means that many websites which do encryption properly, such as almost all banking websites, are not vulnerable to authentication theft in the way that Firesheep accomplishes it.

The second weakness is in the way the vulnerable websites perform authentication and authorization.  Without getting too technical, these sites rely on cookies, and merely having that cookie implies both that you are who you say you are, and you’re allowed to access the content you’ve requested.  Not all websites have this issue; as noted, banking websites don’t rely on this model.  Other sites such as GMail and corporate applications at the University of Waterloo don’t either, and so your credentials there are safe from this attack.

What can I do to protect myself?

The simplest thing you can do is not use open wireless networks.  These are ones which do not require a key or password to access.  uw-wireless is one such network, but many coffee shops and restaurants and other companies provide such networks for the convenience of their customers.  This also affords attackers certain conveniences.

The next-best thing is to not use sites vulnerable to Firesheep attack whilst connected to an open wireless network.  Be aware that some sites you visit may effectively force you to give up your credentials anyway, as noted under How Does It Work?

Some clients customized for use by some social networks, such as Tweetdeck, may allow these networks to be used in a manner that does not expose authorization credentials to Firesheep.  That does not necessarily mean that these clients always operate in a safe manner.

Some people have authored Firefox extensions which could potentially warn you about the use of Firesheep on your network segment.  The use of these extensions (the most commonly mentioned are FireShepherd and BlackSheep) is prohibited on University wireless networks, as they have a deleterious effect on the operation of the campus network and, not incidentally, of the remote service.

Networked printers are cool

In lieu of actual content, I give you a fake commercial:

80386 clone: $2500
Paying university tuition to teach yourself how to use the above: $20,000
Getting paid to rickroll a group of co-workers' insecure networked printers: priceless.

The downside was I lost sanity points when one of them recognized what I’d done, and started singing at me.  Remember folks, just because the printer has an ACL doesn’t mean that ACL is respected.

UNC faculty member held responsible for security breach

I don’t know any details beyond what’s published here but it seems to me that the prof probably has a point about being scapegoated.  It’s unlikely that she personally set up all the computer systems involved in her research project – at least, I hope she didn’t, she got paid too much to fiddle with that.  Judging from intimate experience with working with faculty, I find it equally likely that she just wasn’t told about issues, or that she was and overrode staff protests.

If she wasn’t told, then shame on the staff, particularly if she’s correct and “everybody knew but me.”  (I would hope though, that if “everybody” included other faculty members, that they tried to impress the scope of potential issues on her; often faculty who won’t listen to staff will listen to other faculty.)  If she was told but overrode the concerns, then I don’t think the discipline was enough – she should be fired.  If she wasn’t told, she shouldn’t be disciplined; the people who didn’t tell her should be dismissed.

However it actually happened, it feels like something is missing from that story, there’s detail missing about interaction between her, her group of researchers, and the support staff involved.  That detail is what would allow the informed reader to judge whether or not the discipline she received was fair.

Suricata and pf_ring on RHEL 5.5

I wanted to evaluate Suricata in its recommended configuration, using libpcap linked against the pf_ring library.  But there are a lot of READMEs out there, a lot of them referring to older versions of pf_ring, and the pf_ring documentation itself isn’t very clear.

It took me some digging around and experimenting, but this blog post has a comment by Wil Metcalf that made it all much easier for me.

Succinctly: check out pf_ring revision 4079, then build the kernel modules, then the userland/lib stuff.  You may need to add /usr/local/lib to /etc/  I had troubles with the latest version of pf_ring on my RHEL 5.5 installation.  YMMV by this point, of course.

You may also find this post to be useful, although it still talks about patching kernel sources.

Tangentially but also useful if you’re relatively new to RHEL and kernel sources, you might find this post also to be helpful – I did, but there’s probably nothing new there for experienced RedHat admins.

Once you have pf_ring going, you’ll want to rebuild libpcap to link against pf_ring.  I used vanilla source for this, and it was no problem with a straight ./configure && make.  And now suricata:

./configure –enable-pfring –with-libpfring-libraries=/usr/local/lib –with-libpfring-includes=/usr/local/include

And that was pretty much it for me.