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
