Are your user profiles open to Abuse?

 

By Dan Riehl

 

First Appearing in System iNEWS Magazine

 

2004-2009 Dan Riehl , All rights reserved

 

 

As an OS/400 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 objects. The point of this article is to explain this risk, and how to fix it.

 

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 OS/400 security, like looking at the production payroll file, or worse yet, modifying the 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 OS/400 will allow me to access the file. One particularly easy way to do this, in most OS/400 installations is to hijack the authorities of some user profile more powerful than mine, maybe QSECOFR. Being able elevate my own authorities through what I call the "Profile Hijack" can be painfully easy at system security level 30 and below. Even at level security level 40, it's probably do-able. Once I have hijacked a more powerful profile, I have elevated my authority, and thereby I get access to the payroll file.

 

So, How do you Hijack a User Profile?

 

Of the reports I like to run while doing a vulnerability assessment is the "Public authorities report" for user profile objects. This report will tell me if any user profiles have authority other than *PUBLIC *EXCLUDE. The command to run this report is (Print Public Authority) PRTPUBAUT OBJTYPE(*USRPRF). The output of this command is displayed 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 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 and batch processes. This can be as simple as running a SBMJOB command specifying the name of the other user profile in the USER parameter, as in:

 

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

(Where OTHERUSER is a profile to which I at least have *USE authority.)

 

This command will submit a batch job to run under the OTHERUSER user profile, and will print out the records in the payroll file, that I do not have access to, but to which the OTHERUSER does have access.

 

Another hijack method, although a little more complex is to use the IBM supplied User Profile Swap profile APIs to set my current job to run under the authority of a different user profile. These APIs (QSYGETPH and QWTSETP) will be the subject of an upcoming article, and are well documented in the iSeries Information Center at:

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/QSYGETPH.htm

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/QWTSETP.htm

 

 

To reiterate the danger

 

If I have at least *USE authority to another user profile, that means I have the rights to use that profile to perform work on their behalf. I can submit batch jobs for them or dynamically swap my job to run under their profile in place of mine. In so doing I hijack and use their OS/400 authorities. If I have *USE authority or better to another profile, I do not even need to know their password to run commands and jobs as if I were them.

 

 

So, let's take a look back at figure 1(the output of the command PRTPUBAUT OBJTYPE(*USRPRF))

with all this in mind. In the figure, you'll notice several user profiles marked in Red type. The *PUBLIC authority on these is *USE or greater. So I can hijack any profile listed in Red. Especially onerous is that *PUBLIC has *USE authority to the QSECOFR user profile. This allows any user to run commands and jobs as QSECOFR, the most powerful user profile on the system. This affords me the opening to do ANYTHING on this machine. (Note: I have seen this vulnerability countless times on production boxes in large, medium and small shops. It's a particularly scary thing to see!)

 

In figure 2, (the Output of command PRTPVTAUT OBJTYPE(*USRPRF)) we see all the authorities, both *PUBLIC and private. In these selected profiles, you'll notice (In Red type) *PUBLIC has use authority to both of these profiles, so anyone on the system can hijack their profile. But you may also notice (in Red type) that individual profiles PRTACRX and DRIEHL have *ALL authority to a user profile. This allows these users to hijack the respective user profiles to perform work under their authority.

 

 

It's not IBM's fault

 

Under OS/400, user profiles are created with the default public authority of AUT(*EXCLUDE), this is exactly what you want. If you have modified the authorities of your user profiles to assign a different authority for *PUBLIC or assigned various private authorities, you are probably open to the user profile hijack attack.

 

To fix this problem, check your user profiles to make sure that user profiles are secured by AUT(*EXCLUDE), and that no unneeded private authorities exist to the profile. If they are not secured correctly, then change the authority to AUT(*EXCLUDE), and remove any unneeded private authorities.

 

 

The related issue of Job Descriptions

 

Under system security level 30 another easy user profile hijack method is available, which is widely known and has been published by iSeries NEWS, and is documented in the iSeries Security Reference. This method of hijacking a profile is one of the many reasons to run your system at security level 40 or 50.

 

This exposure is found when running a job using a job description that specifies the name of a user profile in the USER parameter. When a job is run using one of these job descriptions, the job runs under the authority of the named user, not under the authority of the submitting user. For example, I submit a job using a job description that specifies QPGMR as the USER parameter. When the job runs, it runs under the authority of QPGMR, and not my submitting user profile.

 

The problem at security level 30 is that I do not need any authority to the user profile named in the job description, all I need is *USE authority to the Job Description itself. This hole is fixed under security level 40 and 50, in which I need *USE authority to both the Job Description and the named User profile.

 

Caveats:

 

There are a few IBM profiles for spooling and other internal functions that should not be messed with. Other IBM profiles like QSECOFR, QSYSOPR, etc should be AUT(*EXCLUDE). In some companies I have visited, the applications have been implemented in such a way that *USE authority to certain profiles is required to make certain jobs run. If you have these implementation issues, you need to revisit why the authority was required in the first place, fix the problem and test-test-test before you implement. In any case, you will want to move ahead with a view to removing any requirement to have access to another user's profile.

 

 

Figure 1..Output of command PRTPUBAUT OBJTYPE(*USRPRF)

 

Publicly Authorized Objects (Full Report) Page 1

5722SS1 V5R2M0 020719 S16173A 12/15/03 09:55:27

Object type . . . . . . . . . : *USRPRF

Specified library . . . . . . : QSYS

ASP Auth ----------Object----------- ------------Data------------

Library Object Device Owner List Authority Opr Mgt Exist Alter Ref Read Add Upd Dlt Execute

QSYS ARRCFRX *SYSBAS ADDSECO *ALL X X X X X X X X X X

QSYS AWWGROUP *SYSBAS QSECOFR *USE X X X

QSYS RTVPGMR *SYSBAS MIKETL *ALL X X X X X X X X X X

QSYS QDBSHR *SYSBAS QSYS USER DEF X X

QSYS QDBSHRDO *SYSBAS QSYS USER DEF X X

QSYS QSECOFR *SYSBAS QSYS *ALL X X X X X X X X X X

QSYS QTMPLPD *SYSBAS QSYS USER DEF X

QSYS XXXFER *SYSBAS QSECOFR *CHANGE X X X X X X

 

Figure 2 Output of command PRTPVTAUT OBJTYPE(*USRPRF)

 

Private Authorities (Full Report) Page 9

5722SS1 V5R2M0 020719 S11FF1A 12/15/03 10:04:38

Primary Auth ----------Object----------- ------------Data------------

Object Owner Group List User Authority Opr Mgt Exist Alter Ref Read Add Upd Dlt Execute

AXXGEDS DHWPGMR *NONE DHWPGMR *ALL X X X X X X X X X X

AXXGEDS USER DEF X X X X X X X

PRTACRX *ALL X X X X X X X X X X

*PUBLIC *USE X X X

{ More profiles omitted }

 

QSECOFR QSYS *NONE QSYS *ALL X X X X X X X X X X

QSECOFR *ALL X X X X X X X X X X

DRIEHL *ALL X X X X X X X X X X

*PUBLIC *USE X X X

 

 

 

 

 

 

--------------------------------------------------------------------------------------------------------------------------------------

 

 

 

2004-2009 Dan Riehl , All rights reserved