×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Null-Prefix SSL Attacks Enabled In New sslsniff

timothy posted more than 4 years ago | from the ready-or-not-here-it-comes dept.

Security 48

An anonymous reader writes "Moxie Marlinspike, who recently published new attacks on SSL at Defcon 17, seems to have released the new version of sslsniff which supports these attacks. While the release appears to coincide with a patch from Mozilla, every product that uses the Microsoft CryptoAPI is still vulnerable, including Internet Explorer and Outlook. The new version of sslsniff also supports built-in modes for hijacking software auto-updates that depend on SSL, and apparently includes techniques for defeating OCSP as well — making the elimination of existing null-prefix certificates difficult."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

48 comments

Just to make things easier in the future (-1, Flamebait)

Rosco P. Coltrane (209368) | more than 4 years ago | (#28940395)

every product that uses the Microsoft CryptoAPI is still vulnerable, including Internet Explorer and Outlook

Every product that uses the Microsoft [insert name here] is still vulnerable, including Internet Explorer and Outlook.

Re:Just to make things easier in the future (0)

Anonymous Coward | more than 4 years ago | (#28940491)

Every product is still vulnerable.

FTFY

fp (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28940417)

ladies, get your pussies ready!

Re:fp (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28940657)

Troll? Dude wants to sniff moxie's trim. Do the moderators know what this article is about?

SSLSniff? (0)

Anonymous Coward | more than 4 years ago | (#28940421)

Sniffing SSL isn't good for your nasals

Appears to coincide.. (4, Insightful)

sys.stdout.write (1551563) | more than 4 years ago | (#28940537)

appears to coincide with a patch from Mozilla

If some guy waited until Microsoft fixed a vulnerability to release a patch, but not before Mozilla fixed the patch, then we would all be crying foul.

Since it's the other way around, nobody will have a problem I'm sure.

Re:Appears to coincide.. (4, Funny)

sys.stdout.write (1551563) | more than 4 years ago | (#28940557)

And by "fixed the patch" I mean "I'm retarded".

English is hard.

Re:Appears to coincide.. (0)

Anonymous Coward | more than 4 years ago | (#28941579)

Don't beat yourself up. I still didn't get what was wrong with the wording in that other story summary "a bit faster, ... 5 times less power, ... 10 times cheaper."

Re:Appears to coincide.. (0)

Anonymous Coward | more than 4 years ago | (#28946803)

"5 times less" makes absolutely no sense. The most valid interpretation I can think of would be A - 5A = -4A. Five times than something is four times its negative. Similarly, "2 times more" or "200% increase" means A + 2A = 3A, or triple the original value, whereas "Twice as many" or "Twice as much" clearly means 2A.

I think using the word "times" in this context is rather slangy and ambiguous. I wish they never taught it to me in grade school.

Re:Appears to coincide.. (1)

Kurusuki (1049294) | more than 4 years ago | (#28940617)

If one waited until Microsoft fixed a vulnerability we'd be waiting until Hell is ordering winter parkas

Don't forget the time machine (1)

someone1234 (830754) | more than 4 years ago | (#28943907)

And it would require some kind of time machine to jump back before Mozilla fixed the same vulnerability.

Re:Appears to coincide.. (0)

Anonymous Coward | more than 4 years ago | (#28940903)

I'm curious if this exploit also affects non-browsers such as wget and repository package managers.

Re:Appears to coincide.. (3, Interesting)

BasharTeg (71923) | more than 4 years ago | (#28941271)

You're absolutely right. If this guy didn't inform anyone except Mozilla, he's bringing browsers wars to a new low, by being willing to expose a majority of web users involved in e-commerce and other "secure" online access to his vulnerability for whatever the lead time of patching is, but exempting users of his favorite browser. IF that's what he did, that's ridiculous, childish, and petty.

What about all the other vendors of SSL dependent software? SSL based VPNs like OpenVPN for example. No love for them either? Just Mozilla?

It shows how people like Dan K are smart enough to recognize major vulnerabilities that can potentially affect massive amounts of service/traffic/commerce need to be handled differently. It doesn't reduce the respect you gain as a security researcher for finding such a major flaw to give vendors notification in a reasonable time period before publication. I'm all for full disclosure as a means of punishing companies that don't respond, but for larger vulnerabilities I think notification and a deadline are the way to go.

Re:Appears to coincide.. (1, Informative)

Anonymous Coward | more than 4 years ago | (#28941703)

If this guy didn't inform anyone except Mozilla...

From the security advisory at Mozilla [mozilla.org]

Mozilla would like to thank Dan and the Microsoft Vulnerability Research team for coordinating a multiple-vendor response to this problem.

Looks like MS was informed (as they certainly should have been), just considerably slower on the fix (imagine that?). How long should have Mozilla waited before releasing their fix? Until after Windows 7 ships and MS decides they can afford some dev cycles to go patch WinXP?

Re:Appears to coincide.. (1)

John Hasler (414242) | more than 4 years ago | (#28941915)

According to the article Dan K was one of the people who discovered the flaw. Why do you assume that Microsoft and others weren't notified months ago when Mozilla was?

Re:Appears to coincide.. (4, Informative)

gnasher719 (869701) | more than 4 years ago | (#28942001)

You're absolutely right. If this guy didn't inform anyone except Mozilla, he's bringing browsers wars to a new low, by being willing to expose a majority of web users involved in e-commerce and other "secure" online access to his vulnerability for whatever the lead time of patching is, but exempting users of his favorite browser. IF that's what he did, that's ridiculous, childish, and petty.

Reading the article, there seemed to be a good reason to inform Mozilla first, because they were the most vulnerable. Apparently, to spoof say Internet Explorer, you need a certificate for "www.ebay.com\0.evilhackers.com", one for "www.amazon.com\0.evilhackers.com" and so on, but to spoof Mozilla-based browsers, a certificate for "*\0.evilhackers.com" will be accepted for _every_ site in existence.

Re:Appears to coincide.. (1)

Benfea (1365845) | more than 4 years ago | (#28947909)

I refuse to accept your answer! You are clearly part of the conspiracy against Microsoft! *chews on carpet*

Re:Appears to coincide.. (1)

Ingenium13 (162116) | more than 4 years ago | (#28943329)

OpenVPN wouldn't be affected by this. Unlike a browser, it doesn't go fetch a certificate and verify it against the domain name of the server; instead, the client already has the certificate and compares it to the server's certificate. In other words, OpenVPN's certificates aren't based on domain names. I'm pretty sure other SSL based VPNs are the same.

Re:Appears to coincide.. (2, Insightful)

John Hasler (414242) | more than 4 years ago | (#28941857)

Evidently Mozilla was notified as early as February. What makes you think that Microsoft wasn't notified at the same time?

Winning combination (5, Funny)

Norsefire (1494323) | more than 4 years ago | (#28940567)

Excellent technical skills, interest in hacking and a name that no security department will take seriously.

Re:Winning combination (5, Funny)

MyLongNickName (822545) | more than 4 years ago | (#28940819)

Moxie Marlinspike? I thought we had a new Ubuntu release. And I was wondering what happened to the L's.

Re:Winning combination (0)

Anonymous Coward | more than 4 years ago | (#28951083)

Oh, you fucking bastard, you made me crap my pants.

linux spell check? (0)

Anonymous Coward | more than 4 years ago | (#28940573)

does linux have a spell check? "atttacks"?

C null-terminated string brain damage! (1)

morgan_greywolf (835522) | more than 4 years ago | (#28940713)

Gotta love that C null-terminated string brain damage!\0Heh. Stupid fsckers will never see this!!!

Re:C null-terminated string brain damage! (1)

bill_mcgonigle (4333) | more than 4 years ago | (#28947147)

Gotta love that C null-terminated string brain damage!\0Heh. Stupid fsckers will never see this!!!

Yay, Slashdot is written in perl. ;)

Say what you will about CryptoAPI (0)

Anonymous Coward | more than 4 years ago | (#28940729)

... it's a hell of a lot easier to use than OpenSSL.

Re:Say what you will about CryptoAPI (0)

Anonymous Coward | more than 4 years ago | (#28940843)

Dude, OpenSSL is so much easier. I write my own openssl.conf files from scratch. I'm hardcore.

Re:Say what you will about CryptoAPI (0)

Anonymous Coward | more than 4 years ago | (#28941007)

Careful with that. You forgot all the:

This post includes cryptographic software written by ...

Re:Say what you will about CryptoAPI (1)

DarkOx (621550) | more than 4 years ago | (#28947519)

What planet are you on? CryptoAPI is only easier if all you want is the most basic web server certificate functions. As soon as you start wanting to do any custom subjects or anything else even slightly outside the the nine dots CryptoAPI is a confusing mess.

Protocols (2, Interesting)

ledow (319597) | more than 4 years ago | (#28940745)

Just wondering... will this help analysis of some "secured" protocols, maybe?

I don't know how it works, but let's say something like Steam uses SSL or similar (I have no idea if it does, just pretend)... before we couldn't do the protocol analysis without a massive reverse-engineering going on (could only see "client to server" messages because we only have access to the client's private key). Now we might be able to fool non-patched SSL programs to believe that they are talking to an authentic server without having to delve into their code and thus be able to see / fake both sides of the conversation?

Am I way off the mark, or is this now possible with unpatched programs relying on SSL etc. layers to hide their protocols?

Re:Protocols (1)

nxtw (866177) | more than 4 years ago | (#28940937)

If the program uses a known API for encrypted communication and is linked dynamically, one could simply provide a shared library/DLL that copies the unencrypted messages... the API implementation used doesn't even have to be open source, as one could just write an intermediary library that implements all the functions of the original and copies the data before calling the original library.

If the program dynamically links to an open-source library for encryption, or runs on Wine, you can just modify the implementation.

Yeah, right (2, Interesting)

FranTaylor (164577) | more than 4 years ago | (#28941251)

That is the first thing they think of. You can bet your lunch money that they statically link their crypto library, and then obfuscate the binary for good measure.

Re:Yeah, right (2, Interesting)

greed (112493) | more than 4 years ago | (#28946445)

Mua-ha-ha-ha.

I've run into one of those annoying runtime licensing systems that not only uses out-of-the-box static build of OpenSSL in its code, it's an older version, too.

Unobfuscated. With all the original OpenSSL symbol names. But they don't provide _all_ of OpenSSL, so you can't just use their old & busted one.

Yes, this causes a serious multiple-definition problem if you want to use that library in an SSL application.

Their "fix"? "Remove these filenames from the .a file we sent you. And these ones. And these, too."

dot your i's and cross your t's (2, Funny)

kronosopher (1531873) | more than 4 years ago | (#28940767)

.. even extra unnecessary ones.

Is an "atttack" anything like an "attack"?

The actual paper (4, Informative)

Anonymous Coward | more than 4 years ago | (#28940999)

Here's a link to the actual paper on the topic:
http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf

Interesting, but not exactly new (1)

BillX (307153) | more than 4 years ago | (#28951559)

He found that if he created certificates for his own Internet domain that included null characters -- often represented with a \0 -- some programs would misinterpret the certificates.

That's because some programs stop reading text when they see a null character.

This is the same exploit used in an older Nintendo Wii jailbreak [marcansoft.com] - people just keep on using strcmp and its cousins to compare hashes.

Three parts to this (1)

pclminion (145572) | more than 4 years ago | (#28951599)

I saw Moxie's talk at BlackHat. Extremely good presentation. There are three things necessary to carry out this attack:

1. You need to convince a CA to sign your CR when you have a \0 in the common name.
2. You need to target a browser or other application that uses a vulnerable certificate parser.
3. You need to be able to execute a MitM attack.

And of course, there's a weak "4":

4. You need to be able to forge the OCRP "Try later" response, which is trivial since you're already "in the middle."

As far as part #1, the CAs have been informed, and no longer will sign a CR where the common name has a \0 character. But there may be (in fact, definitely are) null-prefix certificates in the wild which were created before this issue was widely known
As far as part #2, the application teams are scrambling to fix their implementations
As far as part #3, the various MitM methods are well known and not specific to this attack
As far as part #4, the OCRP protocol is terminally brain dead and needs to be chucked out the window, or at least revised such that all of the valid response codes require a signature payload to authenticate that the OCRP response is actually from a legitimate CA

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...