Vulnerable SMB Protocol - Beyond WannaCry

By now everyone in Security domain should've gained enough insights of WannaCry Ransomeware. In this post lets talk technical what makes WannaCry work, Although I don't want to take you through vulnerability analysis but at high level picture of the issue and its mitigations.

SMBv1.0 very old protocol we shouldn't really blame Microsoft for this bug because those days getting things done really matters without security approach, but we should blame them for not opting out from such old protocol for these many years.

What makes it so special than other vulnerabilities ?

May be day-by-day people are getting more conscious towards security. Social media and viral message forwards are seriously playing their role in creating awareness.

NSA leaks has all exploits which are being used in different variants of the malware nothing new everything was pubic before worm entered space. Also, it's quite possible to expect a worm like WannaCry post leak, as vulnerability was related to SMB which can be easily exploited remotely.

As always reactive approach from Microsoft, came up with patch in March (thanks to Microsoft; without you there is no security business).

SMB Negotiation & Detecting SMB v1.0:

1. The client and server establish a NetBIOS session.
2. The client and server negotiate the Microsoft SMB Protocol dialect. Client says these are the dialect supported by me. Server choose the best out of what client supports and establishes communication channel.
3. The client logs on to the server.
4. The client connects to a share on the server.
5. The client opens a file on the share.
6. The client reads from the file.

It's as simple as other protocols right ? Lets see request in Wireshark to get clear picture..

In above picture client initiated an SMB Negotiation and says I support SMB till dialect NT LM 0.12 which means at max SMB v1.0 :-)

Left with nothing just one option ... Yes looks malicious. To understand better, I've included other request with all dialects from non-malicious client request for your reference. In this case may be client could be old version of windows which just support SMB v1.0 or malicious EternalNSA Exploit.

Non-Malicious or latest OS would send negotiation request as shown below:

Now innocent server will respond to this request selecting SMB v1.0 as shown below:

And now attacker will come to know SMBv1.0 is enabled on the machine & might try exploiting it.

What makes protocol vulnerable ?

MS17-10 actually addresses more than one problem, however as it was all about SMB protocol vulnerability it was projected as one. I got chance to go though detail vulnerability here listed was high level summary of analysis:

Attacker need to detect SMB v1.0 to exploit this vulnerability as it exists in protocol implementation.

Create pipe & has to write data to pipe, for example using the Write AndX SMB command.

And now attacker has to set AC_WrittenData value saying these many bytes are written over the pipe & these value leaves protocol vulnerable by triggering buffer overrun, when crafted with malformed large value.

You can control these values using MaxParameterCount from TRANS_PEEK_NMPIPE command of SMB.

Upon receiving a TRANS_PEEK_NMPIPE command, Windows kernel calls srv!SrvPeekNamedPipe to process it. A remote attacker could exploit this vulnerability by sending crafted SMB messages to a target server.

NSA Eternal tools exploits same protocol vulnerability reliably using multiple techniques on different flavours.

Recommendation ?

Disable SMBv1.0, patch it :-)

FAQS:

If patched then why still disable ?

It’s 30+ years old protocol where Microsoft has itself has recommended to disable couple of years back. Recently, a famous hacking group has claimed that they have identified vulnerability in windows which could comprise windows remotely. The best guess for this vulnerability would be SMB v1.0 as its too old and ships default with fresh install copy of Windows.

If disable SMB v1.0 then why to patch ?

Problem exists in srv.sys its kernel driver where we now knew that SMB v1.0 is using particular function which has problem or vulnerability, that can be remotely exploitable. But being system function there might be chances of calling same function from other programs as well.

WannaCry affects 2008 and below, then why patching 2008 above ?

Problem exists in kernel drivers and all flavors of windows carry these drivers till 2016 to maintain backward compatibility. However due to mitigation techniques & complexity of taking control over latest operating system's exploit mitigation techniques it was very difficult. But actual vulnerability still exists in protocol, at this moment it just not exploitable.

So to stay abreast of vulnerability before we getting exploited it is recommended to patch all OS till 2016.

We've many vulnerable machines why nothing was affected with this worm ?

We never know as WannaCry was wild people learned about it and also primary motivation was to make quick money. There might be other worm targeting for some other reason had already exploited your machine with some other motivation, mining some bitcoins in your network :-)

Also worm initially targeted through Internet only, which will scan for 445 port on public infrastructure and then check for vulnerable SMB server to exploit, once infected it will move laterally within the network to spread, this was one hinder that worm has, as public infra was mostly closed over 445 due to security awareness & malware researchers alert news moved faster than actual worm ...

My machine is running with least privilege user I'm still vulnerable ?

Yes you are. SMB server runs with System privileges and can be remotely exploited, once exploited any piece of code (a.k.a shell code) invoked within this vulnerability will ran with same privilege as SMB Server. So as combo offer exploiting this will give attacker high privilege as well.

Can I just remove server component to mitigate ? I don't want to remove SMB v1.0 client functionality as I need to communicate with 2003 Servers.

SMB has both client and server components in this case server module was vulnerable. You can just disable server following MS guidelines here. Once disabled SMB v1.0 client requests will be ignored for negotiation from server and will not be exploited with this particular vulnerability, doing this will let your SMBv1.0 client work without any issue. However, its highly recommended to go for patch.

Reference:

https://www.ericconrad.com/2017/04/shadowbrokers-pcaps-etc.html

https://technet.microsoft.com/en-us/library/security/ms17-010.as