The 9 Laws of Phishing

Copyright © What The Hell? Security

[ Part 1 | Part 2 | Part 3 ]

What the hell is it about phishing that makes it seem so intractable?

First off, let’s talk intractable.  An uncontrollable or incurable problem. Computational complexity theory adds a convenient twist: A problem that can be solved, only not fast enough for the solution to be useful. Like with phishing. With me?

I don’t think so. See, the real issue with an intractable problem isn’t always its intractability.  Sometimes it’s our frame of reference. It’s how we’re thinking about the problem. Like Relativity Al said, when you create a problem with one kind of thinking, it takes a different kind to solve it. With me now?

I still don’t think so, but let’s find out. To do that you need to momentarily dismiss everything you know about anti-phishing. I’ll stipulate that you know everything that can be known about how phishing works, but I need you to pretend you have no preconceptions about how to stop it. Grade your pretending skills by how strongly you want to argue with me before reading this whole piece through a couple of times.

Law 1:  Phishing Is About Commerce

Not visual appearance. Nor ads. Nor search. Nor browsers even. Those things are attack vectors. You can address attack vectors forever without ever getting to the root of the problem.

Take forged email for instance. As phishing attack vectors go, this is the most despicable. Only not for the reason you think. It’s despicable because it is a red herring attack vector. It’s the Mother of All Security Red Herrings, in fact. Why? Because what we call forgery is so integral to our 40-year old email system that it would cease to function without it. Did you get that? Every legitimate email message you have ever sent or received via the Internet had to be forged — using the exact same technique that phishers use — in order to get delivered.

There is only one prime mover of phishing, and it is commerce. In the mid-1990s, we began introducing commerce into pre-existing systems like email and the Web, when they had no accommodation for commerce. And guess what? They still don’t. Not a shred. And before you say SSL, keep reading.

Law 2:  Phishing Education Is Irrational

So we’re trying to teach half the human population to not do the one thing that comes naturally on the Web — click on an interesting link — and to do a bunch of things that come unnaturally — like interpreting unicode URLS and ignoring clearance sales. On something like a $1 budget. C’mon.

Law 3:  Phishers Win By Playing Our Game, On Our Field, Using Our Players, Following Our Rules

Our game: campaigns. Our field: hypermedia. Our players: hijacked CPUs, storage, bandwidth. Our rules:  phishers are always on offense.  We’re always on defense, and score only when they fumble.

This doesn’t mean phishers are less guilty of their crimes.  But we’re guilty too — of being a little disingenuous.

Law 4:  Phishing Is Not Caused By Broken Technology

If you don’t believe me, go read the RFCs.  It’s all working as designed.

And dammit, quit blaming Tim and Vint for the sorry state of security.  It’s a gross injustice.  We should in fact be thanking them for building insecure systems, because adding security to systems that have no foreseeable need for it is a lousy idea.  (Note I said foreseeable, not immediate, which is another story entirely.) They set out to solve very pressing problems at hand, which they did, which is why their stuff got so widely adopted. It’s not their fault that we threw the monkey wrench of commerce into the gears of their systems years after the fact. Blaming them for bad security is like blaming Karl Benz for inventing cars that make for poor submarines.

Law 5:  Phishing Blacklists Are Not Blacklists

They are, pure and simple, blocklists. Not blacklists. See the important difference?!?

Law 6:  SSL Certificate Authorities Increase Phishers’ROI And Reduce Merchants’

SSL was introduced in 1995 to solve two problems:  1) help consumers identify legitimate sites, and 2) encrypt the channel between browser and webserver to protect sensitive information.

The latter is free. The former works so poorly that it actually helps phishers at the expense of merchants.  The only reason merchants pay for certs (other than out of check-writing habit) is to prevent people’s browsers from ralphing error messages that Rivest, Shamir and Adelman can barely understand.

SSL didn’t always have this problem.  CAs like VeriSign started out with good certificate issuance practices.  Later, upon realizing that the market for legitimate certs was bounded on the smallish side, they unbounded it by issuing certs to anybody having the means (fraudulent or not) to pay for them.

Law 7:  It’s The Clicks, Stupid

If you learn one thing today, let it be this.

You can’t control content produced by other people. In many cases you can’t even anticipate its delivery to you. But you control what you do with it.

You control whether or not you click on a link. You control whether or not you click on a form’s control to populate it. You control whether or not you click on a form’s submit button. Get it?

And I don’t think for a minute that I mean the clicks that SiteAdvisor invites with its army of green checkmarks.  Look closely and you’ll see that it’s a blocklist wearing a clever (and rarely washed) blacklist disguise.

Law 8:  Documents Matter, Sites Do Not

A site owner is a site owner. A content publisher is a content publisher. A content author is a content author. A third-party content developer (like those building on Facebook’s platform) is a third-party content developer.

