I'm not sure, but I suspect that a job submitted via FTP with an invalid userid 
or password would just disappear. If there is no userid then it would run under 
the userid of the server, so that should not have access to anything sensitive. 
It's not rocket science, but you do have to be careful to define appropriate 
access to the server if you allow job submission.

And, yes, security requires that you have all of the pieces in place, starting 
with management buy-in.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Farley, Peter x23353 <[email protected]>
Sent: Tuesday, May 28, 2019 7:31 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Thank you for the explanation.  I can see that proxy access to other userid's 
would need tight control, like a production job scheduler product has, but even 
so wouldn't the FTP server itself receive a failure if it tries to submit a job 
sent to it with invalid credentials?  Or does the job just disappear, as could 
happen (depending on various exit behaviors and your own ESM authority) if you 
TSO SUBMIT a job with a userid other than your own?

I can also see that there are lots of levels to actually effective security.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 5:51 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

FTP JES access relies on the credentials of the userid under which the FTP 
server is running. Under normal circumstances the user would need to provide a 
userid and password on his job card. If the FTP server has proxy access to 
other userids then it needs to be tightly controlled.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Farley, Peter x23353 <[email protected]>
Sent: Tuesday, May 28, 2019 4:57 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Farley, Peter x23353 <[email protected]>
Sent: Tuesday, May 28, 2019 3:57 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Peter - That is a good question. I think there may be several ways to explain 
this:

  * When I explain code vulnerabilities to z/OS assembler developers I
    tell them: It is not good enough for the code to work as designed -
    it must have no unintended consequences.If an installation
    implements FTP JES support in such a way that it allows both
    legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base
    products) and illegitimate users to use it then there may be a
    vulnerability in the FTP JES implementation. For example, if an
    external user could run a job submitted via FTP JES to list the
    payroll file or the ESM database but that is not the installations
    intended use of the FTP JES support then I would suggest that this
    would be a vulnerability.
  * If an exploit was developed to exfiltrate the payroll file or the
    ESM database and FTP JES was part of the path the exploit used then
    one should review the FTP JES implementation to see how controls can
    be tightened to eliminate or reduce the "unintended consequences".
    You would of course also look at the other parts of the exploit and
    do the same.

Which option you use is usually dictated by whether you are looking for 
problems that may not have occurred yet (1st option) or you are trying to 
figure out what happened (2nd option).

The use of FTP JES option is not by itself a vulnerability. But it can be if 
not properly configured (including the ESM controls). It is also something the 
other platforms understand and will take advantage of if not properly 
controlled for unintended consequences.

/IOW, how is FTP JES submission any different from TSO SUBMIT? /Functionally, 
they both do the same thing. What I think is different is that FTP JES may be 
done from environments outside the scope and control of a z/OS system. Those 
environments may not be as secure as z/OS.
//


On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote:
> Ray,
>
> PMFJI here, but as a regular application programmer (not a sysprog) I do not 
> understand how the FTP JES option allowed is a configuration vulnerability.
>
> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS Explorer 
> Eclipse-based products (and maybe other ISV Eclipse GUI's) provide to let you 
> submit and review the results of compile and program test and bundle 
> transmission jobs?   If my FTP submitted jobs must have my userid+1 as the 
> job name and my userid access is properly controlled by the ESM, how is that 
> vulnerable?
>
> IOW, how is FTP JES submission any different from TSO SUBMIT?
>
> Peter
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: [email protected]
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken
> down. I have been talking to mainframe people about vulnerabilities
> for the last 12 years. I have talked with people just like Bill
> Johnson. My discussions went just like this discussion did. The
> problem (as I saw
> it) was that discussing a "mainframe vulnerability" is too ambiguous.
> The discussion needs to be more specific. This led to categorizing
> vulnerabilities. When the vulnerabilities were categorized (which also
> defined their capabilities BUT does not allow the hacker to generate
> an
> exploit) the discussions evolved to the point that not only did the mainframe 
> people better understand the vulnerabilities and their associated risk but 
> also allowed C level, managers, Auditors, Security, Pen testers, and Risk 
> people to understand and participate in the vulnerability discussions.
>
> For example, you can classify mainframe vulnerabilities based upon their 
> source - configuration or code based. Classifying the vulnerability 
> eliminates ambiguities that are inherent when you don't classify. It is these 
> ambiguities that can cause the discussion to break down.  For example, how 
> would the discussion have changed if the vulnerabilities under discussion 
> were classified as follows:
>
> -Configuration based vulnerabilities
>
>    * APF authorized data sets not adequately protected
>    * SMP/E data sets not adequately protected
>    * FTP anonymous allowed
>    * FTP JES option allowed
>    * Outgoing TCPIP traffic not protected
>
> -Code based vulnerabilities
>
>    * Storage alteration
>    * Trap door
>    * System Instability
>
> <Snipped>
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

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

Reply via email to