Return of Bleichenbacher's Oracle Threat | Hacker News Reader

Return of Bleichenbacher's Oracle Threat

robotattack.org

134 pointshannob15 comments

Want to understand this attack better? We'll walk you through it in the Matasano Crypto Challenges:

http://cryptopals.com/sets/6/challenges/46 (and 47, 48).

Bleichenbacher's RSA oracle --- some people call it BB'98 --- is the RSA equivalent of the best-known real-world attack on crypto, the CBC padding oracle. The math behind the exploit is a little trickier (it's 10th grade algebra, plus the very basic finite field stuff you'd get in a single decent blog post on how RSA works) but it's otherwise mechanically pretty similar.

The basic idea is: the client sends the server messages; it can send any message it wants, valid or not. The server processes those messages. In doing so, it causes the message to interact with the server's private key. Once that interaction happens, any observable behavior the server exhibits can be used to infer things about that key. In the case of a padding oracle: send random messages; see if you can detect the padding validation error from the server. Based on that one signal, establish new bounds for the key.

This paper is pure Hanno Böck. His M.O. is straightforward and awesome. Take a crypto vulnerability everyone assumes has been eradicated for years, especially on serious hosts. Now, here's the tricky part: scan the Internet for it. Oh, look: it's everywhere. Including CISCO.COM and FACEBOOK.COM and a gajillion F5 devices.

Want to put the skills you learned from those challenges to good use?

There's also a CTF at https://ctf.robotattack.org

> Take a crypto vulnerability everyone assumes has been eradicated for years

I wish!

https://twitter.com/veorq/status/683360050199552001

> Bitcoin does not use RSA, instead it uses elliptic curve cryptography based on the curve secp256k1. Our attack cannot be directly applied to that. However if you transform a quantum key exchange to a supersingular Isogeny you can attack post-quantum RSA and thus apply our attack indirectly to secp256k1.

Can someone translate this? I don't understand how this attack would apply to Bitcoin even if it did use RSA since there's no server accepting or rejecting messages based on a private key.

It's definitely an infosec current events buzzword bingo joke.

J.o.k.e.?

Haha, ok, should have guessed.

Anyone else get this when using the test server feature?

Host xyz.zyx added to queue.

It can take a few minutes till the test is finished. This page will be automatically reloaded.

But then the page never actually reloads?

Sorry, this was all created in a rush. I must have removed the reloading metatag.

At the moment the queue is overfull anyway... I will make sure I improve this tomorrow, in the meantime download our tool, use testssl.sh or use the ssllabs dev test.

Hey, thanks for the reply. Will do!

For whatever it's worth: if you're using a standard TLS stack --- Amazon's, or a stock OS distro's packaging of OpenSSL, or OpenSSL built from source, or Golang, or even at this point Java's TLS, which had this bug a few years ago and now has been pretty well tested --- it is vanishingly unlikely that you have this problem.

The things you want to test are sites behind middleboxes and sites with custom TLS implementations.

Yes.

The page has no javascript whatsoever, and no <meta> refresh. It can't reload itself. Manually reloading the page for hosts that have been in the queue for more than an hour yields no change. Does anyone have any evidence the test server feature does anything at all?

Does this attack affect the security of RSA-based SSH keys, or is it TLS-only?

Protocol 1.5 had BB98 vulnerabilities. I believe modern SSH uses RSA just to sign.

I wonder how many times it's coming back before people will actually start to put some thought (or learning) into design of things that involves a lot of un-obvious considerations?

Reply on news.ycombinator.com