Feature Article

Stealing User Profiles!   Exploiting Unsecured User Profiles

By Dan Riehl - SecureMyi.com

As an IBM i security consultant, I have the opportunity to help companies uncover flaws in their security implementation and determine the best way to fix the problems found. One of the major security risks that I find to be quite common in both large and small companies is unsecured user profile(*USRPRF) objects. The point of this article is to explain this risk, and HOW TO FIX the problem!

Let's say for a minute that I'm an inquisitive programmer or contractor at your place. I want to look at things, or do things that I'm prohibited from doing by IBM i security, like looking at the production payroll file, or worse yet, modifying some records in the file. Since my user profile is prohibited from even looking at the file, I need to find a way to get an elevated level of authority before the system will allow me to access the file. One particularly easy way to do this, in most IBM i installations is to steal the authorities of some user profile more powerful than mine, maybe QSECOFR. Being able to elevate my own authorities through what I call the "Profile Hijack" can be painfully easy at system security level 30 and below. Even at security level 40 and 50, it's do-able on almost every system I have seen. Once I have hijacked a more powerful profile, I can use that profile, and probably elevate my own User Profile authority to get the access I need to ANY File on the system.

So, How do I Become YOU?   Hijacking a User Profile?

One of the reports I run during an IBM i vulnerability assessment is the "Public authorities report" for User Profile objects. This report will tell me if any user profiles have authority that is not set to the default of *PUBLIC AUT(*EXCLUDE). The command to run this report is (Print Public Authority):

PRTPUBAUT OBJTYPE(*USRPRF)

The sample output of this command is shown below in Figure 1. In a moment I'll explain to you the significance of profiles listed in this report.

Another related report that I run is the "Private Authorities Report" for User Profile objects. This report as shown in Figure 2 below will tell me if any individual or group profiles have explicit authority to other user profiles. The command that produces this report is (Print Private Authority):

PRTPVTAUT OBJTYPE(*USRPRF)

Deciphering the output

Before diving into the reports, we need to understand what constitutes a clear vulnerability for the User Profile "Hijack". Let me provide an explanation of the problem.

If I have even *USE rights, or better(e.g. *CHANGE, *ALL) to someone else's user profile, I can "Hijack" their profile; using their profile to run commands. This can be as simple as running a SBMJOB command specifying the name of the "Hijacked" user profile in the USER parameter, as in:

SBMJOB CMD(CPYF FROMFILE(PAYROLL) TOFILE(*PRINT))   USER(PAYUSER)

(Where PAYUSER is a user profile that has read rights (i.e. AUT(*USE)) or better to the PAYROLL file, and to which I have, at least *USE authority to the PAYUSER User Profile.)

This SBMJOB command will submit a batch job to run under the PAYUSER user profile, and will print out the records in the Payroll file, that I, by my own authority, do not have access to, but to which the PAYUSER User Profile does have access.

Read More . .