The 80's called - They Want Their Mainframe Back!

Published: 2013-01-09
Last Updated: 2013-01-09 14:51:50 UTC
by Richard Porter (Version: 1)
5 comment(s)

When I see TCP Port 992 open, I always get a warm feeling – I’m taken back to my first IT job, as a night operator on MVS and VM systems at IBM in the early ‘80’s.  And yes, we had Virtual Machines (that’s what the “V” stands for) back in in 1980’s, just on much bigger hardware!  
When I see port 992 these days, that typically indicates the telnets service (telnet over SSL), which often means it’s an iSeries (previously AS/400), or a mainframe system (OS/390 or z/OS).  Oddly enough, after 30-plus years today's z/OS mainframe class machines still have current versions of z/VM and MVS.  As with most common ports, traffic statistics for port 992 can be found in our database, at

This all seems like kind of a “back in the day” thing, you might think.  Didn’t we migrate all the mainframes and AS/400’s over to Windows and *nix back in the late ‘90s?  Only old coots like – um – me should care about that stuff, right?  Think again – migrating mainframe apps written in COBOL and the like, written in the 70’s, 80’s and even 90’s is a bear of a task – it costs big money and carries a ton of risk, and LOTS of companies have just let those sleeping dogs lie (aside from patching and upgrading that is).  And the iSeries platform just never went away – if you drive past a factory or a big-box hardware or department store, chances are pretty good there’s an iSeries datacenter running the show.

So just how common are these platforms on the internet?  In a simple scan of 2 class B’s I picked at random (Ok, I knew that they were both at colo’s), I found 2 iSeries hosts and 1 z/OS  telnets host.   If you’re using nmap, be sure to use –sV to get a better handle on the host offering up the service:

Nmap –p 23,992,1023,2323 –sV –open x.x.x.x

iSeries hosts almost always are well identified by NMAP  (even  a –version-intensity=1 will find them):

23/tcp  open  telnet     IBM OS/400 telnetd
992/tcp open  ssl/telnet IBM OS/400 telnetd
Service Info: OS: OS/400

Mainframes (z/OS) hosts are also well fingerprinted by NMAP (though OS/390 is long gone, it should be labeled as z/OS):

23/tcp   open  telnet  IBM OS/390 or SNA telnetd
992/tcp open  ssl/telnet IBM OS/390 or SNA telnetd
1023/tcp open  telnet  BSD-derived telnetd

We’ve mentioned a few common ports - besides port 992, what other ports might you typically see open on an iSeries host?

Service Name Port (Plaintext) Port (SSL)
Telnet (PC5250 Emulation) telnet 23 992
NetServer netbios  (yes, really!) 137 ---
NetServer netbios 139 ---
NetServer CIFS 445 ---
DRDA DRDA 446 ---
DDM DDM 447 448
Server Mapper as-svrmap 449 ---
RUNRMTCMD REXEC (just as good as netbios most days!) 512 ---
HTTP Administration as-admin 2001 2010
Service Tools Server as-sts 3000 ---
POP3 (MAPI) pop3 5010 ---
License Management as-central 8470 9470
Database Access as-database 8471 9471
Data Queues as-dtaq 8472 9472
Network Drives as-file 8473 9473
Network Printers as-netprt 8474 9474
Remote Command as-rmtcmd 8475 9475
Signon Verification as-signon 8476 9476
Ultimedia Services as-usf 8480 9480
IBM AnyNet APPC over TCPIP 397 (TCP and UDP) ---
Management Central as-mgtc  5555 and 5544 5566

Note that ports 23 and  992 on these platforms generally serve up TN5250 (iSeries) or TN3270 (z/OS) terminal servers over telnet or telnets.  You’ll also find (thanks to suggestions in IBM’s Redbook Series of books) that it’s common to see the unencrypted telnet running on ports 1023 or 2323 as an added security measure.  We can have a whole 'nother debate about how effective that is, especially if it’s in the vendor documentation.

OK – so now that we’ve found a target host, what might we look for if you are in a pentest or a security assessment engagement?  The same thing as you’d look for in any *nix SSH or telnet server  – problems with encryption (and the phishing opportunity that comes with it), mismanaged ssl keys (isc story ) and well known accounts with easily guessable passwords are all good places to start.  If the easy stuff works (every time for me so far), there’s no reason to try complicated attacks right?

For starters, let’s take a look at a typical certificate hosted on an iSeries host (organization specifics are elided):

C:>openssl s_client -connect x.x.x.x:992 2>&1
Loading 'screen' into random state - done
depth=1 /C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate chain
 0 s:/C=Ca/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ISERIES.ORGNAME.COM
   i:/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
 1 s:/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
   i:/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
Server certificate

Raw certificate material removed

subject=/C=Ca/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ISERIES.ORGNAME.COM
issuer=/C=CA/ST=Ontario/L=Some City/O=Organization Name/OU=ORGNAME/CN=ORGCOM
No client certificate CA names sent
SSL handshake has read 1401 bytes and written 322 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 975A05E1077C10000000000000000178
    Master-Key: CB948E0C6F005C654B2208ECAD1DFD1E5CC692256BE8615C74F403ABB22B2B8A97910A305EB4D4B2C4209C55C1146D9F
    Key-Arg   : None
    Start Time: 1357423010
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

At this point, you might be asking “Wait, did I see that right?”   And I’d reply – “Yes, you did!” – while most TN5250 and TN3270 terminal emulation programs support SSL (on port 992), many do NOT ACTUALLY CHECK the host certificate for validity!  If the terminal application is capable of checking, normally that check is OFF by default.  This means that if you are assessing larger hosts like this, you’re very likely to run into self-signed certificates.