None of these need to be the same, and increasingly with time, they are not. Imagine you’re examining a source page that contains a link to a destination page. The destination contains content from a dozen sources. Just because you know who the destination site owner is, does that really make it safe to click on the link?  (Hint: No.)

The whole notion of a site will slowly erode, for no reason other than hypermedia does not require it. Hypertext did just fine without it for 30 years.

Law 9:  The Solution Is A Platform

(continued)

[ Part 1 | Part 2 | Part 3 ]


GOTO Website Considered Harmful

Copyright © What The Hell? Security

You wanna know the biggest problem with the Web?

Browsers.

I actually don’t mean the fact that every browser I’ve encountered is a steaming pile. But now that I’ve brought it up, let’s talk about that too.

Sure, some browsers steam less than others.  But be honest.  Browsers have been around since 1991.  That’s 19 years folks.  Let’s check out the  brag sheet from the latest rev of Firefox (3.6):

Amazing New Feature! Translation
Change Firefox’s appearance with a single click! Click your way through thousands of themes to find the one you like.
Protection from out-of-date plug-ins! if (version = compatible) then behave(as_expected);
Full screen native video! All new levels of pixelization.
Scripts can run asynchronously! Render 3K of your 10M page at an indeterministic point in time.
Improved Javascript performance! But still a lot slower than NOSCRIPT. You are running NOSCRIPT, right?
Improved startup time! More spin time for the idle process while you wait for your homepage to load.
Improved responsiveness! Queues keyboard and mouse events.

C’mon.  I wrote loads of Internet client-server apps in the late 1980s.  Production ones, used by tens of thousands of people every day.  These are the kinds of improvements I would brag about on alt.misc while listening to Hall & Oates.

But like I said, that’s not the point I actually wanted to make. The bigger problem with browsers is that they have to exist at all. I don’t know about you, but I sure as hell don’t want to GOTO Amazon.com to buy a book. I want the book to show up on my Kindle. I sure as hell don’t want to GOTO all 142 job sites to post my resume. I want my resume to end up on them. I sure as hell don’t want to GOTO my bank’s site to transfer money from checking to savings. I want my money to get moved from checking to savings.

GOTO website is an artifact of the procedural web, just like the GOTO statement was an artifact of procedural programming.  The latter went away.  So should the former.

Security and the Unforeseen Use Case

Copyright © What The Hell? Security

Paul Vixie, venerable champion of DNS, writes a brilliant piece titled What DNS Is Not.

Vixie understands what most people don’t, or if they do, they’re too damn quiet about it. When you take a solution to one problem, and apply it against a different problem, you can create a whole new problem. Which — surprise! – somebody will try to solve with a solution to a completely different problem.

The fundamental issue here is one of unforeseen use cases. Our eyes are pretty good at spotting them in the physical world. Sometimes they’re handy, like the Ikea server rack. And then there’s the unfortunate Husqvarna fingernail trimmer.

But when it comes to software, our eyesight is pure crap.

Take the almighty HTTP cookie. Its initial purpose was to tell Bianca’s Smut Shack when you last visited. Next thing you know, it’s telling your brokerage to liquidate your NASDAQ:NSCP holdings and wire the proceeds to Kenya.

So who’s to blame? Let’s make this simple and boil it down to one of two representative scapegoats:

  1. The smart guy who implemented cookies to manage HTTP state
  2. The dumb guy who confused “HTTP state” with “user authentication”

Hint: It’s not the dumb guy.

See, the smart guy wasn’t smart enough. If he had been, he would have foreseen that unforseen use cases would arise. By definition he had no way of knowing what they would be. But he should have known that there would be at least one. For anything useful there always is.

The smart guy should have recognized that by building a solution intended for universal adoption, he inherited the responsibility to shout out not just the kinds of things that cookies might be used for, but also the kinds of things they should never be used for. Foreseeing their use of as authenticators wasn’t exactly a big stretch.  Especially since he was Netscape. (So was the dumb guy by the way.)

See, you can’t foresee the unforeseeable.  But you can — and must — foresee that there will be unforeseeables. Account for that, and you’ll find yourself making much smarter decisions.

Unfortunately  — as Vixie knows all too well — nobody riding on your coattails is obligated to do the same.

Man Awakens From Phishing-Induced Coma

Copyright © 2010 What The Hell? Security

San Francisco, Calif. — A man who spent the last 9 years in a phishing-induced coma awoke today — only to relapse  minutes later upon learning that absolutely no progress had been made on the anti-phishing scene since 2001.

In an exclusive interview held at Sanford Wallace Memorial Hospital, Dr. Hormel Aspic told this reporter that his patient, whose family wishes anonymity, first collapsed during the 2001 RSA Conference, apparently while observing a panel discussion on phishing. Witnesses independently confirmed that the man lost consciousness “as if choreographed” after a unanimous agreement by panel members that authenticated email would stop phishing.

