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