Just to clarify something that I wri=ote and maybe missed somehow about
feature. So, yes, NMAP can try scan the mainframe, but if the IP STAK is
well configured, it will be hard to get the open ports. This is not to say
that you can't telnet CSSMTP...
Post by Robyn GilchristThis is an area I have been investigating for the past few months. I
think a network scanner is a good place to start and Nmap is a very strong
network scanner. An open port isn't a problem per se (SMTP port 25 or HTTP
on port 80) since open ports are required for communication. Nmap network
scanner will indicate ports of interest and can do things like OS version
discovery and use crafted scripts (written in LUA) to perform more
sophisticated tests.
As far as whether the network is vulnerable, I'll give the tried and true
"it depends". As an example, I have crafted Nmap commands that will
display status of z/OS ftp on port 21 with no z/OS userid required. Is the
machine vulnerable because anyone can know that JESINTERFACELEVEL=1?
Probably not, but if it is =2 that may raise my concern. Vulnerability
depends on security practices, system and app bugs, config settings,
design, etc. If ftp is tightly controlled with a strong configuration,
good RACF rules and uses encryption (FTPS), then JESINTERFACELEVEL=2 may
not concern you, but it probably would make me nervous.
Nessus, a popular vulnerability scanner, banner scrapes IBM HTTP Server
V5.3 and reports that the machine is "vulnerable" regardless of whether
UK90649 has been APPLYed (Nessus plugin id 66760). At least they tell you
that in the description - Emily Litella practice. There is an "exploit"
written by Solider of Fortran in Metasploit that indicates issuing
FILETYPE=JES and getting response=200 is a vulnerability. Is it? I don't
think that is any more "vulnerable" than TSO SUBMIT. I'm still bound to
the userid I logged on with and if I can spawn a high authority shell (or
TMP) or change my RACF attributes, that's the vulnerability to address.
I'm studying the Logica attack and it is hardcore. The attackers got
UID(0) on z/OS. Machine "pwned", as the kids would say. Traffic blended
in with all other traffic and the attack was designed to be difficult to
trace back to origin and to fly under the radar. The attack was initially
spotted on z/OS as an anomalous load, not on the network. The
vulnerabilities included lax firewall rules, bad RACF dataset and resource
protection, loose policy on password strength, just to name a few factors.
It was a perfect target and the attackers were very talented and very
sophisticated.
I like the SMTP vector mentioned here and will be incorporating that into
my investigations. Thanks ITschak! :-)
As a total aside, I just got back on IBM-MAIN today for the first time
since ... er ... a long time. I was a heavy user of IBM-MAIN back in the
early '90s before all of the swanky new interwebs. I used to read Lionel
in NaSPA's magazine back when that was still a thing. I recognize a bunch
of names and it's good to see they're still here. :-)
Robyn
----
Robyn Gilchrist
RSH Consulting
www.linkedin.com/in/robyn-e-gilchrist
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,