SambaCry, the Seven Year Old Samba Vulnerability, is the Next Big Threat (for now)
Overview
The Samba team released a patch on May 24 for a critical remote code execution vulnerability in Samba, the most popular file sharing service for all Linux systems. Samba is commonly included as a basic system service on other Unix-based operating systems as well.
This vulnerability, indexed CVE-2017-7494, enables a malicious attacker with valid write access to a file share to upload and execute an arbitrary binary file which will run with Samba permissions.
The flaw can be exploited with just a few lines of code, requiring no interaction on the part of the end user. All versions of Samba from 3.5 onwards are vulnerable.
As Samba is used as part of many organizations’ storage systems, we expect a ransomware attack to take advantage of the flaw in the near future.
Next we will discuss the impact of the vulnerability on organizations and home users, compare between this server side vulnerability and the WannaCry vulnerability and provide detection and mitigation steps.
Samba by Numbers
|
Who is affected?
Many corporate network storage systems (NAS), home routers and other IOT devices run Samba for file sharing. Some are accessible only from within the network, while others are also exposed to the internet. At the moment there are over 110,000 internet accessible devices that appear to be running vulnerable versions of Samba.
Every device running Samba with writable file shares and weak passwords is at risk. These devices can then be exploited by attackers to hold entire file servers for ransom, exfiltrate data or move laterally inside a network.
SambaCry vs WCry
Comparison to the Windows flaw that the WannaCry ransomworm exploited earlier this month is inevitable. The vulnerability exploited by WannaCry (EternalBlue) is also more than five years old, resided in the widely used SMB protocol and allowed code execution without requiring end users to do anything to trigger it.
However, there are also distinct differences between the two. The most important is the fact that EternalBlue was a pre-authentication vulnerability while the Samba vulnerability requires the attacker to have valid credentials to a writable share, reducing the likelihood that it will be ‘wormable’. However, a post breach attacker is likely to obtain the required credentials, providing an incredibly versatile platform for lateral movement.
While detecting and remediating EternalBlue was made simple for many reasons such as the DoublePulsar backdoor, detecting exploits using this new Samba vulnerability is far more complex. Since exploiting the Samba vulnerability is trivial, we expect to see a wide variety of exploits.
What you should do to protect your network
Patching
Samba has provided a patch for versions 4.4 onwards: https://www.samba.org/samba/history/security.html
Guardicore detection script
We’ve created an nmap script which will help you scan your network for potentially vulnerable Samba servers. The script is very easy to use, just run:
nmap –script gc-SambaCry.nse -p445
Usage example:
nmap –script gc-SambaCry.nse -p445 10.0.1.159
Scripte output:
Starting Nmap 7.40 ( https://nmap.org ) at 2017-05-26 20:11
Nmap scan report for 10.0.1.159
Host is up (0.0010s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| gc-SambaCry:
| State: POTENTIALLY VULNERABLE
| Samba-vuln-CVE-2017-7494
| Summary: Remote code execution from a writable share.
| Description: The Samba vulnerability (CVE-2017-7494) enables a malicious attacker with valid write access to a file share to upload and execute an arbitrary binary file which will run with Samba permissions.
| Affected Version: All versions of Samba from 3.5.0 onwards.
|For more info: https://www.guardicore.com/2017/05/samba/
Nmap done: 1 IP address (1 host up) scanned in 3.84 seconds
Workaround
If your Samba server is vulnerable and patching or upgrading is not an option, there are two main workarounds:
1) (the official advisory) Add the following line to the Samba configuration file:
nt pipe support = no
Then restart the network’s SMB daemon (named ‘smbd’). The change will disable some expected functions for Windows machines.
2) Use SELinux policy to prevent execution.
For example, RHEL’s default policy prevents exploitation.
If you’re not using Linux distribution with activated SELinux, a simple mitigation would be to mount the file system hosting writable shares with a “noexec” option.
