Fact or Fiction: Critical Security Flaws Are Found in IBM i

IBM i (OS/400, i5/OS)
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Carol Woodbury discusses a recent presentation at Defcon asserting that there are critical security flaws in IBM i.

 

As a security professional who's made her career espousing the virtues of IBM i security, it's disconcerting to receive an email from a client with the title, "New Critical Exploits for iSeries Announced at Defcon." Defcon for those of you who are not familiar, is one of the world's largest hacker conventions. It's held annually in Las Vegas. The presentation was called "Hack the Legacy! IBM i (aka AS/400) Revealed." Not that IBM i security is perfect or has never had flaws, but to see IBM i as the topic of a presentation at Defcon makes you sit up and take notice!

 

I opened the slides attached to the email with a bit of trepidation and then I realized that, as with most presentations I've seen that use grandiose and gee-whiz demos, this author had taken significant liberties and had obviously configured his system to be in an unnatural state. Kind of like the Labradoodle dog…yes, it's a dog, but the characteristics of this dog don't naturally occur in nature. Yes, this presenter describes vulnerabilities, but most of them are the result of purposefully misconfiguring his system or specifically taking advantage of the fact that he is using a profile that has *ALLOBJ and *SECADM special authorities. I'll describe a few of the issues and then, unlike the presenter, discuss some actual issues that we need to be aware of.

 

Let me say that I did not attend this presentation, so I can only comment on the content of his slides. My experience and my investigation into these so-called "flaws" says that if there had been something of note in this session, there would be a set of fixes coming quickly. I am confident that there are no fixes coming for any of these "issues." It appears to me that all "flaws" can be avoided with good security practices.

 

Let's take a look.

 

One of the assertions was that you could easily switch to run as a different profile. His assertion hinged on the fact that end user profiles were in the same group as administrators and programmers and that that group owned all of the profiles on the system. Two problems with this assertion: While it's obviously possible, I have never seen a system where all users are a member of the same group. Perhaps all end users are a member of the same group, but I have never seen programmers, operators, and administrators in the same group as end users. It is true that anything the group owns, the users also own (that is, have *ALL authority to). And certainly, if I have *ALL authority to a user profile, I can use several methods to change my job and run as that profile—even a profile with more privileges than mine. Here's where the example falls down: the appropriate use of group profiles demands that you group like sets of users. In other words, you put everyone who performs the same job (role) in the same group. You don't put users in totally different roles into the same group. So his example doesn't make sense. What he could have shown—and which I have seen—is when the *PUBLIC authority of user profiles has been changed from the default setting of *EXCLUDE to *USE. This is an exposure. Setting a profile to be *PUBLIC *USE gives all users on the system the ability to submit a job and run as this profile. If the profile has *ALLOBJ and *SECADM, it allows the user to submit a job and create a new profile that also has *ALLOBJ and *SECADM and now that user can have some real fun. Can there be an exposure with the authorities associated with a user profile? Absolutely! Just not the examples he was showing.

 

Another assertion was that an end user could run a remote command and that this ignores the limited-capability setting in the user profile. Excuse me, but that's hardly new news! Anyone who has paid attention to IBM i security in the last 15–20 years knows that the limited capabilities setting in the user's profile is of limited (pun intended) value. What is required to protect your data is object-level security. If the user doesn't have authority to download or upload (modify) a file, I don't care what interface is used—remote command, ODBC, JDBC, etc.—the attempt will fail. Clearly the presenter was either using a profile with *ALLOBJ special authority or had applied no object authorities.

 

An assertion that was also very misleading is that anyone can use the QSYRUPWD API to get IBM i user profile passwords. This API is intended for use by HA and password synchronization vendors to allow you to have the same password on multiple systems. The first problem with the presenter's assertion is that this API can be run only by a profile that has *ALLOBJ and *SECADM special authorities—not just any end user. Second, even if you determine how the value returned by this API is formatted, it's still not the user's password. As the V7R2 IBM i Security Reference manual documents, users' actual passwords are not stored. The password is used as the key to encrypt the user profile name. Only a brute-force attack is going to get you back a user's password. Finally, the API returns only one value at a time—not the entire set of IBM i profiles. Unlike the sensational assertions of the presenter, there are some actions you can take to protect your system:

 

  • (Obviously) limit the number of profiles that have *ALLOBJ and *SECADM special authorities.
  •  

     

  • Audit the use of this API; if you detect use by something other than your HA or IDM (Identity Management) solution, send yourself an alert.
  •  

     

  • Run at a minimum of QPWDLVL 1, but better is QPWDLVL 3, which increases the character set of your passwords to be both uppercase and lowercase letters, any special character, and numbers.
  •  

     

  • Require the use of complex passwords—especially for profiles with *ALLOBJ and *SECADM—to make it more difficult to perform a brute-force attack to obtain valid passwords. The easiest way to do this is to use the options provided by the QPWDRULES system value.
  •  

     

    Final Thoughts

    Critical Security Flaws in IBM i: Fiction! While I have definitely seen what I would consider to be critical flaws in numerous systems' IBM i security settings, this is a result of the choices made by administrators, not a result of vulnerabilities in the operating system. No good can come from IBM leaving an exposure for which there is no fix. When there's an exposure revealed in a current release, IBM will provide us a fix. It's up to us to responsibly implement the features provided by IBM to protect our systems and data. It's also up to us to watch for and apply Integrity PTFs as soon as possible. Integrity PTFs have direct security implications. Best practices say that these should be applied as soon as possible. Staying current with PTFs, in general, is also a good practice.

     

    Am I upset that this presentation was given? Yes and no. Plenty of examples of common configuration mistakes are available that show how data can be left vulnerable on IBM i without having to show examples of configurations that are contrived. This makes me irritable because time is wasted explaining that these exploits don't make sense and that if you follow common-sense security rules, these assertions don't apply. However, I'm always happy when IBM i is discussed outside of the normal IBM or user group conferences—even at hacker conferences. This helps raise awareness and provides hard evidence that IBM i is known in the hacker community. I often tell my classes that this is the case, but most of the time I don't think attendees believe me!

     

    We all need to be diligent about how we protect our data. Data residing on IBM i is no different.

     

    BLOG COMMENTS POWERED BY DISQUS