With more government agencies and organizations being affected by malware, steps need to be taken to ensure IBM i isn’t affected.

Some organizations have spent millions of dollars cleaning up after their systems were infected with malware, often paying a ransom to the intruders if they weren’t prepared. While IBM i itself is “virus resistant,” we’ve seen many organizations’ Integrated File System (IFS) be affected. Today, I’ll discuss how can this happen and what steps can be taken to protect IBM i from malware.

As I said, IBM i is virus “resistant.” The operating system doesn’t recognize the instructions used to run today’s viruses, so unless the virus is written specifically for IBM i, it’s going to be difficult to get most viruses to run on IBM i itself, meaning from a command line or via program or other executable. However, there are at least two situations when we should be concerned.

Scenario 1

First, let me describe the configuration that sends shivers down my spine whenever I find it during a Risk Assessment: a Read/Write share to the root (/) directory, made even worse when the root directory has been left at the shipped value of *PUBLIC DTAAUT(*RWX) OBJAUT(*ALL), which is the equivalent of *PUBLIC(*ALL). Let me explain why this is such an extremely high-risk situation.

A file share is what allows someone within the network to connect to a directory (or library) on IBM i. Once connected, what’s been shared looks like any other drive to the PC. When a user clicks on the wrong link or otherwise gets malware on their PC, the malware will do its harm on the PC and then start to walk through all of the drives that are attached, including IBM i. When the share to IBM i is a Read/Write share to root, the entire operating system—not just the IFS—is at risk. That’s because, when you share root, you also share /QSYS.lib—that is, the operating system and all of your libraries. Because the share allows writing, if the user profile connected to the share has sufficient authority, the objects will be affected by whatever the malware is doing—be it encrypting the object (ransomware) or some other harm.

We had one client with a Read/Write share to root that had left the root at the default authority and many directories under root were also *PUBLIC *ALL. A user that was connected to the root share clicked on a bad link and an executable was downloaded that first renamed all of the directories on her PC and then went through and renamed all of the directories on IBM i that she had sufficient authority to, which was most directories. They were down for several days cleaning up the mess and restoring directories and their contents. Those organizations that have been affected with ransomware have had to delete the encrypted objects and restore from a backup to avoid paying the ransom.  

How can this nightmare be avoided?

• DO NOT SHARE ROOT! There is no need to share root, especially with a Read/Write share. If you must share root, then make it a Read-Only share to ensure malware cannot affect objects on IBM i. But I would prefer to not share root at all. Why? Because as I mentioned earlier, it shares the entire system, not just the IFS. So if someone maps to root, they can see the entire structure of the system. I would prefer not to expose the system in this way. Instead, create a share at the point that needs to be shared—no higher.
• Create shares as Read-Only whenever possible.
• Hide the share so it cannot be discovered by adding a $ to the end of the name when it’s created, e.g., ShareName$.
• Reduce the permissions on directories to reduce or restrict access.
• Reduce the number of users with *ALLOBJ special authority.

Scenario 2

The other issue that you’ll want to be concerned about is when documents, files, or other infected objects are stored on the IFS. While they will likely not infect IBM i, the next person to download or open the infected file will be infected. This is why IBM i has been dubbed the “perfect host” for viruses. It doesn’t get infected itself but infects everyone that comes in contact with the virus (think of Typhoid Mary, who doesn’t know she’s sick but gets everyone she comes in contact with ill.)

How do you avoid this situation? By virus-scanning your IFS to find those hidden pockets of infection. Do you think your IFS can’t contain viruses because you have virus-scanning software on all your workstations? You may want to reconsider that assertion. I’ve found that most organizations have some process that never goes through a virus scanner prior to storing an object in the IFS. Some examples include FTP downloads from a bank, EDI processes, downloads from a website, etc. I’ll be honest. I didn’t used to recommend virus-scanning the IFS if you had virus-scanning on all of your workstations. But after seeing customers with various ways their objects can get into the IFS without being scanned and because viruses have become so destructive, I’ve changed my mind. Today, I want to find viruses as soon as I can, so I find myself recommending a natively running virus scanner to scan the IFS more often than not.

Please note I said a “natively running virus scanner.” Yes, you could map a drive and run the antivirus from your PC against that mapped drive. But now you’ve had to implement a Read/Write share to root (see my previous point about that!) so that the virus scanner can isolate/fix the infected object. The process must run as a profile with *ALLOBJ so it has authority to scan and fix all objects. In addition, it’s likely to cause false positives as it attempts to run against /QSYS.lib (because it’s much more difficult to exclude /QSYS.lib when running a desktop antivirus). Finally, your AV software isn’t sent up to IBM i to scan there. No, when scanning from your desktop, everything from the IFS is brought down to your PC to scan. Imagine the network traffic! And by the way, it’s all in cleartext. Hopefully, now you understand my recommendation!

Summary

Unfortunately, phishing attempts are getting more and more sophisticated, and even the most seasoned employees can fall prey. Rather than leaving your IBM i open and vulnerable, I hope you’ll take these steps to avoid it being affected by malware.

Next month, I’ll be discussing tips for securing the IFS, including tips for securing the root (/) directory.

 

Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

 

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95 Now On Sale

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice