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 https://isc.sans.edu/port.html?port=992

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):

PORT    STATE SERVICE    VERSION
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):

PORT     STATE SERVICE VERSION
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?

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 https://isc.sans.edu/diary.html?storyid=14770 ) 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
CONNECTED(00000108)
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
-----BEGIN CERTIFICATE-----
MIICcjCCAdugAwIBAgIHR8WrVwLluDANBgkqhkiG9w0BAQ ….
…
Raw certificate material removed
…
CIwH3P8akfuJ0pzjb7zoFsnaS6QJY8vArirEt6mgBiWX18V7igxr0WstsJCQppUP
wa9lcXHE
-----END CERTIFICATE-----
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
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 975A05E1077C10000000000000000178
    Session-ID-ctx:
    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 “iseries.domain.com”, go register a similar domain and a host name, say “iseries.doma1n.com”, then  mount a phishing run.  Send emails to internal users at domain.com from the fake domain, asking them to login to the host “mainframe.doma1n.com” 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 (https://github.com/mainframed/TSO-Brute ), 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 https://github.com/mainframed/MFSniffer.  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:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc415302.pdf

The folks at Tenable have conveniently integrated the contents of this doc into Nessus:
http://blog.tenablesecurity.com/2012/02/new-ibm-iseries-audit-policy.html

Soldier of Fortran has a site dedicated to mainframe security issues: http://mainframed767.tumblr.com/, his tool repository is on github: https://github.com/mainframed/ .  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:
http://www.redbooks.ibm.com/redbooks/pdfs/gg244200.pdf
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c415302515.htm

A couple of GIAC papers on AS/400 Auditing (both are a bit dated, but are mostly directly applicable to the newer iSeries platforms):
http://www.sans.org/reading_room/whitepapers/basics/as-400-iseries-comprehensive-guide-setting-system-values-common-practice-securi_425
http://www.giac.org/paper/gsec/597/about-as-400-auditing-how-to/101449

ISACA also has a decent document on auditing  OS/400:
http://www.isaca.org/Journal/Past-Issues/2002/Volume-2/Pages/A-Beginners-Guide-to-Auditing-the-AS-400-Operating-System.aspx

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
Metafore