Blog: Fortigate CVE-2023-27997 (XORtigate) in the eyes of the owl
Critical vulnerability in SMBv3 (SMBGhost / CVE-2020-0796)
Published on
SMB is an old Microsoft protocol recovered from IBM in the 90s and used, basically, to share files but also to execute commands.
It was formerly named Lan Manager (in IBM's time), then SMB (Server Message Block), renamed CIFS (Common Internet File System) and then SMB again with its version 2.0. Today, SMB is at its 3rd major version, bringing, among other things, the encryption of flows. Yes, before SMB 3.0, released in 2018, the streams were in clear text, thanks to Microsoft 🤦♂️: https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-security
SMB is mostly known for being a risky protocol and is infamous for being the propagation vector of the WannaCry (based on the MS17-010 vulnerability also called EternalBlue) and NotPetya worms.
Globally, SMB 1.0 is full of vulnerabilities (for the most recent one: EternalRomance/EternalSynergy/EternalChampion) and it is very strongly recommended to disable it wherever possible, which can be complicated with printers, scanners, some antivirus servers....
SMB 2.0 is barely better and SMB 3.0, I let you read the title again 😉.
The SMBGhost / CoronaBlue / CVE-2020-0796 vulnerability
On Tuesday, March 10, 2020, the blog a Talos (Cisco's research team) published an article announcing Microsoft's new monthly security patch bulletin, including the CVE-2020-0796 vulnerability a little too early in these words:
"CVE-20200796 is a remote code execution vulnerabilityIn Microsoft Server Message Black 3.0 (SMBv3). An attacker could exploit this bug by sending a specially crafted packet to the target SMBv3 server, which the victim needs to be connected to. Users are encouraged to disable SMBv3compressionand block TCP port 445 on frewalls and client computers. The exploitation of this vulnerability opens systems up to a "wormable" attack, which means it would be easy to move from victim to victim."
Simple translation: SMBv3 is vulnerable to remote code execution without authentication, making this vulnerability usable by a worm to spread (WannaCry, NotPetya and other such happy worms).
Except that the bulletin in question did not fix this vulnerability, which sent the security community into a tizzy, looking for this vulnerability regarding compression on SMBv3. Once the error was discovered, the article was corrected but too late:
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...
