Exploit Development – Mainframe Security

Mainframes, An Overlooked Cyber Attack Target: Part Two

Part two of my interview on Mainframes as a Cyber Attack target

Mainframes, An Overlooked Cyber Attack Target: Part Two

ArcticCon – Thawing the frame – slide video

Enjoy – Thawing the frame from ArcticCon

Watch the video (no audio) of the slides here:

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.

Metasploit, now with Privilege Escalation!

Update: The PR was accepted. Update your Metasploit installation and have a look!

Version 1 of an APF privilege escalation (Requires Creds) of a metasploit module has been submitted for inclusion. This version has no bells or whistles.

You can view it here:

PR# 8228 z/OS Privesc via authorized APF library write access

SP4RKCON 2017 – Hacking mainframes for CICS and giggles

Here’s the presentation I gave at sp4rkcon:

Hacking mainframe for CICS and giggles

(PPTX ~43mb)

SHARE2017 – Presentations

SHARE 2017 Mainframe Pentesting

SHARE 2017 Ransomware Mainframe Checkmate

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:

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.
File cataloging and encrypting.
- Just what it sounds like – find files of interest, encrypt them in place, destroy the local copy of the key.
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.

Return Oriented Mainframe Exploits

Follow up to "Smashing the DSA Chain". from mainframe

Another impeccable write-up by @_ciq

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:

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:

import java.io.ObjectInputStream;
import java.io.ByteArrayInputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.io.InputStream;
import org.apache.commons.collections.*;

public class SerialTestPlain{
  public static void main(String args[]) throws Exception{
    Bag bag = new HashBag();
    Path path = Paths.get(args[0]);
    byte[] data = Files.readAllBytes(path);
    InputStream d = new ByteArrayInputStream(data);
    ObjectInputStream ois = new ObjectInputStream(d);
    ois.readObject();
  }
}

import java.io.ObjectInputStream;

import java.io.ByteArrayInputStream;

import java.nio.file.Files;

import java.nio.file.Path;

import java.nio.file.Paths;

import java.io.InputStream;

import org.apache.commons.collections.*;

public class SerialTestPlain{

public static void main(String args[]) throws Exception{

Bag bag = new HashBag();

Path path = Paths.get(args[0]);

byte[] data = Files.readAllBytes(path);

InputStream d = new ByteArrayInputStream(data);

ObjectInputStream ois = new ObjectInputStream(d);

ois.readObject();

}

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:

Exception in thread "main" java.lang.annotation.IncompleteAnnotationException: java.lang.Override missing element entrySet
 at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:81)

1 2	Exception in thread "main" java.lang.annotation.IncompleteAnnotationException: java.lang.Override missing element entrySet at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:81)

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.

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