The Real Effects of Malware on IBM i
Deck: Users with *ALLOBJ special authority is a no good, terrible, very bad idea.
One cool thing about working for iTech Solutions is the boss doesn’t nickel and dime our team’s education, resources, and technology. We need to practice on new hardware, so we got a POWER9. We need practice with external storage, so we got a V5030. We need to practice on virtual tape libraries, so we got one from Cybernetics.
I have a presentation in the Fall called IBM i Security: Perception vs Reality. I needed to test some system security scenarios with malware built by yours truly so my colleague Nathan Williams propped us up an IBM i 7.4 partition. We called it WLECYOTE…because we wanted to drop an anvil on its head.
Long preamble aside, I keep hearing how malware can’t affect the IBM i operating system. Just last week in fact I had to correct someone on Facebook who said that critical system files are immune from a malware attack. He said “prove it.”
So I’m proving it. For his hubris and your sake.
On WLECYOTE, we built the system very vanilla. The only things we added were a virtual tape drive, configured virtual Ethernet, and set up three user profiles: one for iTech personnel, one called WEAKUSER, and another called ALLOBJUSR. WEAKUSER has no special authorities. ALLOBJUSR has *ALLOBJ special authority. The last thing I did was create a read/write root directory share: a common Achilles heel.
I created a script that would do something similar to what a piece of malware would do: wreak havoc on attached network shares. The code would be launched as a macro from an excel spreadsheet. It iterates through every directory and attempts to delete whatever it finds. I originally wanted to encrypt the files it found, but that would take a little more time to set up so I settled on deletions. There’s a bit of a difference there. Compared to deleting an object, encrypting it may require different privileges depending on how you do it. But the point is the same: how does each type of user affect IBM i? Can a standard user cause damage to the core operating system?
As well, there are no user libraries on this system except for the defaults. No ERP. No payroll. Nothing of value to iTech’s business. On a customer system, there could be hundreds of insecure libraries and a couple hundred thousand IFS directories/objects.
Here are the results of each test:
I mounted the drive as a Windows share and supplied the WEAKUSER credentials, then I kicked off the script. This thing ran for the better part of a day, likely because of the VPN connection to the partition and the fact that it had a lot of delete failures to log.
All in all, the system was left functional. The only system integrity failure was with PASE which ended up in a *ERROR status. All other licensed programs were in good shape. PTF groups were intact. WLECYOTE did an IPL and came back up. Minor damage and very fixable by reloading the PASE product option. System integrity and functionality were intact for the most part with my limited testing.
Again, no user libraries or objects were on this system. If there were, and while the OS was left largely intact, the damage from a standard user could’ve been much worse from a data perspective. Most shops I do security assessments for have at minimum, 50% of libraries have *PUBLIC *CHANGE authority. This is why setting proper object security is important. Exclude rights by default. Minimize your damage risk.
Now here’s where we explain why allowing users to have *ALLOBJ special authority is no good, terrible, very bad idea.
First, I did not repair the damage that WEAKUSER caused because it’s a drop in the bucket compared to what ALLOBJUSER will do. ALLOBJUSER will do that damage again and much more.
I remounted the share using the ALLOBJUSER profile and kicked off the script. I ran CHKPRDOPT a number of times to check on the operating system integrity. Within 30 minutes almost all of the operating system program options were in *ERROR status. By the time the script was complete the following was observed:
- My once-active Telnet session was unusable.
- We were unable to get a functioning console to the partition from the HMC.
- SMB was actually still up! I could navigate to different directories on the IFS.
- Navigator for i was unusable.
- We attempted an IPL from the HMC. It did not succeed. Partition left in an error state with a B90037FF reference code.
Great success. WLECYOTE partition destroyed.
At this point, we’re looking at a scratch install and recovery from our last WLECYOTE full system save to recover the system. But we’re not going to do that. Nate and I have proven our point.
- Sharing the root directory of the IFS is unacceptable. Even standard users can cause damage.
- Providing users with *ALLOBJ special authority is unacceptable. Even without the root share, someone with *ALLOBJ can achieve similar results by simply deleting the system by putting a 4 on the root directory with a WRKLNK command.
- The combination of points 1 and 2 can be a catastrophic scenario.
- If your user libraries and IFS do not have proper object-level authority set, they’d better.
- This is why full system saves are important.
- Share this article with anyone who thinks that *ALLOBJ is a necessary evil. With new features like Authority Collection, pulling those rights back from people who don’t need them is far easier. Authority Collection is yet another reason to get to 7.3 or 7.4.
All systems are vulnerable to malware, hacking, and misconfiguration. IBM i is not different.
Learn what VERIFi Security Advisor can to do ensure you minimize your security vulnerability risk.