The fact is there have been several successful "real" hacks of production mainframes, so some sort of real, present-day "hacker" exposure is not unheard-of in the wild.
By "real" I mean not some "staged" attack on Hercules or the like but a real outsider breach of a production mainframe, with disastrous results. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Young's Black Hat 2013 talk - was mainframe tribute song On 01/03/2015 09:23 PM, Paul Gilmartin wrote: > On Sat, 3 Jan 2015 10:13:21 -0600, Ed Gould wrote: >> >> Indeed it was at least interesting. >> I would be curious if IBM would like to comment on some of the >> statements on how how RACF "encrypts" the passwords. >> I disagree with how RACF encryption is done (at least by the >> commentator)but I am not RACF trained so I can not call the >> commentator out. >> IBM? >> >> On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: >>> >>> Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a >>> Philip Young and it's about an hour long. >>> >>> http://youtu.be/uL65zWrofvk >>> > It has been mentioned here and not refuted that RACF uses single-DES > with the password as key and the user ID as salt. > > I had not heard (and do not fully believe) that the hashed password > data set is generally readable (UACC=READ?). > > I had not heard, but it's quite plausible, that passphrases, however > long, are collapsed to 56 bits becase DES supports no greater. > > And Phillip Young stressed the weakness of the potential for user ID > enumeration -- TSO LOGON tells you immediately whether a string is a > known user ID -- he calls it much "too friendly". But z/OS partisans > here have advocated that excess friendliness as a boon. > It reduces the search space from MxN to M+N, regarded contemptuously > by non-mainframers. > > -- gil > >From the full title of the report, perhaps Young is referring to MVS >installations that have been in existence for over 30 years that have somehow >managed to ignore all the security advice of the last several decades and have >continued in unsafe configurations. Perhaps some such installations do exist. The password mangling Young describes sounds like the old pre-DES password encoding (not an encryption). It wasn't even recommended by 1985 when we migrated to MVS/XA. If the old encoding is still supported, it should be way past time to discontinue that support. But, the password encoding in the RACF data base only becomes a security issue if READ access to the RACF data base itself is not properly restricted by RACF. Without READ access to the RACF database, one is reduced to making actual logon/authentication attempts, which may serve as a denial of service attack when a userid is revoked after a relatively-low, installation-specified number of failures, but would be of marginal use in finding a functional userid/password combination by trial and error and attract attention from a user whose userid gets revoked. And, SMF RACF logging data shows what LU or IP address is responsible for invalid authentication attempts -- we audited logon failures and all revoked userids daily. MVS can certainly be made insecure, but the basic security concepts are not that complex to understand" Require all users of the system to authenticate. By default, protect all DASD and tape data sets, and have rational data set naming standards that make default identification of ownership and access rights feasible. Protect all system data-sets, system configuration data, PROCLIB sources for started task JCL, and any installation "Authorized" libraries from UPDATE by all but Technical Support staff entrusted with maintenance of the system. Disallow even READ access to sensitive data sets (like RACF databases). Restrict physical access to corporate network and MVS consoles, and use RACF to restrict usage of sensitive commands, resources and applications. RACF Security Administrators and their Technical Support counterparts must be properly trained, which includes knowing what authorization requests from managers are unreasonable and must be denied to preserve system integrity -- and being slightly paranoid about protecting their own authentication credentials helps. 3270 communication protocols were designed with secure corporate networks in mind, and as Young points out that means logon passwords transmit in clear text even though visually hidden. Any remote access to MVS over non-corporate, unsecured networks MUST be encrypted, via use of a VPN or some other technique, and standards should also be in place to protect remote user's equipment from password-trapping malware. Users should only be authorized to the functional access on MVS required by their job. Need to access a transactional system (e.g., CICS), does not imply a need for access to TSO, or OMVS/UNIX, or FTP, or batch job submission; access to FTP does not imply a need for FILETYPE=JES job submission and retrieval (and it is not that difficult to design an FTP exit that uses RACF to selectively allow/disallow JES access via FTP to specific users). I was also mildly amused by the idea of someone using FTP FILETYPE=JES to submit a surreptitious interactive "listener" job. In our shop, batch initiators that were not restricted to production use were a closely watched commodity, and nothing would have attracted the attention of Operators, Tech Services, or other users quicker than a job that appeared to be "hung" using few resources, and holding up the processing of other jobs in classes served by that initiator -- especially if the job violated installation standards by attempting to suppress its JES message log to hide what it was doing. By properly compartmentalizing a user's MVS authorities based on their corporate role, the potential harm of a single compromised set of user credentials is minimized. By properly protecting the RACF database, it would be highly unlikely that attempts to compromise multiple userids on MVS would not attract attention. I would think the biggest exposure would be legitimate MVS users deliberately using their same authentication credentials on less secure corporate platforms that might be more easily compromised; but one could hope that the more sophisticated MVS users, the ones with the real power to compromise the MVS system itself, would be the ones most likely to recognize that risk and avoid such practices. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
