We didn't have to wait long to see the appearance of tools allowing to identify potentially vulnerable systems and ... exploitation codes, the first of which was made public on Saturday March 14, 2020: https://www.exploit-db.com/exploits/48216avec the code here: https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/48216.zip
This vulnerability is an integer overflow due to two 32-bit values that the client (and thus the attacker) controls: a size (OriginalCompressedSegmentSize ) and a memory position (OffsetOrLength). These two values are added together and copied into a new 32-bit integer used to perform an allocation, allowing this integer overflow. Here is a detailed article from Synacktiv about this vulnerability: https://www.synacktiv.com/posts/exploit/im-smbghost-daba-dee-daba-da.html
Note that integer overflows are generally easy to identify but complex to exploit.
Detect SMB 3 and compression activation, remotely
Here is an open source tool to remotely identify if services are potentially vulnerable: https://github.com/ollypwn/SMBGhost
This can also be done with a simple* nmapdetecting SMB 3.11: nmap -p445 -script smb-protocols -Pn -n subnet-a-scanner-ici-or-single-address-ip | grep -P '\d+|^\d+|. | tr 'Nmap scan report for' '@' | tr '@' '\n' | tr '|' ' ' | tr '' ' ' | grep -oP '\d+\d+\d+.\s+3.1.1||.\s+3.11' | tr '\n' ' ' | tr 'Nmap scan report for' '@' | tr '@' '\n' | tr '|' ' ' | tr '' ' ' | tr '_' ' ' | grep -oP '\d+\d+\d'
- well... when I say simple, it's a bit exaggerated 😉
You can also use SMBMap (usually used for offensive purposes 😉 ) which allows you to simply list SMB shares and associated rights, but it is rather dedicated to be used on an internal network: https://github.com/ShawnDEvans/smbmap
You can finally search in your Active Directory with a PowerShell command like: Get-ADComputer -LDAPFilter "(|(operatingSystemVersion=10.0 \2818362\29) -Properties operatingSystemVersion,operatingSystem
Solution
Following this communication error, Microsoft had to publish a workaround method consisting in disabling the compression, in PowerShell locally: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\ServicesLanmanServerParameters" DisableCompression -Type DWORD -Value 1 -Force
Microsoft proposed an article to detect (locally) and disable SMB 1 to 3: https://docs.microsoft.com/en-gb/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3
But in front of the risks, they ended up releasing the patch "out of band", i.e. outside the monthly security patch release cycle: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796
So I recommend you to: identify, analyze the risks, correct or disable or partition.
The ANSSI has also published an article full of common sense and which repeats what we have been saying for ages: NEVER EXPOSE SMB services on the Internet.
https://www.cert.ssi.gouv.fr/alerte/CERTFR-2020-ALE-008/
They also point out that even internally, SMB streams should be blocked. These recommendations are so aligned with what we have been saying for years, that I'll copy them:
- Prohibit all SMB flows on ports TCP/139 and TCP/445 in and out of the Information System 2 ;
For internal partitioning: only allow SMB flows when necessary (domain controllers, file servers, etc.) and block this flow between workstations;
- For mobile workstations: prohibit all incoming and outgoing SMB flows and only allow these flows to SMB servers through a secure VPN [3]4.
- Except that with Azure, you may have many SMB services exposed without knowing it.
For PaaS solutions, Microsoft takes care of hardening configurations and applying security patches, but for IaaSc it's up to you to identify, analyze and correct (see tools above in addition to your Azure console).
We are saved!
Everything is identified and fixed, are we saved? Not so sure.
As HTTP has become a transport protocol supplanting TCP (with crazy overheads!), QUIC, now HTTP/3, allows to transport SMB: https://techcommunity.microsoft.com/t5/itops-talk-blog/smb-over-quic-files-without-the-vpn/ba-p/1183449
QUIC is an optimized implementation of HTTP in UDP, benefiting from all the advantages of HTTP/2, becoming a binary protocol and no longer text.
Microsoft's idea is that to access files in SMB, you have to set up VPN tunnels, which is complex. With Azure and Office 365, they will implement SMB access through HTTP/3, taking advantage of the authentication capabilities of this protocol (including strong authentication), encryption (with TLS 1.3) and SSO.
Why not do away with SMB and develop a modern, elegant solution, rather than taking an old protocol and adding extra overhead? Good question 😉.
SMB insecurity has a long way to go...
