SambaCry — old protocol, new threat
Last year in May there was a big uproar in IT world about EternalBlue vulnerability. It was used to exploit thousands of computers around the globe with ransomware called WannaCry and Petya. The vulnerability existed for years in SMB protocol for Windows and was known and used by NSA, for invigilation, as a backdoor. After patching it, researchers started sniffing for other vulnerabilities around the SMB/CIFS protocols and a bug SambaCry (CVE-2017–7494) in Samba service has been found.
But what the hell is Samba?
Samba is the software that enable Linux and Unix systems to use the SMB/CIFS protocol and communicate with Windows-based servers to share files and printers. It also allows Linux to use Active Directory for accessing Windows network, use its logon and authentication features.
How the SambaCry works?
Like EternalBlue vulnerability, SambaCry has existed in code for a long time but has not been discovered until 2017. It is the bug introduced at designing level, allowing Samba to load libraries from shared location without verification whether those are provided by trusted source. However, system must be specifically configured to be exploitable. A shared space with permissions to write must be exposed, making it possible to upload malware to a victim’s system.
- The first step of the attack is to copy malicious file to the server’s shared space. As long as the code is not executed, it’s not a big deal. To cheat the Samba, an attacker needs to open the uploaded library file in the first step.
- The hardest part is to find a full path of the shared space. How it can be done? Hackers were checking most popular or default paths (we love tutorials, thank you google! 😉) of shared space locations (/volumeX/myshare, /volumeX/MYSHARE, /volumeX/MyShare etc.) and requested for earlier uploaded file.
- Last but not least, a malformed IPC request, containing full path location to the malicious file, was sent. In a result of exploitation, an attacker gained remote access to the victim’s console with super user privileges, and by that have possibility to do anything, meaning the could simply run any command on the system.
PoC
To test this vulnerability, I’ve prepared a host with Ubuntu OS and Samba installed. As both projects have been already patched, proper versions of those should be used. I’ve also used one of the most popular security toolset — Kali Linux which contains all the necessary tools for the attack like Nmap and Metasploit.
I’ve started with scanning a local network to find hosts with port 445 open (default for Samba).
root@kali-vm:~# nmap 10.0.0.* -p 445
As one can see the host 10.0.0.102 with open port 445 has been found.
Having such information, I scanned the host using Nmap to check Samba service version:
root@kali-vm:~# nmap -A 10.0.0.102
Results of the scan go together with host network settings.
user1@sambaCryServer:~$ ifconfig
user1@sambaCryServer:~$ smbd -V
Then, I configured exploit in Metasploit accordingly.
msf exploit(linux/samba/is_known_pipename) > show options
Everything was ready, I could start exploitation and take control over the target host. A Meterpreter session to victim’s host has been established, and I could run Meterpreter commands. I switched to shell and verified a hostname, current user, IP address and samba settings to confirm that I was on the expected host with root privileges.
msf exploit(linux/samba/is_known_pipename) > exploit
This simple attack shows how dangerous was the bug, and how easy it was to attack the systems. Of course, without such tools like Metasploit it won’t be so simple, but still not a big effort for a determined person. The worst thing about this bug is that due to its simplicity, this type of attack could be automated to run network scanners on infected systems and use them exploit another hosts. Being so easy to implement, the bug allowed hackers to build cryptocurrency farms all around the world and the more hosts were infected, the bigger ROI they could achieve.
How to protect the system against such type of attacks?
1. Updates — Samba has been patched in versions 4.4.14, 4.5.10, 4.6.4, so if you have those or higher versions, then you’re safe. For some OS (e.g. Ubuntu) it may be enough to just apply system updates.
2. Do not allow anonymous writing to the shared space. In most networks such feature can be disabled, so only authenticated and authorized users can upload or change files in theshared space.
3. Do not share the space if you don’t really need. For users who need to use Samba just as client, a sharing option can be disabled.
4. Use read-only access for the shared storage if you don’t need to allow users writing to the space(e.g. you only share some files for others — updates or download server).
There are some environments with updating policy that do not allow quick patching. For such systems, it is possible to implement some workaround. Remember, do it only if disabling anonymous writing is not an option.
5. Set the ‘nt pipe support = no’ option in Samba configuration. As it can affect some SMB features, you should test such a configuration before applying on production environment.
Note!
Perform security testing ONLY against environments which belong to you or on those which you are allowed. By working with other systems you can expose yourself to legal consequences.’
