When I see TCP Port 992 open, I always get a warm feeling Im taken back to my first IT job, as a night operator on MVS and VM systems at IBM in the early 80s. And yes, we had Virtual Machines (thats what the V stands for) back in in 1980s, just on much bigger hardware!
When I see port 992 these days, that typically indicates the telnets service (telnet over SSL), which often means its an iSeries (previously AS/400), or a mainframe system (OS/390 or z/OS). Oddly enough, after 30-plus years todays 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. Didnt we migrate all the mainframes and AS/400s 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 70s, 80s and even 90s 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 theres an iSeries datacenter running the show.
So just how common are these platforms on the internet? In a simple scan of 2 class Bs I picked at random (Ok, I knew that they were both at colos), I found 2 iSeries hosts and 1 z/OS telnets host. If youre 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
Weve mentioned a few common ports - besides port 992, what other ports might you typically see open on an iSeries host?
Telnet (PC5250 Emulation)
netbios (yes, really!)
REXEC (just as good as netbios most days!)
Service Tools Server
APPC over TCPIP
397 (TCP and UDP)
5555 and 5544
Note that ports 23 and 992 on these platforms generally serve up TN5250 (iSeries) or TN3270 (z/OS) terminal servers over telnet or telnets. Youll also find (thanks to suggestions in IBMs Redbook Series of books) that its 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 its in the vendor documentation.
OK so now that weve found a target host, what might we look for if you are in a pentest or a security assessment engagement? The same thing as youd 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), theres no reason to try complicated attacks right?
For starters, lets 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 21
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
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
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
Protocol : TLSv1
Cipher : AES128-SHA
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 Id 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, youre 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 youll 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, youll 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 lets do something with the (well documented) list of default userids on the iSeries:
Ive 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, youve 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! Hes 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 dont check the cert, plus a user-selected password is not much protection at all. Its 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, Id 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 youll see commercial products in this space). In many cases theyll 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 80s (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 dont need to install a terminal client.
Using a VPN solution hides the host completely, but isnt 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. Youll likely get more traction on an HTTPS front end, mostly because itll make the green-screen application prettier and mouse-friendly. But youll 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: http://mainframed767.tumblr.com/, his tool repository is on github: https://github.com/mainframed/ . A great site if youre 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 youve got suggestions, stories on internet-attached mainframe or iSeries hosts (good or bad), or comments, please post to our comment form!
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.