It is common knowledge that people get phished on non-SSL HTTP web sites. RSnake has blogged and presented about the weaknesses in todays web browsers that make this possible. These same weaknesses are presumably what Moxie Marlinspike exploited after he thwarted SSL site-validation and encryption via man-in-the-middle (MITM) attacks against HTTP traffic on the Tor network, as discussed in his BlackHat DC talk.

While these weaknesses have been known, what makes Moxie’s presentation unique is that he launched this attack against a large sample set of real victims, and succeeded in capturing their login credentials. Further, Moxie has shown us that his tool SSLstrip, and others like it, can make these attacks easy and automatic – assuming you have a foothold as a MITM. Hopefully somewhere, upon reading Moxie’s slides, a browser UI designer has finally let out a “Doh!” and slapped his own forehead.

MITM attacks on SSL aside, the most interesting thing I’ve taken away from Moxie’s talk that he was able to identify user accounts for specific web sites on the Tor network. You can read about how Tor works on the Tor Project site, but the purpose of Tor is to provide reliable anonymity while surfing the Internet. Anonymity is key for folks who want to blog about their oppressive governments, as well as those who engage in less-than-ethical activities on the Internet.

Posting an anonymous blog on a free blog service is one thing. But what about anonymously logging into your bank’s web site? Or anonymously checking your PayPal account? Isn’t that kind of like anonymously presenting your drivers license to the bouncer at the bar? The person on the receiving end of the communication knows who you are claiming to be.

If I wanted to do something that would hide my identity, I would use the Tor network. However, if I were doing something to hide my identity, I would not do so using my own peronally identifiable information (PII). This really makes me wonder about the people that Moxie man-in-the-middled. Were they ignorantly using Tor, assuming that anonymity in the network provided them increased security to perform their online banking? Or were they bad guys (phishers) logging in to compromised accounts using Tor to hide their identity and protect them from prosecution?

There are a lot of misconceptions about SSL and “online security” in the non-security geek world. People don’t get it. The big question I have after Moxie’s presentation is “do similar misconceptions apply to the use of Tor”? I would be very interested to know more about the people compromised in Moxies experiment.

-Schmoilito

Authenticating to a web application is a mutual process. Before a user enters credentials into the application, they validate the web applications credentials: its hostname, content, and SSL certificate (assuming it uses SSL).

Essentially, you validate the web site against what you know to be true (hostname and expected content). The browser validates that a trusted third party signed the web sites public key, and together they vouch for the sites identity by showing you a visual cue.

If the web site passes your personal validation and you decide to provide them, the application will take your credentials and validate them against what it knows to be true: a directory or other repository with user information. If it validates your credentials, it lets you in.

Dan Kaminsky’s DNS flaw makes it possible for attackers to spoof one of the three credentials web servers use to authenticate against users: the host name. The look and feel of a particular web site is already easy to spoof: phishers have been doing this for years. The only remaining credential the web server has that can’t easily be compromised is its SSL certificate, and the signature of a trusted third party (one of the commercial certifcate authorities).

Now that two of the three credentials could be spoofed, I started wondering how hard it would be to spoof the third. If you can get a valid SSL certificate, you can completely steal the identify of a web site. Unfortunately, it is not too dificult, and it is through no technical fault of the SSL protocol.

For me, it required no social engineering, no illicit hacking or ninja skills. In fact, it was kinda scary in its simplicity, and the real fault is in the process of the certificate authority (a big one). Is it that bad? I attempted to get certs for three HUGE Internet sites, and I was successful with one. An interesting application logic problem prevented me from getting another, and the certificate authority basically told me no (over the phone) for the third. The one I did get, however, is a biggie.

I’ll drop the details at the beginning of my SSL VPN talk at BlackHat next week. I won’t divulge them sooner. Not even if Matasano kidnaps me, sends me overseas, and water boards me.

-Schmoilito

A few weeks ago I was looking into writing an application for my iPhone. At some point, I felt compelled to actually give it a shot, and I headed over to Apple’s web site to download XCode and whatever other tools I needed. Of course, I couldn’t remember my Apple developer center password, so I went through their “Forgot Your Password” routine on my Dell laptop.

A few seconds later, an email popped up on my Mac containing their magic link to pull up my change password form. I clicked it and went through the reset process, which ultimately asked me to authenticate with my new password.

Finally, I was redirected to the URL I originally requested . . . on my Dell. Hmm. How did my Mac get to where my Dell originally was?

Turns out Apple was maintaining a session for me on the server which retained my original URL. When you requested a URL that required authentication, Apple 302′d you to the login page with your desired URL contained in a query-string parameter. Once on the login page, you could tamper with the URL before it was stored in the session. You could also then enter your username (or, even better, someone elses’) and initiate the change password process.

