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. http://creativecommons.org/licenses/by-nc-nd/3.0/ 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.

Is that ransomware on your mainframe?

Next week at SHARE – San Jose, I’m giving a talk on ransomware on z/OS.  I’ve been asked multiple times if I thought ransomware could happen on Z, is it possible: Unequivocally yes.  Come see this talk and watch a live demonstration of how this might work.   If you are responsible for mainframe security, work for a company with a mainframe, or just want to better understand the landscape of this particularly insidious threat, don’t miss this talk.

Ransomware is a combination of 3 basic moving parts:

  1. A delivery mechanism (Phishing email, infected web page, malicious program).
    • This infects the user’s machine – allowing for sniffing of credentials and network traffic.  It can then upload a payload to the host system.
  2. File cataloging and encrypting.
    • Just what it sounds like – find files of interest, encrypt them in place, destroy the local copy of the key.
  3. Some type of Command & Control (or at least reporting) – centralized server.
    • Some means of transferring the keys out to the bad guys. Also, a way for the affected users to connect and pay ransom. (This is not strictly required, but does have precedent.  Steps #1 & #2 can happen regardless of the system’s ability to ‘phone home’ ).

We will also look at how to attempt to mitigate this catastrophic event, as well as ideas about how to recover from it.  Items such as two-factor authentication, proper ICSF / RACF security controls, egress filtering and intrusion detection.

Mainframes – Java – Deserialization

I was asked a week or so ago whether or not I thought z/OS would be susceptible to the types of Java deserialization attacks we’ve seen (a great primer from Fox Glove Security).   Of course!, I replied.  However, I don’t like unsubstantiated claims – so I built this POC:

java

It uses the basic ysoserial payload generator found on Github.   The SerialTestPlain.java file I use to test is from a blog here:

The source is simple:

Simple enough right?    Java on the mainframe is basically Java anywhere.  The only major gotcha (which should come as no surprise to anyone) are with issues of character translation  EBCDIC<->ASCII.   In this case, the ysoserial jarfile I built on x86 and just binary copied it to OMVS and that worked out of the box.

Other times I’ve had to use an a2e / e2a custom decoder – just depends on the implementation.  Currently working to test the JBoss exploits and modify them, if need be, in MSF for z/OS.  More as that unfolds!

NOTES:

While testing this POC first on x86, I kept running into an error like this:

The above mentioned blog helped – Basically Java 1.8u72 (since last December) needs to have the most current version of ysoserial, and use the CommonsCollections5 in order to work (and it does).   Prior versions of Java work just fine with the Release Version (0.04) of ysoserial.

Also, aside from fixes that are library based (like the Adobe Commons Collections one used here), most fixes to this bug have to happen in customized code, often written by organizations.   That makes this vulnerability particularly ugly and potentially difficult to mitigate.