A Simple IBM i Penetration Test Lesson – Part 2

A few months ago we talked about two very simple core components of our IBM i penetration test: exploiting firewall NAT rules and default passwords.

I wanted to build upon that by showing you other ways to properly lock down your system by way of showing you how to easily exploit it.

So let’s talk about object authority on user profiles…

Now, most people look at a user profile and think about some of the attributes defined within, such as special authorities, initial menus, password expiry intervals, etc. Those are certainly important, but I want to focus on the object itself.

By default, IBM i user profile objects are given the *public authority of *exclude. That means that users without *allobj special authorities or private authority to the user profile objects have no access to view a user profile or determine anything about the aforementioned attributes. Unfortunately, there are always a few profile objects on a system that have *public authority of *use, *change or *all. And guess what? Those profile objects usually have some sort of special authority. I’m not sure just why that is but my guess is that generally they’re vendor-created profiles. A vendor gets on the system and has the ability to create user profiles and set them up for adopted authority for their software…but they just didn’t really know what they were doing. They end up giving the new user profiles special authorities and then set up the profile object as something other than *public *exclude.

So, when we come into the picture on a white box penetration test to check if we can elevate our authority, the first thing I attempt to do is see what user profiles are not set up as *public *exclude. Why would I do that? It’s a simple vulnerability I want to exploit. It’s an old and simple hack, but a very effective one if you’re not buttoned up. And so you’re aware, there’s a very similar one regarding Job Descriptions when you’re at QSECURITY level 30…but that’s another topic for another day. Quick point…if you’re at QSECURITY 30, you need to be at 40.

Back to the original point. If I have *use, *change or *all private authority to a user profile with some special authorities, then I can simply submit jobs and have them run as that particular user.

For example,

I can do a wrkusrprf *all on a command line and review what I can find. As an aside, for those thinking “Ha! We don’t allow a command line because our users have limited capabilities set on their user profiles,” then I’ve got news for you: it doesn’t matter. Do you think 5250 is the only door I’m kicking down? Limit Capabilities does not respect anything other than a Telnet connection. So once I see that my profile is locked down to have no command line inside Telnet, you can guarantee I’m trying Run SQL Scripts, FTP, SSH or the many other interfaces that allow me to have command line capabilities. If those interfaces aren’t locked down with exit point programs, I’ll have no trouble moving forward. It’s a cakewalk.

For Run SQL Scripts? Simple:

SELECT *

FROM QSYS2.OBJECT_PRIVILEGES

WHERE USER_NAME = ‘*PUBLIC’ AND SYSTEM_OBJECT_SCHEMA = ‘QSYS’ AND OBJECT_TYPE =

‘*USRPRF’ AND OBJECT_AUTHORITY <> ‘*EXCLUDE’;

 

A little redundant I suppose…because I’m only going to see the objects I have access to to begin with even without qualifying user profile objects that are not *public *exclude. This query is for YOU. It shows you all profile objects that are not excluding *public.

Once I’ve seen what user profiles I can access, I’ll review what special authorities they have.

SELECT *

FROM qsys2.user_info

WHERE special_authorities <> ”

 

Again making the initial SQL statement redundant, because I could run this first and get the same info. The first statement again is for you.

Once I review what special authorities people have, I can simply select the most powerful profile (let’s call it SUPERUSER) to do some damage with. Let’s just assume SUPERUSER has all special authorities. I then do any of the following:

CL: SBMJOB CMD(CHGUSRPRF USRPRF(STEVE) SPCAUT(*JOBCTL *ALLOBJ *SECADM)) JOBQ(QSYSNOMAX) USER(SUPERUSER)

Give my own profile special authorities it shouldn’t have.

CL:SBMJOB CMD(PWRDWNSYS OPTION(*IMMED)) JOBD(QGPL/QDFTJOBD) JOBQ(QSYSNOMAX) USER(SUPERUSER)

Power down the system.

CL:SBMJOB CMD(DLTLIB LIB(*ALL)) JOBD(QGPL/QDFTJOBD) JOBQ(QSYSNOMAX) USER(SUPERUSER)

Delete all libraries.

 

And so on. Just think about all the mischief a privileged user can get into and they can do any and all of it. My favorite example is to copy a “secured” library to a new one for me just to prove it can be done.

So there are a few things you need to think about.

1. Reduce *public rights on all user profile objects to *exclude.
2. Stop relying on Limit Capabilities. There are MANY other interfaces besides Telnet.
3. Start using exit point programs to lock those interfaces down so that people can’t issue commands through them.

If you need a hand with any of this, or want me to show you how open your system really is to an attacker, please reach out to [email protected] and we’ll book your penetration test.

 

More from this month:

• Permanently Applying PTFs & Why Doing So is Important
• How Does Power Systems Fit in My Organization?
• How To Explain Cloud Services To Your Mother
• IBM i Journaling Management 
• iTech iTip Videos
• Sips & Tricks: Coffee with iTech
• iBasics: IBM i Education for the Beginner System Administrator
• Let iTech Take You Out to the Ballgame
• Upcoming Events
• iAdmin Spring 2022 – Save the Date!
• iTech Spotlight
• IBM i, FSP, and HMC release levels and PTFs (February 2022)