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:
|
1 2 3 4 5 6 |
$:~/uss_apf/testmount1 $ extattr +a ./oeconsole $:~/uss_apf/testmount1 $ ls -alE ./oeconsole -rwxrwxrwx a-s- 1 CHAD SYS1 8192 Nov 16 17:26 ./oeconsole $:~/uss_apf/testmount1 $ extattr -a ./oeconsole CH$:~/uss_apf/testmount1 $ ls -alE ./oeconsole -rwxrwxrwx --s- 1 CHAD SYS1 8192 Nov 16 17:26 ./oeconsole |
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:
