This is something thats bothered me for quite some time. It’s one of the primary reasons I got in to this whole business in the first place: The mainframe community is insular, unfriendly to newcomers, difficult to work with and stubborn as shit.
your example, John the Ripper, does not even run on z/OS so it is a very poor example.
Over the years I’ve seen amazing things said and done by mainframe experts that demonstrates why I worry about this platform. The original reason I wanted to write this was because of this discussion. This was about 10 months after support for JtR had come out for RACF and when RACFSnow came out. Both tools actively (and quickly) crack mainframe passwords. RACFSnow even comes with a nice little primer on how RACF actually obfuscates the password as part of the algorithm.
That whole thread is actually a really nice microcosm of how hard it is to deal with that world. You have to prove you know what you’re doing and what you’re talking about before you even step foot in that space. You’re also dealing with people who take IBMs word at face value. Why wouldn’t they, they’ve based their entire career and future around that platform.
This post is the perfect example of what I’m talking about. Keep in mind this post was made January 2013, just over a year ago (as of the writting of this post). It’s just such a wonderful example of:
Even IBM’s requirement in this scenario is insane: So yeah we store a hash of the password in the RACF database. But make sure no one has access to it, unless they need it, then it’s coo’.
SLEEPING the REXX is NOT the solution.What it is is an indicator of bad design
And I wish this was the only example of being unhelpful. Let’s take another look at a seemingly easy question: How does one ‘sleep' in a rexx script. I came across it because I had a script that had specific timing needs (to display a bitchin’ ASCII logo before clearing the screen) and this kind of thing is very very easy in windows and linux. The person asks a simple question (how to pause for a bit) and gets their answer. Then the rest of the forum chimes in with this and that about how using sleep isn’t the right answer and blah blah blah.
Keep in mind that this is on a separate forum on a completely different website and yet the person gets greeted with the exact same kind of toxic atmosphere.
I also often see this as a response to simple questions:
Or maybe you should just RTFM:
Or perhaps I’m just so inflexible in my understanding of IT concepts that you need to be extra pedantic and extremely careful when speaking with me because I WILL feign misunderstanding you.
I liken this example to someone who goes to the mechanic with a problem in one of their wheels and says “I have a problem with the wheel, it won’t spin” and a week later the mechanic come back yelling at you for failing to explain that you meant tire and not steering WHEEL!
I’m sure I could go on but this rant/stream-of-consciousness has gone on long enough. I will say that I have met some extremely helpful people in my travels but it took me having to drop words like LPAR, PARMLIB and CLASSES to get them to take me seriously.
So in my last entry we talked about how TSO, OMVS and ‘SU’ interacts strangely on the mainframe. Today we’ll talk a little about SURROGAT (or surrogates) which is basically the equivalent of SU in TSO. We’ll also talk a little about the side effects.
In z/OS you generally use jobs to perform tasks. Think of a job like a script file. The interpreter is your PGM, the commands are in SYSTSIN etc.
Using a VERY simple REXX script (CASE.MYID) which simply echo’s your USER ID to the screen we’ll demo how SURROGATES works.
CASE.MYID simply prints your USERID to the screen. That’s it! Here it is:
Using IKJEFT01, which is just a program that executes commands in TSO (think of it like #!/bin/bash), we’ll execute the CASE.MYID REXX script:
When we submit this JCL (using ‘SUB’) we’ll see the output of the command EX 'CASE.MYID'. To do that we’ll use SDSF:
Here you can see the StepName ‘EXECSU’ matches the one above. When we look at the output we get:
Now, say a user named BT0 had access to some very specific files that I didn’t have access to and BT0 was going on vacation for a week. He could give me access to submit jobs on his behalf. This is called ‘surrogate’ access.
He would do so using this command:
PERMIT BT0.SUBMIT CLASS(SURROGAT) ID(CASE) ACCESS(READ)
After entering this command I (CASE) would have the ability to submit jobs on BT0’s behalf, and all it would take is a simple change to the JCL. In the first line you add ‘USER=BT0’ and now any job you submit is executed as though that user submitted the job:
To make the change clearer here it is outlined:
Now we submit this job and we look at the same output:
So from now on, any job you submit will be executed as that userid!
If BT0, however, had left on vacation without giving me surrogate access, I could still submit jobs as him, I would just have to include the ‘PASSWORD=’ option in the first line (which is also known as the jobcard). So I could put ‘USER=BT0,PASSWORD=0TB’ and it would act the same. Since sharing a password is a big no-no using surrogates is considered the right way to do this.
There’s one more fun and interesting thing you can do with surrogate. If you give someone access to BPX.SRV.<userid> in the surrogate class they can use SU (in UNIX) without having to know your password.
So for example, I issue the command:
PERMIT BPX.SRV.BT0 CLASS(SURROGAT) ID(CASE) ACCESS(READ)
Now, if I log on as CASE and issue the SU command all I need to do is hit enter at the password request (without submitting a password) and I have access. Here’s an animation demonstration:
Worse still, if I use ‘su -s’ I won’t even be prompted for the password, it will just straight up give me access.
Take that as you will and see what ways you can thing of taking advantage of this!