Hacker Defends DEF CON Talk on IBM i Vulns

Two weeks ago we told you about a presentation about hacking the IBM i server that was held at the recent DEF CON conference. Now the hacker behind the presentation is taking exception with assertions in the story, and insists that his hacking technique exploits security flaws in IBM i OS and don’t rely on poor server configurations. Carol Woodbury, a former IBM security architect, looks into the hacker’s new claims.

Bart Kulach, who runs the www.hackthelegacy.org website and delivered a DEF CON presentation by the same name, sent us this letter. It’s reprinted here with his permission:

Dear Mr. Woodie,

After reading your article about my latest Def Con presentation, I feel obliged to react as the text as well as reaction provided by Carol Woodbury may mislead the potential readers.

Having read Ms. Woodbury’s reaction, I have to notice the following errors in her logical reasoning:

1. For the privilege escalation, you DO NOT initially need any special privileges besides membership to a group profile, for which profiles have ownership set to *GRPPRF. By jumping to other profiles, it might–I stress it might–be possible to escalate access rights to higher level, given that some linked profiles are connected to that group. This is a standard setting used by the majority of commercial banking and insurance products I have pentested. Therefore, Ms. Woodbury’s assumption of having *ALLOBJ and *SECADM is wrong.

2. The statement provided by you: “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” is simply false. The presentation provides information about the QSYRUPWD API allows for getting password hashes that can be easily cracked offline.

3. The major attack vector stressed in the presentation relates to the Java interface. The Java VM residing within AS/400, due to its nature, gives the user more visibility of the system and allows for deeper information gathering than via other interfaces. Also, the pure Java interface bypasses certain limitations set either via iSeries Navigator or 5250. This fact is not mentioned or discussed in the reaction and seems to be inconvenient for Ms. Woodbury to mention.

4. After reading the quotation: “On a production system, most people aren’t allowed to compile programs. [. . .]So it’s not just anybody who can run that.” I got assurance that Ms. Woodbury didn’t really put much effort into reading the full presentation nor contacting me before giving her impressions. Again, as mentioned above (and in the presentation), the Java interface is enough to make use of certain APIs without having to compile and/or promote any programs on the AS/400 box itself.

5. Also, regarding this comment: “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. […] This guy provides none of it.” Please note, that solutions were discussed and provided during the session. It is up to author’s decision to decide what information is included in the slides, and what is provided during the session. I am happy to exchange my knowledge and experience with Ms. Woodbury if she is open to enter into dialogue.

While I have other, personal reactions to the text, including the tone it’s written in, I still feel happy that IT Jungle raises the problem of AS/400 security. Also, I want to ascertain the readers that the presentation was not made to blow smoke but to raise awareness on potential security issues on corporate AS/400 systems. Finally, the presentation was aimed to raise a question to IBM on when real improvements on the field of security can be expected. So far, the question remains open.

Best regards,

Bart Kulach

Below is the response from Carol Woodbury, who was quoted extensively in the original story:

Dear Mr. Kulach,

I’ve read your response to my interview and hindsight obviously says I should have contacted you directly about my concerns. It’s clear to me that we share the same passion about the need to get the IBM i (iSeries) into a more secure configuration. And while our styles and methods for raising the awareness differ, we are in obvious agreement that many IBM i systems are not configured securely and that data is at risk.

Let me respond to your responses:

1. Let me clarify. While I see vendors requiring application users to be a member of the group owning the application, I do not also see them requiring that owning group to also own the users’ profiles. I agree that being a member of the group that owns both the application and the application users’ profiles is not a secure configuration. But while I’ve seen this configuration on occasion, it much more the exception than the rule. Simply being a member of a group profile does not allow you to use another member’s credentials as I’m sure you know. The group would have to own all of the profiles. Again, since this is not a configuration I typically see, I use a different example. The application configuration issue I point out is that when the application users are members of the owning group, they (the application users) also own the application. They, therefore, have *ALL to all application data.

2. My point is that this API does not return a cleartext password and that work needs to be done with the value returned before you can get a password. Also you have to have *ALLOBJ and *SECADM special authority to call the API. If you’re saying you can call this API without *ALLOBJ and *SECADM, then this is a bug and it needs to be reported to IBM. I’m also guessing that the passwords being cracked are only available at password level (QPWDLVL) 0 and 2. True?

3. I did not respond to the Java references because there was not enough detail on the slides for me to know what you had done for the exploitation. It’s no secret that limited capability settings are ignored by most interfaces outside of the 5250 interface and many settings in Application Administration are merely security by obscurity. If you are referring to something other than these settings, then again, the details were not in your slides for me to comment on.

4. My mention of needing a compiler was in reference to the use of the QSYRUPWD API. If you’re saying that you’re calling the API using Java from your desktop–OK. But it still remains that the process invoking the API has to have *ALLOBJ and *SECADM. (Again, if that’s not true, then please report that bug.)

5. You’re correct–it’s up to the author to decide what it is on one’s slides. I prefer to publish the resolution to the issue along with the issue because I feel that it provides the attendees with a better educational experience. It gives them reference material if they didn’t write down everything and/or they need to refer to it several months later. (Also, by publishing the resolution with the slides, my motives never have the chance to be called into question should the slides be viewed outside of the actual presentation.)

I appreciate your passion and a dialog is certainly warranted but there’s one topic I want to make sure is on our agenda. It seems like you’re saying there are gaps or vulnerabilities for which IBM has provided no solutions. From what I can discern from your slides, all of the issues you discussed can be resolved by implementing the features included in IBM i–object level security (e.g., setting *PUBLIC authority of *FILES to *EXCLUDE), appropriately managing system value settings (e.g., running at QSECURITY level 40 and QPWDLVL 3), and user profile configurations (limiting *ALLOBJ profiles and don’t make users the member of the application owner profile, etc). If you’re saying there are scenarios for which there is no solution, then I encourage you to immediately report the gaps or vulnerabilities to IBM so they can be fixed.

Sincerely,

Carol Woodbury

Vice President Global Security Services SkyView Partners, a Division of HelpSystems.

RELATED STORY

Did IBM i Just Get Hacked at DEF CON?