|
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! 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 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 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.
C:>openssl s_client -connect x.x.x.x:992 2>&1 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. 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? 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:
=============== |
Richard 168 Posts ISC Handler Jan 9th 2013 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Thread locked Subscribe |
Jan 9th 2013 8 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi,
we have an iSeries. From http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzaii%2Frzaiimst26.htm there are a lot of system values you can set to enhance your iSeries security and some are used by default In particular QMAXSGNACN QMAXSIGN cause, after 3 wrong password, "vary off device and disable the user profile" until a *SECOFR re-enable it Regards |
Anonymous |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Jan 9th 2013 8 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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. |
Rob VandenBrink 556 Posts ISC Handler |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Jan 9th 2013 8 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi,
an interesting free firewall for iSeries: http://www.easy400.net/sectcp/start (only work on telnet and ftp) If you have enough money, also look at http://www.razlee.com/ Regards |
Rob VandenBrink 8 Posts |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Jan 9th 2013 8 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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... |
Hal 50 Posts |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Jan 9th 2013 8 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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.
|
Anonymous |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Jan 9th 2013 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!
