Much like the EternalBlue exploit that was released in April 2017 after being stolen from the NSA, Samba was discovered to have a remote code execution vulnerability as well. Dubbed ‘EternalRed’ by industry-types, this vulnerability dates as far as 2010. So even if you chose the red pill thinking Linux was a safer alternative, for 7 years you were just as vulnerable as those using Windows. Samba version 3.5.0, the version that introduced the flaw, was released in March 2010. The bug causing this vulnerability is in the is_known_pipename() function. The Samba project maintainers wrote an advisory on May 24th urging anyone running a vulnerable version (3.5.0 - 4.5.4/4.5.10/4.4.14) to install the critical patch as soon as possible or risk certain pwnage.
Samba was introduced in 1991 as an open source software that provides services allowing Microsoft Windows end-users to access files, printers and other commonly shared network resources utilizing the SMB/CIFS protocol. Samba runs on most Unix, OpenVMS and Unix-like systems, such as Linux, Solaris, AIX, and also BSD variants.
CVE-2017-7494, can be reliably exploited with just one line of code, as long as a few conditions are met:
· Port 445 being open on the target device, and
· Shared files are present with write privileges at either known or guessable server paths.
With these conditions met, the vulnerability allows remote attackers to upload code and execute it, thereby giving them a foothold and, depending on the platform, root privileges.
Much Like EternalBlue before it, this vulnerability could also be worm-able. This means the potential for a new outbreak of Ransomware taking advantage of the flaw for financial gain and giving companies bigger headaches is also greatly increased. A large number of users, both consumer and enterprise are using network-attached storage (NAS) devices for backup systems, many of which are vulnerable to this new ‘EternalRed’ threat. So far Synology has been exploited successfully, with many other vendors undoubtedly being tested as you read this. Rapid7 stated they detected approximately ~110,000 devices on the Internet that appeared to run vulnerable versions of Samba. Of those, 92,500 of them appeared to be running unsupported versions of Samba for which no patch was available. Netgear has also released an advisory stating a bunch of their Routers and NAS devices are also affected.
You can test this on any box installing a vulnerable version of Samba and editing the smb.conf file
comment = "Exploitable Share Folder"
path = /tmp
public = yes
writeable = yes
" | sudo tee -a /etc/samba/smb.conf
sudo /etc/init.d/smbd restart
sudo service smbd restart
The vulnerability is super simple to trigger this exploit. This one line of code executes malicious code on the affected system.
The person who found the vulnerability released a POC and did a few others
To make things even easier, H D Moore from the Metasploit project already ported the code to Metasploit within a few hours and updates coming in almost hourly since. The pull request at the time of writing hasn’t been added so you can easily test this out with the following commands:
wget https://raw.githubusercontent.com/hdm/metasploit-framework/0520d7cf76f8e5e654cb60f157772200c1b9e230/modules/exploits/linux/samba/is_known_pipename.rb -O is_known_pipename.rb
Metasploit Tested versions:
Ubuntu 16.04 with Samba 4.3.11 (2:4.3.11+dfsg-0ubuntu0.16.04.6)
Synology NAS DS2415+ running DSM 6.1-15047 Update 1 and Samba 4.3.11
The maintainers of the Samba project have provided a patch for version 4.4 and up. This should be applied immediately to any devices you have under your control using 4.4 and up to avoid falling victim. A workaround for unsupported older versions (3.5- 4.4) is available, but it would be recommended to upgrade to a newer version as the first possible fix. If using a NAS, I would recommend creating an offline copy of critical data as soon as possible if patching cannot be done immediately, and considering locking down ACL’s to prevent access to port 445 on said device.
Alternatively, adding the parameter:
> nt pipe support = no
to the “[global]” section of the smb.conf on the impacted device, and then restarting smbd service will also prevent vulnerability to this exploit.. This change prevents clients from accessing any named pipe endpoints on the given system, which nullifies the bug causing this vulnerability.
Note this can disable some expected functionality for Windows clients, so exercise this option with caution.