White Hats Completely Dismantle Menu-Based Security
February 6, 2023 Alex Woodie
Think menu-based security can prevent cybercriminals from accessing the most important parts of your IBM i system? Think again, as the white hat hacking group Silent Signal recently demonstrated in a real-world penetration test of a bank’s IBM i system through a seemingly restricted green-screen interface.
Life was demonstrably simpler for midrange administrators before the Internet took off. Before we had all these different protocols providing access to applications and data – ODBC, FTP, SQL, Remote Command, etc. – an administrator could feel somewhat confident that users weren’t accessing things they shouldn’t by simply configuring their menus in a restrictive fashion.
But just as “security through obscurity” turned out to be (mostly) a myth, the protective powers of an old-school green-screen menu have turned out to be not nearly as solid as many believe. At best, menu-based security may play one role in a bigger security play. At worst, they may provide a dangerous false sense of actual security.
The latest IBM i security horror story comes to us from Silent Signal, the long-established Budapest, Hungary-based penetration testing outfit that’s beginning to turn its attention to the IBM i. The company only started exploring the security situation with IBM i in 2021, as we wrote about last September. But it’s already helping to pop some long held beliefs around IBM i security like an unwanted Chinese spy balloon, which can help us all improve security on this platform.
The company recently published a blog that discusses some of the details of a recent penetration test of a client’s IBM i system. The client, which Silent Signal says is a bank, provided only an IP address to the white hat crew, and challenged them to do much with it. As the security professionals showed, they managed to do quite a bit on the system, up to and including gaining ALLOBJ access, giving them free reign on the box.
Silent Signal’s Zoltán Pánczél does a good job of describing all the moves his team used to compromise the client’s system. It started out with the most basic, simplest hack: logging on through with a user profile with a default password. As we all know (or should know) by now, the default password for an IBM i user profile is the same as the user profile.
Menu-based security is a myth. (Image courtesy: Silent Signal)
Arguably the most impactful move the Silent Signal hackers demonstrated was bypassing the menu-based security system. Despite the default password, the bank had done some things right. It turned on the limited capabilities (LMTCPB) function, which theoretically restricts a user to run only the commands that are allowed by the administrator.
“At this point we had command line access, but immediately realized the user is ‘limited’ and we could not run CL commands with 5250,” Pánczél writes.
However, the Silent Signal hackers knew something that the bank’s admin apparently did not. Pánczél explains:
“Setting the profile ‘to limited’ is the recommended way to restrict users from using the command line, so this must be secure, right? WRONG. The limited user profile setting only applies to some protocols, like 5250 and FTP.”
The bank had done some things right, but one of the glaring security errors is that it had left 63 remote services accessible. One of these was the Remote Command API, accessible via port 8475. Silent Signal was able to use this protocol to run CL commands, thereby overcoming the inability to run CL via a 5250 emulator.
The hackers then did something very creative, which is surely why they charge the big bucks: They knew that every IBM i server can run Java, so they installed a Java-based Bind shell to port 4444, thereby giving them access to the PASE UNIX subsystem. Once in PASE, the options really opened up, including the ability to run SQL.
This allowed the hackers to scan the system for additional misconfigurations, and wouldn’t you know it, there were more! While the bank had installed an exit program to block the database service (port 8471), the hackers found a way to query the system anyway.
The resulting SQL queries allowed the hackers to find user profiles with ALLOBJ as well as which other user profiles were marked as *USE. Combining the results of the two queries gave the Silent Signal hackers all the info they needed. They switched into a user profile with ALLOBJ authority, changed the original user profile’s LMTCPB setting from Yes to No, took a screenshot for proof. The system had been compromised, the supposedly insurmountable barrier of menu-based security left in tatters.
“I think the biggest, most general takeaway, is security isn’t static,” Balint Varga-Perke, a senior IT security consultant and co-founder with Silent Signal, tells IT Jungle. “Something considered secure yesterday may become an easy target tomorrow, because of changes in the environment.”
The original idea that menu-based security can improve security on IBM i wasn’t wrong, he says. This approach is actively used with other systems, where the only way to access a system is through physical terminals with a limited set of options available through the menu. It’s a “reasonable strategy,” Varga-Perke says.
“We see similar setups when testing ‘kiosk PCs,’ that have only a couple of buttons exposed. It’s usually not possible to do anything unexpected with only two buttons, even if we know there is a regular keyboard interface inside the casing that would provide full control,” he continues. “The problem is that real-world midrange systems ‘have more than two buttons.’”
The first problem with relying on green-screen, menu-based security is that there are usually other ways to access the system, such as through Web or PC clients. The administrator must replicate the security controls across all of those systems, he says.
“Second, allowed menus can implement dangerous functionality and contain exploitable vulnerabilities,” Varga-Perke says. “While menu security can reduce the attack surface, this risk should be handled with a defense in depth approach, implementing proper, object-level access controls.”
Does the IBM i world need the security equivalent of a full-body scan? (Image source: Wikipedia)
The whole episode caught the eye of Jack Woehr, an IBM Champion for Power and a consultant with Seiden Group. Woehr sees a few problems with relying on menu-based security.
“The belief in menu-based security comes from more innocent times,” he says. “Whether young folks believe it or not, there was a time once when not every mom-and-pop shop was under attack by nation-state-sponsored hacking teams. In those days, ‘A lock was meant to keep honest people out,’ as the old saying goes.”
Some understaffed IBM i shops would prefer not to think about the security situation at all, he says. These are the types of situations where gaps in security can be overlooked.
“They’re running with two systems programmers where there used to be nine on staff,” Woehr says. “The consultants come in, offer ‘counsel of perfection,’ propose an amelioration breathtaking in scope, and like the character Pig in Stefan Pastis’s Pearls Before Swine, everyone goes back to bed and eats cheese and tries to think happy thoughts.”
Woehr theorizes that perhaps one-third of IBM i shops has an IT staffer who understands the Internet, while perhaps only 10 percent have someone who understands the ins and outs of SSH/SCP/SFTP. “This is an important attack vector of the future,” he tells IT Jungle.
As the recent IBM i Marketplace Study from Fortra (formerly HelpSystems) shows, security is still on the minds of IT staffers and IT decision-makers. In fact, security has been the top concern of IBM i professionals for the past six years straight, beating out other things that occupy the midrange mind, like modernization, high availability, skills, automation, cloud, analytics, spending, and compliance.
But all that concern hasn’t changed the situation on the ground much, according to Woehr. “The security posture in our niche is woeful,” he says. “There are so many avenues of compromise yielding possible results, ranging from noisy destruction to quiet data theft, that the mind boggles. The enemy is within and without.”
Woehr says he’s working with Seiden Group and Absolute Performance to develop a “full-body scan” security offering for IBM i, which he says is desperately needed.
In the meantime, pen testers like Silent Signal will continue to poke holes in old security setups. Such exploratory probes can’t be much fun for the patient, but if it helps them detect the damaged tissue before it succumbs to disease, then it’s well worth the time and expense.
RELATED STORIES
Security Still Top Concern, IBM i Marketplace Study Says
Pen Tester Silent Signal Targets IBM i
The Global State of Cybersecurity Is Not Good
Nice.
Been putting this into our presentations for over 35 years. LMTCPB, exit point, socket server exits, and monitoring are also a myth. Not that they don’t improve information security, but they are a LONG WAY from being all you need. As IBM Rochester and those of us with deep knowledge know, these myths are all what we in the CIS call Shiny Object Syndrom, slick sales pitches to make information security seem simple. All those years I worked on the assessments in Rochester and now as an IBM Business Partner, we know that the hardest part of information security is explianing to the business that it’s a bussiness risk, not an IT risk and that it’s not easy, or everyone would be safe and secure and the hacks would have stopped a long time ago, instead of increasing every year as they do.
I have been programming RPG for F500’s for 30 years and have the fortune of working for companies that practice the highest standards of security using state of the art products and practices, and I will have nothing more to say on that.
Having said that, this menu authority thing is a complete red herring. The key to this break in was using a Remote Command API for PC’s which deliberately provides access to IBM i to perform this kind of work. Has zero to do with 5250. In fact, they explicitly point out restrictions applied to 5250 but not this API stuff.
So the 5250 stuff is red herring crap. This company deliberately exposed their system to execution access by PC’s and all of this is something that could be done from PC’s from the get go, so deal with it honestly. A minor point is that these ports on the IBM i would not be exposed to untrusted sources and it is an unstated prerequisite that the pen group were given access to internal network to do this. Not that cracking Windows to gain access to internal network is insurmountable, to say the least, but needs to be said to be honest.
The next biggest fail was having a user profile with *ALLOBJ that you could just switch over to from whatever the default profile/password was used to gain access. Obviously a place that doesn’t know enough to reset default passwords will have some yahoo who was given *ALLOBJ authority, because… well, who cares, but of course they will.
Nevertheless, an excellent article with tons of good lessons, which this company at least had enough smarts to solicit a pen test will take to heart and hopefully address using said state of the art products and practices.