Category: Exploit Development

A logical first step

The first z/OS exploit module in the Metasploit Framework, landed last Friday.

This is an exploit which takes advantage of a default or poorly configured FTP server. And, it requires valid credentials.  However, given this (and it’s a very common configuration), you will be presented with a very nice Unix shell – allowing for deeper testing of the system.

This is how it begins:  attackers look for low hanging fruit. The evolution of pentesting tools for the mainframe has to start somewhere, and this is the first concrete milestone in what has been an ongoing journey. Many x86 exploits are simply taking advantage of default configurations or poorly written code. z/OS is no different – it can suffer from neglected configurations and defaults like all other OS’s. So, that’s where I started. From here, we’ll build on default configuration exploits and work up and on through binary / code exploitation. Baby steps.

At any rate – I’m very proud of how this turned out. Thanks to those who helped in the prototyping phases (SoF & others noted within the exploit) – and as always, the super helpful folks on the MSF teams. For those of you testing mainframe systems – hopefully it’ll help red teamers with an easy win and start the conversation on securing the big iron.

There are more goodies in the queue, so stay tuned!

PR # 6834 – Authorized FTP JCL exploit for z/OS

JCL Scripting for Metasploit-Framework

# update 3/31 – added Reverse Shell JCL – this can be used by any direct-to-JES2 delivery method (e.g. FTP, NJE, etc)

PR #6737

In continuation of adding more mainframe functionality to Metasploit, I’ve built (and am in the process of incorporating) JCL (job control language)-based payloads (and exploits which use them) within the framework.

Once these updates are complete, Metasploit users with credentials (or some other type of vulnerability exploit), will be able to submit jobs directly to JES2 via ftp(/s) or NJE (hats off to Soldier of Fortran, for the python prototype of NJE).

I’ll keep a running tally of the Pull Requests here, along with demonstrations and updates.

The first PR is simply a basic JCL cmd payload, that does nothing but submit a job which always returns a code 0 (success).

PR #6717

Here’s a screenshot of one of the finished exploit modules that will be submitted for inclusion soon:ftp_exploit

More to come!

 

A (mostly) useful debugger on z/OS

One item that has eluded me in my continuing quest to dive deeply into z Systems architecture is finding a native (IBM-supplied) assembler debugger/disassembler** on the platform that is fully functional, user-friendly and versatile.

Quickly I gave up on user-friendly and versatile and settled on trying to find one that was fully functional; simply stated – can execute and sustain integrity through any command in the POP manual. Of the 4 debuggers on the system, or as part of an add-on package, all have major out-of-the box ‘features’ that prevent them from being a worthwhile tool to anyone who has used a modern debugger (Like Immunity, Olly, or even GNU’s gdb).*

For this platform, my criteria for fully functional was this:

  1. Be able to debug programs which are link-edited APF-authorized and live in APF authorized libraries.
  2. Debug programs that switch into and out of supervisor state, and also switch PSW key mask values.
  3. Allow execution of commands that switch address space control (ASC) modes and manipulate storage in any of the 3 modes.
  4. Do the rest of the actions a basic debugger would do: set breakpoints, single step, watch variables / registers, examine and change memory, and so on.

The first 3 are functions unique to the z/Architecture platform, and I would expect at least the 3 z/OS based debuggers to handle (and possibly the one OMVS/USS based one also).   None do.  At least out of the box.  A quick list of the debuggers tried, and their limitations is at the end of this post.

Continue reading A (mostly) useful debugger on z/OS

Mainframe Shell – Metasploit Framework

The public metasploit-framework now (officially) has the basic underpinnings for beginning mainframe pentesting.

As of 10/25 – there is now a shell which, along with the some core architecture files implemented a while back, will let non-EBCDIC based machines running the Metasploit Framework communicate with processes on the mainframe, doing the ASCII<->EBCDIC conversions under the covers.

What can you do with it?  Nothing.  Yet.  The next steps are payloads, then exploits.   The payloads are in the bank, written and being tested against a couple different versions of Z/OS (1.12, 1.13, 2.1 for now).  Those should show up in the framework soon.   Once there, they provide the last basic requirement for exploit development (generally rewarded with some type of shell).

Other items in various stages of development (TN3270 work done in collaboration with and much coding from @mainframed767) :

 

Bind Shell – shellcode and source

This is an addendum to the last post.  Here is shellcode (and it’s stripped down source) that achieve the same goal as the prior post.   The difference is the payload is XOR encoded and the shellcode, and it’s source, have a built in decoder stub that decodes the payload in memory then jumps to it.

If the payload decoder coding looks a bit obtuse, it’s because instructions and operands were chosen that have neither nulls “\x0” nor EBCDIC newlines “\x15” in them.

The code also includes an egghunter that finds the location of the payload in memory, in case they need to be separated.   You can read about egghunters here and here if you aren’t sure what that means.

Full source code on github
Shellcode version

Mainframe Bind Shell – Source Code

Key in any basic toolset for pentesting the mainframe platform is a selection of payloads that can be used to test vulnerabilities.

Below is a bind shell payload, written from scratch in mainframe assembler.  The shell can be connected to using netcat. The payload differs from its Intel counterparts, in that it contains its own EBCDIC to ASCII convertor.  Because of this, the standard exec(‘/bin/sh’,’sh’) could not be used.  Read on for more technical details.

Continue reading Mainframe Bind Shell – Source Code

Building shellcode, egghunters and decoders.

Creating shellcode on System Z (Mainframe)  Unix System Services (USS) employs the same disciplines required for the same activities on Intel platforms.   The difference lies in the syntax, assembler mnemonics, tools available, and debugging utilities.  There are certainly other ways to achieve this, and I’m still refining my favorites.  The below is one of my early successful attempts at doing so.

If you have never created shellcode from scratch, including a hand-hewn encoder for zapping bad characters, I recommend you do so on a well-documented platform.   Become familiar with using basic (but powerful tools for the task) such as dd, od, gdb and basic python scripting.

Continue reading Building shellcode, egghunters and decoders.