Understanding NonStop Vulnerabilities to Ransomware

Introduction

NonStop is different, in case no one noticed, I figured I would finally say it. There is no GUI, no web browser, no user accessible HDMI, USB, or flash drives. The operating system is hardened, secure, with unmodifiable system memory. There are no auto-reboots, no automatic updates (not yet anyway), but there are CLIMs, Java, Perl, Python, more other common tools, C compilers, and an x86 instruction set. There are also virtual machines that we need to protect.

We also have major banking, financial, manufacturing, healthcare, and other applications running on the platform because of our resilience to standard attacks and a more hardened architecture.

Where does that leave us in the Ransomware world? Not safe, if that was your first reaction. It means that the typical attack is not likely going to be a traditional vulnerability.

Even something as simple as the following can cause significant problems:

This is why we have code reviews of all delivered source code as part of the git Pull Request processes. Never do what is shown above.

Quoting Keith Moore, a Distinguished Technologist for HPE NonStop:

File access, change management, revisioning, and audit trails are a critical part of modern DevSecOps processes; not limited to just source code management. A secure repository with fingerprinted versioning helps protect all files within it from malware which often metastasizes into malicious manipulation of data, including data hostage. All enterprise data can benefit from tools like git that allow formal multi-user data protection, fingerprinting, and audit.

An Attack Scenario

Ransomware designers have a few goals:

• Find targets who are worth going after. There is no question that applications that run on NonStop are prime high-value targets. Corrupting bank accounts, wire transfers, credit and debit cards, health records, are things that criminals want to hold hostage.
• Find targets who are vulnerable. In general, we are in a better position than most platforms, so this might seem to take us off the list, but it doesn’t for those looking for the highest return for their criminal conduct.
• Find challenging targets. There are those who go after targets because they are difficult. These are not typically kids downloading Ransomware toolkits and thinking they could get your bank account. The character of these attackers could be as bad as foreign governments or NGOs with ample resources that want to do damage to our infrastructure.
• Find lazy targets. Perhaps the most promising target for ransomers are those who know what has to be done but have not dedicated the time and effort to put in place measures that will catch most if not all Ransomware.

So how would a NonStop server fall victim to Ransomware? Many typical attack vectors involve social engineering or some mechanism where a user interacts with an external link that downloads malware. Fortunately for the NonStop community, there are few applications where accidentally downloading a hostile file will go without notice. With sftp, curl, or wget, someone could download something bad, but they would have to explicitly specify the location. This would typically become nowhere malware very quickly because security rules in Safeguard or XS1 would block a direct attack.

Another more likely vector is via a user workstation. In this scenario, a user interacts with a targeted external link that downloads malware only to the workstation and waits in hiding until some future moment where the malware figures out that it is at a vulnerable target, let’s say, your system – a good reason to start with having solid anti-malware software on your workstations. Once the malware wakes up, it only has direct access to resources accessible through your workstation. This can be problematic. Suppose the malware targets a remote editor so that when you access a system startup script on your NonStop, it makes changes to the script (without you knowing, while you are editing it), including download and execution of Ransomware as SUPER.SUPER on startup. Or similarly, the malware could change source code in software you are modifying to do similar access, download, and execution in production as the application user. There are many nightmare scenarios that now come into play, but I will leave those to your now (hopefully) frightened imagination.

Mitigation

A highly plausible vector, in summary, is a modification of a core production file via a workstation, even if the modification is done initially without escalated user permissions. Detecting the change, even if the user does not see it explicitly, is crucial. It is not predictable to know whether an attack will come, in this scenario, through a developer’s or an operator’s workstation. Fortunately, proven solutions exist to foil this vector through implementation of DevSecOps practices.

In this case, the practice of taking direct access to production files away from anyone.

I can imagine your first question: how can I do my job if I cannot touch the file? Well, the key word here is directly. One clear way of dealing with this is making a change, committing it into a git repository, and delivering the code using a git Pull Request.

The next obvious question is: how does this help? A change is a change, right? In the case of git those are not the same. When a change is made and then committed to git, it is transformed into git’s internal structure, which is definitely not the same as the file that someone modifies. This applies to text and binary files. With NSGit introduced, it also includes Guardian EDIT, Enscribe, native and-non-native objects. During the approval of the Pull Request or merge process, the complete change is visible. NSGit will even show the changes to object code regions and data file records. The combination of git and NSGit can be used to integrate malware scanners, including x86 object scanners available on other platforms, into the delivery process.

By adding in SSH content signing through NSGit in Guardian and git in OSS, the signature of code deliveries can be authenticated at any point even if some process running as SUPER.SUPER modifies files in the git repository. A corrupt repository can be recovered using git’s mirroring function, and NSGit and git can restore corrupt files in the application or operating system.

Other products, including third party products and using TMF audit trails and replication solutions to restore transaction files. Catching Ransomware in the act using git processes can help mitigation and recovery by providing a timeframe when the Ransomware started corrupting files.

Another Attack Vector

Another way an attacker can get in is via a Virtual Machine (VM). Because the VM lives in the file system of a hypervisor, if the hypervisor is compromised, there is very little a VM can do to protect itself. Even SUPER.SUPER-level Safeguard rules cannot protect the file system from an attack coming from the physical disk of the hypervisor, assuming that the attack is well coordinated and knows they are attacking NonStop VMs.

In this scenario, it is even more important to use SSH content signing in NSGit to protect your repositories from this type of attack. Once your repository is protected with valid signatures, you can determine whether any critical files like:

• Application programs
• Startup scripts
• Database Maintenance scripts
• OS components
• CLIM load files.

have not been tampered with.

Conclusion

Ransomware is a scourge on our infrastructure, but many known attack vectors to NonStop can be mitigated using currently available solutions. HPE and partners are working hard to provide solutions to protect the community, but it does take everyone to do their part and put in place appropriate mechanisms to mitigate the impact of Ransomware on our production environments. Remember that production and development are intertwined in ensuring that we all practice safe computing.