Linux users who installed npm 5.7.0 released Feb. 21 quickly took to Twitter and GitHub to report that the update broke their filesystems by changing the permissions on critical system directories and files.
“This destroyed 3 production servers after a single deploy!,” one user reported. Another one reported that he experienced this in a clean system on Amazon’s EC2 cloud computing platform, forcing him to re-create the EC2 instance.
The npm developers released version 5.7.1 Feb. 22 to fix the issue and noted that the error only happened when npm commands were used with sudo, a utility that executes commands passed to it with superuser privileges.
Running npm commands with sudo is generally discouraged because it poses a security risk, but users who installed Node or npm using sudo in the first place might be forced to use sudo to install any subsequent updates. The fact that this incident affected so many users shows how widespread the practice is.
Users also took issue with developers’ excuse that 5.7.0 was a pre-release and shouldn’t have been used on production systems. While the 5.7.0 did indeed have a pre-release tag on GitHub, the release was announced on the official blog with no indication that it was not a stable version.
“Thankfully, it only affected users running ‘npm@next’, which is part of our staggered release system, which we use to prevent issues like this from going out into the wider world before we can catch them,” the Npm developers said in a blog post announcing the fix. “Users on ‘latest’ would have never seen this!”
The lessons from this incident are: 1) Check if your npm installation was done with sudo and reinstall it using an alternative method that doesn’t require running sudo npm commands in the future, and 2) If you run npm on a production system, make sure that your installation is subscribed to the proper update channel, not the pre-release one.
Ransomware Forces Shutdown of Colorado Transportation Department Computers
Staff at the Colorado Department of Transportation have reportedly been forced to use pen and paper for the past two days after a ransomware infection forced the department to shut down more than 2,000 computers.
Critical services such as cameras, CoTrip and traffic alerts were not affected because they were running on separate systems, but the CDoT shut down all employee computers running Windows and which had McAfee security software installed, the Denver Post reported.
The reason for the shutdown was a variant of a ransomware program called SamSam that also hit other organizations last month. In one case, a hospital from Indiana agreed to pay a $55,000 ransom as it was quicker to recover the affected files with the attackers’ help than to restore them from backups.
The Colorado Department of Transportation has no intention of paying and is working with security firm McAfee which has already provided an update to detect and block the malware from spreading further.
The SamSam ransomware first appeared in 2016 when it infected organizations by exploiting a vulnerability in JBoss servers. However, security experts believe that in the recent attacks, the hackers might have installed the malware through compromised remote desktop services.
The modus operandi of the SamSam group involves infecting a few initial systems and then moving laterally through an organization’s internal network to compromise other computers.
According to researchers from SecureWorks, a SamSam campaign that ran from late 2017 to early 2018 earned attackers $350,000. Giving its success, it’s unlikely that this threat will go away anytime soon.
More importantly, the SamSam incidents show how disruptive ransomware infections can be to large companies. When responding to such incidents, the first step is to shut down all computers to avoid the malware from spreading. This, in turn, can severely affect an organization’s normal operations.
If a large enough number of systems get infected before the compromise is discovered, companies might discover that it might be easier to just pay the attackers because their backup restoration procedures could take weeks. Of course, security experts never recommend paying these ransoms because there’s never a guarantee attackers will provide the decryption keys and even if they do, it just encourages them to keep doing it.