Security fail: FedEx.com

One of the first rules of security on the Internet for avoiding phishing attacks is that you never, ever, enter your user credentials into a web site unless you know that you're talking to that web site, and that web site alone -- not some spoofed web site. The way we do this in the modern era is with SSL encryption. https provides not only encryption of the content being transmitted between you and the web site, it also provides authentication. Only one server (well, tightly controlled constellation of servers for bigger web sites) has the private key whose public key is being served to you (and which can be validated against the global public key infrastructure). And that's the server that you think you're talking to. If you type, say, https://www.google.com, you will be on the Google.com homepage. Up in your browser URL bar will be a green lock. Click on that lock, and with some clicking around (depends on browser) you will be able to view the certificate and verify that you are, in fact, connected to the one and only Google.com home page owned by the one and only Google. Then, and only then, is it okay to hit the 'Login' link up at the top right of the page and log in.

So, this is how any of us who are concerned about security operate. We don't put in a user name and password unless we see that green lock, click on it, and it says we're talking to who we think we're talking to. This is because of a hacker technique called DNS poisoning, where hackers can manage to convince your local name servers that their server, not the real Google.com's web server, is where you should go to get to https://www.google.com. They then intercept the user name and ID that you enter. Well, they can convince your DNS to give the wrong address, but they don't have Google's private key, so they can't impersonate Google. So you won't get that green lock. But they hope you won't notice. You should.

This attack is called phishing, and is used to filch your user name and password, which are then used in an automated fashion on other web sites. Usually after your DNS is poisoned, you get an email telling you to go to http://some.web.site.com because your password is expiring and your account will be deleted. So I got what looked like a phishing email from Fedex.com saying that my account was going to be deleted because I hadn't logged in for over a year, unless I logged in within the next two weeks. This actually would be normal for FedEx -- the only reason to ever log in to their web site is to set up your notification preferences that tell you that a package is on the way, has been delivered, and so forth. So with the possibility that it might actually be a valid email, I manually type https://www.fedex.com into my browser's URL bar (*never* click on a URL in email! Never!), hit the ENTER key... and immediately got kicked out to a non-encrypted site.

At which point my reaction was, "WTF? Have hackers hacked the FedEx web site and are grabbing user credentials?" But it appears that's not the case. Using the host and whois systems to resolve the IP address, it goes into Akamai's site acceleration service. Instead, it looks like pure rank incompetence. FedEx is deliberately putting their customers' user names and passwords at risk because... why? Well, because they're too stupid to know how to implement SSL in an Akamai-distributed architecture, apparently. Despite the fact that Akamai has explicitly supported SSL for years.

So anyhow, I use LastPass so my password was random gibberish in the first place, so after examining the source code of the web page to see if there were obvious problems, I logged in. At that point the web site did put me into a proper SSL-encrypted web page. But the point... the point... I should have never had to enter my user name and password into a plain text unencrypted web page in the first place. There's no -- zero -- way to authenticate that you are actually talking to the site you thought you were talking to, if you're talking to a web site that's not https. DNS poisoning attacks are ridiculously easy and could have sent me *anywhere*. The only reason I felt even halfway safe talking to this web site was because LastPass had generated me a random gibberish password for this web site a year ago, so if they *did* steal my FedEx credentials, at least they could only be used to hack my FedEx account, which would be no big deal (I don't have credit card information or billing information associated with the account, it's strictly an informational account). But still. Bad FedEx. Bad, bad FedEx. Bad DevOps team, no cookie, go to your room!

The takeaway from this:

1. Check those green locks. They're important. It tells you a) whether you're talking to the web site you think you're talking to or not (if it's there, you know you are, if it's not, you don't know), and b) tells you that any user names and passwords that you enter will go to the web site via an encrypted connection.
2. Any web site that your company provides should only ask for user names and passwords on an SSL-encrypted https page. If someone tries to go there with a plain http: url, it should immediately be forwarded to the SSL site.
3. If you don't follow that last rule, you will be publicly shamed, if not by me, by someone. And a public shaming is never good for your brand.
4. Furthermore, if you don't follow that last rule, there's many potential customers who will simply refuse to use your web site. This perhaps is not a big deal for FedEx, since most of their customers have no choice but to use their web site to schedule package pickups, but if you're providing a web service to the general public? Dude. You are leaving money on the table if you do something stupid like ask for a username and password on an unencrypted page.

