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

What is http://port139online.com:139/ ?

• Port139online.com:139/ IS a website
• Port139online.com:139/ IS a protocol
• Port139online.com:139/ IS a service (a service that tells you if your ISP is providing a tampered, filtered, limited, and incomplete service.)

I started port139online.com:139 to annoy the tech support agents at Cox Communications. I subscribed to their business Internet service because the sales rep told me that absolutely NO port filters existed for business customers. I don’t know if the sales rep lied to me on purpose to meet a quota, or if she just didn’t have all the information.

After several phone calls to Cox support, I finally got them to admit which ports they filtered (both inbound and outbound). They offered to reduce my bill by 45 dollars a month, but they would not remove the filters. I’m now a Verizon Business FIOS customer and couldn’t be happier with my pure, unmolested Internet.

Shortly after my Shmoocon presentation, Comcast went before the FCC. An executive vice president for Comcast lied to the FCC commissioner and the rest of the panel, when he said:

“I’m going to say again, on the record in front of this Commission, Comcast does not block any Web site, application, or Web protocol, including peer to peer services. Period. Doesn’t happen.”

Oh really? Well http://port139online.com:139/ IS a website AND an application AND uses a WEB PROTOCOL… and guess what? Comcast IS blocking it.

Read more about it here:

http://arstechnica.com/news.ars/post/20080225-comcast-and-net-neutrality-advocates-clash-at-fcc-hearing.html

And listen to the MP3 here: http://arstechnica.com/news.media/fcchearing25feb08.mp3

Reference: Comcast does block websites, ports, and protocols: http://taosecurity.blogspot.com/2005/07/what-does-your-isp-block-only-low-cost.html

http://www.dslreports.com/forum/remark,15481407

**** NOTE ****

You can only visit http://port139online.com:139/ from Internet Explorer. Firefox blocks many ports.

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.

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

There was an interesting update yesterday about last month’s story about a Swedish security researcher who released the password and login information for 100+ embassy and government workers.

(I’m going to take some liberties summarizing this)

A Swedish researcher released 100+ passwords claiming he wanted to expose that the practice of using pop3, imap, etc shows a lack of user awareness. This also shows a lack of care and regard from the government institutions that permit inbound plain text authentication.

Some called for the lynching of this “hacker” while others were more curious about how the passwords were obtained. My initial off-the-cuff guess was a web exposure or a password list carelessly left online for google to cache.

How the passwords were really obtained proved to be much more interesting. In a blog posting yesterday, Dan Egerstad, revealed that he has been operating TOR exit nodes and sniffing passwords. I’m absolutely not surprised some people think that using TOR magically fixes all clear text protocols. What did surprise me is that government and embassy workers are using TOR. Are these workers really using TOR? It’s true that Tor is effective at masking the origination IP address from the destination address.

I think the REAL story here is that 100+ accounts have been compromised for months (maybe years) and that the real attackers have been using Tor to mask their origin IP address. Without Dan Egerstad exposing this; hackers, spies, (and who knows) could have gone on accessing these government email accounts unobstructed.

-higB

Jack Germain interviewed me on the security implications of peer-to-peer file sharing programs. Excerpts from that interview can be found in this article that discusses the grilling of the LimeWire CEO by a congressional committee.

Personally, I stay away from P2P prgrams other than Skype voice chat. Yes, Skype voice conversations are peer-to-peer.

 -Rohyt