Kode Vicious - @kode_vicious
PDF
Phishing for Solutions
Kode Vicious could devote every month to security questions and never run out. Whether it’s the latest worm or ongoing problems such as this month’s topic—phishing—security provides a cornucopia of challenging programmatic puzzles. Phishing alone warrants a book-length treatment, but that won’t discourage KV. Here he offers helpful hints for taming this wily beast.
Dear KV,
I noticed you covered cross-site scripting a few issues back (“Vicious XSS,” December-January 2005-2006), and I’m wondering if you have any advice on another Web problem, phishing. I work at a large financial institution and every time we roll out a new service, the security team comes down on us because either the login page looks different or they claim that it’s easy to phish information from our users using one of our forms. It’s not like we want our users to be phished—we actually take this quite seriously—but I don’t think it’s a technical problem. Our users are just stupid and give away their information to anyone who seems willing to put up a reasonable fake of one of our pages. I mean, come on, doesn’t the URL give away enough information?
Phrustrated
Dear Phrustrated,
Ah, yes, your users are stupid. They just sit around waiting for someone to pop up a login screen or a page full of inputs for personal information, and they’re doing it just to get you. It’s very comfortable to think along these lines because it leaves you feeling superior and means you don’t have to work to fix the problem; instead, you think you should fix the users. Unfortunately, as I have learned from long experience, beating stupid people doesn’t make them any smarter.
Now, I don’t like users any more than you do. They’re demanding, and they want things simple and just ruin my fun at playing with what really are “my toys.” Alas, we’re both paid to make these toys work well in the service of the users, so we have to give them some small consideration. So, what is phishing? Well, first of all it’s a very annoying misspelling, far more annoying than kode. (Go ahead, call me a hypocrite, I’ll wait.)
More to the point, phishing is the ability of an attacker to get someone to give away important or useful information. At the highest level, this is one of the oldest tricks in the book and likely dates back as far as the oldest profession. It’s a con job: Your users are the marks, and unless the marks are paying attention, they are going to be conned out of their user name and password, or social security number, phone number, birthday, etc. The Internet has amplified the abilities of old-time con men (there must also be con women, but this is not listed in my dictionary), because now there is a tremendous amount of important information stored on computers and because the Internet reaches into hundreds of millions of homes from anywhere on Earth.
Although there is no sure technical fix to the phishing problem, there are ways to evaluate possible solutions, and these ought to be kept in mind for those moments when someone in a meeting says, “Well, if we just...” I have an allergic reaction to that particular phrase because it is usually followed by a specious or poorly thought out suggestion that sounds good until you try to follow it to a logical conclusion.
Many smart people are thinking about this problem, but the best advice I’ve seen on evaluating anti-phishing technologies comes from Rusty Shackleford. Rusty’s rules can best be summed up in this way:
- Anything the attacker can see, the attacker can spoof.
- Anything the user knows, the user can, and will, disclose. (Corollary: Anything the user’s browser knows, the user’s browser can and will (quite willingly) disclose.
- Your solution is only as good as its first step. That is, your solution is only as good as what your users do when they find themselves in unfamiliar surroundings.
Let’s take these one by one. “Anything the attacker can see, the attacker can spoof.” It may seem simple, but many people miss this point. Often people go to a lot of trouble to put visual cues into pages so that the users “know” they’re logging into the right page. The problem is that anything you show to all your users, all the “bad guys” can see as well—and pretty easily re-create, no matter how complex. Eventually all that complexity just gets lost to the users anyway, so don’t bother—they’re not going to notice. If you can come up with something that personalizes the page, perhaps an image, and not one chosen from a list of 10, or 100, then that might begin to provide some protection. Sounds are another way to personalize a page, though an annoying one for those of us who hate noise in public places like cafés or cubicles.
A harder problem to tackle is “Anything the users knows, the user can, and will, disclose,” with its corollary about the user’s browser being tricked in place of the user. This is the root of the problem. Users are being tricked, and if an anti-phishing system just depends on a different set of data being collected from each user—for example, the question, “What is the meaning of life?” instead of “What is your mother’s maiden name?”—then you’re just moving the problem around, like shuffling the deck chairs on the Titanic. One goal of a good anti-phishing system should be to do away with collecting any “personal and secret” information from the user, because that information isn’t really personal or secret and the user will willingly type it into a cleverly built phishing page.
Perhaps the hardest of the rules to understand is, “You’re only as good as your first step.” What Rusty was saying here is that no matter how good and tightly constructed the later phases of your system, the whole thing will unravel if the first step is susceptible to any of the issues pointed out in the previous two rules. Confused users are the easiest ones to phish. So, for example, if your account recovery page requires users to type in a lot of complex “personal and confidential” information, it is likely that phishers will take advantage of this and instead of hosting a fake login page they’ll happily host a fake account recovery page. It’s just as easy to steal an account with the account recovery information as it is with the login and password.
Alright, I admit it, I was unable to solve phishing in 1,200 words or less, but I hope Rusty’s advice is helpful and makes you a bit less frustrated. It has allowed me to quash some of the more questionable anti-phishing ideas I’ve heard of, and some days, that’s half the battle.
KV
KODE VICIOUS, known to mere mortals as George V. Neville-Neil, works on networking and operating system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor’s degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who has made San Francisco his home since 1990.
Originally published in Queue vol. 4, no. 4—
Comment on this article in the ACM Digital Library
More related articles:
Paul Vixie - Go Static or Go Home
Most current and historic problems in computer and network security boil down to a single observation: letting other people control our devices is bad for us. At another time, I’ll explain what I mean by "other people" and "bad." For the purpose of this article, I’ll focus entirely on what I mean by control. One way we lose control of our devices is to external distributed denial of service (DDoS) attacks, which fill a network with unwanted traffic, leaving no room for real ("wanted") traffic. Other forms of DDoS are similar: an attack by the Low Orbit Ion Cannon (LOIC), for example, might not totally fill up a network, but it can keep a web server so busy answering useless attack requests that the server can’t answer any useful customer requests.
Axel Arnbak, Hadi Asghari, Michel Van Eeten, Nico Van Eijk - Security Collapse in the HTTPS Market
HTTPS (Hypertext Transfer Protocol Secure) has evolved into the de facto standard for secure Web browsing. Through the certificate-based authentication protocol, Web services and Internet users first authenticate one another ("shake hands") using a TLS/SSL certificate, encrypt Web communications end-to-end, and show a padlock in the browser to signal that a communication is secure. In recent years, HTTPS has become an essential technology to protect social, political, and economic activities online.
Sharon Goldberg - Why Is It Taking So Long to Secure Internet Routing?
BGP (Border Gateway Protocol) is the glue that sticks the Internet together, enabling data communications between large networks operated by different organizations. BGP makes Internet communications global by setting up routes for traffic between organizations - for example, from Boston University’s network, through larger ISPs (Internet service providers) such as Level3, Pakistan Telecom, and China Telecom, then on to residential networks such as Comcast or enterprise networks such as Bank of America.
Ben Laurie - Certificate Transparency
On August 28, 2011, a mis-issued wildcard HTTPS certificate for google.com was used to conduct a man-in-the-middle attack against multiple users in Iran. The certificate had been issued by a Dutch CA (certificate authority) known as DigiNotar, a subsidiary of VASCO Data Security International. Later analysis showed that DigiNotar had been aware of the breach in its systems for more than a month - since at least July 19. It also showed that at least 531 fraudulent certificates had been issued. The final count may never be known, since DigiNotar did not have records of all the mis-issued certificates.
© ACM, Inc. All Rights Reserved.