|
||
|
October 24, 2012 - Vol 2, Issue 18
|
||
|
||
|
Feature Article
"Hijack" a User Profile on IBM iBy Dan Riehl As an IBM i security consultant, I often 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, or possibly elevate my own authority to get the access I need to the Payroll file. So, How do you Hijack 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 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 outputBefore 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(OTHERUSER)
(Where OTHERUSER is a user profile that has, at least, read rights to the PAYROLL file and to which I have, at least, *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 user profile does have access. |
|
In This Issue
Quick Links
Thank You! To Our Great Sponsors
Platinum Sponsor |
IBM i Security and Audit ResourcesIBM i Security Videos from SecureMyi.com SecureMyi Newsletter Home and ArchivesSearch Security Site for IBM i and i5/OS IBM i Security Reference - IBM i 6.1 IBM i Security Reference - IBM i 7.1 QAUDJRN Audit Types By AUDLVL 6.1 QAUDJRN Entry Type Record Layout 6.1 RedBook - Security Guide for IBM i 6.1 PCI SSC Data Security Standards 
|
|
IBM i Security News Bytes
Arpeggio Software releases FREE version of ARP-SFTP for the IBM i IBM i Security Calendar of Events
|
|
|
Featured YouTube Educational VideoIBM i Security
|
||
|
||
Security Shorts -
By Dan Riehl When you create a new file or program, you have the option of specifying the authority to the new object. But we typically do not specify that authority. Each CL command used to create objects has the parameter Authority (AUT), which is used to specify the authority for the new object. For most of us, we do not even see the AUT parameter because we seldom prompt the CRTxxx commands. Even if you doprompt the CRTxxx commands, the AUT parameter is usually the very last parameter in the long list. We seldom get that far in the prompt. Understanding CRTAUT and *LIBCRTAUTFor almost all object types, the CRTxxx command uses the default value AUT(*LIBCRTAUT). This value *LIBCRTAUT is specified to assign the new object authority based upon the library in which it is created. So for one library, the value *LIBCRTAUT may mean AUT(*CHANGE), for another library it may mean AUT(*EXCLUDE), depending all on the library's CRTAUT value. When you create or change a library (CRTLIB, CHGLIB), one of the parameters is Create Authority (CRTAUT), as shown in this command to create a library: CRTLIB LIB(MYLIBRARY) CRTAUT(*EXCLUDE) When the library's CRTAUT value is *EXCLUDE, new objects created within the library will be set to *PUBLIC AUT(*EXCLUDE), based upon the CRTAUT of the library. Overriding the Library's CRTAUT ValueYou do not need to accept the CRTxxx command default of AUT(*LIBCRTAUT). You can specify the authority for the object as needed, as in the following command to Create a Data Area: CRTDTAARA DTAARA(MYLIBRARY/MYDATA) TYPE(*CHAR) LEN(100) AUT(*USE) Here, the CRTAUT value of MYLIBRARY is not considered, and the data area is assigned *PUBLIC AUT(*USE) authority. Using an Authorization ListWhen setting the value for a library's CRTAUT parameter, the name of an authorization list can be assigned, as shown here on the Change Library (CHGLIB) command: CHGLIB LIB(MYLIBRARY) CRTAUT(MYAUTL) Then, when a new object is created in the library, the new object will be secured by the MYAUTL authorization list. This assumes that we accepted the default value on the CRTxxx command of AUT(*LIBCRTAUT) or that we specified AUT(MYAUTL). Using an authorization list to assign the authority for a newly created object gives you some nice flexibility. You are not limited to only assigning *PUBLIC authority, but when using an authorization list, you can assign all private authorities to the object at the time the object is created. Object Ownership: The GotchaThe only gotcha when it comes to assigning authority to a new object is that the object will be owned by the creator or by the creator's primary group profile. The owner will have *ALL authority to the new object, which might not be what you want, especially if you are securing the new object with an authorization list. In these cases, you will need to develop a method to reassign the ownership of the new object. I'd be anxious to hear your ideas on the best way to set the exact authority that you want on a newly created object when the creator/owner should not have a distinct authority to the object. I am one who believes that most objects types should be owned by an "owning" profile, whose sole purpose for existence is to own objects. For example, create the user profile PRODOWNER. Assign PRODOWNER as the owner of your production objects. This owning profile PRODOWNER is not a group profile. It is simply a profile to own objects. This works fine in practice until someone creates a new object, which makes them (or their primary group) the owner and not PRODOWNER. What I'd Like to SeeIt would be great to have an OBJOWNER parameter on all the Create commands, where you could specify something like OBJOWNER(*LIBOBJOWN), which would assign the ownership of the new object based upon a library attribute of "Library Default Object Owner." But alas, right now we may need to retrofit the ownership of these newly created objects to set them correctly. |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
|
Send your IBM i Security Related News and Events! Advertise in SecureMyi.com Security Newsletter Copyright 2012 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |
||