When you chose to have Apple send you a link to change your password, the session you started with your original URL persisted via the data contained in the link. After you went through the process of changing your password and you finally authenticated, Apple sent down a small HTML file with a META-REFRESH tag that actually sent you where you originally wanted to go.

It is in this HTML where the badness happened. The original URL Apple stored in the session was being written here without being HTML encoded or properly validated. Apple did prevent you from specifying http://attackersite.com, but they did not validate against iphone.html”><SCRIPT>…</SCRIPT>.

The attack would have been as follows:
1. Tamper with the original URL and inject an XSS attack.
2. Enter someone elses’ username in the logon form, and click “Forgot Your Password”
3. Have Apple send the victim the password reset email.
4. Here is the kinda far fetched part: you need to hope/pray/socially engineer/somehow get the victim to go through the password change process, and authenticate.
5. Once they authenticate, you own their browser.

This attack is interesting to me for a number of reasons. First, it is a persistent XSS attack in a credential management system (ouch!). Second, the injection point is pre-auth, while the payload executes in the victims browser post-auth. Third, it is very easy to target individual users using legitimate emails from Apple: no spoofing required!

Apple was very quick to fix the problem, and even gave us credit here.

Good job Apple!

-Schmoilito

At this year’s RSA conference Ira Winkler went on to tell the audience about hacking into an energy company (via an authorized penetration test) using a targeted phishing email. Details are in this networkwold article: http://www.networkworld.com/news/2008/040908-rsa-hack-power-grid.html

“The penetration team started by tapping into distribution lists for SCADA user groups, where they harvested the e-mail addresses of people who worked for the target power company. They sent the workers an e-mail about a plan to cut their benefits and included a link to a Web site where they could find out more.”

Are we surprised they were successful? Absolutely not. We’ve been using this technique and responding to real incidents that that used spear phishing for quite some time now. But what if those same employees had already been “phished” through targeted awareness and then presented with the appropriate training material? What if you ran this exercise against all your employees regularly?

Phishme.com already has pre-built scenarios to make this training quick and easy. It has many generic domain names to choose from or you can register your own look-a-like domain.

There is no sense in paying a pentest company high dollar consulting fees to find out if your employees are vulnerable to phishing. I’m about to save your company a boat load of money.

Dear Magic Eight ball, I don’t currently conduct phishing attacks against my own employees as a means to train them. Am I vulnerable to spear-phishing attacks?

Someone beat us to the shmooball launcher.  It’s probably for the best since we were going to order parts from this company. We heard ambulances only take 180 seconds to get to the hotel.

The presentations were very hit or miss this year, with unfortunately a bit more of the latter.  I felt a lot of presentations would have fit a shorter turbo style time slot better than the hour long time slots.  For example, the ‘baffle’ application for wireless AP finger printing looks like a very cool first generation tool. Easy to use, hack around with, well researched, and makes pretty graphs. Score. Unfortunately they dragged out the presentation with the whole history of tcp finger printing and made us wonder what the students were IM’ing about as they sat on the stage trying not to look too embarrassed or bored.

Mad props go out to Brad Antoniewicz and Joshua Wright. Not only for releasing a cool tool for wireless PEAP/TLS client credential pwnage (FreeRADIUS – Wireless Pwnage Edition), but for fun presentation skillz and shmooball dodging.  Find the video for this one. It was probably my favorite talk of the con (not sure if the camera man caught the start of the talk though).

The guys at Vigilar also rocked with a new and improved version of VoIP Hopper; complete with practical usage scenarios and some good demos with a standard VoIP phone.  They showed how to get on to the corporate network bypassing vlans setup for the VoIP traffic. I could think of a number of locations I’ve been at where it would be handy to have this tool with me.

Our very own Jaime and Aaron got a lot of people thinking with their forced internet condom. They’re moving the web hosting provider, but there’s some good data about what ports ISPs are blocking over at portscan.us (and you can help add to the project as well).

I unfortunately missed h1kari’s (David Hulton) GSM talk due to train delays, but the word at the hotel bar was that it was one of the most techincal and interesting talks of the con.  His GSM rainbow tables may make things very interesting when the FPGAs complete in three months (anyone get a link to where that will be?).  Speaking of FPGAs, I’m proposing the FDA needs to start looking into these things since they’re basically giving every geek I know an erection that is lasting way longer than 4 hours.

