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:

VIDEO – Z Ransomware – SHARE 2017-San Jose

For anyone who missed my talk at SHARE 2017 – Ransomware on Z – Checkmate!

Here it is in its entirety. Enjoy! Ransomware on Z – Checkmate!

Please note that these videos and all videos released by SHARE are copyrighted by SHARE and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 license. This means that you can use but not edit or create derivative works of/from this video. All credit for video and its distribution are from SHARE.

New job – Doing what I love

Well – the time has come to start doing what I love to do full time. I couldn’t be happier to announce that I’m working with RSM Partners, Ltd to help bring their amazing mainframe services, security & software business to North America. This is going to be a great challenge and a great opportunity. Super excited to work with all the amazingly talented people at RSM.

RSM Appoints North America Director

Enterprise Systems Media – RSM Partners announces new N. America Director

Iptables brute force protection w/ nat

Setting up a vm on top of linux which communicates via a TAP adapter (on the 10.1.1.x network), I wanted iptables to prevent brute forcing to both the host ports (here 22 for ssh) and ports forwarded to the vm (here 443) as they are exposed to the internet. This little snippet does both by using iptables’ conntrack – simply more than 3 connections to either of those ports mentioned inside 60 seconds will lock that source IP out for 60 seconds.

The offending connections are marked in the nat table – prerouting chain, and checked (depending on whether forwarded or direct to host) in the filter table forward / input chains respectively. Logging is optional, you may choose to just DROP them once you’re confident on your ruleset.

Here’s a sample of the final ruleset I made:

For debugging, I cannot recommend highly enough using the TRACE target on the raw table (PREROUTING chain).

Something like:

Will show in your log, every stop along the iptables chains for every packet, including which rule or policy was acted upon it to get it to it’s final destination and shape. Don’t forget to remove it when you’re done!

Also, install the actual conntrack utility to see the connection tracking tables.