SambaCry, the Seven Year Old Samba Vulnerability, is the Next Big Threat (for now)

/in /by Ravit Greister






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 organisations’ 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 organisations and home users, compare between this server side vulnerability and the WannaCry vulnerability and provide detection and mitigation steps.

Samba by Numbers

  • The Samba vulnerability is 7 years old
  • The vulnerability affects all versions of Samba from 3.5 onwards
  • Samba 3.5, the version that introduced the flaw, was released in March 2010
  • At least 110,000 devices exposed on the Internet run vulnerable versions of Samba

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.

.

Fill in your details to get the detection script

4 replies
  1. Saam
    Saam says:

    There is potential false positive possibility while using this script against Redhat enterprise server v6 based on the official RedHat security page;
    https://rhn.redhat.com/errata/RHSA-2017-1270.html#Red
    the latest Samba update for Red Hat Enterprise Linux Workstation (v. 6) is
    SRPMS:
    samba-3.6.23-43.el6_9.src.rpm
    In this case, if you scan a host using the above script, it will show you the host is vulnerable, which is kind of false positive.
    Redhat has the official script for the CVE-2017-7494, which you can use to make sure if any Samba inRedhat v6 servers are vulnerable or not.
    https://access.redhat.com/sites/default/files/cve-2017-7494.sh
    (It should be run locally on the target server)
    I changed your script a little bit to prevent having this issue as below;
    21 if string.match(version,”^3.5″) and not string.match(version,”^3.6.23-43″) then
    22 return true
    I assume this change would generate a more accurate result. To be more precise you can include all 3.5 and 3.6 Redhat vulnerable version inside the code.

    Reply
  2. Lewis Muhlenkamp
    Lewis Muhlenkamp says:

    I got the following errors when I tried to run it on a RHEL 6.9 server:

    root@server:/tmp> nmap -script ./gc-SambaCry.nse -p 445 127.0.0.1

    Starting Nmap 5.51 ( http://nmap.org ) at 2017-05-30 09:15 CDT
    NSE: failed to initialize the script engine:
    /usr/share/nmap/nse_main.lua:389: ././gc-SambaCry.nse is missing required field: ‘description’
    stack traceback:
    [C]: in function ‘error’
    /usr/share/nmap/nse_main.lua:389: in function ‘new’
    /usr/share/nmap/nse_main.lua:578: in function ‘get_chosen_scripts’
    /usr/share/nmap/nse_main.lua:1006: in main chunk
    [C]: ?

    QUITTING!
    root@server:/tmp> cat /etc/redhat-release
    Red Hat Enterprise Linux Server release 6.9 (Santiago)
    root@server:/tmp> rpm -q nmap
    nmap-5.51-6.el6.x86_64

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *