'Bar Mitzvah attack' should see off ancient and crocked RC4 algo Security boffin Itsik Mantin has found a new attack based on old weaknesses that is the first 'practical' attack on SSL that does not require man-in-the-middle to steal sensitive data from RC4 algorithms. The Imperva bod's research reveals a 13 year-old weakness in the superseded algorithm, which is known to be insecure but is …
...just another undocumented feature. Just ask the designer.
Tickled me that they're now enforcing SSL for connections to their website. I bet that raises a few smirks there too. ;)
What I can't help wondering is... are we all expected to go on pretending that, just because they haven't been publicly unpicked yet, all the other, more recent NSA NIST recommendations are secure? Shirley not!([1],[2],etc...) Yet there would appear to be something of a PR campaign going on to achieve that! How quaint.
[1] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
[2] http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all&_r=1
The article fails to mention how the attack came to be dubbed the Bar Mitzvah attack, but the linked Dark Reading article does: It's because the vulnerability is 13 years old; I don't know (and can't be arsed to look up) the meaning of the term, but I know it's a Jewish term relating to boys once they are 13 - so there's the basic reason for the name.
However, as names for such things go, it's a bit crap, really.
POODLE - sounds fluffy and cute, but it's all in caps* so it must be REALLY BAD.
BEAST - not only is it all in caps* and therefore REALLY BAD, it's a word that itself is meant to be scary.
CRIME - again, all in caps*, so REALLY BAD, and a word with negative connotations.
Then there's the Bar Mitzvah attack.
Nah. Not good enough. Alternative suggestions:
UNLUCKY 13
TEEN TERROR
* Granted, the real reason for the caps is that they're acronyms. Just pretend not to realise that...
I know and like RC4 and while I was aware of the weak-keying issue, that can be mitigated when choosing the initialization vector (or if using the algorithm as a proper stream cipher, rather than a block cipher as it was in WEP).
The "L shaped pattern" described in the PDF is a new one on me, even though it was apparently described in the same paper 13 years ago. Not sure it's a home run however, it still relies on a (larger) class of weak key, and (if I've read that paper right) the best case is those are only 1 in 2^16 of sessions. So an individual RC4 encryption is likely still fine, it's only when there are millions of them that one becomes statistically likely to fail. The odds of that one having a password, credit card or whatever are still low.
So I'm not going to panic just yet.
So an individual RC4 encryption is likely still fine, it's only when there are millions of them that one becomes statistically likely to fail. The odds of that one having a password, credit card or whatever are still low.
Agreed, but - as always - the threat has to be evaluated against a threat model. The paper specifically suggests using the vulnerability for session hijacking, for example. If the attacker is in a position to passively sniff a lot of RC4-encrypted sessions against a busy site, and make use of hijacked sessions, and automate the whole thing (obviously), it could be a credible threat.
It also notes that accounts with commonly-used passwords could be particularly vulnerable because a password table grouped by LSB greatly decreases the number of passwords that have to be attempted. So attacker sniffs a lot of traffic, detects weak keys (the paper notes how this can be done with good probability), and then later does active attacks using passwords from the appropriate subset. That requires a fair bit of additional exposure to work: the attacker needs other information (eg account name) and the attacked system needs a sufficiently liberal password-attempt policy. But it's not outside what's believable.
I've suggested before on Reg forums that the "RC4 must die now!" argument is a little too broad; that lots of traffic isn't valuable enough for anyone to bother attacking it, that probability of success is still low, that RC4 has other applications that it's still suitable for. But clearly the recommendation to use AES-GCM for session encryption (and one of the PFS EC key-exchange ciphers) is the more cautious position.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
