Just before Christmas, an admin from StartCom certificate authority disclosed that he was able to procure an SSL certificate for Mozilla.com from a registered agent of the CA Comodo. He was not authorized to obtain this certificate, and the RA and CA clearly failed to properly vette his cert signing request. Shame on Comodo. You can read the entire saga on mozilla.dev.tech.crypto.

The discussion resulting from StartComs blog post is quite interesting, and touches on many issues spanning from internal CA domain validation procedures, to how to revoke a certificate in the Mozilla root cert program. One issue in particular, is exactly what I talked about in my last post.

Frank Hecker, of the Mozilla Foundation, said “[right] now we have no real idea as to the extent of the problem (e.g., how many certs might have been issued without proper validation, how many of those were issued to malicious actors, etc.).”

When a flaw in a CA validation mechanism is uncovered, it can sometimes be trivial to fix. The hard part is determining if any other certificates were obtained by taking advantage of the same flaw, and then revoke them. Although I can imagine a methodology for this process, I can’t comment on how any given CA would actually tackle this problem. Based on my own application security experience, I will say that I’m sure lots of logs that would need to be parsed, might not actually exist.

One person who commented on the StartCom post that started this all critiqued the post by saying it seemed dodgy that StartCom was blatantly pointing out flaws in a competing CA. The reader did, however, understand the severity of the problem that was found and thanked StartCom for publicly disclosing it. I agree with the reader, and I think StartCom did a good thing in disclosing this bug.

So in the interest of full-disclosure, here is what happened on Friday December 19 (three days before the StartCom disclosure). I found a flaw in StartCom’s domain validation mechanism that easily allowed anyone to authorize themselves for ANY domain name, on various .TLDs. While I only tested .COM, many other TLDs were available including .GOV.

The screen shot above shows the domain names my StartCom account was allowed to create signed certificates for. These certificates would have been trusted by Firefox, but not Internet Explorer. The first one is a domain I control. Phishme.com and Intrepidusgroup.com are domains owned by my employer for which I am not an authorized contact, and for which I should not have been, but was, granted a signed certificate. Needless to say Paypal.com and Verisign.com are companies I’m also not authorized for.

Fortunately for Verisign and PayPal, a defense in-depth strategy succeeded for StartCom. While I by-passed StartComs domain validation process, my attempts to create a signed certificate for Verisign.com was flagged by a black-list and not permitted. This is good news for the prominent sites on the black-list, but bad news for lesser known sites that rely on the trust gained by having a valid SSL certificate (small credit unions, for example).

Because they’re a good CA, the StartCom team was immediately aware of my attempt to get a certificate for Verisign. I disclosed the details of the flaw to them, and the simple problem was fixed within hours. But the question remains: did anyone else take advantage of the flaw?

PKI is not a perfect system, and there is no perfect CA. But, there are at least two types of CAs. One type treats SSL certificates as a cash cow, pushing signed certificates out the door, and counting the money. The second type is like StartCom. This second type understands that trust comes before money and that trusted CAs are a critical piece of Internet infrastructure.

-Schmoilito

(cross post on Schmoilito’s Way)

Alex Sotirov, Jacob Appelbaum, and crew did some awesome work. They showed that it was possible to exploit RapidSSL’s use of MD5 for signing certificates in order to create their own rogue CA signing certificate. This exploitation is many orders of magnitude more severe than when I used a loop hole to get the login.live.com certificate from Thawte.

So what should happen when a CA screws up? Last summer, folks thought that the CA which issued the login.live.com certificate should have its status as a trusted CA revoked. I’m sure people feel the same way about RapidSSL. In my opinion, they are correct. However, it is clear that this could not happen, as it would effect the millions of businesses that rely on these CAs being trusted, which is what a VP at Verisign reaffirms in the comments of this post on the Breakingpoint blog.

A different question that Appelbaum asked during the presentation in Berlin, and one I’ve asked many times during my research of Certificate Authorities, is: if we were able to do this, how do we know if anybody else has done the same thing?

No one can ever give a straight answer. I’ve reported a number of flaws to CAs responsibly; flaws that can allow people to get certificates that they shouldn’t be allowed to get. The flaws get fixed, and thats great, but the damage that could have already been done is immeasurable.

It sucks when an online retailer gets hacked one or even multiple times. It’s bad for them, and it’s bad for their customers. When a trusted CA gets hacked, it sucks for the ENTIRE INTERNET. The CAs are supposed to help us secure the Internet. What does it mean if they are not secure themselves? To me, it means that we can’t rely on trusted third parties.

I know that abandoning PKI and trusted third parties is a bad idea, and probably won’t happen. However, people need to be more involved in the process of making trust decisions when communicating online. And I don’t mean little yellow locks and green address bars. I have some ideas on how to make better use of SSL in web browsers and other SSL clients. So far, I’ve gotten mixed responses to them from my peers However, with what the Sotirov/Applebaum team accomplished, maybe my ideas will make more sense. Stay tuned…

-Schmoilito

(cross post on Schmoilito’s Way)

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.

There seems to be a problem with Cross-Site Request Forgeries. It seems like a large majority of people have this type of attack confused and I am not just talking about developers or end users. Security professionals still don’t know what this attack vector is (and I’m not talking about higB’s tongue-in-cheek Balls post.) The other week I heard a webinar by a major Web Application Firewall vendor claim his product protected apps from XSS and therefore it was the same as stopping CSRF. Granted, maybe the product can try to prevent both types of attacks, but it sure isn’t going to do it with the same types of checks. This was followed by a web application security meeting where the slides were trying to show a CSRF example and the presenter talked about checking for XSS. If the people in the security industry can’t even get this right, how are we suppose to educate developers and clients about this issue?

Let’s all start by renaming this attack. While I personally like the name ‘OMG you stole all my money without JavaScript’, the more generic ‘Session Riding’ probably works better for the long term. Yes it’s a subtle change, but it states what the attack is doing and drops the unnecessary ‘cross-site’. I’ve also found that many people think scripting is required for a Session Riding attack. While there’s no doubt that you’ll typically find JavaScript included in crafting a complex or obfuscated attack, it’s clearly not a requirement. In fact, it’s one reason these attacks can be so terrifying is that you can browse with all scripting disabled, no third party components, dropped privileges and a fully patched browsers, but a Session Riding attack could still work against you.

I’d recommend reading this PDF and the CSRF FAQ which both go into good deal on Session Riding attacks and countermeasures. But for a quick difference between the two, just look at what your typical attack payload for an XSS attack verses a CSRF attack would be.

XSS Attack Payload:
<script>alert(‘xss’)</script>

Session Riding Payload:
http://www.example.com/changepwd.jsp?newpwd=1234&confirm=1234
 
While you typically need to store/reflect your XSS payload on the site you’re going after, in the case of a Session Riding attack, you can store this URL on any site. In this example payload, we are trying to change the user’s password. JavaScript would not need to be required. The site can be doing whitelist input validation and it wouldn’t stop this attack.

There are plenty of ways to protect against these attacks (CAPTCHA, re-entering password, additional secure tokens, …). Some of the popular web application frameworks even have settings or plug-ins that can be dropped in to prevent Session Riding attacks. However, if we don’t understand the risk or report the threat, how can we help developers to implement this correctly into their applications?

-b3nn

Download the Presentation:

 Hack Your Car – Defcon 15

Thanks b3nn (another phishme blogger) for being the video guy. We love the video: http://www.youtube.com/watch?v=D3hyzAD0q_c

Thanks for sending me to Vegas and giving away 100+ shirts: http://intrepidusgroup.com
Great site: http://www.osecuroms.org
Thank you to the enginuity team: http://www.enginuity.org
Thank you to all the hard workers and great forums at openecu: http://www.openecu.org

Special thanks once again to Tactrix for donating the hardware giveaways. These guys rock: http://tactrix.com

Nasioc of course: http://forums.nasioc.com/forums/forumdisplay.php?f=24

Water/Alc Injection information:
http://coolingmist.com/
http://www.alcohol-injection.com/
http://www.snowperformance.net/
http://www.aquamist.co.uk/

See you at next years DefCon!

–higB

I didn’t come up with the joke in the title but I nearly turned blue from laughing so hard while watching the now famous SNL TSA Security skit. (Catch it on YouTube if you haven’t seen it yet: http://www.youtube.com/watch?v=ykzqFz_nHZE)

If your job requires you to fly often, then you probably have some complaints about the TSA and security checkpoint lines. It’s probably the number one conversation between strangers at airports these days. Everybody can commiserate while swapping ridiculous stories.

If your job is to analyze and test security, then you probably have even more to say about the “appearance” of security vs. real security. One of best security minds blogs about airport security quite often: (Bruce Schneier http://www.schneier.com/cgi-bin/search/search.pl?Terms=tsa&Realm=blog )

Recently my Tartar Control Whitening Crest with Scope toothpaste was confiscated. This toothpaste must rank high on the banned substance list because it’s both a liquid and a gel (according to the label http://www.crest.com/products/liquidGels.jsp) I was quite distraught because this toothpaste is one of the most important tools for a security consultant. I’m trying to keep airports safe; instead of carrying both mouth wash and toothpaste, I can maintain minty freshness (and whiten teeth) in one compact package.

The problem is that the net weight is 4.6 ounces which is 1.6 ounces over the dangerous toothpaste limit. I didn’t think that was a problem because someone with a GED could use their eye-sight and see through the clear container noticing that I only had a third of this wonderful stuff left. WRONG! — I protested, it didn’t matter. “We go by what the container says sir” —

While later sitting down to tie my shoes on the Dulles airport people mover I looked up to notice what appeared to be a rather large gerber or spyderco knife clipped to the hip of an airport employee.

I wonder if I made friends with this guy if he could hook me up with some toothpaste. (Liquid or gel preferred.)

–higB

Welcome to http://blog.phishme.com – the home of rand(security)and technology discussions.

We will use this blog to comment on topics like cool phishing ploys, IM and its privacy implications, hacking cars, and bashing on (or bowing to) the latest application hacks. Security geeks and a love of technology go hand in hand so expect some commentary on general tech too.

We plan to post here at least once a week, so keep us on that RSS radar or keep visiting!

Thanks,

The Intrepidus Group Team

http://intrepidusgroup.com

Phishme.com was created by the Intrepidus Group.

Intrepidus Group is a leading provider of information security consulting services. To learn more about our company and our services, please visit our main site.

http://intrepidusgroup.com