Security hysteria in an example: SMBv1 vs the world.

Security hysteria in an example: SMBv1 vs the world.

The ETERNALBLUE vulnerability as provided generously by the ShadowBrokers group exploited a flaw in the SMB protocol version 1 (SMBv1) implementation of Windows family of operating systems. When news broke, many vulnerability scanners *cough* Nessus *cough* highlighted mere support of SMBv1 as a critical risk*. Microsoft then aggressively started pushing out recommendations (which were amplified by the usual Twitters and blogs) that SMBv1 is really bad and should be disabled  and if not disabled then gremlins will come and eat your lunch.

But what is the risk? The post on TechNet "Stop using SMB1" summarises all the good and bad features of protocol versions 1, 2 and 3 and the bad things when version 1 is compared to version 2 is *drumroll* use of MD5 in message authentication. That's it. Practical (and by this I mean a skilled pentester can do this quickly) attacks against MD5 are rare and require serious pre-computation and special conditions. Now, there are arguments that versions 2 and 3 are simply more efficient, but in that case client and server will negotiate the highest version and enjoy the better performance. So why the hysteria? A possible and implied message from Microsoft is "The SMBv1 code is a jungle and sucks, we tried auditing but after half a day of exposure, the auditor started chanting Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn while half naked" in the cafeteria, so we gave up". The ETERNALBLUE exploit was technically brilliant and novel and required very careful heap massaging to exploit it. It wasn't something Y2 CompSci students in their spare time are likely to discover and create a 50/50 exploit.

To sum it up, other than the general concept of reducing attack surface by disabling seldom used code, SMBv1 support is a hysteria and Microsoft's decision to not enable it by default in Win 10 must have cost enterprises and regular users hours of support costs and lost productivity.

"But wait!", you'll say, "what about v2 vs v3 protocols?". This is where it gets ugly. You see, only with version 3 (Windows 8 and 2012 onwards) the contents are encrypted. That's right, for last 30 odd years, file sharing in Windows world was not encrypted - if you were on insecure wifi or someone was MiTMing you, recovering files from data stream was a child's play. No security scanner seems to alert on this, no one ever wrote in their reports this: "Hey there, it seems you use the basic Windows file sharing, you do know it's insecure?", yet everyone wrote: "gee-whiz, that SSLv2/3 protocol can be intercepted and if stars align just-right, you might get some clear text traffic" or "look, telnet and rexec, this is bad, can capture traffic!". 


So why doesn't Microsoft say: "please disable SMBv2, we ballsed up there too, sorry!"? Because the amount of systems that speak only v1 or v2 is really big (see here for those that speak only v1) and if that message - v2 sucks as well - would be parroted on twitters, it would make an awkward conversation. 

To be clear then: in majority of situations, the file sharing that you use sends files in clear text across your network and no one has done anything about it. Dear infosec folk - please stop hyping up scary stories, do risk analysis and compare it to already accepted risks.


Now get off my lawn!



* to be clear, if SMBv1 support was disabled in Windows systems, then the vulnerability could not be exploited so therefore it was a useful mitigation at the time - disable SMBv1 support and be not affected.





It’s a circus and “security practitioners” are clowns.

要查看或添加评论,请登录

Konrads Klints的更多文章

社区洞察