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

Behold the XKCD Passphrase Generator

Behold the XKCD Passphrase Generator. Copy and paste it into a file on your own Linux machine, and run (assuming you've installed the 'words' package, which is almost always the case). It'll pick five random words and concatenate them together. Should also run on other machines with Python installed, but you may need to find a words file somewhere and edit accordingly. If this were a real program I'd add paramaters yada yada, but since it's just a toy...

#!/usr/bin/python
# XKCD passphrase generator.
# See XKCD 936 http://xkcd.com/936/
# You'll have to provide your own 'words' file. One word per line.
# Unix based systems usually have /usr/share/dict/words but you'll need
# to get that from somewhere else for Windows or etc.
# After editing wordsfile, numwords, separator:
# Execute as: python genpf.py  

import os

wordsfile="/usr/share/dict/words"
numwords = 5
separator = ".%*#!|"

def gen_index(len):
    i=(ord(os.urandom(1)) << 16) + (ord(os.urandom(1)) << 8) + (ord(os.urandom(1)))
    return i%len

f=open(wordsfile)

pf=""
words = f.readlines()

i=gen_index(len(separator))
c=separator[i]
while (numwords > 0):
    i=gen_index(len(words))
    s=words[i].strip()
    if (pf==""):
        pf=s
    else:
        pf=pf+c+s
        pass
    numwords = numwords - 1

print pf

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

Convicted monopolist wants RealID for Internet

Yes indeed, Craig Mundie, head of Microsoft Research, wants a "driver's license" for the Internet.

This is the craziest thing I ever heard of. It's estimated that 20% of drivers here in the state of California don't have a driver's license. Despite that, they still drive, even though if they're caught it means their car would be impounded and they'd face possible jail time. But people who are here illegally, have had driving rights removed for legal reasons such as DWI, or whatever, a lot of them choose to drive anyhow despite those risks.

There are no traffic cops on the Internet to stop you and seize your computer if you don't have the proper Internet driver's license, so how the heck would any such thing be enforced? I mean, it's as if Craig Mundie never heard of the fact that Social Security cards, birth certificates, and driver's licenses are regularly forged.

There are a lot of things that can be done to improve Internet security, such as cutting off any ISP that refuses to deal with spam or DOS attacks emanating from its IP addresses. But this? This is a non-starter. Apparently Mr. Mundie still hasn't figured out that not everybody is a law-abiding Microsoftie like he is, and that people will violate the law if they feel that it is in their best interests to do so. I mean, all he has to do is look at his own employer, for cryin' out loud! Where there is a will, there is a way -- even if it requires forgery. If Mr. Mundie's proposal were adopted, the only people who would comply would be law-abiding people, which sort of renders the whole thing useless, don't you think?

-ELG

ACL management on MacOS Snow Leopard

So I was going to follow the directions at this hint site to prevent Time Machine from doing a full backup again once I updated my MacBook Pro to a bigger drive. After all, I don't want to re-backup the stuff I just restored from my backup! But my attempt slammed to a halt after I type 'fsaclctl' and... uhm... WTF? It isn't in Snow Leopard! And by the time you get to userland the permission to override a "Deny All to All" ACL is dropped even if you su to root... you just can't get there from here unless you can somehow turn off ACL support for the whole filesystem!

Ah, but never fear, the Leopard version of fsaclctl works just fine on Snow Leopard. The question is, which of my half dozen backup drives up in the storage closet or offsite is old enough to have Leopard on it? I was about to get up and go grab one, when I glanced down and... there was the Mac OS Leopard 10.5.2 install DVD, right there, in the pile of disks I'd used to re-image the Mac.

So first thing to do was drill down and find the package. The packages live in '/Volumes/Mac OS X Install DVD/System/Installation/Packages' and the easiest thing to do is 'go to folder' from the Finder 'Go' menu to go there. Then by dragging dropping packages onto the /Developer/Applications/Utilities/PackageMaker utility, I discovered that fsaclctl lives in package "BSD.pkg" in directory /usr/sbin.

The next question is, how do we get the file out of the package? I couldn't drag it out of PackageMaker, PackageMaker simply refused to do so. So I grabbed a utility called 'Pacifist'. I won't claim it's the best utility for doing this because it's simply the first one that came up when I googled, but it allowed me to drop the BSD.pkg onto it, drill down to the file, then drag the file out to a folder on my desktop, from whence I could then put it into ~/bin and use it.

Now, this isn't about the Time Machine hack (BTW, it didn't work -- apparently Time Machine's implementation has changed since Leopard), but, rather, about security. Some folks wonder why MacOS is more secure than Windows. This experience gives you one clue why. There are things you cannot override even if you have full administrative access, once permissions are dropped during the boot process. I suspect that in future releases of Snow Leopard will remove the low-level ioctl that fsaclctl relies on, further securing the system. But it's clear that while Apple doesn't make splashy announcements about security and doesn't have some of the bells and whistles like address space randomization, they're doing some things quite right in the background to keep things secure.

-EG

So what about China?

Yet more paranoia about China and outsourcing engineering to China.

Pretty much every laptop computer you buy today is already made in China. That Macbook Pro that the paranoid executive won't take to China? Made in China.

There are some reasons to suspect corporate espionage, but the nationality of the perpetrator is irrelevant. I'm unclear about the exact motivations for the rampant China bashing that seems to happen in our media today, but the Chinese as a people have every motivation to not engage in dishonest dealing -- they need the West's money in order to continue modernizing their economy. China was a third world nation only 20 years ago, with an industrial base similar to that of most Western nations in the 1950's but 10 times more people to support with that industrial base. They've come a long ways in the past twenty years, but still have a lot further to go and they know it. Engaging in organized skulduggery (as vs. the ordinary disorganized industrial espionage that happens between business competitors) is not in their best interests and the least of our worries.

I've managed Chinese programmers working on security products. They're smart, but green. They still have a lot to learn about what it takes to get products through the whole product cycle from concept to final delivered product in the customer's hands, and they know it. Perhaps at some time in the future we'll need to worry about Chinese programmers inserting time bombs into security products, but today? Again, they have too much to lose, especially if their code is being regularly reviewed by senior American engineers, as was true in our case.

In short, you should definitely follow your normal procedures for detecting and closing security vulnerabilities, but singling out one nation -- China -- for special scrutiny is just plain silly. Yes, follow good practices -- don't leave your cell phone out and about, same deal with your laptop computer, make sure your firewall software is running, don't stick foreign media into your computer's ports or hard drives or install unsigned programs, if you've outsourced development have regular design and code reviews to catch security issues early, etc. But I have to think that all this emphasis upon one nation as a "threat" has more to do with politics than with technology, and distracts us from the real problems of securing our computers against real threats -- which are more likely to come from Eastern European virus writers than anything coming out of China.

-E

Real life vs. movie

So there is apparently a EMP bomb doomsday conference going on today, presumably to generate some leads for hardening financial institution computers. Must be a shortage of ways to spend taxpayer money, presumably.

In reality, terrorists do not need EMP devices to disable internet-connected devices. All they need to do is rent a botnet to do a DDOS. Furthermore, the biggest risk to the integrity of financial data and computing systems is not the explosion of a nuclear device, which is what would be required to create an EMP pulse capable of wiping out data (and I might add that if you just got vaporized in a nuclear explosion you're unlikely to care anymore anyhow). Rather, the biggest risk is insider fraud and technological meltdowns caused by inadequate internal controls. Remember, Countrywide and its fellow sub-prime lenders and securitizers such as Goldman Sachs did more damage to the nation's financial system than any nuke has ever done.

In short, as usual, people are focusing on flash, not meat. Computer security and financial integrity in general is not, in reality, a glamour product. It's a multi-level system of firewalls, security software, policies, procedures, regulatory activities, and checks and balances intended to detect and remedy any intrusion, extrusion, or fraud before it can culminate in actual data loss or financial loss. Or as Bruce Schneier is fond of saying, security is a process, not a product. It's a bunch of hard work, and too often not done correctly, but I suppose talking about the hypothetical effects of fictional nuclear devices is more exciting for our mindless press to blather about...

-Eric