The big cybersecurity news of the past couple of weeks has been the WannaCry worm. It took advantage of some rather old bugs, dating back to Windows XP and Windows Server 2003.
We got lucky! The vulnerability, the problems in the targets, allowed unlimited abuse. But the exploit, the attackers’ code, had a built-in “kill switch” that the good guys accidentally triggered. That shut down the world-wide attack before it went too far.
Security researchers have now discovered a similar vulnerability in non-Windows operating systems. Attackers may soon build and deploy exploit code for it. The next exploit probably won’t have a “kill switch”.
Patch your Samba servers immediately!
The SMB protocol has been used for ages to share files and print service in Windows environment. CIFS has replaced the SMB protocol, but we all tend to say “SMB” to mean both classic old SMB and newer CIFS.
The Samba package provides equivalent file and print service on non-Windows platforms. Not just compatible, but indistinguishable from a native Windows server.
Samba is included with Linux and the various BSD Unix versions, and it can be added to Mac OS X plus commercial UNIX-family operating systems like Solaris, HP-UX, AIX, and anything vaguely UNIX-like. We add Samba packages and then set up and test file and print service to Windows clients in Learning Tree’s Linux server administration course.
A logical flaw entered the Samba code seven years ago. Any Samba package version 3.5.0 or later contains this vulnerability. And, it’s a doozy.
A malicious client can upload a shared library file to a writable file share, causing the server to load and execute it. This could be encrypting ransomware as with WannaCry. Or it could be a “wiper” as we’ve seen in some nation-state attacks where data and operating systems were obliterated. It certainly could contain the logic to spread itself.
Some early announcements played down the risk by describing an exploit as being difficult. Well, yes, if you had to figure it out on your own and code everything from scratch. However, with Metasploit it’s a short one-liner. The exploit itself and a terse description fits into a 140-character Twitter post!
The Rapid7 security group did a quick scan. They spotted over 100,000 vulnerable Samba systems exposed to the Internet. I don’t know what fraction of the globally routeable IPv4 and IPv6 space they scanned, but it’s clearly a significant problem.
This series of two (so far) related vulnerabilities illustrates how important patching is.
However, I recognize that most organizations can’t just slam patches into place without risking self-inflicted problems. And, some of you may use Samba packages from conservative (or just slow!) providers. You may not have a trusted patch.
Add the following line to the
[global] section of your Samba configuration file. That’s probably
nt pipe support = no
Then restart the Samba service.
The Internet of Things causes problems again…
Some IoT devices will ask the firewall to expose some of their network services to the Internet. Many firewalls support such risky “plug and play” behavior. It’s a trade-off of convenience and ease-of-use in place of security.
While your NAS (or Network-Attached Storage), DVR (or Digital Video Recorder), and other IoT devices very likely run Linux, you have no way of updating packages or changing their configuration.
Scan yourself from the outside, and make sure that ports 137, 138, 139, and 445 are all closed. Those services should not be passed through the firewall in either direction!
Scan yourself with
nmap using the following syntax. Do this from outside your organization. Replace 220.127.116.11 with your external IP address:
# nmap -sS -sV -p 137,138,139,445 18.104.22.168 # nmap -sU -sV -p 137,138,139,445 22.214.171.124
You want to see “closed” (active rejection) or “filtered” (silently dropping) for all four ports. You want that for both TCP (the first command) and UDP (the second).
If you don’t, your firewall needs some fixes!
Check out Learning Tree’s Linux server administration course to learn more about the parts of this critical work: testing whether Samba is installed, and if so, which version; checking for and then downloading and applying all available patches; reconfiguring Samba; restarting network services; and more