RE: PenTest for Mainframe

["Richard High" <rico.suave.high () gmail com>]

The specific mainframe hasn't been give to our team. We are going in with no idea what type of mainframe. But the 
information that was provide has been very helpful. Thanks everyone. 

-----Original Message-----
From: Vic Vandal [mailto:vvandal () well com] 
Sent: Monday, August 06, 2012 3:53 PM
To: rico suave high
Cc: security-basics () securityfocus com
Subject: Re: PenTest for Mainframe

I'm guessing you won't get many responses to your inquiry, if any besides mine.  Mainframe hacking isn't impossible, 
but it's a bit of a dark art.  Auditing a mainframe (without doing a deep dive) can be relatively easy.  Pen-testing a 
mainframe is usually not easy.

I grew up on mainframes and used to do that sort of security and anti-security 10-20 years ago.  I don't have a testing 
checklist handy and would have to dig through some old offline data to share details (for OS/390, z/OS, aka MVS).  No 
guarantee on when I'd make the time to find that though, as my schedule is constantly overbooked to the extreme.  I 
also don't know you personally nor the context of your question, so I would be hesitant to share a lot of details.  You 
might want to audit your own organization's mainframe (all well and good), or you might be looking to illegally attack 
someone else's (which I can't condone or endorse).  Most likely you work for some security consulting company that 
wants to do some mainframe pen-testing for a customer, in which case I'm definitely not in the business of helping 
commercial companies or consultants generate more revenue (sorry).  But pointing you towards publicly available 
information is one thing I can do without any regrets or harm done.

Your question also mentions a desire to "cover all aspects".  You might not understand the scope involved here, and no 
one can provide such a response that wouldn't be volumes of information to pour through.

If your target runs Websphere you can always start with traditional web attacks.  Check out these related resources, as 
well as the many web-hacking tutorials that can be found online via quick searching.
http://www.redbooks.ibm.com/redpapers/pdfs/redp4839.pdf
http://publib.boulder.ibm.com/infocenter/zos/v1r11/topic/com.ibm.zos.r11.dgwa400/imwziu18300.htm

There are also a few "mainframe audit checklists" that might help (do a web search for them).  For each audit item that 
is supposed to be set a certain (secure) way do some research on what's possible if it's not set that way, and then try 
to mount some of those attacks.

Bone up on some basic system commands, so you'll know what to try if you get system access and what each command does.
http://publib.boulder.ibm.com/infocenter/zos/v1r11/topic/com.ibm.zos.r11.ieag100/cmdref.htm#cmdref

Read up on APF libraries.  If you can gain access to an insecure system perhaps you can leverage those to much more 
powerful access.  There used to be an old vulnerability to where if you could read the contents of an APF library 
(which 95% of system admins leave readable) you could write your own program using any of the same program names.  Then 
when you ran your trojan program the system would cross-check the actual APF library, find a matching name, and let 
your program run with elevated privileges.  Yep, totally stupid.  That's been fixed for a long time, but that's just an 
example of the system not being bulletproof, and that IF you can exploit an APF weakness it pays big dividends.

Some mainframe systems don't have the SYS2. and SYS1. DSNs properly secured.  Lazy or ignorant Admins may have provided 
excessive permissions to those DSN suffixes to everyone.  The terminology differs depending on the security package 
used, but for comparison sake it's like World permissions on Unix or PUBLIC permissions in Oracle (or Everyone in 
Windows NTFS or Share permissions).  For mainframes running CA-TSS those "everyone" grants are in what's called the 
*ALL* record.  Anyway some of those SYS2 and SYS1 DSNs contain information/programs/etc. that shouldn't be accessible 
to everyone.  I have a personal checklist on the "interesting" ones, but again I don't have that handy.  You can find 
those system default DSN names and descriptions by searching online though.  You'll have to figure out which ones are 
interesting based on their individual descriptions, and then see if they're secured or not.

Read up on RACF security administration.
http://publibz.boulder.ibm.com/epubs/pdf/ichza7a0.pdf
Yeah I know, that's 800 pages of content.  I didn't say it would be easy.  But look at that just like an audit 
checklist - reversing the secure configuration into what can be exploited if not properly secured.

Also read up on ACF2 and TSS security administration.  I don't have any stats on which is used more commonly these 
days.  ACF2 is cheaper, and TSS is better.  I've provided enough links already, and you can easily search those 
yourself.

There are a variety of subsystems/facilities/etc. on z/OS, and they traditionally run IDMS, DB2, and Oracle databases.  
Attacking those databases over the network can be an easy way to pen-test, provided that you're already in the 
corporate network and can access those TCP/IP ports and protocols.  Besides the web side that's the 2nd thing I'd try 
attacking (the databases).  
And if I were able to get some access to TSO/ISPF I'd try running jobs or commands that can disable (or enable) some of 
the security controls for those companion facilities and/or databases, using TSS or ACF2 commands and routines.  That 
may sound vague but the point is that some resources can have their security protections completely enabled or 
completely disabled by running a quick snippet of JCL, when the resources/commands/programs used to enable or disable 
security are not properly protected themselves.  That's always fun when you find a case like that (I have).

It's only of little value compared to getting onto an actual mainframe system, but you can find some MVS and TSO 
emulators, that you can run on a Windows PC or *nix system to practice system navigation and commands.  You'll want to 
be able to navigate around in TSO and ISPF, if you can actually hack yourself some logical access to the target system.
http://www.hercules-390.org/
http://www.z390.org/
http://faculty.cs.niu.edu/~leon/benson_tso_guide/guide.php?section=2  (just a quick look at one of the front door 
interfaces)

That's all I've got for now.  There's a LOT more to mainframe security but I have other work to do.  Good luck and 
happy reading.

-Vic



----- Original Message -----
From: "rico suave high" <rico.suave.high () gmail com>
To: security-basics () securityfocus com
Sent: Monday, August 6, 2012 11:13:36 AM
Subject: PenTest for Mainframe

I'm looking if anyone has any experience with pentesting a mainframe and if they have some sort of tech checklist or 
guide to to cover all aspects. 

Thanks.


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------