How might you take advantage of this?  Attack the weakest link – the users of the target host, with their “first initial last name” userid and 8 digit RACF (or OS/400 in this case) password.  For  a target host “”, go register a similar domain and a host name, say “”, then  mount a phishing run.  Send emails to internal users at from the fake domain, asking them to login to the host “” to reset their password, check a critical report status or whatever.  As they say, it only takes one person to fall for it, and you’ll have an interactive login account!  If your client asks you to narrow the attack, target the most senior people in the organization that you are permitted to.  Or target their helpdesk or operator staff.  Sadly, the helpdesk and senior execs - the two groups you never want to get phished in - almost always fall for the phish.

Note that the TN5250/TN3270 uses EBCDIC, so while you can use Ettercap for the MITM attack, you’ll need to decode back to ASCII when you read the final captured file in Wireshark. Or in a pinch you can use dd to move back and forth between ASCII and EBCDIC, though Wireshark does a *fine* job!

What else might you try?  How about let’s do something with the (well documented) list of default userids on the iSeries:


I’ve had some good luck in engagements involving iSeries hosts, taking advantage of  QSECOFR (the Security Officer) or QSYSOPR (the System Operator), both of which have elevated privileges on the system.  Try these with either QSYSOPR/QSECOFR as the password, or the company name, or sometimes a word scraped off the company website.  Or, if you phish was successful, you’ve already won.

Soldier of Fortran describes TSOBRUTE ( ), which you can use to brute force TN3270 passwords, with a list of known accounts plus the ones you can glean with a domain name and a bit of google-fu, it works like a charm!  He’s also written a password sniffer - MFSniffer, which you can find at  I still use ettercap and wireshark for my MITM setups, but a password snarfer like this can make things much simpler, if all you are looking for is credentials.

Is there an easy fix for these two simple issues?  Well, yes – sort of.  And no – not really.

Protecting an internet host with a packet filter firewall, SSL with a self signed certificate, SSL clients that don’t check the cert, plus a user-selected password is not much protection at all.  It’s not materially different than using straight-up telnet.  When I see a direct login to a target host of any kind that is not  as hardened (or as able to be hardened) as you might like, I’d normally suggest putting it behind a VPN gateway, or possibly behind an https gateway. 

There are a ton of HTTPS gateway products that will sit in front of an SNA host, either commercial or open-source (though mostly you’ll see commercial products in this space).  In many cases they’ll even web-ify an application by screen scraping and presenting the app in a gui.  SNA Gateways are a mature technology, in common use since the late ‘80’s (though back then we were front-ending native QLLC/SNA with TCP).  Using an HTTPS front-end can allow you to filter out the use of sensitive accounts, and also makes enforcing the use of trusted certificates much easier.  Also, it means that your end-users don’t need to install a terminal client. 

Using a VPN solution hides the host completely, but isn’t as useful if you expect customers or partners to use the system – forcing multiple logins on end users never won System Admins any friends.  

Neither of these approaches is a silver bullet – protecting anything with a simple password these days is less than stellar idea.   At the end of the day, the host being discussed has likely been internet connected for 10-15 years, so making any changes, especially changes that make life more difficult for end users, is going to be met with a lot of resistance.  You’ll likely get more traction on an HTTPS front end, mostly because it’ll make the green-screen application prettier and mouse-friendly.  But you’ll be replacing a userid and a password with, well, a userid and a password, just with better encryption.

Where can I go next for more information?
Well, for starters, IBM has a Security Reference Document for the iSeries, located at:

The folks at Tenable have conveniently integrated the contents of this doc into Nessus:

Soldier of Fortran has a site dedicated to mainframe security issues:, his tool repository is on github: .  A great site if you’re trying to keep up with the attack side of things (since vendor docs and audit resources will generally be about defense).

A couple of other useful IBM documents:

A couple of GIAC papers on AS/400 Auditing (both are a bit dated, but are mostly directly applicable to the newer iSeries platforms):

ISACA also has a decent document on auditing  OS/400:

If you’ve got suggestions, stories on internet-attached mainframe or iSeries hosts (good or bad), or comments, please post to our comment form!

Rob VandenBrink

5 comment(s)



we have an iSeries. From
there are a lot of system values you can set to enhance your iSeries security and some are used by default
In particular


cause, after 3 wrong password, "vary off device and disable the user profile" until a *SECOFR re-enable it

Exactly, good call, and that's both in the IBM doc and (I hope) in the Nessus checks. Be aware that if someone *is* brute forcing you though, they are likely doing it in a distributed manner, most likely using a botnet of hundreds or thousands of IP's.

To make an impact on management, password guessing works best if you can succeed on the first or second try (for instance, using qsysopr as the qsysopr password)

I find that the phish/MITM approach is the most successful. Standing up a fake iSeries login screen is another variation on this.

an interesting free firewall for iSeries: (only work on telnet and ftp)

If you have enough money, also look at

Heh. My first job back in the '80s was creating an environment on Unix to run COBOL programs (Microfocus COBOL) that were written for a different environment. Basically had to create a JCL implementation and other supporting framework. This on a Motorola 68000-based Burroughs Unix system. Burroughs and Sperry merged into Unisys in the course of the project. (Always thought that they should have named the new company Sperroughs, i.e., "Sparrows", get it?)

Oh, wait, you said this wasn't a "back in the day" posting...
Another consideration of these 'legacy' systems is many of them were managed by 3rd parties who used dialin/modem access. I've observed on more than 1 occassion where these systems still have a modem and POTS line hooked up. The 3rd parties are long gone, no one is monitoring modem access, the phone number just shows up on the phone bill along with many other numbers and doesn't stand out ... accounting pays the bill like always. These legacy modems usually never had 'callback' or other security other than user/pwd which is often weak, can be brute forced given enough time, and no one is monitoring login failures.

Diary Archives