Can you keep Linux-based ransomware from attacking your servers?

According to SophosLabs, Linux/Ransm-C ransomware is one example of the new Linux-based ransomware attacks, which in this case is built into a small command line program and designed to help crooks extort money through Linux servers.

“These Linux ransomware attacks are moving away from targeting end users and gravitating toward targeting Linux servers, web servers specifically, with a piece of software that encrypts data and is similar to what we’ve seen in previous years such as CryptoWall, CryptoLocker, and their variants,” explains Bill Swearingen, director of Cyber Defense, CenturyLink.

As long as attackers can leverage the ease of coding strong encryption and the high availability of anonymous currencies and anonymous hosting, ransomware is here to stay, says Swearingen. With security organizations like SophosLabs seeing and tracking new variants of Linux ransomware, enterprises should make themselves aware of its risks and cures, since as server owners, users, or operators they are prime targets.

Typical target trip ups

With the amount of open-source software in use on Linux web servers, it is very easy for attackers to take advantage of these CMS systems such as WordPress, Drupal, and Joomla with their many unpatched vulnerabilities and exploit them, insinuating these Linux encoders / ransomware and holding enterprise web servers and their data in exchange for some form of booty, says Swearingen. 

Though the first rounds of Linux ransomware have been poorly coded, according to Swearingen, coming rounds will be increasingly more effective. As attackers are writing the next wave of Linux encoders, enterprises need to prepare to withstand their effort.

One obvious answer to Linux malware is to keep those CMS products and the web servers continually patched and updated. But patching produces its own challenges. Even Linux web servers have many layers that the enterprise needs to patch, says Swearingen, including the OS layer, the application layer, and the database layer. "Traditionally companies focus on the operating system layer, running vulnerability scanners. But it’s the applications that the attackers are targeting,” says Swearingen. The enterprise needs to expend effort to uncover and patch holes at all levels. That comes with additional investments in time and money.

Immediate patching is often impractical since patches may be flawed, creating their own issues. Enterprises should thoroughly test new patches before installation to production environments. Proper testing also comes at the sacrifice of time, effort, and additional finances. Enterprises have thresholds where they can begin to afford testing and below that, many cannot justify the expense. 

Even patches that generally function properly may negatively affect certain adjacent applications and software dependencies with conflicts and lack of interoperability so that these CMS and other Linux web server products experience faults or stop working altogether. Ultimately, the enterprise will have to weigh the risks and costs of patching as they approach patching solutions.
Beware: if the same vulnerabilities remain unpatched for years, this is what most attackers are targeting. “Attackers are utilizing well known, well documented vulnerabilities in externally facing applications,” says Swearingen. You must patch eventually, or expect to become a statistic.

Secure development

The best place to secure web applications is at the start, in development. When developers follow coding standards that address the riskiest vulnerabilities that an application can have, they greatly mitigate the potential for successful attacks. “In any custom application, ensure that your developers are referencing the OWASP Top Ten,” says Swearingen.

The OWASP Top Ten application security risks include injection flaws, poorly implemented authentication, cross-site scripting flaws, direct object references, insecure configurations, sensitive data, PII exposure, missing function level access controls, cross-site request forgeries, known-vulnerable components, and unvalidated redirects. In each case, the security hole permits an attacker to insert or access data or components, leading to a broader compromise.

By checking and closing each vulnerability as they create an app, developers can deal the greatest blow to attacks before the app even sees the light of day.

Vulnerability monitoring

As with the OS, there are vulnerability scanners tailored to CMS and web applications. “If you’re running a Word Press site, there is an application called WPScan that can test it,” says Swearingen. HackerTarget makes multiple web and CMS scanners available. OWASP has a WordPress scanner. There are also scanners that can check the source code.

Of course, once you find a vulnerability you will have to either patch it or find some other solution such as a WAF to secure around it.

“You’ll want to implement security best practices including a backup strategy that you can test and confirm works to restore the system in the event that an attacker does encrypt it and hold it for ransom,” says Swearingen. If someone else has provided the server and the enterprise is in charge of the application layer, you should backup the application and perhaps the database, depending on your circumstance, he explains.

To ensure that backups as an approach in general will really counter a Linux ransomware attack, keep the backups on a different system at a different location with different credentials, so that a compromise of the server is not automatically also a compromise of the backups. “Whether you are using server snapshots for backups, make sure the backup system is not mounted from the original server that is subject to compromise,” says Swearingen.

Security practices

Security best practices will lead the enterprise to segment web servers from any externally exposed server and from other networks, and to use highly restrictive access controls, says Swearingen. You should always use all applicable layers of defense that are available to you.

Additional security practices including running certain apps in containers to isolate them from the rest of your systems, says Ben Johnson, chief security strategist, Bit9+Carbon Black. “An app or web server in one container can’t leave it to attack an app in a different container. Even if an attack landed in one container, it wouldn’t get back out to attack something else,” says Johnson.

There are well-known forms of controls that help, too. “Use whitelisting to approve apps that can run on your web server and block everything else,” says Johnson. Hardening systems including closing unused ports goes hand in hand with application blocking.