“Our secure hospital records (© 2001-2010 Google) indicate that upon the patient’s admittance to our emergency room, the physician in charge undertook our standard procedure of comparing the man’s vitals against every entry in Black’s List of Universally Recognized iLlnesses,” a.k.a. Black’s List of URLs, said Aspic. “Unfortunately this procedure dramatically slowed rendering of his EKG monitor.  So the physician abandoned it in favor of a detailed examination of the markup.”  The results were stunning: The patient had contracted a new strain of the Hepatitis virus, since dubbed Hepatitis P, most likely from a nearby cyber cafe known to serve contaminated shellscript.

Aspic says that nine uneventful years passed for the patient (and anti-phishing solutions), until he was making this morning’s rounds. “The patient’s eyes suddenly snapped open. After affirming his right to anonymity, and verifying that he knew his name was Henry Limpett, I explained that he’d been comatose for 9 years.  I then urged him to try to recall the events immediately preceding his blackout. He appeared to recount the phishing panel discussion with such clarity, that I felt moved to hand my HIPAA-compliant laptop to an outsourced orderly wearing a DEFCON t-shirt, asking him to locate some quotes from the 2001 panel.  After kindly upgrading my browser to IE 2.0, he found some [here], and sure enough, the patient had nailed every one of them verbatim.”

What happened next is a matter for debate, but the end result is not: Ninety seconds later the patient relapsed into coma. Aspic asserts that the injection he administered of Canadian Imported Career Advancing Acai-flavored Vi@gra 80% OFF re-triggered the Hepatitis P virus. But the patient’s celebrated shift nurse, speaking under condition of anonymity, claims otherwise. “The patient asked if he could borrow Aspic’s laptop to altavisa how phishing had eventually been eliminated during his nine years in coma. After clarifying his request by conjugating ‘to altavista‘, the patient glanced at the still open story [here]. The last thing he said before his head thudded on the pillow was “What the hell? This story is dated 2010 not 2001!”

Editor’s Note: Since ALL of the links in this story are phishing links, do not click on any of them until applying this important anti-phishing procedure:

1. copy-and-paste this story into an email message
2. digitally sign the message
3. send it to yourself
4. locate the message in your inbox
5. verify its digital signature

The links in THAT copy of the story, being contained within an authenticated email message, will no longer be phishing links. Click here for more details.

Why We Need Fewer Security Engineers

Copyright © 2010 What The Hell? Security?

Don’t get me wrong. I love security engineers. Some of my best friends are, or used to be, security engineers. Hell, I used to be one myself.

But we’ve gotten to the point where we have way to many of ‘em. They’re practically crawling out of the woodwork relative to what we need. And what we need are loads and loads of security coaches. What’s a security coach, you ask? A security professional that:

Converses in the business vernacular
Operates in harmony with the business
Achieves progress with a light hand
Converts skeptics into volunteers
H
ighlights reliability over security

Quick now:  Did you roll your eyes or turn up your nose at that acronym?  Or gag yourself with a spork?  Yeah, so did I. We’re security engineers!

And the rest of you are non-spork-totin’non-gaggin’security coaches! So what the hell are you doing standing around looking at me for? Go on, get the hell out of here. And start coaching I mean.

Eerie Coincidences Between Fortran and the Web

Copyright © 2010 What The Hell? Security

Back in the mid-1970s somebody came up with a clever way of flipping a penny into half a buck: the Lincoln-Kennedy Penny.  The least interesting part of which was the defaced — well, technically it was enfaced — coin.  What people were actually interested in was the litany of weird coincidences involving the two presidents.

It occured to me recently that there are also some mighty scary coincidences between Fortran and the Web.

Both were designed by and for scientists

Fortran was invented because assembly programming was a royal pain. The Web was invented because assembling documentation was a royal pain

Fortran introduced the unfortunate “GOTO” construct.  The Web assigned the unfortunate "GOTO WEBSITE" construct

Fortran apps are devised to be portable. Web apps run on portable devices. Both sound more helpful than they actually are

Fortran has no obvious garbage collector. The Web obviously has no garbage collector

Fortran developers are not required to learn about object classes.  Web developers are not required to take security classes

Fortran is an anagram of for rant.  A Web blog is a sociogram for ranting

Fortran developers think globs are handy.  Web developers think blogs are handy

Fortran fans examine arguments with debuggers.  Web fans enjoy arguments with debunkers

Fortran II users couldn’t wait for Fortran 77 to arrive.  Web 2.0 users can’t wait for Web 77.0 to arrive

Like I said, scary, huh?  So I figured what the hell, why not sell Fortran-Web pennies for five bucks apiece.  Flipping a penny into a fiver, as it were.

Follow

Get every new post delivered to your Inbox.