A new worm named EternalRocks is in the news this week . EternalRocks leverages some of the same vulnerabilities and exploit tools as WannaCry but is potentially more dangerous because it exploits seven NSA tools that were released as part of the ShadowBrokers dump. EternalRocks has the potential to spread faster and infect more systems but for now it is not armed with any malware that can create damage/still information. But it could easily become a dangerous tool and therefore taking preventive steps is critical.
EternalRocks emerged in first half of May 2017, with oldest known sample dating to 2017-05-03. It spreads through public (The Shadow Brokers NSA dump) SMB exploits: ETERNALBLUE, ETERNALCHAMPION, ETERNALROMANCE and ETERNALSYNERGY, along with related programs: DOUBLEPULSAR, ARCHITOUCH and SMBTOUCH.
EternalRocks does not have a kill-switch which helped curtail WannaCry and mitigate the ransomware damage and its’ malware runs a process with two stages:
First stage malware UpdateInstaller.exe downloads necessary .NET components (for later stages) TaskScheduler and SharpZLib from Internet, while dropping svchost.exe (e.g. sample) and taskhost.exe (e.g. sample). Component svchost.exe is used for downloading, unpacking and running Tor from archive.torproject.org along with C&C (ubgdgno5eswkhmpy.onion) communication requesting further instructions (e.g. installation of new components).
Second stage malware taskhost.exe (Note: different than one from first stage) (e.g. sample) is being downloaded after a predefined period (24h) from http://ubgdgno5eswkhmpy.onion/updates/download?id=PC and run. After initial run it drops the exploit pack shadowbrokers.zip and unpacks contained directories payloads/, configs/ and bins/. After that, starts a random scan of opened 445 (SMB) ports on Internet, while running contained exploits (inside directory bins/) and pushing the first stage malware through payloads (inside directory payloads/). Also, it expects running Tor process from first stage to get further instructions from C&C. (Github)
All of the vulnerabilities exploited by the EternalRocks worm were patched by Microsoft earlier this year as part of MS17-010. Once again, like in the Wannacry case, patching is just a temporary solution. SMB1 protocol is highly vulnerable and we are expecting to see more new vulnerabilities discovered frequently. Patching is very complicated and keeping in pace with this new flaw of SMB1 patches is hard. It is better to work on a permanent solution for the problem- stop using SMB1! as Microsoft recommends for few years now;
As mentioned by Microsoft in the TechNet blog- "The original SMB1 protocol is nearly 30 years old, and like much of the software made in the 80's, it was designed for a world that no longer exists. A world without malicious actors, without vast sets of important data, without near-universal computer usage”.
If you are a systems administrator and you manage IT infrastructure that relies on SMBv1, and you haven't done so yet, you should prepare to remove SMBv1. Since Windows Server 2003 is gone, the main concern will be third party software or hardware like printers, scanners, NAS devices and WAN accelerators. You should make sure that any new software and hardware that requires the SMB protocol is able to negotiate newer versions (at least SMBv2, preferably SMBv3). For existing devices and software that only support SMBv1, you should contact the manufacturer for updates to support the newer dialects.
Microsoft really wants organizations to get rid of SMBv1. During the last 6 months many critical remote code execution vulnerabilities have been discovered in the protocol and patches were published. for example:
- September 2016: MS16-114: Security Update for Windows SMBv1 Server (3185879)
- March 2017: CVE-2017-0147, MS17-010 Security Update for Microsoft Windows SMB Server (4013389)
Click here to get a security policy for your Windows servers
Disabling SMBv1 is not simple as many applications, platforms, printers, etc., are heavily dependent on it. This object should be carefully examined on a OS basis before hardening is performed.
Here are a few examples of SMB1 dependencies that should be taken into consideration when disabling it:
- Un-encrypted/sign communication between OS's and applications
- LM and NTLM V1 / V2 communication
- Low level clients file/shares communication or communication with high level clients
- File/Shares communication between platforms, for example: Linux to Windows via CIFS
- Legacy applications and SMB1 fixed communication applications for example: Sophos, SonicWalls, EMC VNX, vCenter/ vSphere (AD integration), Aruba, Juniper Pulse Secure SSO and more
- Printers and Print servers for example: HP, Konica’s, Toshiba’s, Ricoh’s, Xerox’s, etc.
- Android communication to Windows server applications
- Different versions of OSx communicating with Windows
- Filers like NetApp (by default use SMB1 and can be change to SMB2 or SMB3)
- Databases: MDB files used by many users at the same time. With SMB 2/3 the MDB will get corrupt, the only way is to use SMB 1
- Backup applications for example: dump the configs to a share and keep a version for x amount of time
There are dozens, if not hundreds, of potential dependencies that should be carefully studied and examined before disabling SMB1. We recommend learning and maping the activity of SMB1 on your servers. IT teams should keep in mind that there is an operational risk in disabling SMBv1; the usage of the SMBv1 protocol should be mapped and all the dependencies must be revealed on servers before hardening. Using the Calcom Hardening Solution (CHS) learning capabilities saves time and lowers the operational risk related to hardening SMBv1. CHS’s learning mode provides automated usage mapping and reveals the systems and applications dependent on the protocol.
Disabling SMB1 must be integrated to the organization's hardening policy. Both existing and new servers should be configured to use up to date versions of the SMB protocols. SMB1 is only one example of why you should harden a broad security policy for your servers.
References and additional information:
