Just to clarify something that I wri=ote and maybe missed somehow about
NAMP: Z/OS can be configured to block slow or fast scans using the IDS
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...

ITschak

On Fri, Jul 13, 2018 at 5:42 PM Robyn Gilchrist <
[email protected]> wrote:

> This 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
> r.gilchrist"at"rshconsulting.com <- replace "at" with @ to email me
> www.linkedin.com/in/robyn-e-gilchrist
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to