All aboard the USS Exploits

Using UNIX System Services to escalate your privileges on z/OS (Pt. #1 of 2)

Much has been written about privilege escalation on z/OS using tried and true methods of abusing UPDATE access to APF-authorized libraries. Suffice to say when the code has made its way to Metasploit, the jig is up. The purpose of this post is to describe the other ways to gain APF authorization, the less documented/explored ways – via Unix System Services (USS, interchangeably referred to as OMVS).

By way of quick refresher, APF (Authorized Program Facility) is one of the (and by far the biggest) gateways between running programs as a normal user (problem) state and running them in a privileged, nothing-can-stop-me (supervisor) state – the latter having the ability to run any CPU instruction and read/modify any memory contents.

The z/OS mechanism to provide integrity via APF is through a list of libraries (another name for folders), the aptly-named “APF-Authorized Library List” or APF list for short. If you can clear the security hurdle and update one of these libraries (i.e. place your own binary in it) or add your own to the list (e.g. using an MVS command like SETPROG), what you can make the system do is limited only by your mischievous mind. I’ll include some links to useful tools at the end of this post.

Being able to update an APF-authorized library is still one of the biggest misconfigurations and risks I see all the time during mainframe pentesting engagements. If a company has hundreds or thousands of datasets in the APF list, then they may also have as many or more dataset profiles to secure them, management of all those profiles is a nightmare – and it only takes one misconfiguration to leave a hole that any attacker can find, with tools readily available on the internet, and ultimately exploit.

As some readers may be aware, APF authorized programs are entirely possible within USS, yet there is no concept of APF-libraries or an APF library list in USS. How then are programs authorized in the USS world? With one bit.

APF-authorized programs in USS are individually authorized with an extended attribute bit. To set or unset this bit, the program ‘extattr’ is used, and to list the presence of the bit, you can use ‘ls -alE’ example:

Note the “a” in the 4 bytes after the permission bits. These are the extended bits. The “a” denotes that this program is itself APF-authorized. Setting that flag is the only security hurdle required to bless the USS program as APF-authorized. So, our goal as pentesters is to get that bit set on a program that then elevates our privileges. Obviously, not just everyone can execute that extattr command; next we’ll look at what controls access to extattr.

In RACF there is a profile in the FACILITY class called BPX.FILEATTR.APF. Users with READ access to this profile can execute the commands I mention above. Obviously, this being a hacker/pentester blog, I’m not stopping here – but of course this would be a good permission to find out you have during a pentest. If you do, then once again you’re only limited by your creativity and coding skills. But, are there any other ways of achieving the desired APF authorization of a USS program? Indeed there are…

Now that we’ve learned what’s possible with APF authorized programs and the standard method for creating them in USS, the next post will give code examples which exploit these methods so we can gain APF auth in creative ways.

tools / reading:

Tips / Tricks – 7/2/15 (update)

Updated.  Added update to the packet capture section below, included pcap export!

ISPF editor

  • Want more real estate in your ISPF editor?   In an editing session enter EDSET in the command line, then check the line marked:
      X Remove action bars in ISPF edit and view panels
    This will remove the menu bars and give you more room.   If you haven’t already, I’d clear these two settings in the main menu ISPF settings also.

ispf_set

Unix System Services

  • These commands will help you find / list APF authorized binaries in USS.  First one finds apf auth with sticky bit (suid) set.  These could be great targets for exploits.  Second finds all apf authorized binaries (no dll’s or shared object files).  The ls -E is just a switch to ls, you can use separately to show the extended flags.  an “a” in the display (e.g.  a-s-) means the apf auth bit is set.
    • find / -type f -ext a \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \;
    • find / -type f -ext a -exec ls -E {} \;|grep -v .so|grep -v .dll

Packet Captures – TCP/IP Networking

  • Getting a packet capture on a mainframe is a non-trivial event.  I’ll save you the trouble of digging up all the requisite tutorials and lay down my version here:

There are 4 major components to this effort:
1) A trace writer proc, put in your favorite PROCLIB, created with JCL such as:

2) The TCPIP packet trace functionality. Started with a command like this from the master console or SDSF – (check the link at the bottom for more filter options):

3) Then, start the writer and execute the capture by issuing the following commands:

4) Using the IPCS functionality to format the trace into a spool file.  I use JCL like this (Make sure to modify datasets to match your system):

Bonus Step 5)  If you want to export the dump to a pcap file, readable by tcpdump, wireshark and the like, substitute step 4 JCL (the inline portion after DD* only) for something like the following:

Then I like to use USS copy and sftp (make sure you use something that does strict binary transfer) to dump the file to your PC and open with Wireshark.  Enjoy!

That’s it .. simple right?

Here’s some useful links:

TCPIP Packet Tracing

How to collect packet trace on z/OS

V TCPIP,,PKT command syntax

ZOS IP Diagnosis Guide (SNIFFER CTRACE and others syntax)