October 24, 2012 - Vol 2, Issue 18

SEA Live Webcast - Assessing your IBM i Security

SEA Live Webcast - Assessing your IBM i Security



IBM i Snapshot from Powertech



Security Compliance Automation Tools - Designed by Carol Woodbury - Security Policy Compliance - Vulnerability Assessments - Audit Journal Reporting - Register today for a FREE Trial! - Brought to you by SkyView Partners

Feature Article

"Hijack" a User Profile on IBM i

By 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 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(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.

Read More.

In This Issue


Featured Article - Hijacking a User Profile

Security Shorts - Authority for New Objects

Featured Video - Vulnerable User Profiles

Industry News and Calendar

Security Resources

Quick Links


Search Security Site for IBM i and i5/OS

SecureMyi Website

Security Training from The 400 School

SecureMyi Newsletter Home/Archives

Need Access to an IBM i? Visit RZKH.de


Thank You! To Our Great Sponsors


Platinum Sponsor
    Software Engineering of America


Gold Sponsor
    The PowerTech Group

    Skyview Partners, Inc

Sponsor
    Cilasoft Security Solutions

    The 400 School, Inc


IBM i Security and Audit Resources

IBM i Security Videos from SecureMyi.com

SecureMyi Newsletter Home and Archives

Search 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

COBIT Framework - ISACA

HIPAA Resources

HITECH Enforcement

CISSP - Certification


Follow SecureMyi on Twitter




Follow SecureMyi on YouTube




Cilasoft Security Solutions - Intelligently Engineered Security Solutions



IBM i Security News Bytes

Arpeggio Software releases FREE version of ARP-SFTP for the IBM i

Arpeggio Software , a provider of security software solutions for the IBM i announced the release of a free version of its secure FTP product ARP-SFTP.

ARP-SFTP is a native implementation of sFTP based on the OpenSSH library. It enables IBM i users to automate the file transfer process over a secure shell (SSH) connection with support for DB2 files as well as IFS.

See more Information from Arpeggio.


Raz-Lee Software Announces Major Enhancement to Change Tracker

Razz-Lee's Change Tracker software has been enhanced to now track Applying, Removal and Status of PTFs and related Objects.

Based upon QAUDJRN, Change Tracker monitors and reports changes made to programs(both source and object code) and other production objects.

See more Information from Razz-Lee.



IBM i Security Calendar of Events



Live Security Related Webcasts and Training for IBM i

10 Ways for Making Your IBM i Security Administration Easier
Live webcast - Featuring Carol Woodbury - Sponsored by Skyview Partners
Thursday, October 25 10:00 AM CT
More Information and Register to Attend

2012 IBM Power Systems Technical University
Featuring over 400 educational sessions and labs
October 29-November 2
Caesar's Palace - Las Vegas, NV
More Information and Register to Attend

Assessing your IBM i Security - Key Areas to Consider
Live webcast - Sponsored by the Software Engineering of America
Featuring Mr Mel Zucker
Tuesday, November 6 1:00 PM ET
More Information and Register to Attend

Attaining and Maintaining the Compliance Lifestyle
Live webcast - Featuring J.D. Seal - Vice President - Skyview Partners
Sponsored by Skyview Partners
Wednesday, November 7 10:00 AM CT
More Information and Register to Attend

Live 4-Day Hands-On Expanded Security Workshop for IBM i
Full Length Training Workshop - November 13-16 9:00am - 4:00pm Central Time
Dan Riehl presents his 4-Day Live Online Hands-on Security Workshop for the IBM i.
More Information and Register to Attend



IBM i Snapshot from Powertech


Is Your JD EDWARDS Database Secure? See how SKYVIEW PARTNERS can help!


Featured YouTube Educational Video

IBM i Security

Are your User Profiles Vulnerable to Profile Hijacking?

Featured Video - Misconceptions on Ownership and Authority to User Profiles
Live Online Training from The 400 School

Security Shorts -

Setting the Authority for New Objects

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 *LIBCRTAUT

For 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 Value

You 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 List

When 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 Gotcha

The 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 See

It 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
Security Services from SecureMyi

Expert Level Security Consulting
IT Security and Compliance Group, LLC

In Depth Security Assessment of IBM i
Upgrade to QSECURITY level 40 or 50
Forensic Research and Analysis
Audit Assistance and Remediation
Security Training for IT and Audit Staff
Security Software Selection & Configuration
Customized Security/System Programming


Live Training from The 400 School, Inc

Live Online Hands-On Workshops
Special Fall/Winter Class Discounts


System Administration & Control Nov 5-9

IBM i Security Workshop Nov 13-16

RPG IV Programming January 7-11



SEA Live Webcast - Assessing your IBM i Security

Training from The 400 School


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