Did IBM i Just Get Hacked at DEF CON?
September 2, 2015 Alex Woodie
A presentation at the recent DEF CON hacker convention in Las Vegas raised some eyebrows among the IBM i crowd. In “Hack the legacy,” a European IT worker purported to demonstrate how to bypass the operating system’s security and take control of the machine. But according to IBM i security pro Carol Woodbury, the so-called vulnerabilities that could let black hats into your machine are actually old hat. You’d be fooling yourself if you believed that the IBM i platform was never discussed among hackers. But rarely has the proof been so stark as what came out of DEF CON 23 last month, when Bart Kulach, an IT worker from Poland, purported to share secrets of IBM i security in his “Hack the legacy! IBM i (aka AS/400) revealed” presentation; you can find a copy of the slides at www.hackthelegacy.org/attachments/HackTheLegacy-DC23-final.pdf. “In many industries, although the front-end systems are all new and shiny, in the back-end they still rely on well-known, proven IBM i (aka AS/400) technology for their back-office, core systems,” reads the description of presentation on the DEF CON website. “Surprisingly, nobody truly seems to care about the security. Even if these nice IBM heavy black boxes are directly connected to the Internet.” In the presentation–which Kulach says is aimed at helping users to secure an IBM i system from the perspective of an external and internal intruder–purports to show a series of techniques for compromising the system, including “privilege escalation by nested user switching, getting full system access via JDBC, bypassing the ‘green screen’ (5250) limitations,” and how to get direct access to password hashes through an undocumented API.
Kulach’s presentation caught the eye of a worried IBM i user, who notified Woodbury, the former OS/400 security architect at IBM whose company, SkyView Partners, was recently acquired by HelpSystems. Woodbury checked out the slides, and came to a conclusion that Kulach was mostly blowing smoke. The main problem is his presentation doesn’t reflect how systems are actually configured in the real world. “The things he’s exploiting, you’d have to have ALLOBJ and SECADMN authority to do,” Woodbury tells IT Jungle. “The scenarios he presents are either not exploitable unless you have admin rights, ALLOBJ and SECADM, or else … you configure it that way, but nobody ever does that and the system certainly doesn’t ship this way.” That’s not to say customers configure their IBM i servers 100 percent correctly, security-wise, in the real world, Woodbury says. As a highly respected IBM i security expert, she’s seen her share of shoddy security settings in the wild. The poor state of security is also well-documented in the “State of IBM i Security” reports that HelpSystems’ subsidiary PowerTech does every year. “There are a significant number of systems out there that are just totally wide open and the data is very, very vulnerable,” Woodbury acknowledges. But to pull off Kulach’s approach to hacking an IBM i server would require such a poorly configured IBM i server that it just strains the credulity of the premise. Woodbury has an opinion on these sorts of “red herring” presentations. “They clearly have development machines or machines they can play around with on their own, and are not in traditional production environments, where things that are being restored or processes that are coming onto the system are very tightly controlled,” Woodbury says. “While this might work in a sandboxed system, hopefully most of the people have processes in place that would prevent this type of thing from even coming close to the production system.” Woodbury was particularly concerned about Kulach’s depiction of how to hack the QSYRUPWD API, which IBM exposes to allow high availability software vendors replicate passwords from a production to a backup machine. Kulach infers that users can gain clear-text passwords out of this, but Woodbury says that is false, and would require a brute-force attack to pull off. “Number one, that API requires ALLOBJ and QSECOFR privileges. And number two, it requires programing skills,” she says. “On a production system, most people aren’t allowed to compile programs. You’d have to promote it to the production box through a development process and/or they have tight control for what’s being restored onto the system. So it’s not just anybody who can run that.” Woodbury also takes issue with Kulach’s positioning the API hack as a security vulnerability in the OS. “I have a problem when people just talk about exploits,” she says. “From these slides, it makes it appears that IBM has left it wide open or this is how the system works naturally and there’s nothing you can do about. If there was a vulnerability out there, IBM would be working on it.” The odd part of all this, Woodbury says, is there are far easier ways to hack the IBM i server if you already have ALLOBJ and QSECOFR privileges.
“Why don’t you just talk about the things you can do normally with these privileges? Why go through the sensationalism to make it look like anybody on the face of the planet can do this, when there’s a lot of other things you can exploit . . . when you have this combination?” she says. “I can read any database file, download it to a spreadsheet. I can modify data with those privileges, create user profiles. I can go and change the QSECOFR password and get a listing of all the user profiles on the system. “You can do whatever you want to with ALLOJB and SECADM . . . so why would I go through the hoops that he’s gone through?” Woodbury has her suspicions. “He wanted to make this presentation as sensational as possible, so he went through some unnatural acts,” she says. “There’s certainly a number of ways that people have left the system with a less than desirable or secure configuration without having to bend over backwards to show this sensational scenario that doesn’t occur in real life.” While Kulach presented the information as education, he also neglected to do what every educator does when presenting about IBM i security vulnerabilities: provide the solution. “To me this doesn’t really serve the IBM i world well,” Woodbury says. “You would never see me or [PowerTech director of security services] Robin Tatam deliver a presentation on vulnerabilities without having a solution on the next slide. This guy doesn’t do any of that. While Robin and I might give a presentation called ‘Hacking the i,” what we’re trying to do is provide a service to the IBM i community. This guy provides none of it. So what’s his motivation?” Kulach provides a link in his presentation to his website, www.hackthelegacy.org. The website contains a forum for discussing IBM i hacking and penetration tools. It also offers download of Kulach’s own IBM i hacking tool, called hack400tool, which is also available on Github under a GPL v3 license. RELATED STORIES State of IBM i Security? Still Horrible, After All These Years Dubious Achievement: iSeries Gets Some Attention From Hackers
|
“The things he’s exploiting, you’d have to have ALLOBJ and SECADMN authority to do,”
This is partially true. Some commands do require that others do not. Like dumping the password hashes, something any user can do for their own account and others in the same group(?). ALLOBJ will allow to dump for all users.
“There’s certainly a number of ways that people have left the system with a less than desirable or secure configuration without having to bend over backwards to show this sensational scenario that doesn’t occur in real life.”
This is a grandstanding statement with no basis or evidence to back up the claim.
“You would never see me or [PowerTech director of security services] Robin Tatam deliver a presentation on vulnerabilities without having a solution on the next slide. This guy doesn’t do any of that. ”
Partially true. He does not state that in his presentation but if you use the hack400tool it contains a Audit program, in Java, that will provide a PDF report of needed config changes.
I have used this program and the functionality works. You can escalate permissions to other profiles. You can dump password hashes. You can execute commands on profiles that are restricted from doing so. So on and so on.
I have been doing penetration testing for years and I have yet come across a admin that was able to secure all of the configurations on all of his/her systems. Contrary to what Woodbury says, you will come across systems that are not configured securely. That may be because a user doesn’t know that they should not change a specific setting or there is a business reason for the insecure change. This is security 101 and not something new. The defaults IBM uses are often very insecure (default profile passwords anyone?) that should have been coded out decades ago and are well known issues. Bringing light to these issues may be one way to get IBM to finally make the changes needed.
If you admin an AS/400 I recommend downloading hack400tool and testing it out on a test LPAR or lab box. Learn about the security issues and don’t dismiss them offhandedly like Woodbury does.
Just ran the tool against an iSeries today. I was able to login with a low privileged account, escalate to security officer, and retrieve password hashes. The hashes have been cracked via John the Ripper.