Yes, an ID they got hold of -- my impression was that it was the original ID -- had read access to the RACF database. They downloaded it, and posted questions here and there about how RACF passwords are encrypted. Within a few days a new version of John the Ripper appeared, reworked for RACF. The forensics people ran that version on an unexceptional PC afterward, as a test, using a dictionary attack of course, and as I recall they said they got ten or twenty thousand passwords out of it in the first day or two, which of course gave them access to IDs on other LPARs as well.
I'm kind of surprised how often I find that a client thinks the admins need update access to the security database in order to do their job. Sometimes they even let me take it away; not always, my dire warnings notwithstanding. I'm more disturbed at how often a site has a rule giving everyone read access to SYS2.**, which often includes the security database along with everything else. I suppose they set it up that way in the beginning, "just to get things rolling", and never looked at it again. About coming in through USS: When I first wrote up the report on the Logica hack for my then-employer, my Conclusions section started out with this confession: Overall, what I see is that the hackers got on through a stolen password (obtained no doubt through the usual means). Then they used OMVS to gain superuser access, UID(0), and go from there. My jaundiced notions of Unix security, and my prejudice in favor of MVS’, are strengthened by this tale rather than weakened. The problem with this reaction is that I know nothing of Unix; really I should learn something about it before I conclude anything. And after all, since OMVS is a part of MVS, that makes Unix part of my responsibility, no? I know more about OMVS security now, but not nearly enough. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* One of the justifications for democracy is that everyone's interest should be represented in government. But....the homeowner who locks his door is looking out for his own interest just as much as the burglar who picks the lock, but not exactly in the same way. The voter who wants to keep his own money isn't seeking the same thing as the voter who wants the state to give him someone else's money. -Joseph Sobran */ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of David Spiegel Sent: Friday, October 8, 2021 11:18 From what I recall, the bad guys had "READ" to the RACF Database. (It helps to have incompetent SecAdmin staff and auditors.) They downloaded it and then dictionary-attacked it easily, because there was no password limitation and there was no trivial-password-exclusion list. Also, NVAS had no security. That is, once in, the hackers could logon to any 3270 application from the main panel. --- On 2021-10-08 10:54, Bob Bridges wrote: > The way I read in the long Polish article about the Logica hack, when I > researched it back in 2013, is that there was speculation about USS and about > an HTTP flaw, but the forensics folks in the end thought they probably got > hold of a password in the good old-fashioned way and went from there. They > did indeed find and exploit USS configuration goofs. And the HTTP flaw is > real...but Logica's post-hack report doesn't mention it; so they, at least, > didn't think it figured into the original break-in or in the culprits' > activities afterward. > > -----Original Message----- > From: Charles Mills > Sent: Thursday, October 7, 2021 18:49 > > Assuming you don't count Logica. ("Oh, that wasn't a real mainframe > hack, they came in through USS.") > > -----Original Message----- > From: Bill Johnson > Sent: Thursday, October 7, 2021 3:21 PM > > You’d have to be a poorly run shop to permit any of those to occur. Maybe > that’s why mainframe hacks have actually never happened.... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN