Stealing User Profiles!   Exploiting Unsecured User Profiles on IBM i.

By Dan Riehl

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 very do-able on almost every system I have seen. Once I have hijacked a more powerful profile, I can use that profile, or elevate my own User Profile's authority, to get the access I need to ANY File on the system.

So, How do I Become YOU? Hijacking another User's 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.

The setting of the USER parameter of the SBMJOB command is set by IBM default to *CURRENT, meaning the Submitted Batch job will run under the User Profile of the User that Submitted the Job. But, you can specify any user to which you have at least *USE rights.

Another hijack method, although a little more complex is to use the IBM supplied User Profile Swap APIs to set my current job to run under the authority of a different user profile. These APIs essentially allow you to Swap your job's current user profile to another user profile by specifying the other user's UserID and Password. But when you have *USE or better authority to the Swapped-To profile, the password is not needed. Once Swapped to a different user profile, you can perform any function allowed for that user profile. These APIs (QSYGETPH and QWTSETP) will be the subject of an upcoming article, and are well documented in the IBM i Information Center at:

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/apis/QSYGETPH.htm

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/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 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.

With all of this in mind, let's take a look now at Figure 1(The output of the command PRTPUBAUT OBJTYPE(*USRPRF))

In Figure 1, you'll notice several user profiles where the *PUBLIC authority on these is *USE or greater. So I can "Hijack" any profile listed as *USE, *CHANGE or *ALL. Especially onerous is that *PUBLIC has *ALL authority to the QSECOFR and MYSECOFR user profiles. This allows ANY user to run commands and jobs as MYSECOFR or QSECOFR, the most powerful user profiles 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 is quite alarming.)

The listings shown in Figure 1 and 2 are cut off from the full report, which, in addition to showing Object Rights, shows Data Rights. In order to "HiJack" a User Profile, *USE rights are needed, but even a USER DEF scheme will allow a "HiJack" if OBJECT OPERATIONAL Rights and DATA EXECUTE Rights are provided. For Group Profiles, this is important, in that a member of the Group has a ton of rights to the Group, but thankfully, does not have DATA EXECUTE rights to the group. This means that you cannot "HiJack" one of your Group Profiles, unless excess authorities have been granted to you, which would need to include DATA EXECUTE rights.

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 that *PUBLIC has *ALL authority to both of these profiles, so anyone on the system can "Hijack" their profile. But you may also notice that individual user profiles have *USE or *ALL authority to the user profiles. This allows these users to "Hijack" the respective user profiles to perform work under their authority.

It's not IBM's Fault

Under IBM i, 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.

Remediation for this Problem

To fix this problem, check your user profiles using PRTPUBAUT and PRTPVTAUT to make sure that user profiles are secured by *PUBLIC AUT(*EXCLUDE), and that no unneeded private authorities exist to the profiles. If they are not secured correctly, then change the authority to *PUBLIC AUT(*EXCLUDE), and remove any unneeded private authorities. Obviously, you will need to test to insure the change will not impact production processes.

Watch Our YouTube Video - Are your User Profiles Vulnerable to Profile Hijacking?

The Related Issue of Job Descriptions

Under system security level 30 and below another easy user profile "Hijack" method is available, which is widely known. 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 can run 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 can optionally run under the authority of QPGMR, and not my submitting user profile. This assumes I override the default of the SBMJOB command USER parameter from USER(*CURRENT) to USER(*JOBD).

The problem at security level 30 and below 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. These are QDBSHR, QDBSHRDO and QTMPLPD. Other IBM profiles like QSECOFR, QSYSOPR, etc should be *PUBLIC 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 this 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
5761SS1 V6R1M0  080215                                       SECUREMYI  09/23/14  17:23:45 CDT
 Object type  . . . . . . . . . :   *USRPRF                        
 Specified library  . . . . . . :   QSYS 
      
                          ASP                     Auth               ----------Object-----------
  Library     Object      Device      Owner       List    Authority  Opr  Mgt  Exist  Alter  Ref
  QSYS        ARRCFRX     *SYSBAS     ADDSECO             *ALL        X    X     X      X     X
  QSYS        AWWGROUP    *SYSBAS     QSECOFR             *USE        X    
  QSYS        MYSECOFR    *SYSBAS     QSYS                *ALL        X    X     X      X     X
  QSYS        RTVPGMR     *SYSBAS     MIKETL              *ALL        X    X     X      X     X
  QSYS        QDBSHR      *SYSBAS     QSYS                USER DEF   
  QSYS        QDBSHRDO    *SYSBAS     QSYS                USER DEF       
  QSYS        QSECOFR     *SYSBAS     QSYS                *ALL        X    X     X      X     X
  QSYS        QTMPLPD     *SYSBAS     QSYS                USER DEF    X 
  QSYS        XXXFER      *SYSBAS     QSECOFR             *CHANGE     X 
 

Figure 2 … Output of command PRTPVTAUT OBJTYPE(*USRPRF)

                                   Private Authorities (Full Report)                Page     1
5761SS1 V6R1M0  080215                                       SECUREMYI  09/23/14  17:26:21 CDT
 Library  . . . . . . . . . . . :   QSYS                                  
   *PUBLIC authority  . . . . . :     *USE                                
 Object type  . . . . . . . . . :   *USRPRF                                
 ASP device . . . . . . . . . . :   *SYSBAS    
                           
                          Primary     Auth                         ----------Object-----------
  Object      Owner       Group       List  User        Authority  Opr  Mgt  Exist  Alter  Ref
  AXXGEDS     DHWPGMR     *NONE             DHWPGMR     *ALL        X    X     X      X     X
                                            AXXGEDS     USER DEF    X    X                
                                            PRTACRX     *ALL        X    X     X      X     X
                                            *PUBLIC     *ALL        X    X     X      X     X
{ More profiles omitted }
 
  QSECOFR     QSYS        *NONE             QSYS        *ALL        X    X     X      X     X
                                            QSECOFR     *ALL        X    X     X      X     X
                                            SALLYW      *USE        X
                                            *PUBLIC     *ALL        X    X     X      X     X

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn