Malware on IBM Power Systems: What You Need to Know
Malware – what are the threats?
Malware can come from and in a variety of attack vectors. Besides using ‘traditional’ methods of spreading malware, adversaries can leverage more sophisticated methods to turn your Power System into a ‘malware host’.
The key target is your data. Data is valuable, and organisations have paid at least $602 million to ransomware gangs in 2021. If they are not stealing it to sell on the dark web (social security numbers, credit card numbers, names, and addresses) then it will be held for ransom… “Give us some $$$ if you want to have your data decrypted.”
Why bother?
A lot of organisations are subject to regulatory requirements, such as PCI-DSS, HIPAA, FISMA, Gramm-Leach-Bliley Act (GLBA), UK DPA and GDPR. The penalties can be severe for any organisation “leaking” data. A UK airline, for instance, was fined £20,000,000 by the Information Commissioners’ Office (ICO).
The average cost of a breach in 2021 was €3.9 million ($4.24 million), marking a 10% increase compared to 2020. In the case of breaches, time is money and on average it takes 287 days to identify, close and remediate a data breach.
Power systems can’t be infected, right?
Because an Intel (x86)-architected virus cannot execute on IBM i, AIX, RHEL, or CentOS Operating systems running on IBM’s Power Chipset, we run the risk of misreading this as “no viruses are possible!” IBM has never claimed that the IBM i IFS was immune, as evidenced by the fact that the IBM i acquired integrated anti-virus protections in V5R3 in 2004.
However, that doesn’t stop malware from being stored. All these Power OS’s can share disk space. The IBM i uses its Integrated File System (IFS) to allow NetServer shares – which enables Windows desktop users to access the IBM i IFS through a mapped drive. AIX and Linux allow Networked File Systems (NFS) which permit the same thing, that is, the ability to access the file system through a mapped drive. This means that if an Intel virus is copied to the mapped drive of the target system, then it will quite happily hide there without being detected by any antivirus software on the source system.
This then makes your Power System like an asymptomatic ‘carrier’. There are no symptoms on the ‘host’ OS, but it can reinfect your Windows machines if the user clicks on the file or object in the file share from their Windows desktop.
More recently, 35% of all new malware being written is targeted at Linux, the predominant OS of cloud services, which means this can be executed and is a real threat. However, this is not a new problem. In 2014 a massive botnet of 25,000 compromised Linux servers was found using a mixture of malware (Ebury and Cdorked to name but two) to redirect web-traffic and send out spam.
How to combat this?
There are some simple steps you can take to combat this.
Known admin accounts
Disable known admin accounts, such as QSECOFR and root. Prevent them from logging in. Get some Privileged Access Management (PAM) software or implement sudo for *NIX servers. Don’t use obvious usernames like ‘JSMITH’ and work on the principle of least privilege for everyone, including your sysadmins!
Shutdown and remove unnecessary services
There are a multitude of services that are still shipped with IBM I, AIX and Linux that are inherently insecure and there are three that are common to all platforms. If you have TFTP, FTP or TELNET running, implement SSH and then shut them down and remove them.
Tighten the configuration of remaining services
If you are running SSH, NFS, Apache server, etc. ensure you are following best practices and standards such as the ones developed by the non-profit Centre for Internet Security (CIS). Monitor your configuration to ensure it has not changed from a set ‘benchmark’ as badly configured databases and http servers are common entry points for data breaches.
Define a strong password policy
Reuse options, distinctions between old and new passwords, and password length are all excellent practices, but it’s even better to start employing “pass phrases” that cannot be broken using brute force dictionary attacks. Even better, begin utilizing an SSH key that only permits access to a system upon exchange of a key that is encrypted. Consider two-factor or multi-factor authentication as an additional, difficult-to-crack security layer.
User accounts
Keep in mind that 61 percent of breaches are caused by compromised credentials, so you should frequently evaluate your user accounts and lock those that have been inactive for an extended period. A check of owned objects should also be performed, as production code and files should not be held by individuals, but rather by groups or maintenance accounts.
Patching
The era of “don’t fix it if it’s not broken” is over! Daily, new vulnerabilities are discovered, thus you should adhere to a regular patching plan.
Backups and Disaster Recovery
54 percent of organizations recovering from a ransomware attack employed reinstallation and backup restoration to resolve the issue, whereas 23 percent of organizations having a Disaster Recovery plan do not test it.
It’s worth remembering that the core reason for having a disaster recovery plan and testing it regularly, is to arm you and your team with the confidence that digital continuity can be provided, minimizing disruption to the business. Regular testing proves the plan and ensures that agreed recovery points and times continue to be achievable.
Hire and retain top talent
It might seem obvious, but treat your staff well. Threat actors and criminal groups are actively recruiting disgruntled employees to provide access into systems and networks. The LAPSUS$ ransomware group even posted a ‘job advert’!
Concluding thoughts
We can all do our bit. Don’t pay ransoms. It is far better to avert a ransomware attack by hardening your attack surfaces than to have to deal with the aftermath. Power Systems, like the IBM i and AIX can’t be infected, but they can act as hosts. RHEL and SUSE can be compromised and run malware. Protect your Power systems with native antivirus software to catch malware at the source.
About the Author: Mike Davison has worked on IBM equipment in IT Operations since starting on the 4381 running VM/VSE as a trainee Operator in 1987. He’s worked for blue-chip companies in global data centres and has a varied 30+ years’ experience of IBMi, AIX, VIOS, UNIX, Linux, storage and disaster recovery. Currently a Senior Technical Consultant for Helpsystems, Mikes main role is to provide consultancy and support for customers seeking to secure, monitor and automate their Power system operations.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
The post ” Malware on IBM Power Systems: What You Need to Know” appeared first on TripWire