This isn't rocket science, people. This is just basic Web Services 101. Get it right, or choose a different profession. I understand that McDonalds is hiring. Just sayin'.

-ELG

Disk encryption and LUKS

One of the interesting features of recent Linux distributions such as Ubuntu is LUKS, which allows you to encrypt (most of) your data on the hard drive. So the question I was asked is: How secure is LUKS?

Let's look at the Ubuntu implementation. It uses AES-256 to encrypt the disk volume using an appropriate cipher feedback mode to deal with frequency attacks and other such attacks against statically encrypted data. First, is the cipher secure? The answer there is, yes. AES (Rijndael) has been subjected to extensive cryptanalysis both as part of the AES cipher competition and afterwards, and there are no known compromises against full AES. The reality is that even AES-128 would be sufficient for this purpose, because the weakness of the Ubuntu implementation lies elsewhere: the passphrase. A NSA employee once stated in public that they didn't care anymore about how well encryption algorithms worked, because there was an infinity of methods to obtain the passphrases of anybody they really wanted to spy on.

Remember, a cipher is *not* a cryoptosystem. A cryptosystem consists of both the cipher, and the software required to feed it keys and data. In this case, the biggest weakness is in the keystore (stored in the header of the volume) and the method of securing it. The keystore is secured by a passphrase. Brute force dictionary attacks against the passphrase to decrypt the keystore might work, but usually won't if you chose a sufficiently complex passphrase incorporating non-word "words". The most likely attack here is either a passphrase sniffer injected into the system or a phishing exploit where a prompt is put up for the passphrase, but it is not by the login process, it is by software previously injected into the system via other means (typically a network-based exploit that then uses a privilege elevation exploit to gain permission to insert itself into the system boot sequence at the correct place).

Or, black bag cryptanalysis could be used if done by a determined organization -- a hardware keystroke scanner placed in your system, a pin mike pointed at your keyboard that then can be used to determine what keys were pressed based upon sound (each key has a subtly different sound when pressed, and which keys were pressed can be determined via frequency analysis for your language and assigned to the appropriate sound given sufficient keystroke sounds recorded), a pin camera can be mounted somewhere aimed at your keyboard to record your key presses. If you cannot guarantee that your system and computing environment has been physically secured, no cryptosystem is going to be sufficient. Thus the various exploits against ATM machines, where the machines are physically compromised (via scanner equipment physically added to them) to gain access to ATM card codes and PIN numbers for later use by thieves.

The Ubuntu setup, in other words, is sufficient for dealing with the issue of casual theft of computer equipment by random thieves -- they will not have previously captured passphrases thus will be reduced to brute force dictionary attacks upon the keystore encryption, which should fail as long as you choose a sufficiently complex passphrase -- but is insufficient to deal with a determined attack by someone who is willing to go to the trouble of rootkit'ing or black-bagging you. In particular, it is useless for dealing with network-based exploits, which occur after the passphrase has already been entered and can extract your data via the network accordingly. So it is useful, but adjust your expectations -- it is not going to stop a determined attacker (as vs. a casual theft of your drives or computer).

So, could this setup be made more secure against even passphrase interception attacks? Yes and no. You would need to load the Linux kernel and all pre-boot software from secure read-only media and also have the keystore reside there, then physically secure this media in some location other than with your physical hardware. A dongle in your laptop bag, for example, is not sufficient. You would need to have this media physically secure in your presence at all times to avoid having it compromised by black bag attacks, and have some method of physically destroying it if impending rubber hose cryptography seems likely and the data in question is so sensitive that the repercussions of it being decrypted is dire. But even there, you're still susceptible to ordinary network-based attacks that trick you into installing malware onto your drive or which exploit holes in your network software and which then steal your data via the network.

The reality is that the only computer that is completely and utterly secure is one located in a vault with no network access. Unfortunately, said computer is also not very useful for our day-to-day computing needs. The LUKS setup sufficiently deals with the problem of casual theft of computer equipment but will not stop a determined attacker with the resources of a major criminal syndicate or government behind it. It is a reasonable compromise between security and usability. So adjust your expectations accordingly.

-ELG

Cryptography engineering

A new post at the VPEP blog.

I'm currently reading Bruce Schneier's new book Cryptography Engineering (actually the second edition of Applied Cryptography), and the above was just me riffing on some thoughts I had while reading the first chapter.

-EG