And for more geek porn,  let me suggest the Solid State Drives Data Recovery Comparison to Hard Drives presentation.  Scott Moulton makes powerpoint look a commadore 64 next to his smoothly timed 3D graphics.  His guy also rocks for having them online for everyone to get jealous of… oh and teach us that deleting or wiping flash based drives is completely useless because of the wear-levelling process done by the controllers on these things. (and yes, I did sit there thinking of all the times I’ve futilely done PGP wipes of data on my flash drives). The good news though is that the recovery of that data sounds pretty damn hard at this time.  Also in good news, we can now write off a few power tools from home depot as business expenses since you’ll want a hammer now to “wipe” those drives.

A number of us caught the phishing talk by Syn Phishus. I think we’ll have a full follow-up post on that (but just to clear one rumor we heard, no, he does not work for or have anything to do with phishme.com). He obviously agrees with us that mock phishing exercises need to be done… but I’d say our approachs to this differ greatly.

-b3nn

I just got back from The Credit Union Information Security Professionals Association 3rd annual National event in Austin Texas where Rohyt and I were talking to the folks about www.PhishMe.com.
I have never attended a CUISPA event before and welcomed the opportunity. It was refreshing to see this industry work together. Credit unions don’t have the budgets larger institutions do and many of their technologists wear multiple hats. Security is a group effort. (as it should be)

Two major takeaways I had from the conference:

1.) Credit Union security professionals have a can-do attitude and value networking with their peers to solve their security woes
2.) Don’t show up to a Credit Union event dressed in New York-Financial attire (unless you enjoy looking like that creepy sales guy)

On the heels of the CUISPA event is a good white paper I saw on BankInfoSecurity.com titled The State of Information Security 2008 – Survey Executive Overview (Free signup)

Tom Field (Editorial Director) did a good job putting the overview together. The top security issues I heard the Credit Union folks discuss are the same ones captured in this survey. (It’s good to see that this paralleled what I saw in person at CUISPA … too often these days a whitepaper is just a synonym for marketing fluff.)

Of course the #3 issue “3) Training – Employees, Customers Need More.” grabs our attention as our http://www.phishme.com/ moves from beta and inches towards launch.
I’m beyond excited.
-higB

p.s. If you happen to attend my ShmooCon 2008 presentation please be kind with the Shmooballs.

I was adding a little special sauce to Phishme.com this past week and thought this might be fun to share. We have a few different ways a user can craft their phishing links. If he/she chooses the IP address option, then there is also the choice of encoding options. This lets you mask the IP address in an attempt to trick the user into thinking part of the sub directory is perhaps the host name. Or as in the case with my mom… she thinks it is just the phone number so the computer knows where to call. And it’s hard to blame her when you see a decimal encoded IP address.

http://2130706433/somecompany.com

The team over at Marshal has put together a good walk through of the encoding so you can follow along. If you would like to view the javascript, you can find it here. This may not work on all browsers, but it holds up pretty well on your corporate windows boxes with IE or Firefox. Want to test it out? Just put in an IP address below and click on the link it generates.

-b3nn

Carnegie Mellon researchers presented a paper at the Anti-Phishing Work Group’s E-Crime Researchers Summit in October 2007. The results of the study indicated the following:

• Users learned more effectively when the training materials were presented after they fell for a phishing attack (embedded training), rather than when the training materials were simply emailed
• Users also retained more knowledge and transfered more knowledge about how to avoid phishing attacks when trained with embedded training

These are the underlying principles of PhishMe.com – Phish n’ Educate. PhishMe.com will facilitate the execution of mock phishing attacks against employees. Those that fall “victim” will be presented appropriate training materials.

-Rohyt

Those close to us know that we’ve been working on a self-service portal designed to help organizations run mock phishing exercises aimed at raising employee awareness. Shortly after the recent news about Oak Ridge National Laboratory and Los Alamos being targeted by spear phishing was published, I was interviewed by eWeek.

Read the full article here: Phishing Drills Teach Employees to Dodge the Hook

-higB

Phishing is now recognized as a 2007 SANS Top 20 risk, and rightly so. What I was even more excited to see is SANS calling out the countermeasure correctly. They didn’t recommend deploying millions of dollars worth of technology to “catch” phishing attacks, but said “user awareness is a key defense. The most promising method of stopping spear phishing is continuous periodic awareness training for all users; this may even involve mock phishing attempts to test awareness”.  As I said in a previous blog post , we are in total agreement with SANS on the efficacy of this countermeasure. In fact we are so in agreement that we have developed a solution (www.phishme.com) to do exactly that – run mock phishing attacks to test and measure employee awareness.

Now for the gimmicksmen. Qualys just made an interesting announcement – “Free security scan available for the new SANS Top 20“. I wonder how they are going to scan for phishing vulnerabilities.

 - Rohyt