Coffee To Code

As everyone’s gearing up for the madness this week, I thought I’d join in. I’ll be giving talks at both BlackHat and Defcon on some of my recent work in webapp fingerprinting.

At BlackHat: (Wed 7/28, 1515) BlindElephant: Web Application Fingerprinting with Static Files

At Defcon: (Fri 7/30, 1400) Web Application Fingerprinting with Static Files

The Defcon talk is essentially a shorter, more technically focused version of the BH talk. Links to code available here after the talk!

I’ve been sorting through the massive amount of content on display over the next week, and the various posts others have made on what they intend to catch have been useful. Here’s some of my “want to see” list (I actually found there’s usually at least two presentations I really want to see in each timeslot, but I gotta choose):

Wednesday:

• 1000-1100 Wayne Huang, Caleb Sima: Drivesploit: Circumventing both automated AND manual drive-by-download detection
• 1115-1230 Charlie Miller, Noah Johnson: Crash Analysis using BitBlaze
• 1345-1500 Barnaby Jack: Jackpotting Automated Teller Machines Redux
• 1515-1630 Me! BlindElephant: Web Application Fingerprinting with Static Files

I’m kinda bummed I’m at 1515 because I actually really wanted to catch Arshan Dabirsiaghi:
JavaSnoop: How to Hack Anything Written in Java.

Thursday:

• 1000-1100 Nathan Hamiel, Marcin Wielgoszewski: Constricting the Web: Offensive Python for Web Hackers
• (My colleague Ivan Ristic is also giving his talk State of SSL on the Internet: 2010 Survey, Results and Conclusions Routers in this slot; it’s good stuff, so I’m torn.)
• 1115-1230 Julien Tinnes, Tavis Ormandy: There’s a party at Ring0 (and you’re invited)
  • (Gunter Ollman is also talking a 1115. If you’ve never heard him speak or want an intro to the economic underpinnings of malware and botnets, definitely check it out)
• 1345-1500 David Byrne, Charles Henderson: GWT Security: Don’t Get Distracted by Bright Shiny Objects
  • (Though I am interested in the TitanMist project, I’m skeptical of all “frameworks”)

And finally, my coworker Rami is going to be giving the details on the malware detection he built. He’s modest about the underlying techniques, but the full system is pretty cool. Do check it out.

• 1515-1630 Rami Kawach: NEPTUNE: Dissecting Web-based Malware via Browser and OS Instrumentation

I hope to get to BSides for at least a while, and I haven’t even figured out what I’m going to catch at Defcon (somehow it seems less amenable to planning than Black Hat)

If you’ll be be around, look me up! As usual, email or @coffeetocode on Twitter.

I’ve gotten reports from a few people about an SMS phishing scam that is targeting customers of a small credit union near Sacramento, CA. Ordinarily I’d just ignore it as one more bit of flotsam in the teeming sea of junk that’s on the net, but this one has a few interesting aspects.

Here is the text that has been going out to cell phones in the 530 area code [1]:

From: NOTICE3319@yolofcu.org

NOTICE: Your YOLO-FCU CARD starting with 4661* has been put on hold. Please call us at (888) 819 9661.

Calling the line (which is still active as of this morning, 6/19) gives you a synthesized-voice prompt:

Thank you for calling Yolo Federal Credit Union 24 hours (sic) credit activation services.

For card card activation, press 1.
To change your pin, press 2.
To end this call, press pound.

The usual first line defense of simply reading the text (and listening) in this case should be a least a mild tipoff. The first detail that jumps out is the use of the first four digits of the account number (“starting with 4661″)[2]. Banks and card issues always refer to accounts by the last four digits, because the first four are always the same for a given issuer; they’re called the Issuer Identification Number (IIN). What’s particularly devious about this detail is that it lends false credibility to the phish because it invites users (victims) to improperly generalize from the familiar security practice of referring to an account by only the last four digits.

The next detail that seems a bit incongruous is the synthesized voice message. While not entirely unknown, one might expect a reputable credit union to use a real voice in the recorded message (if only for customer service reasons).

Other than those couple details (and the fact that no bank should ask for the information it’s requesting), this is a pretty decent phish. I give it a C+.

Feeling Insecure Is As important as Feeling Secure

Using SMS is a new twist, and is devious for the same reason the IIN was. The use of the cell phone as out of band (OOB) authentication (for email, banking and brokerage accounts) is beginning to permeate the public consciousness. Likewise, SMS doesn’t (in the US) typically get spam or solicitors the way email and land lines do, so it has a bit more of an aura of authenticity. These two pieces help make this particular incident nastier than your average phish.

We all need to remember that the more something feels secure, the more value there is to the criminal in subverting it or co-opting it. User training and UI design can’t just be about making users feel secure, it has to be about making them feel secure when they are actually secure, and likewise (and just as important) making them feel insecure when they are actually insecure.

If you regularly teach your users to “look for the lock icon” when connecting to a secure site, it can’t just be rote (though I know sometimes that’s what we have to settle for). What we should also teach along with it are the implications of what it means when the lock isn’t there. This is the type of knowledge that can help internalize and instinctualize security behavior (yes, I made up a word).

Banks: Please Meet Us Halfway

The last thing that I thought was interesting was the website for the real Yolo Federal Credit Union.

Here’s what I saw when I visited:

Wow, nothing about the scam? Seriously? That’s unconscionable. Oh wait, let me turn off NoScript:

Better-ish.

Here’s a catch 22 for YFCU; I’m sure they would advocate secure browsing practices (using NoScript while doing online banking is a no-brainer), and yet users trying to do that right wouldn’t see this important security information on the site. You’ll notice that it’s all an image, and wrapped inside a flash object. So, again a plea to site designers banks and everyone else; please, at least meet your security conscious users half way.

[1] I’m including the entire text of the scam message to raise the visibility of

[2] Similarly, the first five digits of a Social Security Number (e.g. 224-87-XXXX) are also fairly public information. Data that is presumed private has the effect of legitimizing a communication, making it all the more important to help users differentiate public and private data.

The first portrayal of hacking that gets it right; I officially owe this man a case of beer.

(Saturday Morning Breakfast Cereal — don’t wait, just add it to your feed reader)