A username enumeration vulnerability is used to describe an application that allows someone to ‘guess’ usernames in an operating system or application. This commonly occurs when an application will give you a more descriptive error message than is really necessary during logon. For example the correct way to tell a user why the logon failed is:
The Username or Password you have entered is incorrect
The wrong way is to tell someone why the authentication attempt failed:
You have entered an invalid user ID
You have entered the incorrect password for “username”
Before I go any further I need to explain some complexities in z/OS. RACF is a security product by IBM which manages all security on the mainframe (in theory). z/OS can also have multiple components running on things like TSO, CICS, Unix and FTP servers. If you have a username and password for one you have access to all (so long as that account has been granted access).I’ll assume the reader is familiar with Unix and why normal telnet or FTP isn’t a candidate for user enumeration. CICS are generally custom applications (similar to a website) which may or may not allow enumeration. But the rest of this article is going to be talking TSO.
TSO (or Time Sharing Option) is the equivalent to shell access in Linux. You can run programs, commands or scripts from the READY prompt. TSO is where the magic happens. It’s where you can manage user access rights, run scripts (e.g. JCL). One interesting tidbit of TSO is the username limitation. Usernames are limited to 7 characters, must not start with a number and can only contain A-Z, a-z, 0-9, @, # or %. Which effectively means ALL users are limited to 7 chars.
To get to the TSO READY prompt you generally have to go through the TSO/E Logon Panel, which looks like this:
Before you get there, you might be asked to give your user ID first:
But what happens if you enter an invalid user ID? Say, for example I input the user ID: phoney?
Hmm, phoney didn’t work (of course, because its not a real user) but the TSO/E Logon panel was friendly enough to tell me why:
Already we have enough information to know that the logon panel for TSO would, easily allow you to enumerate users. But what does this error actually mean? It could mean that this is an account that doesn’t have access to TSO (and in a big shop you could have people with Unix accounts but not TSO) but in general it means that this account doesn’t exist.
From this panel you can enter any other user IDs and if it’s not a valid ID this panel will always present you with “Userid <user> not authorized to use TSO”. This is the current behavior and without bypassing this panel (with an exit) it will always show this information.
Now, what happens when you finally supply a valid userid but the wrong password?
Take a close look at the top of the screen, when you have a valid user but an invalid password the logon panel will tell you to enter the current password.
So knowing what we know about user enumeration we can enumerate all the users who have an account with TSO access. We could do this manually but it might be better, and faster, to use a tool. Unfortunately I’m not aware of any tools which support TSO user enumeration. Neither THC-Hydra nor Medusa support TSO, which is what prompted me to write my own script. I wrote a blog post about it a few months ago here, or you can just download the script on GitHub. A word of warning, on linux you’ll need to install s3270.
TSO Brute works by using python and has two modes:
- Bruteforce Mode: in this mode the script will iterate through a listing of users from a text file and once it encounters a valid user it will iterate through a listing of passwords to try and bruteforce the account.
- Enumerate Only Mode: in this mode the script will only identify valid accounts it encounters.
At the moment the script relies on you supplying it with text files of usernames and passwords. This script is slow. So very slow but it will get the job done, eventually.
How can companies protect themselves from someone enumerating their users and minimizing a potential brute force attack? Well, for starters take a look to make sure you’re mainframe has a low account lockout threshold. Second, use a third party product that forces a logon before accessing the TSO logon panel (but try not to put your password requirements on the logon panel):