Re: RACF database backup and recovery

[Mike Cairns]

Also the RACF-L discussion list is a much better place to seek information on 
this topic (not that people here aren't helpful and knowledgeable):  
lists...@listserv.uga.edu - RACF-L - subscription instructions are found at the 
start of every piece of IBM RACF documentation.

Cheers - Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF database backup and recovery

[Allan Staller]

Classification: Confidential

The RACF System Programmers Guide would be a good starting point.
HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Wednesday, September 25, 2024 1:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF database backup and recovery

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello

Is there any documentation which talks about RACF database and recovery?

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RACF database backup and recovery

[Peter]

Hello

Is there any documentation which talks about RACF database and recovery?

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

New RACF Database Encryption Enhancement

[Timothy Sipples]

There are several z/OS enhancements that have recently shipped as "continuous 
delivery" features. One of them that I haven't seen mentioned yet in this forum 
is the new and improved RACF database encryption. z/OS RACF can now use a VSAM 
data set that can be both AES256 encrypted and shared in certain 
configurations. The distinction is that "classic" RACF databases contain 
encrypted entries, but now the whole data set can (also) be encrypted. This new 
approach strengthens the security profile of RACF and the overall system. I 
suggest you implement it now or as soon as reasonably practical.

For details and caveats please refer to APAR OA62267.

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Robert S. Hansel (RSH)]

Clark,

The answer to your original question is 'yes'. With regard to FDR, see the 
following article in our RACF Tips newsletter.

https://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__January_2008.pdf


Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.twitter.com/RSH_RACF
www.rshconsulting.com
-
Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 23-27, 2019
- RACF Level I Administration - DEC 9-13, 2019
- RACF Level II Administration - NOV 18-22, 2019
- RACF Level III Admin, Audit, & Compliance - NOV 4-8, 2019
- RACF - Securing z/OS UNIX  - SEPT 9-13, 2019
-


-Original Message-
Date:Tue, 7 May 2019 09:26:58 -0300
From:Clark Morris 
Subject: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
(snip)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

Passphrases and MFA!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Friday, May 10, 2019 6:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

On 11/05/2019 12:34 am, Dana Mitchell wrote:
>
> Doesn't the KDFAES password encryption algorithm make it *much* more 
> difficult to crack passwords,  given access to the RACF database?  I realize 
> nothing is impossible to crack.. but at least not currently feasible with 
> current available hardware.
>
How slow is KDFAES? How many guesses per second are possible?

This article from 2013 has an interesting discussion on cracking 
passphrases:

https://arstechnica.com/information-technology/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/

The researcher had compiled a library of 1.3 billion potential 
passphrases and was quite successful. There is a reference to $800 of 
hardware being able to do 30 billion guesses per second against Windows 
passwords.

I recall a number where KDFAES was 300,000 times slower (than something) 
- does that mean KDFAES might give 100,000 guesses per second? Which 
gives about 4 hours to try 1.3 billion phrases (if I didn't slip a 
decimal point somewhere!)

My belief is that users are not good enough at choosing passwords for a 
database to hold up to an offline attack - whatever the algorithm. You 
must assume that if someone can read the database, they will be able to 
crack at least some passwords. And you don't know which userids they 
will be.


Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Andrew Rowley]

On 11/05/2019 12:34 am, Dana Mitchell wrote:


Doesn't the KDFAES password encryption algorithm make it *much* more difficult 
to crack passwords,  given access to the RACF database?  I realize nothing is 
impossible to crack.. but at least not currently feasible with current 
available hardware.


How slow is KDFAES? How many guesses per second are possible?

This article from 2013 has an interesting discussion on cracking 
passphrases:


https://arstechnica.com/information-technology/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/

The researcher had compiled a library of 1.3 billion potential 
passphrases and was quite successful. There is a reference to $800 of 
hardware being able to do 30 billion guesses per second against Windows 
passwords.


I recall a number where KDFAES was 300,000 times slower (than something) 
- does that mean KDFAES might give 100,000 guesses per second? Which 
gives about 4 hours to try 1.3 billion phrases (if I didn't slip a 
decimal point somewhere!)


My belief is that users are not good enough at choosing passwords for a 
database to hold up to an offline attack - whatever the algorithm. You 
must assume that if someone can read the database, they will be able to 
crack at least some passwords. And you don't know which userids they 
will be.



Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[ITschak Mugzach]

yes, it is an option, but the solution recommended by the vendor is srver
mode. however, not all products/features that are based on this product
support server mode.

On Fri, May 10, 2019 at 6:43 PM Seymour J Metz  wrote:

> Couldn't you grant the access only through PADS?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of ITschak Mugzach 
> Sent: Friday, May 10, 2019 1:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> I found many security and system programmers assuming that in order to
> manage security, one need access to the security database.I many
> assessments I was able to copy the file with no problem. While this
> assumption is completely untrue, many of you make use of (at least one)
> racf administration product that directly read the racf database, so you
> need to have read access to use it. all products built around this product
> also requires at least read access. In some cases, when I recommended to
> switch to "server" mode, the vendor said that not all products support
> that.
>
> So, even if you have ROAUDIT attribute you got read access to the racf db.
> and this is a security and audit product!
>
> ITschak
>
> On Thu, May 9, 2019 at 8:16 PM Charles Mills  wrote:
>
> > To answer the OP question, Yes, assuming
> >
> > - The perp has the ability to run some sort of volume backup, such as
> > authority to the volume and to run a volume backup program.
> > - The ability to copy the backup off of the system, such as with FTP,
> > access
> > to a physical tape drive, or downloading to a PC and converting to some
> > sort
> > of format accessible to item 3 below.
> > - Access to a "friendly" system, such as Hercules, on which the perp has
> > the
> > ability to restore the backup. Any RACF-type restrictions on access to
> the
> > database would not persist onto this system.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Clark Morris
> > Sent: Tuesday, May 7, 2019 5:27 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Can backup mechanisms be used to steal RACF database? was Re:
> > mainframe hacking "success stories"?
> >
> > [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
> > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:
> >
> > >In most shops only 2 people have the required access to the RACF
> > database.
> > >
> > Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
> > and then download the dump of the database?
> >
> > Clark Morris
> > >
> > >Sent from Yahoo Mail for iPhone
> > >
> > >
> > >On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
> > wrote:
> > >
> > >"Once they’d downloaded the RACF database, they subjected it to a
> > password-cracking tool.  John the Ripper is one such tool, widely
> available
> > on the internet.  On Feb 28, about the same time the RACF database was
> > downloaded, some questions appeared on the mailing list PaulDotCom about
> > hashing methods for RACF; by March 3rd, apparently in response, John the
> > Ripper had been enhanced to include the capability of working on RACF
> > passwords, in collaboration with another tool call CRACF.
> > >
> > >"In the Zauf article is this description:  'Creating a password hash
> > algorithm works like this:  After entering the password, it is padded
> with
> > spaces, if necessary, to a length of 8 bytes.  Each character is then
> XORed
> > with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
> > using the modified password as the DES key.  Developers took a few days
> to
> > determine the algorithm and modify John the Ripper.  Now the utility
> excels
> > at hashing the RACF database.'  It also mentioned a source-code module
> > named
> > racf2john.c, 'a tool that converts database file exported in the input
> > data,
> > read for JTR' [Google’s translation from Polish].
> > >
> > >"By way of testing, investigators attempted to use these tools
> themselves
> > to crack RACF passwords.  They found that a great many passwords could be
> > extracted, that they were easy to discover by dictionary attack, that
> th

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Seymour J Metz]

Couldn't you grant the access only through PADS?


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


From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Friday, May 10, 2019 1:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

I found many security and system programmers assuming that in order to
manage security, one need access to the security database.I many
assessments I was able to copy the file with no problem. While this
assumption is completely untrue, many of you make use of (at least one)
racf administration product that directly read the racf database, so you
need to have read access to use it. all products built around this product
also requires at least read access. In some cases, when I recommended to
switch to "server" mode, the vendor said that not all products support
that.

So, even if you have ROAUDIT attribute you got read access to the racf db.
and this is a security and audit product!

ITschak

On Thu, May 9, 2019 at 8:16 PM Charles Mills  wrote:

> To answer the OP question, Yes, assuming
>
> - The perp has the ability to run some sort of volume backup, such as
> authority to the volume and to run a volume backup program.
> - The ability to copy the backup off of the system, such as with FTP,
> access
> to a physical tape drive, or downloading to a PC and converting to some
> sort
> of format accessible to item 3 below.
> - Access to a "friendly" system, such as Hercules, on which the perp has
> the
> ability to restore the backup. Any RACF-type restrictions on access to the
> database would not persist onto this system.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Clark Morris
> Sent: Tuesday, May 7, 2019 5:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
> 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:
>
> >In most shops only 2 people have the required access to the RACF
> database.
> >
> Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
> and then download the dump of the database?
>
> Clark Morris
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
> wrote:
> >
> >"Once they’d downloaded the RACF database, they subjected it to a
> password-cracking tool.  John the Ripper is one such tool, widely available
> on the internet.  On Feb 28, about the same time the RACF database was
> downloaded, some questions appeared on the mailing list PaulDotCom about
> hashing methods for RACF; by March 3rd, apparently in response, John the
> Ripper had been enhanced to include the capability of working on RACF
> passwords, in collaboration with another tool call CRACF.
> >
> >"In the Zauf article is this description:  'Creating a password hash
> algorithm works like this:  After entering the password, it is padded with
> spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
> with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
> using the modified password as the DES key.  Developers took a few days to
> determine the algorithm and modify John the Ripper.  Now the utility excels
> at hashing the RACF database.'  It also mentioned a source-code module
> named
> racf2john.c, 'a tool that converts database file exported in the input
> data,
> read for JTR' [Google’s translation from Polish].
> >
> >"By way of testing, investigators attempted to use these tools themselves
> to crack RACF passwords.  They found that a great many passwords could be
> extracted, that they were easy to discover by dictionary attack, that they
> were not very complex and in many cases that they’d been unchanged from the
> default when the ID was created.  Using a standalone PC they cracked about
> 30 000 passwords (out of 120 000 on Applicat’s database) in  'a couple of
> days'."
> >
> >---
> >Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> >/* If the Earth were flat, cats would have pushed everything off it by
> now.
> */
> >
> >
> >-Original Message-
> >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> >Sent: Monday, May 6, 2019 13:14
> >
> >I *believe* that was done by investigators after

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[ITschak Mugzach]

That's true password cracking can be complex. However, if you have a copy
of the database you can find who are the users that have admin authority
and concentrate cracking their passwords.



ITschak

בתאריך יום ו׳, 10 במאי 2019, 17:49, מאת Mark Jacobs ‏<
0224d287a4b1-dmarc-requ...@listserv.ua.edu>:

> Yes;
>
> The KDFAES algorithm is used to encrypt passwords and password phrases,
> but not OIDCARD data. It is designed to be resistant to offline attacks by
> incorporating the following properties:
>
> Each instance of a RACF® password injects randomly generated text into the
> encryption process. This prevents the use of pre-computed password hashes.
> That is, an offline attack must perform the full encryption process for
> every password guess, as opposed to simply comparing the password hash
> against a list of pre-computed values. This slows down the attack, making
> it take much longer to guess passwords.
>
> Thousands of hash operations are performed against the password and random
> text in order to generate a key which is then used to encrypt the user ID.
> This also serves to slow down an offline attack, which must perform the
> same number of operations for each password guess. However, the authorized
> user logging on to the system using his clear text password will not notice
> the increased overhead.
>
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, May 10, 2019 10:34 AM, Dana Mitchell 
> wrote:
>
> > On Fri, 10 May 2019 00:24:18 -0400, Bob Bridges robhbrid...@gmail.com
> wrote:
> >
> > > The lesson I take from this, and pass on to
> > > my clients, is that read access to the security database is a huge
> exposure
> > > and in most cases - that is, for most user IDs - completely
> unnecessary.
> >
> > Doesn't the KDFAES password encryption algorithm make itmuch more
> difficult to crack passwords, given access to the RACF database? I realize
> nothing is impossible to crack.. but at least not currently feasible with
> current available hardware.
> >
> > Dana
> >
> >
> ---
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Mark Jacobs]

Yes;

The KDFAES algorithm is used to encrypt passwords and password phrases, but not 
OIDCARD data. It is designed to be resistant to offline attacks by 
incorporating the following properties:

Each instance of a RACF® password injects randomly generated text into the 
encryption process. This prevents the use of pre-computed password hashes. That 
is, an offline attack must perform the full encryption process for every 
password guess, as opposed to simply comparing the password hash against a list 
of pre-computed values. This slows down the attack, making it take much longer 
to guess passwords.

Thousands of hash operations are performed against the password and random text 
in order to generate a key which is then used to encrypt the user ID. This also 
serves to slow down an offline attack, which must perform the same number of 
operations for each password guess. However, the authorized user logging on to 
the system using his clear text password will not notice the increased overhead.


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Friday, May 10, 2019 10:34 AM, Dana Mitchell  wrote:

> On Fri, 10 May 2019 00:24:18 -0400, Bob Bridges robhbrid...@gmail.com wrote:
>
> > The lesson I take from this, and pass on to
> > my clients, is that read access to the security database is a huge exposure
> > and in most cases - that is, for most user IDs - completely unnecessary.
>
> Doesn't the KDFAES password encryption algorithm make itmuch more difficult 
> to crack passwords, given access to the RACF database? I realize nothing is 
> impossible to crack.. but at least not currently feasible with current 
> available hardware.
>
> Dana
>
> ---
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Dana Mitchell]

On Fri, 10 May 2019 00:24:18 -0400, Bob Bridges  wrote:

>The lesson I take from this, and pass on to
>my clients, is that read access to the security database is a huge exposure
>and in most cases - that is, for most user IDs - completely unnecessary.
>

Doesn't the KDFAES password encryption algorithm make it *much* more difficult 
to crack passwords,  given access to the RACF database?  I realize nothing is 
impossible to crack.. but at least not currently feasible with current 
available hardware.

Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

No argument there! :-)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bob Bridges
Sent: Thursday, May 9, 2019 9:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

No, ~I~ quoted "there are solid indications" etc.  Mr Mills asserts that
they did not, which is contrary to my own reading but at this remove perhaps
it doesn't matter.  Whatever actually happened at Logica, the important
point is that with read access a hacker would be able to do so, a situation
most ardently to be avoided :).  The lesson I take from this, and pass on to
my clients, is that read access to the security database is a huge exposure
and in most cases - that is, for most user IDs - completely unnecessary.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[ITschak Mugzach]

I found many security and system programmers assuming that in order to
manage security, one need access to the security database.I many
assessments I was able to copy the file with no problem. While this
assumption is completely untrue, many of you make use of (at least one)
racf administration product that directly read the racf database, so you
need to have read access to use it. all products built around this product
also requires at least read access. In some cases, when I recommended to
switch to "server" mode, the vendor said that not all products support
that.

So, even if you have ROAUDIT attribute you got read access to the racf db.
and this is a security and audit product!

ITschak

On Thu, May 9, 2019 at 8:16 PM Charles Mills  wrote:

> To answer the OP question, Yes, assuming
>
> - The perp has the ability to run some sort of volume backup, such as
> authority to the volume and to run a volume backup program.
> - The ability to copy the backup off of the system, such as with FTP,
> access
> to a physical tape drive, or downloading to a PC and converting to some
> sort
> of format accessible to item 3 below.
> - Access to a "friendly" system, such as Hercules, on which the perp has
> the
> ability to restore the backup. Any RACF-type restrictions on access to the
> database would not persist onto this system.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Clark Morris
> Sent: Tuesday, May 7, 2019 5:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
> 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:
>
> >In most shops only 2 people have the required access to the RACF
> database.
> >
> Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
> and then download the dump of the database?
>
> Clark Morris
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
> wrote:
> >
> >"Once they’d downloaded the RACF database, they subjected it to a
> password-cracking tool.  John the Ripper is one such tool, widely available
> on the internet.  On Feb 28, about the same time the RACF database was
> downloaded, some questions appeared on the mailing list PaulDotCom about
> hashing methods for RACF; by March 3rd, apparently in response, John the
> Ripper had been enhanced to include the capability of working on RACF
> passwords, in collaboration with another tool call CRACF.
> >
> >"In the Zauf article is this description:  'Creating a password hash
> algorithm works like this:  After entering the password, it is padded with
> spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
> with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
> using the modified password as the DES key.  Developers took a few days to
> determine the algorithm and modify John the Ripper.  Now the utility excels
> at hashing the RACF database.'  It also mentioned a source-code module
> named
> racf2john.c, 'a tool that converts database file exported in the input
> data,
> read for JTR' [Google’s translation from Polish].
> >
> >"By way of testing, investigators attempted to use these tools themselves
> to crack RACF passwords.  They found that a great many passwords could be
> extracted, that they were easy to discover by dictionary attack, that they
> were not very complex and in many cases that they’d been unchanged from the
> default when the ID was created.  Using a standalone PC they cracked about
> 30 000 passwords (out of 120 000 on Applicat’s database) in  'a couple of
> days'."
> >
> >---
> >Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> >/* If the Earth were flat, cats would have pushed everything off it by
> now.
> */
> >
> >
> >-Original Message-
> >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> >Sent: Monday, May 6, 2019 13:14
> >
> >I *believe* that was done by investigators after the fact, attempting to
> determine how the attack might have been done. I don't recall that there is
> compelling evidence that Svartholm actually did that.
> >
> >It *is* trivially easy to do, assuming (a.) read access to the DB and (b.)
> old-style password storage.
> >
> >-Original Message-
> >From: I

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Bob Bridges]

No, ~I~ quoted "there are solid indications" etc.  Mr Mills asserts that
they did not, which is contrary to my own reading but at this remove perhaps
it doesn't matter.  Whatever actually happened at Logica, the important
point is that with read access a hacker would be able to do so, a situation
most ardently to be avoided :).  The lesson I take from this, and pass on to
my clients, is that read access to the security database is a huge exposure
and in most cases - that is, for most user IDs - completely unnecessary.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* re-cur-sive (ri: 'kr sIv), from "re-" + Lat. "cursire" (to say "Oh, hell,
not AGAIN!"):  See "recursive". */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, May 9, 2019 17:23

The only thing that I see that is relevant is where you quoted "There are
also solid indications that they downloaded the RACF database (about 28MB",
which certainly seems consistent with Bob's claim.


From: IBM Mainframe Discussion List  on behalf of
Charles Mills 
Sent: Thursday, May 9, 2019 2:35 PM


Yes, that assertion is incorrect. Read my post.

-Original Message-
From: Seymour J Metz
Sent: Thursday, May 9, 2019 11:29 AM

Are you saying that Bob Bridges was wrong when he wrote "The stolen ID also
had read access to the RACF database.."? It's not a vulnerability of the
lock when you leave your key on the porch for anyone to use.

From: Charles Mills 
Sent: Thursday, May 9, 2019 2:20 PM

I have read the entire, very thorough police report, as has Chad R. Phil
Young has done considerable research on this.

There were two parts to it.

Svartholm somehow got the MPAA lawyer's user login for the Infotorg legal
database, hosted on USS. (The "somehow" may be known but I do not know or
recall it.) That userid was insignificant to the overall integrity of the Z
box. He was able to harass the lawyer by changing her password, etc., etc.,
but that was all. No real threat to system integrity. It would be like if I
had the userid and password for one of your vanilla CICS users. Not good,
but not the end of the world.

He leveraged that, via the http vulnerability, into pwning the whole box:
multiple RACF SPECIAL id's, etc., etc. That was the huge, huge, huge problem
for the service bureau.

So the z/OS vulnerability was the key here, not one random userid. And yes,
it was a z/OS vulnerability. It was a zero-day defect in system software
running as a service of z/OS. If that's not a z/OS vulnerability I don't
know what is.

-Original Message-
From: Bob Bridges
Sent: Thursday, May 9, 2019 10:28 AM

I believe Peter's right.  The hackers got a stolen ID with some RACF power,
by means not positively identified but social engineering is as likely as
any other hypothesis.  (I read ~speculation~ about an HTTP vulnerability,
but the forensic investigators never established how the initial breakin
occurred.)  Once they were in, they fooled around in OMVS and were able to
get more power.  The stolen ID also had read access to the RACF database.

"There are also solid indications that they downloaded the RACF database
(about 28MB)Once they'd downloaded the RACF database, they subjected it
to a password-cracking toolOn Feb 28, about the same time the RACF
database was downloaded, some questions appeared on the mailing list
PaulDotCom about hashing methods for RACF; by March 3rd, apparently in
response, John the Ripper had been enhanced to include the capability of
working on RACF passwords, in collaboration with another tool call
CRACFBy way of testing, investigators attempted to use these tools
themselves to crack RACF passwords.  They found that a great many passwords
could be extracted, that they were easy to discover by dictionary attack,
that they were not very complex and in many cases that they'd been unchanged
from the default when the ID was created.  Using a standalone PC they
cracked about 30 000 passwords (out of 120 000 on Applicat's database) in
'a couple of days'."

So yeah, the investigators did it too, but just to establish how effective
might be the new version of John the Ripper.

-Original Message-
From: Charles Mills
Sent: Thursday, May 9, 2019 11:39

No.  Read the original thread here.

It was a vulnerability in a Web server.  Hacking the RACF database was done
well after the fact, by investigators.

-Original Message-
From: Peter Vander Woude
Sent: Thursday, May 9, 2019 6:56 AM

That's what happened in the Swedish bank hack, back in 2012.  In that, once
they got the database copy on their pc, they used hacker tools that are out
there, to crack all the passwords.

-

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Seymour J Metz]

> Yes, that assertion is incorrect. Read my post.

The only thing that I see that is relevant is where you quoted "There are also 
solid indications that they downloaded the RACF database (about 28MB", which 
certainly seems consistent with Bob's claim.


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Thursday, May 9, 2019 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

Yes, that assertion is incorrect. Read my post.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, May 9, 2019 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

> And yes, it was a z/OS vulnerability.

Are you saying that Bob Bridges was wrong when he wrote "The stolen ID also
had read access to the RACF database.."? It's not a vulnerability of the
lock when you leave your key on the porch for anyone to use.


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


From: IBM Mainframe Discussion List  on behalf of
Charles Mills 
Sent: Thursday, May 9, 2019 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

I have read the entire, very thorough police report, as has Chad R. Phil
Young has done considerable research on this.

There were two parts to it.

Svartholm somehow got the MPAA lawyer's user login for the Infotorg legal
database, hosted on USS. (The "somehow" may be known but I do not know or
recall it.) That userid was insignificant to the overall integrity of the Z
box. He was able to harass the lawyer by changing her password, etc., etc.,
but that was all. No real threat to system integrity. It would be like if I
had the userid and password for one of your vanilla CICS users. Not good,
but not the end of the world.

He leveraged that, via the http vulnerability, into pwning the whole box:
multiple RACF SPECIAL id's, etc., etc. That was the huge, huge, huge problem
for the service bureau.

So the z/OS vulnerability was the key here, not one random userid. And yes,
it was a z/OS vulnerability. It was a zero-day defect in system software
running as a service of z/OS. If that's not a z/OS vulnerability I don't
know what is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bob Bridges
Sent: Thursday, May 9, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

I believe Peter's right.  The hackers got a stolen ID with some RACF power,
by means not positively identified but social engineering is as likely as
any other hypothesis.  (I read ~speculation~ about an HTTP vulnerability,
but the forensic investigators never established how the initial breakin
occurred.)  Once they were in, they fooled around in OMVS and were able to
get more power.  The stolen ID also had read access to the RACF database.

"There are also solid indications that they downloaded the RACF database
(about 28MB)Once they'd downloaded the RACF database, they subjected it
to a password-cracking toolOn Feb 28, about the same time the RACF
database was downloaded, some questions appeared on the mailing list
PaulDotCom about hashing methods for RACF; by March 3rd, apparently in
response, John the Ripper had been enhanced to include the capability of
working on RACF passwords, in collaboration with another tool call
CRACFBy way of testing, investigators attempted to use these tools
themselves to crack RACF passwords.  They found that a great many passwords
could be extracted, that they were easy to discover by dictionary attack,
that they were not very complex and in many cases that they'd been unchanged
from the default when the ID was created.  Using a standalone PC they
cracked about 30 000 passwords (out of 120 000 on Applicat's database) in
'a couple of days'."

So yeah, the investigators did it too, but just to establish how effective
might be the new version of John the Ripper.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Be careful of your thoughts; they may become words at any moment.  -Ira
Gassen */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 9, 2019 11:39

No.  Read the original thread here.

It was a vulnerability in a Web server.  Hacking the RACF databas

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Seymour J Metz]

Any customer who discovers a security bug can report it. BTDT,GTTS (just the 
tee shirt, no scars.)


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


From: IBM Mainframe Discussion List  on behalf of Lou 
Losee 
Sent: Thursday, May 9, 2019 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

What causes IBM integrity (code-based) APARs to be generated?  Surely not
all of them are found internally.  The thing is, with the way integrity
APARs are handled the source of the problem is never disclosed.  Many are,
I believe, zero-days, that would cause a hack if found by the wrong person.

Lou
--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown


On Thu, May 9, 2019 at 2:45 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> 5 LPARS, shared DASD, same rules for each LPAR. Full volume backups were
> controlled by 1 DASD Admin.(now deceased) I no longer work there. As the
> installer of the security product, TSS, even I had very limited access to
> the security datasets.
> If hacking the mainframe was easy, or even slightly below extremely
> difficult, you would have hacks happening all the time since it’s where the
> money is. Nearly every bank in the world runs on a mainframe.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, May 9, 2019, 2:22 PM, Charles Mills  wrote:
>
> How about a volume backup? How about from a sandbox LPAR that shares DASD?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Thursday, May 9, 2019 10:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> All of the security datasets are locked down to all but a select few. It
> would be next to impossible for someone not considered highly trustworthy
> to do anything with them.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, May 9, 2019, 1:16 PM, Charles Mills  wrote:
>
> To answer the OP question, Yes, assuming
>
> - The perp has the ability to run some sort of volume backup, such as
> authority to the volume and to run a volume backup program.
> - The ability to copy the backup off of the system, such as with FTP,
> access
> to a physical tape drive, or downloading to a PC and converting to some
> sort
> of format accessible to item 3 below.
> - Access to a "friendly" system, such as Hercules, on which the perp has
> the
> ability to restore the backup. Any RACF-type restrictions on access to the
> database would not persist onto this system.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Clark Morris
> Sent: Tuesday, May 7, 2019 5:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
> 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:
>
> >In most shops only 2 people have the required access to the RACF
> database.
> >
> Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
> and then download the dump of the database?
>
> Clark Morris
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
> wrote:
> >
> >"Once they’d downloaded the RACF database, they subjected it to a
> password-cracking tool.  John the Ripper is one such tool, widely available
> on the internet.  On Feb 28, about the same time the RACF database was
> downloaded, some questions appeared on the mailing list PaulDotCom about
> hashing methods for RACF; by March 3rd, apparently in response, John the
> Ripper had been enhanced to include the capability of working on RACF
> passwords, in collaboration with another tool call CRACF.
> >
> >"In the Zauf article is this description:  'Creating a password hash
> algorithm works like this:  After entering the password, it is padded with
> spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
> with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
> using the modified password as the DES key.  Developers took a few days to
> determine the algorithm and modify John the Ripper.  Now the utility excels
> at hashing the RACF database.'  It also mentioned a source-code module
> named
> r

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Lou Losee]

What causes IBM integrity (code-based) APARs to be generated?  Surely not
all of them are found internally.  The thing is, with the way integrity
APARs are handled the source of the problem is never disclosed.  Many are,
I believe, zero-days, that would cause a hack if found by the wrong person.

Lou
--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown


On Thu, May 9, 2019 at 2:45 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> 5 LPARS, shared DASD, same rules for each LPAR. Full volume backups were
> controlled by 1 DASD Admin.(now deceased) I no longer work there. As the
> installer of the security product, TSS, even I had very limited access to
> the security datasets.
> If hacking the mainframe was easy, or even slightly below extremely
> difficult, you would have hacks happening all the time since it’s where the
> money is. Nearly every bank in the world runs on a mainframe.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, May 9, 2019, 2:22 PM, Charles Mills  wrote:
>
> How about a volume backup? How about from a sandbox LPAR that shares DASD?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Thursday, May 9, 2019 10:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> All of the security datasets are locked down to all but a select few. It
> would be next to impossible for someone not considered highly trustworthy
> to do anything with them.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, May 9, 2019, 1:16 PM, Charles Mills  wrote:
>
> To answer the OP question, Yes, assuming
>
> - The perp has the ability to run some sort of volume backup, such as
> authority to the volume and to run a volume backup program.
> - The ability to copy the backup off of the system, such as with FTP,
> access
> to a physical tape drive, or downloading to a PC and converting to some
> sort
> of format accessible to item 3 below.
> - Access to a "friendly" system, such as Hercules, on which the perp has
> the
> ability to restore the backup. Any RACF-type restrictions on access to the
> database would not persist onto this system.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Clark Morris
> Sent: Tuesday, May 7, 2019 5:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Can backup mechanisms be used to steal RACF database? was Re:
> mainframe hacking "success stories"?
>
> [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
> 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:
>
> >In most shops only 2 people have the required access to the RACF
> database.
> >
> Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
> and then download the dump of the database?
>
> Clark Morris
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
> wrote:
> >
> >"Once they’d downloaded the RACF database, they subjected it to a
> password-cracking tool.  John the Ripper is one such tool, widely available
> on the internet.  On Feb 28, about the same time the RACF database was
> downloaded, some questions appeared on the mailing list PaulDotCom about
> hashing methods for RACF; by March 3rd, apparently in response, John the
> Ripper had been enhanced to include the capability of working on RACF
> passwords, in collaboration with another tool call CRACF.
> >
> >"In the Zauf article is this description:  'Creating a password hash
> algorithm works like this:  After entering the password, it is padded with
> spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
> with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
> using the modified password as the DES key.  Developers took a few days to
> determine the algorithm and modify John the Ripper.  Now the utility excels
> at hashing the RACF database.'  It also mentioned a source-code module
> named
> racf2john.c, 'a tool that converts database file exported in the input
> data,
> read for JTR' [Google’s translation from Polish].
> >
> >"By way of testing, investigators attempted to use these tools themselves
> to crack RACF passwords.  They found that a great many passwords could be
> extracted, that they were easy to discover by dictionary attack, that they
> were not very complex and in many case

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[John McKown]

On Thu, May 9, 2019 at 2:45 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> 5 LPARS, shared DASD, same rules for each LPAR. Full volume backups were
> controlled by 1 DASD Admin.(now deceased) I no longer work there. As the
> installer of the security product, TSS, even I had very limited access to
> the security datasets.
> If hacking the mainframe was easy, or even slightly below extremely
> difficult, you would have hacks happening all the time since it’s where the
> money is. Nearly every bank in the world runs on a mainframe.
>

Yeah, much easier to hack the Windows, or even Linux, front end. And, from
what I've often read, "social engineering" can be even more effective.



-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Bill Johnson]

5 LPARS, shared DASD, same rules for each LPAR. Full volume backups were 
controlled by 1 DASD Admin.(now deceased) I no longer work there. As the 
installer of the security product, TSS, even I had very limited access to the 
security datasets.
If hacking the mainframe was easy, or even slightly below extremely difficult, 
you would have hacks happening all the time since it’s where the money is. 
Nearly every bank in the world runs on a mainframe.


Sent from Yahoo Mail for iPhone


On Thursday, May 9, 2019, 2:22 PM, Charles Mills  wrote:

How about a volume backup? How about from a sandbox LPAR that shares DASD?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, May 9, 2019 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

All of the security datasets are locked down to all but a select few. It would 
be next to impossible for someone not considered highly trustworthy to do 
anything with them.


Sent from Yahoo Mail for iPhone


On Thursday, May 9, 2019, 1:16 PM, Charles Mills  wrote:

To answer the OP question, Yes, assuming

- The perp has the ability to run some sort of volume backup, such as
authority to the volume and to run a volume backup program.
- The ability to copy the backup off of the system, such as with FTP, access
to a physical tape drive, or downloading to a PC and converting to some sort
of format accessible to item 3 below.
- Access to a "friendly" system, such as Hercules, on which the perp has the
ability to restore the backup. Any RACF-type restrictions on access to the
database would not persist onto this system.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, May 7, 2019 5:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
wrote:
>
>"Once they’d downloaded the RACF database, they subjected it to a
password-cracking tool.  John the Ripper is one such tool, widely available
on the internet.  On Feb 28, about the same time the RACF database was
downloaded, some questions appeared on the mailing list PaulDotCom about
hashing methods for RACF; by March 3rd, apparently in response, John the
Ripper had been enhanced to include the capability of working on RACF
passwords, in collaboration with another tool call CRACF.
>
>"In the Zauf article is this description:  'Creating a password hash
algorithm works like this:  After entering the password, it is padded with
spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
using the modified password as the DES key.  Developers took a few days to
determine the algorithm and modify John the Ripper.  Now the utility excels
at hashing the RACF database.'  It also mentioned a source-code module named
racf2john.c, 'a tool that converts database file exported in the input data,
read for JTR' [Google’s translation from Polish].
>
>"By way of testing, investigators attempted to use these tools themselves
to crack RACF passwords.  They found that a great many passwords could be
extracted, that they were easy to discover by dictionary attack, that they
were not very complex and in many cases that they’d been unchanged from the
default when the ID was created.  Using a standalone PC they cracked about
30 000 passwords (out of 120 000 on Applicat’s database) in  'a couple of
days'."
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* If the Earth were flat, cats would have pushed everything off it by now.
*/
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
>Sent: Monday, May 6, 2019 13:14
>
>I *believe* that was done by investigators after the fact, attempting to
determine how the attack might have been done. I don't recall that there is
compelling evidence that Svartholm actually did that.
>
>It *is* trivially easy to do, assuming (a.) read access to the DB and (b.)
old-style password storage.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

Yes, that assertion is incorrect. Read my post.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, May 9, 2019 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

> And yes, it was a z/OS vulnerability.

Are you saying that Bob Bridges was wrong when he wrote "The stolen ID also
had read access to the RACF database.."? It's not a vulnerability of the
lock when you leave your key on the porch for anyone to use.


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


From: IBM Mainframe Discussion List  on behalf of
Charles Mills 
Sent: Thursday, May 9, 2019 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

I have read the entire, very thorough police report, as has Chad R. Phil
Young has done considerable research on this.

There were two parts to it.

Svartholm somehow got the MPAA lawyer's user login for the Infotorg legal
database, hosted on USS. (The "somehow" may be known but I do not know or
recall it.) That userid was insignificant to the overall integrity of the Z
box. He was able to harass the lawyer by changing her password, etc., etc.,
but that was all. No real threat to system integrity. It would be like if I
had the userid and password for one of your vanilla CICS users. Not good,
but not the end of the world.

He leveraged that, via the http vulnerability, into pwning the whole box:
multiple RACF SPECIAL id's, etc., etc. That was the huge, huge, huge problem
for the service bureau.

So the z/OS vulnerability was the key here, not one random userid. And yes,
it was a z/OS vulnerability. It was a zero-day defect in system software
running as a service of z/OS. If that's not a z/OS vulnerability I don't
know what is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bob Bridges
Sent: Thursday, May 9, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

I believe Peter's right.  The hackers got a stolen ID with some RACF power,
by means not positively identified but social engineering is as likely as
any other hypothesis.  (I read ~speculation~ about an HTTP vulnerability,
but the forensic investigators never established how the initial breakin
occurred.)  Once they were in, they fooled around in OMVS and were able to
get more power.  The stolen ID also had read access to the RACF database.

"There are also solid indications that they downloaded the RACF database
(about 28MB)Once they'd downloaded the RACF database, they subjected it
to a password-cracking toolOn Feb 28, about the same time the RACF
database was downloaded, some questions appeared on the mailing list
PaulDotCom about hashing methods for RACF; by March 3rd, apparently in
response, John the Ripper had been enhanced to include the capability of
working on RACF passwords, in collaboration with another tool call
CRACFBy way of testing, investigators attempted to use these tools
themselves to crack RACF passwords.  They found that a great many passwords
could be extracted, that they were easy to discover by dictionary attack,
that they were not very complex and in many cases that they'd been unchanged
from the default when the ID was created.  Using a standalone PC they
cracked about 30 000 passwords (out of 120 000 on Applicat's database) in
'a couple of days'."

So yeah, the investigators did it too, but just to establish how effective
might be the new version of John the Ripper.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Be careful of your thoughts; they may become words at any moment.  -Ira
Gassen */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 9, 2019 11:39

No.  Read the original thread here.

It was a vulnerability in a Web server.  Hacking the RACF database was done
well after the fact, by investigators.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Vander Woude
Sent: Thursday, May 9, 2019 6:56 AM

That's what happened in the Swedish bank hack, back in 2012.  In that, once
they got the database copy on their pc, they used hacker tools that are out
there, to crack all the passwords.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Seymour J Metz]

> And yes, it was a z/OS vulnerability.

Are you saying that Bob Bridges was wrong when he wrote "The stolen ID also had 
read access to the RACF database.."? It's not a vulnerability of the lock when 
you leave your key on the porch for anyone to use.


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Thursday, May 9, 2019 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

I have read the entire, very thorough police report, as has Chad R. Phil Young 
has done considerable research on this.

There were two parts to it.

Svartholm somehow got the MPAA lawyer's user login for the Infotorg legal 
database, hosted on USS. (The "somehow" may be known but I do not know or 
recall it.) That userid was insignificant to the overall integrity of the Z 
box. He was able to harass the lawyer by changing her password, etc., etc., but 
that was all. No real threat to system integrity. It would be like if I had the 
userid and password for one of your vanilla CICS users. Not good, but not the 
end of the world.

He leveraged that, via the http vulnerability, into pwning the whole box: 
multiple RACF SPECIAL id's, etc., etc. That was the huge, huge, huge problem 
for the service bureau.

So the z/OS vulnerability was the key here, not one random userid. And yes, it 
was a z/OS vulnerability. It was a zero-day defect in system software running 
as a service of z/OS. If that's not a z/OS vulnerability I don't know what is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Thursday, May 9, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

I believe Peter's right.  The hackers got a stolen ID with some RACF power, by 
means not positively identified but social engineering is as likely as any 
other hypothesis.  (I read ~speculation~ about an HTTP vulnerability, but the 
forensic investigators never established how the initial breakin occurred.)  
Once they were in, they fooled around in OMVS and were able to get more power.  
The stolen ID also had read access to the RACF database.

"There are also solid indications that they downloaded the RACF database (about 
28MB)Once they’d downloaded the RACF database, they subjected it to a 
password-cracking toolOn Feb 28, about the same time the RACF database was 
downloaded, some questions appeared on the mailing list PaulDotCom about 
hashing methods for RACF; by March 3rd, apparently in response, John the Ripper 
had been enhanced to include the capability of working on RACF passwords, in 
collaboration with another tool call CRACFBy way of testing, investigators 
attempted to use these tools themselves to crack RACF passwords.  They found 
that a great many passwords could be extracted, that they were easy to discover 
by dictionary attack, that they were not very complex and in many cases that 
they’d been unchanged from the default when the ID was created.  Using a 
standalone PC they cracked about 30 000 passwords (out of 120 000 on Applicat’s 
database) in  'a couple of days'."

So yeah, the investigators did it too, but just to establish how effective 
might be the new version of John the Ripper.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Be careful of your thoughts; they may become words at any moment.  -Ira 
Gassen */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, May 9, 2019 11:39

No.  Read the original thread here.

It was a vulnerability in a Web server.  Hacking the RACF database was done 
well after the fact, by investigators.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Vander Woude
Sent: Thursday, May 9, 2019 6:56 AM

That's what happened in the Swedish bank hack, back in 2012.  In that, once 
they got the database copy on their pc, they used hacker tools that are out 
there, to crack all the passwords.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

How about a volume backup? How about from a sandbox LPAR that shares DASD?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, May 9, 2019 10:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

All of the security datasets are locked down to all but a select few. It would 
be next to impossible for someone not considered highly trustworthy to do 
anything with them.


Sent from Yahoo Mail for iPhone


On Thursday, May 9, 2019, 1:16 PM, Charles Mills  wrote:

To answer the OP question, Yes, assuming

- The perp has the ability to run some sort of volume backup, such as
authority to the volume and to run a volume backup program.
- The ability to copy the backup off of the system, such as with FTP, access
to a physical tape drive, or downloading to a PC and converting to some sort
of format accessible to item 3 below.
- Access to a "friendly" system, such as Hercules, on which the perp has the
ability to restore the backup. Any RACF-type restrictions on access to the
database would not persist onto this system.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, May 7, 2019 5:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
wrote:
>
>"Once they’d downloaded the RACF database, they subjected it to a
password-cracking tool.  John the Ripper is one such tool, widely available
on the internet.  On Feb 28, about the same time the RACF database was
downloaded, some questions appeared on the mailing list PaulDotCom about
hashing methods for RACF; by March 3rd, apparently in response, John the
Ripper had been enhanced to include the capability of working on RACF
passwords, in collaboration with another tool call CRACF.
>
>"In the Zauf article is this description:  'Creating a password hash
algorithm works like this:  After entering the password, it is padded with
spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
using the modified password as the DES key.  Developers took a few days to
determine the algorithm and modify John the Ripper.  Now the utility excels
at hashing the RACF database.'  It also mentioned a source-code module named
racf2john.c, 'a tool that converts database file exported in the input data,
read for JTR' [Google’s translation from Polish].
>
>"By way of testing, investigators attempted to use these tools themselves
to crack RACF passwords.  They found that a great many passwords could be
extracted, that they were easy to discover by dictionary attack, that they
were not very complex and in many cases that they’d been unchanged from the
default when the ID was created.  Using a standalone PC they cracked about
30 000 passwords (out of 120 000 on Applicat’s database) in  'a couple of
days'."
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* If the Earth were flat, cats would have pushed everything off it by now.
*/
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
>Sent: Monday, May 6, 2019 13:14
>
>I *believe* that was done by investigators after the fact, attempting to
determine how the attack might have been done. I don't recall that there is
compelling evidence that Svartholm actually did that.
>
>It *is* trivially easy to do, assuming (a.) read access to the DB and (b.)
old-style password storage.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Spiegel
>Sent: Sunday, May 5, 2019 8:02 AM
>
>One of the tricks he pulled was to offload the RACF Database to a PC and
Dictionary Attack it.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive acc

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

I have read the entire, very thorough police report, as has Chad R. Phil Young 
has done considerable research on this.

There were two parts to it.

Svartholm somehow got the MPAA lawyer's user login for the Infotorg legal 
database, hosted on USS. (The "somehow" may be known but I do not know or 
recall it.) That userid was insignificant to the overall integrity of the Z 
box. He was able to harass the lawyer by changing her password, etc., etc., but 
that was all. No real threat to system integrity. It would be like if I had the 
userid and password for one of your vanilla CICS users. Not good, but not the 
end of the world.

He leveraged that, via the http vulnerability, into pwning the whole box: 
multiple RACF SPECIAL id's, etc., etc. That was the huge, huge, huge problem 
for the service bureau. 

So the z/OS vulnerability was the key here, not one random userid. And yes, it 
was a z/OS vulnerability. It was a zero-day defect in system software running 
as a service of z/OS. If that's not a z/OS vulnerability I don't know what is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Thursday, May 9, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

I believe Peter's right.  The hackers got a stolen ID with some RACF power, by 
means not positively identified but social engineering is as likely as any 
other hypothesis.  (I read ~speculation~ about an HTTP vulnerability, but the 
forensic investigators never established how the initial breakin occurred.)  
Once they were in, they fooled around in OMVS and were able to get more power.  
The stolen ID also had read access to the RACF database.

"There are also solid indications that they downloaded the RACF database (about 
28MB)Once they’d downloaded the RACF database, they subjected it to a 
password-cracking tool....On Feb 28, about the same time the RACF database was 
downloaded, some questions appeared on the mailing list PaulDotCom about 
hashing methods for RACF; by March 3rd, apparently in response, John the Ripper 
had been enhanced to include the capability of working on RACF passwords, in 
collaboration with another tool call CRACFBy way of testing, investigators 
attempted to use these tools themselves to crack RACF passwords.  They found 
that a great many passwords could be extracted, that they were easy to discover 
by dictionary attack, that they were not very complex and in many cases that 
they’d been unchanged from the default when the ID was created.  Using a 
standalone PC they cracked about 30 000 passwords (out of 120 000 on Applicat’s 
database) in  'a couple of days'."

So yeah, the investigators did it too, but just to establish how effective 
might be the new version of John the Ripper.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Be careful of your thoughts; they may become words at any moment.  -Ira 
Gassen */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, May 9, 2019 11:39

No.  Read the original thread here.

It was a vulnerability in a Web server.  Hacking the RACF database was done 
well after the fact, by investigators.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Vander Woude
Sent: Thursday, May 9, 2019 6:56 AM

That's what happened in the Swedish bank hack, back in 2012.  In that, once 
they got the database copy on their pc, they used hacker tools that are out 
there, to crack all the passwords.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Bill Johnson]

All of the security datasets are locked down to all but a select few. It would 
be next to impossible for someone not considered highly trustworthy to do 
anything with them.


Sent from Yahoo Mail for iPhone


On Thursday, May 9, 2019, 1:16 PM, Charles Mills  wrote:

To answer the OP question, Yes, assuming

- The perp has the ability to run some sort of volume backup, such as
authority to the volume and to run a volume backup program.
- The ability to copy the backup off of the system, such as with FTP, access
to a physical tape drive, or downloading to a PC and converting to some sort
of format accessible to item 3 below.
- Access to a "friendly" system, such as Hercules, on which the perp has the
ability to restore the backup. Any RACF-type restrictions on access to the
database would not persist onto this system.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, May 7, 2019 5:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
wrote:
>
>"Once they’d downloaded the RACF database, they subjected it to a
password-cracking tool.  John the Ripper is one such tool, widely available
on the internet.  On Feb 28, about the same time the RACF database was
downloaded, some questions appeared on the mailing list PaulDotCom about
hashing methods for RACF; by March 3rd, apparently in response, John the
Ripper had been enhanced to include the capability of working on RACF
passwords, in collaboration with another tool call CRACF.
>
>"In the Zauf article is this description:  'Creating a password hash
algorithm works like this:  After entering the password, it is padded with
spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
using the modified password as the DES key.  Developers took a few days to
determine the algorithm and modify John the Ripper.  Now the utility excels
at hashing the RACF database.'  It also mentioned a source-code module named
racf2john.c, 'a tool that converts database file exported in the input data,
read for JTR' [Google’s translation from Polish].
>
>"By way of testing, investigators attempted to use these tools themselves
to crack RACF passwords.  They found that a great many passwords could be
extracted, that they were easy to discover by dictionary attack, that they
were not very complex and in many cases that they’d been unchanged from the
default when the ID was created.  Using a standalone PC they cracked about
30 000 passwords (out of 120 000 on Applicat’s database) in  'a couple of
days'."
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* If the Earth were flat, cats would have pushed everything off it by now.
*/
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
>Sent: Monday, May 6, 2019 13:14
>
>I *believe* that was done by investigators after the fact, attempting to
determine how the attack might have been done. I don't recall that there is
compelling evidence that Svartholm actually did that.
>
>It *is* trivially easy to do, assuming (a.) read access to the DB and (b.)
old-style password storage.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Spiegel
>Sent: Sunday, May 5, 2019 8:02 AM
>
>One of the tricks he pulled was to offload the RACF Database to a PC and
Dictionary Attack it.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / si

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Bob Bridges]

I believe Peter's right.  The hackers got a stolen ID with some RACF power, by 
means not positively identified but social engineering is as likely as any 
other hypothesis.  (I read ~speculation~ about an HTTP vulnerability, but the 
forensic investigators never established how the initial breakin occurred.)  
Once they were in, they fooled around in OMVS and were able to get more power.  
The stolen ID also had read access to the RACF database.

"There are also solid indications that they downloaded the RACF database (about 
28MB)Once they’d downloaded the RACF database, they subjected it to a 
password-cracking toolOn Feb 28, about the same time the RACF database was 
downloaded, some questions appeared on the mailing list PaulDotCom about 
hashing methods for RACF; by March 3rd, apparently in response, John the Ripper 
had been enhanced to include the capability of working on RACF passwords, in 
collaboration with another tool call CRACFBy way of testing, investigators 
attempted to use these tools themselves to crack RACF passwords.  They found 
that a great many passwords could be extracted, that they were easy to discover 
by dictionary attack, that they were not very complex and in many cases that 
they’d been unchanged from the default when the ID was created.  Using a 
standalone PC they cracked about 30 000 passwords (out of 120 000 on Applicat’s 
database) in  'a couple of days'."

So yeah, the investigators did it too, but just to establish how effective 
might be the new version of John the Ripper.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Be careful of your thoughts; they may become words at any moment.  -Ira 
Gassen */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, May 9, 2019 11:39

No.  Read the original thread here.

It was a vulnerability in a Web server.  Hacking the RACF database was done 
well after the fact, by investigators.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Vander Woude
Sent: Thursday, May 9, 2019 6:56 AM

That's what happened in the Swedish bank hack, back in 2012.  In that, once 
they got the database copy on their pc, they used hacker tools that are out 
there, to crack all the passwords.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

To answer the OP question, Yes, assuming

- The perp has the ability to run some sort of volume backup, such as
authority to the volume and to run a volume backup program.
- The ability to copy the backup off of the system, such as with FTP, access
to a physical tape drive, or downloading to a PC and converting to some sort
of format accessible to item 3 below.
- Access to a "friendly" system, such as Hercules, on which the perp has the
ability to restore the backup. Any RACF-type restrictions on access to the
database would not persist onto this system.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Tuesday, May 7, 2019 5:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Can backup mechanisms be used to steal RACF database? was Re:
mainframe hacking "success stories"?

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 6, 2019, 11:06 PM, Bob Bridges 
wrote:
>
>"Once they’d downloaded the RACF database, they subjected it to a
password-cracking tool.  John the Ripper is one such tool, widely available
on the internet.  On Feb 28, about the same time the RACF database was
downloaded, some questions appeared on the mailing list PaulDotCom about
hashing methods for RACF; by March 3rd, apparently in response, John the
Ripper had been enhanced to include the capability of working on RACF
passwords, in collaboration with another tool call CRACF.
>
>"In the Zauf article is this description:  'Creating a password hash
algorithm works like this:  After entering the password, it is padded with
spaces, if necessary, to a length of 8 bytes.  Each character is then XORed
with x‘55’ and shifted left one bit.  Then the user ID is DES-encrypted,
using the modified password as the DES key.  Developers took a few days to
determine the algorithm and modify John the Ripper.  Now the utility excels
at hashing the RACF database.'  It also mentioned a source-code module named
racf2john.c, 'a tool that converts database file exported in the input data,
read for JTR' [Google’s translation from Polish].
>
>"By way of testing, investigators attempted to use these tools themselves
to crack RACF passwords.  They found that a great many passwords could be
extracted, that they were easy to discover by dictionary attack, that they
were not very complex and in many cases that they’d been unchanged from the
default when the ID was created.  Using a standalone PC they cracked about
30 000 passwords (out of 120 000 on Applicat’s database) in  'a couple of
days'."
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* If the Earth were flat, cats would have pushed everything off it by now.
*/
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
>Sent: Monday, May 6, 2019 13:14
>
>I *believe* that was done by investigators after the fact, attempting to
determine how the attack might have been done. I don't recall that there is
compelling evidence that Svartholm actually did that.
>
>It *is* trivially easy to do, assuming (a.) read access to the DB and (b.)
old-style password storage.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Spiegel
>Sent: Sunday, May 5, 2019 8:02 AM
>
>One of the tricks he pulled was to offload the RACF Database to a PC and
Dictionary Attack it.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Charles Mills]

No.

Read the original thread here.

It was a vulnerability in a Web server.

Hacking the RACF database was done well after the fact, by investigators.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Vander Woude
Sent: Thursday, May 9, 2019 6:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: 
mainframe hacking "success stories"?

That's what happened in the Swedish bank hack, back in 2012.  

In that, once they got the database copy on their pc, they used hacker tools 
that are out there, to crack all the passwords.

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Mike Schwab]

If you can transfer the backup file (real or virtual tape) to another
system, then you can use the admin authorization to restore any or all
files in the backup file.  Just like using a rescue system to restore
at a DR site.

On Thu, May 9, 2019 at 8:56 AM Peter Vander Woude
 wrote:
>
> On Tue, 7 May 2019 09:26:58 -0300, Clark Morris  wrote:
>
>
> >Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
> >and then download the dump of the database?
> >
> >Clark Morris
> >>
>
> Clark,
>
> If they have read access to the database, yes.  That's what happened in the 
> Swedish bank hack, back in 2012.
>
> In that, once they got the database copy on their pc, they used hacker tools 
> that are out there, to crack all the passwords.
>
> Peter
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Peter Vander Woude]

On Tue, 7 May 2019 09:26:58 -0300, Clark Morris  wrote:


>Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
>and then download the dump of the database?
>
>Clark Morris
>>

Clark,

If they have read access to the database, yes.  That's what happened in the 
Swedish bank hack, back in 2012.  

In that, once they got the database copy on their pc, they used hacker tools 
that are out there, to crack all the passwords.

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Clark Morris]

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 6, 2019, 11:06 PM, Bob Bridges  wrote:
>
>"Once they’d downloaded the RACF database, they subjected it to a 
>password-cracking tool.  John the Ripper is one such tool, widely available on 
>the internet.  On Feb 28, about the same time the RACF database was 
>downloaded, some questions appeared on the mailing list PaulDotCom about 
>hashing methods for RACF; by March 3rd, apparently in response, John the 
>Ripper had been enhanced to include the capability of working on RACF 
>passwords, in collaboration with another tool call CRACF.
>
>"In the Zauf article is this description:  'Creating a password hash algorithm 
>works like this:  After entering the password, it is padded with spaces, if 
>necessary, to a length of 8 bytes.  Each character is then XORed with x‘55’ 
>and shifted left one bit.  Then the user ID is DES-encrypted, using the 
>modified password as the DES key.  Developers took a few days to determine the 
>algorithm and modify John the Ripper.  Now the utility excels at hashing the 
>RACF database.'  It also mentioned a source-code module named racf2john.c, 'a 
>tool that converts database file exported in the input data, read for JTR' 
>[Google’s translation from Polish].
>
>"By way of testing, investigators attempted to use these tools themselves to 
>crack RACF passwords.  They found that a great many passwords could be 
>extracted, that they were easy to discover by dictionary attack, that they 
>were not very complex and in many cases that they’d been unchanged from the 
>default when the ID was created.  Using a standalone PC they cracked about 30 
>000 passwords (out of 120 000 on Applicat’s database) in  'a couple of days'."
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* If the Earth were flat, cats would have pushed everything off it by now. */
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Charles Mills
>Sent: Monday, May 6, 2019 13:14
>
>I *believe* that was done by investigators after the fact, attempting to 
>determine how the attack might have been done. I don't recall that there is 
>compelling evidence that Svartholm actually did that.
>
>It *is* trivially easy to do, assuming (a.) read access to the DB and (b.) 
>old-style password storage.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of David Spiegel
>Sent: Sunday, May 5, 2019 8:02 AM
>
>One of the tricks he pulled was to offload the RACF Database to a PC and 
>Dictionary Attack it.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Jesse 1 Robinson]

I'm taking seriously the advice of one poster that *no one* should have ALTER 
access to the RACF data base. That's to minimize the chance that someone might 
casually make a fatal mistake. On the rare occasion where a configuration needs 
to be altered, the requirement for intervention of a SPECIAL user is one more 
speed bump on a one-way road to hell. 

SYSRACF as a phantom user cannot do anything. Furthermore, SYSRACF will never 
leave the company or cede identity to someone else who may be totally clueless. 
(Ooh, how could that happen?) I'm not totally sold on this strategy, but I've 
seen the consequences of too much power in hands of real, even high-minded, 
users.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert S. Hansel (RSH)
Sent: Thursday, May 25, 2017 2:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database

Hi Skip,

I usually assign a group as the owner of a profile. In the case of datasets, I 
typically assign the user or group matching the dataset's high level qualifier 
as the owner. There are exceptions such as when you specifically want a user to 
be able to administer a particular profile or you want to exclude groups or 
users from a Group-SPECIAL administrator's scope-of-groups.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Wed, 24 May 2017 19:22:23 +
From:Jesse 1 Robinson 
Subject: Re: RACF Database

A fallout of this thread is that we're looking to assign a new owner to 
profiles that cover the RACF data sets. I'd like something truly permanent. The 
RACF STC runs with user SYSRACF, which is a valid userid that no one could log 
on to. Does that seem reasonable? Then only someone with RACF SPECIAL could 
make profile changes. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Robert S. Hansel (RSH)]

Hi Skip,

I usually assign a group as the owner of a profile. In the case of datasets, I 
typically assign the user or group matching the dataset's high level qualifier 
as the owner. There are exceptions such as when you specifically want a user to 
be able to administer a particular profile or you want to exclude groups or 
users from a Group-SPECIAL administrator's scope-of-groups.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Wed, 24 May 2017 19:22:23 +
From:Jesse 1 Robinson 
Subject: Re: RACF Database

A fallout of this thread is that we're looking to assign a new owner to 
profiles that cover the RACF data sets. I'd like something truly permanent. The 
RACF STC runs with user SYSRACF, which is a valid userid that no one could log 
on to. Does that seem reasonable? Then only someone with RACF SPECIAL could 
make profile changes. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Jesse 1 Robinson]

A fallout of this thread is that we're looking to assign a new owner to 
profiles that cover the RACF data sets. I'd like something truly permanent. The 
RACF STC runs with user SYSRACF, which is a valid userid that no one could log 
on to. Does that seem reasonable? Then only someone with RACF SPECIAL could 
make profile changes. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert S. Hansel (RSH)
Sent: Wednesday, May 24, 2017 3:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database

Hi Skip,

Point of clarification. IRRDBU00 no longer required UPDATE access with 
NOLOCKINPUT as of z/OS 2.2.

Regards, Bob

-Original Message-
From: Robert S. Hansel (RSH) [mailto:r.han...@rshconsulting.com]
Sent: Wednesday, May 24, 2017 6:07 AM
To: 'IBM Mainframe Discussion List'
Subject: RE:RACF Database

Hi Skip,

I very much doubt the security folks need UPDATE access. At one time, the 
database unload utility IRRDBU00 required UPDATE, but this is no longer the 
case if using PARM NOLOCKINPUT, and besides, they should only be creating 
unloads from an offline IRRUT200 copy of the database and not the live one. 
READ access to generate IRRUT200 copies is the most they should need.

Other utilities that require UPDATE access, which I would not expect them to be 
using, are IRRMIN00 to apply template updates, IRRIRA00 for converting the 
database to the AIM structure, IRRUT400 to copy/reorg the database, and BLKUPD 
to repair the database.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Tue, 23 May 2017 21:57:21 +
From:Jesse 1 Robinson 
Subject: Re: RACF Database

So it turns out that the number of folks here with ALTER access to RACF data 
sets is way smaller than I expected. There are however several userids with 
UPDATE access; they seem to be mostly in the 'security management' department. 
Do the standard RACF utilities require UPDATE for housekeeping? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Elardus Engelbrecht]

Robert S. Hansel (RSH) wrote:

>Restricting access to the RACF database is essential, but it isn't enough to 
>save you if the database is not allocated as unmovable. DFSMSdss' data 
>management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores 
>dataset profiles and can perform functions such as compress on any dataset.

This is a serious gaping black hole which you can plug with this RACF FACILITY 
Class profile STGADMIN.ADR..

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Robert S. Hansel (RSH)]

Hi Skip,

Point of clarification. IRRDBU00 no longer required UPDATE access with 
NOLOCKINPUT as of z/OS 2.2.

Regards, Bob

-Original Message-
From: Robert S. Hansel (RSH) [mailto:r.han...@rshconsulting.com] 
Sent: Wednesday, May 24, 2017 6:07 AM
To: 'IBM Mainframe Discussion List'
Subject: RE:RACF Database

Hi Skip,

I very much doubt the security folks need UPDATE access. At one time, the 
database unload utility IRRDBU00 required UPDATE, but this is no longer the 
case if using PARM NOLOCKINPUT, and besides, they should only be creating 
unloads from an offline IRRUT200 copy of the database and not the live one. 
READ access to generate IRRUT200 copies is the most they should need.

Other utilities that require UPDATE access, which I would not expect them to be 
using, are IRRMIN00 to apply template updates, IRRIRA00 for converting the 
database to the AIM structure, IRRUT400 to copy/reorg the database, and BLKUPD 
to repair the database.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Tue, 23 May 2017 21:57:21 +
From:Jesse 1 Robinson 
Subject: Re: RACF Database

So it turns out that the number of folks here with ALTER access to RACF data 
sets is way smaller than I expected. There are however several userids with 
UPDATE access; they seem to be mostly in the 'security management' department. 
Do the standard RACF utilities require UPDATE for housekeeping? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Robert S. Hansel (RSH)]

Hi Skip,

I very much doubt the security folks need UPDATE access. At one time, the 
database unload utility IRRDBU00 required UPDATE, but this is no longer the 
case if using PARM NOLOCKINPUT, and besides, they should only be creating 
unloads from an offline IRRUT200 copy of the database and not the live one. 
READ access to generate IRRUT200 copies is the most they should need.

Other utilities that require UPDATE access, which I would not expect them to be 
using, are IRRMIN00 to apply template updates, IRRIRA00 for converting the 
database to the AIM structure, IRRUT400 to copy/reorg the database, and BLKUPD 
to repair the database.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Tue, 23 May 2017 21:57:21 +
From:Jesse 1 Robinson 
Subject: Re: RACF Database

So it turns out that the number of folks here with ALTER access to RACF data 
sets is way smaller than I expected. There are however several userids with 
UPDATE access; they seem to be mostly in the 'security management' department. 
Do the standard RACF utilities require UPDATE for housekeeping? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Robert S. Hansel (RSH)]

Todd,

Restricting access to the RACF database is essential, but it isn't enough to 
save you if the database is not allocated as unmovable. DFSMSdss' data 
management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores 
dataset profiles and can perform functions such as compress on any dataset.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Tue, 23 May 2017 18:36:52 +
From:"Burrell, Todd" 
Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Wouldn't a simpler solution to protecting the RACF database simply be to give 
pretty much no one ALTER access to it?   I know that at most shops only one or 
two folks had ALTER or UPDATE to the actual file and that seems like the best 
course of action to avoid accidental deletion? 
And we backed up the RACF DB 4 times a day as well - just in case.  

Todd Burrell | Sr. Mainframe Systems Administrator 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Jesse 1 Robinson]

So it turns out that the number of folks here with ALTER access to RACF data 
sets is way smaller than I expected. There are however several userids with 
UPDATE access; they seem to be mostly in the 'security management' department. 
Do the standard RACF utilities require UPDATE for housekeeping? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Tuesday, May 23, 2017 12:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database

It should go without saying that ALTER (and even READ) access to the RACF 
database data set should be restricted to those that really need direct access 
to the database data set itself.  Ordinary users and even RACF administrators 
should have NONE access to the RACF database data set.  I would have been one 
with ALTER authority. 

I always preferred, whenever not too difficult, to put in place additional 
barriers that would require a positive, deliberate act before a single mistake 
could cause a disastrous consequence, not just assume that those with the 
authority to create a disaster will never commit an error -- like submitting a 
defrag for a drive and then realizing by harsh empirical evidence it had a 
critical active data set like a RACF database that lacked an enqueue.  In our 
case, decades ago, it was an automated system job that ran in the middle of the 
night that conditionally decided what drives to defrag based on fragmentation 
index.  Ran for months without incident until the night the fragmentation index 
threshold was reached on the drive with the RACF database, and the console 
filled up with red RACF I/O failures!  Didn't take long to deduce what had 
happened -- we had to restore the database using our one-drive MVS system, and 
took steps to reduce odds it could ever happen again.
 Joel C. Ewing

On 05/23/2017 01:36 PM, Burrell, Todd wrote:
> Wouldn't a simpler solution to protecting the RACF database simply be to give 
> pretty much no one ALTER access to it?   I know that at most shops only one 
> or two folks had ALTER or UPDATE to the actual file and that seems like the 
> best course of action to avoid accidental deletion? 
> And we backed up the RACF DB 4 times a day as well - just in case.  
>
> Todd Burrell | Sr. Mainframe Systems Administrator
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF Database (was: Sample JCL for file transfer using 
> NJE/TCPIP)
>
> I have not tried this, but IBM supplies a RACF started task whose purpose is 
> to issue RACF commands via a console. As supplied, the RACF STC has no DDs, 
> but I suppose you could add one for the primary and maybe even alternate RACF 
> data base(s) with DISP=SHR. The hard part of coding such a task has already 
> been done. Stopping it seems to require FORCE ARM, but you wouldn't stop it 
> very often anyway. 
>
> -
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 11:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file 
> transfer using NJE/TCPIP)
>
> I've been expecting someone with actual experience in this area to jump in. I 
> don't think you can get away with 'wait forever' logic. Eventually you'll get 
> S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
> libraries, seems to be very busy doing something, accumulating both CPU time 
> and EXCP count. Maybe there's something on CBT?
>
> 
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Monday, May 22, 2017 4:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file 
> transfer using NJE/TCPIP)
>
> On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:
>
>> RECFM PSU may prevent moving the database, but it doesn't block 
>> deletion.  After realizing this somewhat-essential data set wasn't 
>> protected by an enqueue, we picked an installation

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

Someone else pointed out that xxxSTOP works for the RACF STC, where xxx is the 
subsystem identifier specified in IEFSSNxx. 

In a larger shop, severely limiting access to *any* resource is problematic. If 
the installation needs 24x7 support, someone has to hold the key, and that 
someone has to be available to put it in the lock. I agree that too much access 
is a dangerous thing, but too little can be crippling as well. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Radoslaw Skorupka
Sent: Tuesday, May 23, 2017 12:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is 
@STOP). It also can be started again as well. The only cost is "address space 
unavailable" issue.

Of course *properly protected* RACF db cannot be moved or deleted, due to lack 
of authorities. No one should have even READ to this profile.

BTW: VSAM dataset can be read very early - see IODF file. Is it pure VSAM 
access method? Who cares!

R.Skorupka 
(sent from mobile)


BTW


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database

[Joel C. Ewing]

It should go without saying that ALTER (and even READ) access to the
RACF database data set should be restricted to those that really need
direct access to the database data set itself.  Ordinary users and even
RACF administrators should have NONE access to the RACF database data
set.  I would have been one with ALTER authority. 

I always preferred, whenever not too difficult, to put in place
additional barriers that would require a positive, deliberate act before
a single mistake could cause a disastrous consequence, not just assume
that those with the authority to create a disaster will never commit an
error -- like submitting a defrag for a drive and then realizing by
harsh empirical evidence it had a critical active data set like a RACF
database that lacked an enqueue.  In our case, decades ago, it was an
automated system job that ran in the middle of the night that
conditionally decided what drives to defrag based on fragmentation
index.  Ran for months without incident until the night the
fragmentation index threshold was reached on the drive with the RACF
database, and the console filled up with red RACF I/O failures!  Didn't
take long to deduce what had happened -- we had to restore the database
using our one-drive MVS system, and took steps to reduce odds it could
ever happen again.
 Joel C. Ewing

On 05/23/2017 01:36 PM, Burrell, Todd wrote:
> Wouldn't a simpler solution to protecting the RACF database simply be to give 
> pretty much no one ALTER access to it?   I know that at most shops only one 
> or two folks had ALTER or UPDATE to the actual file and that seems like the 
> best course of action to avoid accidental deletion? 
> And we backed up the RACF DB 4 times a day as well - just in case.  
>
> Todd Burrell | Sr. Mainframe Systems Administrator 
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
>
> I have not tried this, but IBM supplies a RACF started task whose purpose is 
> to issue RACF commands via a console. As supplied, the RACF STC has no DDs, 
> but I suppose you could add one for the primary and maybe even alternate RACF 
> data base(s) with DISP=SHR. The hard part of coding such a task has already 
> been done. Stopping it seems to require FORCE ARM, but you wouldn't stop it 
> very often anyway. 
>
> -
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 11:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file transfer 
> using NJE/TCPIP)
>
> I've been expecting someone with actual experience in this area to jump in. I 
> don't think you can get away with 'wait forever' logic. Eventually you'll get 
> S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
> libraries, seems to be very busy doing something, accumulating both CPU time 
> and EXCP count. Maybe there's something on CBT?
>
> 
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Monday, May 22, 2017 4:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file transfer 
> using NJE/TCPIP)
>
> On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:
>
>> RECFM PSU may prevent moving the database, but it doesn't block 
>> deletion.  After realizing this somewhat-essential data set wasn't 
>> protected by an enqueue, we picked an installation started task that 
>> was normally running all the time (but which could be shut down if need 
>> be), and added an unreferenced DD for the RACF database with DISP=SHR 
>> to reduce the odds of both accidental deletion and movement.
>>
> Suppose one wanted to craft a started task expressly for that purpose, using 
> minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
> Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
> command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
> analogue of SIGINT?
>
> -- gil
>
>
> ...


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Radoslaw Skorupka]

RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is 
@STOP). It also can be started again as well. The only cost is "address space 
unavailable" issue.

Of course *properly protected* RACF db cannot be moved or deleted, due to lack 
of authorities. No one should have even READ to this profile.

BTW: VSAM dataset can be read very early - see IODF file. Is it pure VSAM 
access method? Who cares!

R.Skorupka 
(sent from mobile)


BTW

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Burrell, Todd]

Wouldn't a simpler solution to protecting the RACF database simply be to give 
pretty much no one ALTER access to it?   I know that at most shops only one or 
two folks had ALTER or UPDATE to the actual file and that seems like the best 
course of action to avoid accidental deletion? 
And we backed up the RACF DB 4 times a day as well - just in case.  

Todd Burrell | Sr. Mainframe Systems Administrator 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

I have not tried this, but IBM supplies a RACF started task whose purpose is to 
issue RACF commands via a console. As supplied, the RACF STC has no DDs, but I 
suppose you could add one for the primary and maybe even alternate RACF data 
base(s) with DISP=SHR. The hard part of coding such a task has already been 
done. Stopping it seems to require FORCE ARM, but you wouldn't stop it very 
often anyway. 

-
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

I've been expecting someone with actual experience in this area to jump in. I 
don't think you can get away with 'wait forever' logic. Eventually you'll get 
S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
libraries, seems to be very busy doing something, accumulating both CPU time 
and EXCP count. Maybe there's something on CBT?



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 22, 2017 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block 
>deletion.  After realizing this somewhat-essential data set wasn't 
>protected by an enqueue, we picked an installation started task that 
>was normally running all the time (but which could be shut down if need 
>be), and added an unreferenced DD for the RACF database with DISP=SHR 
>to reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose, using 
minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
analogue of SIGINT?

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

I have not tried this, but IBM supplies a RACF started task whose purpose is to 
issue RACF commands via a console. As supplied, the RACF STC has no DDs, but I 
suppose you could add one for the primary and maybe even alternate RACF data 
base(s) with DISP=SHR. The hard part of coding such a task has already been 
done. Stopping it seems to require FORCE ARM, but you wouldn't stop it very 
often anyway. 

-
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

I've been expecting someone with actual experience in this area to jump in. I 
don't think you can get away with 'wait forever' logic. Eventually you'll get 
S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
libraries, seems to be very busy doing something, accumulating both CPU time 
and EXCP count. Maybe there's something on CBT?



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 22, 2017 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block 
>deletion.  After realizing this somewhat-essential data set wasn't 
>protected by an enqueue, we picked an installation started task that 
>was normally running all the time (but which could be shut down if need 
>be), and added an unreferenced DD for the RACF database with DISP=SHR 
>to reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose, using 
minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
analogue of SIGINT?

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

I've been expecting someone with actual experience in this area to jump in. I 
don't think you can get away with 'wait forever' logic. Eventually you'll get 
S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
libraries, seems to be very busy doing something, accumulating both CPU time 
and EXCP count. Maybe there's something on CBT?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 22, 2017 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block 
>deletion.  After realizing this somewhat-essential data set wasn't 
>protected by an enqueue, we picked an installation started task that 
>was normally running all the time (but which could be shut down if need 
>be), and added an unreferenced DD for the RACF database with DISP=SHR 
>to reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose, using 
minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
analogue of SIGINT?

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[David W Noon]

On Tue, 23 May 2017 12:27:10 -0400, Tony Harminc (t...@harminc.net) 
wrote about "Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)" (in 
):



On 22 May 2017 at 12:57, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

[snip]

How does ACF2, based on VSAM, meet this requirement of early availability?


The same way it would if ACF2 used BDAM or QSAM or... VSAM is not like VTAM
or TCP/IP or z/OS UNIX filesystems. There is no "VSAM address space" to be
initialized at some point in the IPL.*  VSAM is almost entirely a
collection of subroutines, just like the older access methods.

* These days there are all sorts of "helper" address spaces around - VLF,
LLA, CATALOG, ... and I suppose one of those may need to be active in order
to allocate and open a VSAM dataset. But just to do the I/O, I don't think
so.


The CATALOG address space needs to be active just to open a VSAM 
cluster. But CATALOG starts very early on in the IPL because it is 
needed to access all and any of the pagespaces. This is because a 
pagespace is a VSAM cluster too.

--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Tony Harminc]

On 22 May 2017 at 12:57, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> > ... In any case, a SAF product has to be available extremely early in
> IPL, ...
> >
> How does ACF2, based on VSAM, meet this requirement of early availability?
>

The same way it would if ACF2 used BDAM or QSAM or... VSAM is not like VTAM
or TCP/IP or z/OS UNIX filesystems. There is no "VSAM address space" to be
initialized at some point in the IPL.*  VSAM is almost entirely a
collection of subroutines, just like the older access methods.

* These days there are all sorts of "helper" address spaces around - VLF,
LLA, CATALOG, ... and I suppose one of those may need to be active in order
to allocate and open a VSAM dataset. But just to do the I/O, I don't think
so.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Dana Mitchell]

On Tue, 23 May 2017 07:30:02 -0500, John McKown  
wrote:

>On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson 
>wrote:
>
>> Brief war story. Long before "z/OS", someone accidentally deleted (!!!)
>> the primary RACF data base. It was not enqueued on as previously noted.
>>
>
>​Been there. Done that. Beat up the programmer.
>

One also gets a similar pleasing effect if you run an IRRUT200 step with DD 
SYSUT1 pointing to the RACF Database.

Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Elardus Engelbrecht]

John McKown wrote:

>>Long before "z/OS", someone accidentally deleted (!!!) the primary RACF data 
>>base. 
>> Could not have done that with VSAM. ;-)

>​Been there. Done that. Beat up the programmer.

I hope he survived your cruel beating, because if he did the same error on the 
BACKUP RACF DB, then you can beat him up AGAIN... 8-P

   ;-D   

.. is it already Friday? 

Groete / Greetings
Elardus Engelbrecht

Gazillion years ago a colleague deleted a UCAT while initializing a volser. 
Great messy drama...  He got that our moving office trophy as a prize for the 
"best error" made in a while... ;-D

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 23 May, 2017 0:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF Database (was: Sample JCL for file transfer using
> NJE/TCPIP)
> 
> Brief war story. Long before "z/OS", someone accidentally deleted (!!!)
> the primary RACF data base. It was not enqueued on as previously noted.
> Data was intact and the system hummed along, but there was no
> 'SYS1.RACF' in the catalog. Using backup listings, we figured out the
> exact location on the volume where the data set lived. Then we
> reallocated it using ABSTR to rebuild the VTOC entry and did a DEF NVSAM
> to rebuild the catalog entry. Some further cleanup action followed, but
> basically there was never an outage.
> 

I did exactly the same, several decades ago, with the JES2 Checkpoint. Now JES2 
allocates (and therefor enqueues) the checkpoint for already some decades. Why 
can't RACF?

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[John McKown]

On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson 
wrote:

> Brief war story. Long before "z/OS", someone accidentally deleted (!!!)
> the primary RACF data base. It was not enqueued on as previously noted.
> Data was intact and the system hummed along, but there was no 'SYS1.RACF'
> in the catalog. Using backup listings, we figured out the exact location on
> the volume where the data set lived. Then we reallocated it using ABSTR to
> rebuild the VTOC entry and did a DEF NVSAM to rebuild the catalog entry.
> Some further cleanup action followed, but basically there was never an
> outage.
>
> Could not have done that with VSAM. ;-)
>

​Been there. Done that. Beat up the programmer.


> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>


-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Paul Gilmartin]

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block
>deletion.  After realizing this somewhat-essential data set wasn't
>protected by an enqueue, we picked an installation started task that was
>normally running all the time (but which could be shut down if need be),
>and added an unreferenced DD for the RACF database with DISP=SHR to
>reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose,
using minimum resource.  Would it suffice to WAIT on an ECB that you
never POSTed?  Would this annoy WLM?  Is there a better way?  Should
it intercept a STOP command and WTOR with an Abort/Retry/Ignore
prompt?  What's the OS Classic analogue of SIGINT?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Paul Gilmartin]

On Mon, 22 May 2017 09:21:48 -0400, Robert S. Hansel (RSH) wrote:
>
>... then immediately closes them.
>
Why?

Does it also FREE then?  Why?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Joel C. Ewing]

RECFM PSU may prevent moving the database, but it doesn't block
deletion.  After realizing this somewhat-essential data set wasn't
protected by an enqueue, we picked an installation started task that was
normally running all the time (but which could be shut down if need be),
and added an unreferenced DD for the RACF database with DISP=SHR to
reduce the odds of both accidental deletion and movement.

I suspect performance may have also been behind the choice of not ever
using VSAM for the RACF database.  VSAM can usually behave pretty well
these days if you can throw enough memory at it for buffers, but in the
old days memory was much less plentiful, and with limited memory your
performance controls with VSAM were at times annoyingly limited -- there
are even scenarios where adding more buffers to VSAM actually degrades
performance because VSAM makes poor choices (like pre-reading many CIs
that will never be needed) from assumptions about future application
behavior that are of necessity based on ignorance of the application's
internal design.   Having RACF in total control surely provided
opportunities for intelligent buffer usage and caching of data that
would have been impossible with VSAM in the picture.
Joel C. Ewing

On 05/22/2017 11:01 AM, Jesse 1 Robinson wrote:
> First off, I take back my comment about the chronology of RACF and VSAM. I 
> had no business making that assertion. I got into this biz in the late 70s. 
> At that time there was plenty of VSAM around, although it was viewed by many 
> sysprogs skeptically and unsuitable to hold the family jewels. Nonetheless 
> ACF2, based on VSAM, was well established by then. I can't speak for ASM1. 
> (OK, it's a long way from Friday.)
>
> I don't think it matters much what DSCB attributes are assigned to the RACF 
> database. RACF will open and process it only one way. I've seen PSU 
> recommended to prevent inadvertent relocation. I've also seen DSORG DA or 
> RECFM U recommended to prevent curiosity browsing. RACF is oblivious to these 
> external labels. In any case, a SAF product has to be available extremely 
> early in IPL, so a complex data base would probably not work. Whatever else 
> you say about DSORG DA, it can be managed with very little 'outside' help. 
>
>
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John McKown
> Sent: Monday, May 22, 2017 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file transfer 
> using NJE/TCPIP)
>
> On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < 
> r.han...@rshconsulting.com> wrote:
>
>> Gil,
>>
>> The RACF database is BDAM (Basic Direct Access Method) and has, to my 
>> knowledge, always been so since it was first released in 1976. The 
>> index records are stored in the database with the profile (data) 
>> records, so it is completely self-contained. I know of no other 
>> product using this structure.
>>
>> Live databases should be allocated as PSU. Unmovable prevents the 
>> database from being moved while in use. RACF is weird. It opens its 
>> databases at IPL and then immediately closes them. RACF uses direct 
>> disk address I/O to read and update its databases thereafter. If 
>> databases are not allocated as U, a data management utility, seeing 
>> they are not "open", might compress or move the databases, unaware they are 
>> in use - with disastrous results.
>>
> ​I've always hated this about some DSNs. RACF is one. CA-1 use of the TMC & 
> Audit are another. What would be better, IMO, would be either a way to 
> allocate the DSNs to the *MASTER* address space (ASID 1) with DISP=SHR or do 
> a "directed ENQ" to *MASTER*​ to do a SYSDSN shared ENQ on the RACF database 
> DSNs. I like this latter because it would make it easier to change the RVARY 
> command to update the directed ENQs.
>
>
>
>> Live databases should be copied/backed up using the IRRUT200 utility. 
>> This utility freezes update activity to the database before making a 
>> copy. The offline copy can be copied using IEBGENER or the like, or it can 
>> be FTPed.
>> I haven't tried FTPing a RACF database, but I suspect you would want 
>> to do so using BIN. It is generally best to pre-allocate the disk 
>> dataset to which the database it is to be copied, and it must have 
>> exactly the same UNIT, SPACE, and DCB cha

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

Brief war story. Long before "z/OS", someone accidentally deleted (!!!) the 
primary RACF data base. It was not enqueued on as previously noted. Data was 
intact and the system hummed along, but there was no 'SYS1.RACF' in the 
catalog. Using backup listings, we figured out the exact location on the volume 
where the data set lived. Then we reallocated it using ABSTR to rebuild the 
VTOC entry and did a DEF NVSAM to rebuild the catalog entry. Some further 
cleanup action followed, but basically there was never an outage. 

Could not have done that with VSAM. ;-)

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Monday, May 22, 2017 7:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin  wrote:

>On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote:
>>
>>>RACF (I'm less sure) is VSAM. 
>>
>>No, it is PSU (PS and Unmovable). Other attributes are mandated by IBM.
>> 
>"Unmovable" would seem to imply uncopyable; the copy would have to go 
>in a different place.  But there must be some provision for backing it 
>up, and little point in trying to move it to another system with such as FTP.

"Unmovable" is recommended to ensure that other tools don't move an active copy 
of the RACF database to a different location on the DASD volume, since they 
cannot tell that it's OPEN and in use. There is nothing actually 
location-sensitive within the database, except that it must be one contiguous 
allocation.

>
>Why not VSAM?  Performance?  Antiquity?  It feels as if RACF has a 
>built-in DB engine.

The RACF database format and processing pre-dates VSAM, or was possibly being 
developed concurrently. (I've forgotten the exact details.) 

I did look, many years ago, at what would be required to switch RACF to using 
VSAM, and it would have required significant redesign, redevelopment, and 
testing. Also, given the way that RACF initializes, and the fact that the 
database is accessed directly and concurrently from all address spaces on the 
system as well as from multiple systems, it was not clear that using VSAM would 
even be feasible.

Yes, RACF has a kind of non-relational DB engine built in. We also considered 
at one point whether it might be possible to switch to using DB2, but we didn't 
want to limit RACF's usage to those customers willing to license DB2, too. 
(And, of course, if we did switch there's the redesign, redevelop, test expense 
to consider, too.)

There were also migration and compatibility considerations, of course. If you 
have several systems sharing one RACF database it would not be appropriate to 
require all of them to have to upgrade to new RACF (or z/OS) releases 
simultaneously so they could all switch to VSAM- or DB2-based databases. And 
allowing a mixture of old-style databases and new-style databases would be 
extremely complex. We did that once when we changed the RACF DB from using a 1K 
blocksize to using a 4K blocksize, and it was complex. But switching to an 
entirely different mechanism like VSAM or DB2 would be even more of an 
undertaking.

--
Walt


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

VSAM, for all its complex capabilities, seems to operate 'simply' at a very 
basic level of the OS. Think of SMF running very early in IPL. ICF catalogs are 
VSAM. I'm not sure it was always thus, but it seems now to have little trouble 
functioning within a minute or two of IPL LOAD. As Walt Farrell said, even if 
RACF could be rewritten for VSAM, what's the ROI? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David W Noon
Sent: Monday, May 22, 2017 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF Database 
(was: Sample JCL for file transfer using NJE/TCPIP)" (in
<507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>):

> On 2017-05-22, at 10:01, Jesse 1 Robinson wrote:
>>  ... Nonetheless ACF2, based on VSAM, was well established ...
>>
>> ... In any case, a SAF product has to be available extremely early in IPL, 
>> ...
>>
> How does ACF2, based on VSAM, meet this requirement of early availability?

ACF2 is supposed to start before JES2/JES3.

It is configured as a subsystem and its PARM field includes the name of the job 
entry subsystem to start (i.e. ACF2 starts JES).
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[David W Noon]

On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin 
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF 
Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in 
<507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>):



On 2017-05-22, at 10:01, Jesse 1 Robinson wrote:

 ... Nonetheless ACF2, based on VSAM, was well established ...

... In any case, a SAF product has to be available extremely early in IPL, ...


How does ACF2, based on VSAM, meet this requirement of early availability?


ACF2 is supposed to start before JES2/JES3.

It is configured as a subsystem and its PARM field includes the name of 
the job entry subsystem to start (i.e. ACF2 starts JES).

--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Paul Gilmartin]

On 2017-05-22, at 10:01, Jesse 1 Robinson wrote:
>  ... Nonetheless ACF2, based on VSAM, was well established ...
> 
> ... In any case, a SAF product has to be available extremely early in IPL, 
> ... 
>  
How does ACF2, based on VSAM, meet this requirement of early availability?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

First off, I take back my comment about the chronology of RACF and VSAM. I had 
no business making that assertion. I got into this biz in the late 70s. At that 
time there was plenty of VSAM around, although it was viewed by many sysprogs 
skeptically and unsuitable to hold the family jewels. Nonetheless ACF2, based 
on VSAM, was well established by then. I can't speak for ASM1. (OK, it's a long 
way from Friday.)

I don't think it matters much what DSCB attributes are assigned to the RACF 
database. RACF will open and process it only one way. I've seen PSU recommended 
to prevent inadvertent relocation. I've also seen DSORG DA or RECFM U 
recommended to prevent curiosity browsing. RACF is oblivious to these external 
labels. In any case, a SAF product has to be available extremely early in IPL, 
so a complex data base would probably not work. Whatever else you say about 
DSORG DA, it can be managed with very little 'outside' help. 



.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, May 22, 2017 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < 
r.han...@rshconsulting.com> wrote:

> Gil,
>
> The RACF database is BDAM (Basic Direct Access Method) and has, to my 
> knowledge, always been so since it was first released in 1976. The 
> index records are stored in the database with the profile (data) 
> records, so it is completely self-contained. I know of no other 
> product using this structure.
>
> Live databases should be allocated as PSU. Unmovable prevents the 
> database from being moved while in use. RACF is weird. It opens its 
> databases at IPL and then immediately closes them. RACF uses direct 
> disk address I/O to read and update its databases thereafter. If 
> databases are not allocated as U, a data management utility, seeing 
> they are not "open", might compress or move the databases, unaware they are 
> in use - with disastrous results.
>

​I've always hated this about some DSNs. RACF is one. CA-1 use of the TMC & 
Audit are another. What would be better, IMO, would be either a way to allocate 
the DSNs to the *MASTER* address space (ASID 1) with DISP=SHR or do a "directed 
ENQ" to *MASTER*​ to do a SYSDSN shared ENQ on the RACF database DSNs. I like 
this latter because it would make it easier to change the RVARY command to 
update the directed ENQs.



>
> Live databases should be copied/backed up using the IRRUT200 utility. 
> This utility freezes update activity to the database before making a 
> copy. The offline copy can be copied using IEBGENER or the like, or it can be 
> FTPed.
> I haven't tried FTPing a RACF database, but I suspect you would want 
> to do so using BIN. It is generally best to pre-allocate the disk 
> dataset to which the database it is to be copied, and it must have 
> exactly the same UNIT, SPACE, and DCB characteristics as the source 
> database, including CONTIG. The copy needn't be PSU unless you plan to 
> RVARY SWITCH to it so that it becomes live.
>
> Regards, Bob
>
> Robert S. Hansel  *** Celebrating 30 years working with RACF ***
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> http://twitter.com/RSH_RACF
> www.rshconsulting.com
>

--
Advertising is a valuable economic factor because it is the cheapest way of 
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[John McKown]

On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) <
r.han...@rshconsulting.com> wrote:

> Gil,
>
> The RACF database is BDAM (Basic Direct Access Method) and has, to my
> knowledge, always been so since it was first released in 1976. The index
> records are stored in the database with the profile (data) records, so it
> is completely self-contained. I know of no other product using this
> structure.
>
> Live databases should be allocated as PSU. Unmovable prevents the database
> from being moved while in use. RACF is weird. It opens its databases at IPL
> and then immediately closes them. RACF uses direct disk address I/O to read
> and update its databases thereafter. If databases are not allocated as U, a
> data management utility, seeing they are not "open", might compress or move
> the databases, unaware they are in use - with disastrous results.
>

​I've always hated this about some DSNs. RACF is one. CA-1 use of the TMC &
Audit are another. What would be better, IMO, would be either a way to
allocate the DSNs to the *MASTER* address space (ASID 1) with DISP=SHR or
do a "directed ENQ" to *MASTER*​ to do a SYSDSN shared ENQ on the RACF
database DSNs. I like this latter because it would make it easier to change
the RVARY command to update the directed ENQs.



>
> Live databases should be copied/backed up using the IRRUT200 utility. This
> utility freezes update activity to the database before making a copy. The
> offline copy can be copied using IEBGENER or the like, or it can be FTPed.
> I haven't tried FTPing a RACF database, but I suspect you would want to do
> so using BIN. It is generally best to pre-allocate the disk dataset to
> which the database it is to be copied, and it must have exactly the same
> UNIT, SPACE, and DCB characteristics as the source database, including
> CONTIG. The copy needn't be PSU unless you plan to RVARY SWITCH to it so
> that it becomes live.
>
> Regards, Bob
>
> Robert S. Hansel  *** Celebrating 30 years working with RACF ***
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> http://twitter.com/RSH_RACF
> www.rshconsulting.com
>

-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Walt Farrell]

On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin  wrote:

>On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote:
>>
>>>RACF (I'm less sure) is VSAM. 
>>
>>No, it is PSU (PS and Unmovable). Other attributes are mandated by IBM.
>> 
>"Unmovable" would seem to imply uncopyable; the copy would have to go
>in a different place.  But there must be some provision for backing it up,
>and little point in trying to move it to another system with such as FTP.

"Unmovable" is recommended to ensure that other tools don't move an active copy 
of the RACF database to a different location on the DASD volume, since they 
cannot tell that it's OPEN and in use. There is nothing actually 
location-sensitive within the database, except that it must be one contiguous 
allocation.

>
>Why not VSAM?  Performance?  Antiquity?  It feels as if RACF has a
>built-in DB engine.

The RACF database format and processing pre-dates VSAM, or was possibly being 
developed concurrently. (I've forgotten the exact details.) 

I did look, many years ago, at what would be required to switch RACF to using 
VSAM, and it would have required significant redesign, redevelopment, and 
testing. Also, given the way that RACF initializes, and the fact that the 
database is accessed directly and concurrently from all address spaces on the 
system as well as from multiple systems, it was not clear that using VSAM would 
even be feasible.

Yes, RACF has a kind of non-relational DB engine built in. We also considered 
at one point whether it might be possible to switch to using DB2, but we didn't 
want to limit RACF's usage to those customers willing to license DB2, too. 
(And, of course, if we did switch there's the redesign, redevelop, test expense 
to consider, too.)

There were also migration and compatibility considerations, of course. If you 
have several systems sharing one RACF database it would not be appropriate to 
require all of them to have to upgrade to new RACF (or z/OS) releases 
simultaneously so they could all switch to VSAM- or DB2-based databases. And 
allowing a mixture of old-style databases and new-style databases would be 
extremely complex. We did that once when we changed the RACF DB from using a 1K 
blocksize to using a 4K blocksize, and it was complex. But switching to an 
entirely different mechanism like VSAM or DB2 would be even more of an 
undertaking.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Robert S. Hansel (RSH)]

Gil,

The RACF database is BDAM (Basic Direct Access Method) and has, to my 
knowledge, always been so since it was first released in 1976. The index 
records are stored in the database with the profile (data) records, so it is 
completely self-contained. I know of no other product using this structure.

Live databases should be allocated as PSU. Unmovable prevents the database from 
being moved while in use. RACF is weird. It opens its databases at IPL and then 
immediately closes them. RACF uses direct disk address I/O to read and update 
its databases thereafter. If databases are not allocated as U, a data 
management utility, seeing they are not "open", might compress or move the 
databases, unaware they are in use - with disastrous results.

Live databases should be copied/backed up using the IRRUT200 utility. This 
utility freezes update activity to the database before making a copy. The 
offline copy can be copied using IEBGENER or the like, or it can be FTPed. I 
haven't tried FTPing a RACF database, but I suspect you would want to do so 
using BIN. It is generally best to pre-allocate the disk dataset to which the 
database it is to be copied, and it must have exactly the same UNIT, SPACE, and 
DCB characteristics as the source database, including CONTIG. The copy needn't 
be PSU unless you plan to RVARY SWITCH to it so that it becomes live.

Regards, Bob

Robert S. Hansel  *** Celebrating 30 years working with RACF ***
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 11-15, 2017
- RACF Level I Administration - DEC 5-8, 2017
- RACF Level II Administration - NOV 13-17, 2017
- RACF Level III Admin, Audit, & Compliance - OCT 2-6, 2017
- RACF - Securing z/OS UNIX  - OCT 23-27, 2017


-Original Message-

Date:Sun, 21 May 2017 14:19:39 -0500
From:Paul Gilmartin 
Subject: Re: Sample JCL for file transfer using NJE/TCPIP

On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote:
>
>>RACF (I'm less sure) is VSAM. 
>
>No, it is PSU (PS and Unmovable). Other attributes are mandated by IBM.
> 
"Unmovable" would seem to imply uncopyable; the copy would have to go
in a different place.  But there must be some provision for backing it up,
and little point in trying to move it to another system with such as FTP.

Why not VSAM?  Performance?  Antiquity?  It feels as if RACF has a
built-in DB engine.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

Are you sure? Could you please specify exactly where too look in the RACF docs? 
Or do you mean the ICHDEX01 exit (for which you can either choose masking or 
implement - program - your own algorithm)?

Costin




 From: Elardus Engelbrecht 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, 8 September 2013, 17:17
Subject: Re: RACF Database protection
 

Shmuel Metz (Seymour J.) wrote:

>>You can wish, but big blue wants backward compatibility,

>How is that an obstacle? If they do it, I'm sure that there will be a switch 
>to enable the new algorithm and that, once enabled, the new algorithm will 
>only be used incrementally.

Agreed, Shmuel. Thanks for your comment. I will be the last person to disagree 
with you. ;-D

They have already done that 'switch'. Read the RACF books about choice of 
password [1] encryption. But still, they will only do that if backward 
compatibility is NOT compromised. If backward compatibility could be 
compromised, they will warn you, just like they did with some product features. 
You remember that phasing out of ISAM? ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - technically, for RACF, not exactly passwords are encrypted, but userids. 
But I used word 'password' to make a point.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Elardus Engelbrecht]

Shmuel Metz (Seymour J.) wrote:

>>You can wish, but big blue wants backward compatibility,

>How is that an obstacle? If they do it, I'm sure that there will be a switch 
>to enable the new algorithm and that, once enabled, the new algorithm will 
>only be used incrementally.

Agreed, Shmuel. Thanks for your comment. I will be the last person to disagree 
with you. ;-D

They have already done that 'switch'. Read the RACF books about choice of 
password [1] encryption. But still, they will only do that if backward 
compatibility is NOT compromised. If backward compatibility could be 
compromised, they will warn you, just like they did with some product features. 
You remember that phasing out of ISAM? ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - technically, for RACF, not exactly passwords are encrypted, but userids. 
But I used word 'password' to make a point.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Shmuel Metz (Seymour J.)]

In
<0539133098161601.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 09/05/2013
   at 03:31 AM, Elardus Engelbrecht 
said:

>You can wish, but big blue wants backward compatibility,

How is that an obstacle? If they do it, I'm sure that there will be a
switch to enable the new algorithm and that, once enabled, the new
algorithm will only be used incrementally.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Elardus Engelbrecht]

Costin Enache wrote:

>Wishful thinking: that IBM, if they decide to change the algorithm, will learn 
>the advantages of open, secure and open to debate cryptography over secret, 
>obfuscated and most often broken schemes.

You can wish, but big blue wants backward compatibility, so it is unlikely they 
will change their algorithms or be open to suggestions when it comes to 
security. Perhaps IBM updated those algorithms, but did not tell us.

Perhaps in a new operating system, yes. ;-D

If you don't like RACF, you can always write your own version of RACF + 
algoritms. :-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

The error can be easily demonstrated, see one of my earlier posts. But I'm only 
a security consultant and I don't work for one of those companies paying 
millions yearly to IBM, so I guess it has high chances to be ignored. Wishful 
thinking: that IBM, if they decide to change the algorithm, will learn the 
advantages of open, secure and open to debate cryptography over secret, 
obfuscated and most often broken schemes.


Costin




 From: Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, 4 September 2013, 17:45
Subject: Re: RACF Database protection
 

On 4 September 2013 04:07, Costin Enache  wrote:
> It may not be APARable. Even if you fix the bug, what do you do with the old 
> password phrases? Maybe update the RACF database with a secure hash value 
> once the user logs in (to add the previously discarded hash bytes), but the 
> system cannot know if the correct password phrase has been used (and not one 
> of the others which also work). Or just invalidate the old phrases. The 
> system does not store enough hash bytes to decide which password is the 
> correct one ... in any case it would be a mess. The bug cannot be used to 
> brute-force authentication (the account will be locked before one can benefit 
> from the collisions) and, in case the RACF db is exposed, it is easy to crack 
> the hashes anyway, the collisions are not really needed. It will probably 
> just stay as it is :)

Not all APARs are opened for what seems to be their obvious reason. It
may well be that, with nothing beyond reported weaknesses in phrase
handling, there is nothing to APAR - even more the case if it is based
on reports from a third party's analysis rather than a customer's
business problem. But an easily demonstrable error (accepting the
wrong phrase and allowing logon) is blatant enough to perhaps get
action, and if the necessary action is to redesign the whole scheme
(or provide for customer/ISV supplied encryption routines, as is done
for passwords), then they might just do it. I'm sure it's not that the
IBM developers don't want to fix it; it's a matter of IBM management
devoting sufficient time and budget to it. And that requires a
customer squeaky wheel.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Tony Harminc]

On 4 September 2013 04:07, Costin Enache  wrote:
> It may not be APARable. Even if you fix the bug, what do you do with the old 
> password phrases? Maybe update the RACF database with a secure hash value 
> once the user logs in (to add the previously discarded hash bytes), but the 
> system cannot know if the correct password phrase has been used (and not one 
> of the others which also work). Or just invalidate the old phrases. The 
> system does not store enough hash bytes to decide which password is the 
> correct one ... in any case it would be a mess. The bug cannot be used to 
> brute-force authentication (the account will be locked before one can benefit 
> from the collisions) and, in case the RACF db is exposed, it is easy to crack 
> the hashes anyway, the collisions are not really needed. It will probably 
> just stay as it is :)

Not all APARs are opened for what seems to be their obvious reason. It
may well be that, with nothing beyond reported weaknesses in phrase
handling, there is nothing to APAR - even more the case if it is based
on reports from a third party's analysis rather than a customer's
business problem. But an easily demonstrable error (accepting the
wrong phrase and allowing logon) is blatant enough to perhaps get
action, and if the necessary action is to redesign the whole scheme
(or provide for customer/ISV supplied encryption routines, as is done
for passwords), then they might just do it. I'm sure it's not that the
IBM developers don't want to fix it; it's a matter of IBM management
devoting sufficient time and budget to it. And that requires a
customer squeaky wheel.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

It may not be APARable. Even if you fix the bug, what do you do with the old 
password phrases? Maybe update the RACF database with a secure hash value once 
the user logs in (to add the previously discarded hash bytes), but the system 
cannot know if the correct password phrase has been used (and not one of the 
others which also work). Or just invalidate the old phrases. The system does 
not store enough hash bytes to decide which password is the correct one ... in 
any case it would be a mess. The bug cannot be used to brute-force 
authentication (the account will be locked before one can benefit from the 
collisions) and, in case the RACF db is exposed, it is easy to crack the hashes 
anyway, the collisions are not really needed. It will probably just stay as it 
is :) 


Costin




 From: Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, 4 September 2013, 1:11
Subject: Re: RACF Database protection
 

On 3 September 2013 09:41, Costin Enache  wrote:

> The phrase clear text is already padded with spaces to a multiple of 8, but, 
> after encryption, the resulting hash is truncated to the length of the 
> original clear text, minus the padding. This leaves us with an incomplete DES 
> cipher text block at the end, if the last clear-text block was padded. This 
> means that, if for example the last block had one character (say 1=F1) padded 
> to a length of 8 with spaces (F14040.), only the first byte of the 
> resulting DES cipher text will be stored. There are many clear-texts what 
> will generate the same byte on the first position when encrypted with DES. 
> Example: create user COSTIN with phrase Abcd1234Abcd1234a, then try to logon 
> with phrase Abcd1234Abcd1234X

I would think that should be APARable...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[R.S.]

W dniu 2013-09-04 04:32, FRANCIS SOUSA pisze:

Ask your network guys to restrict FTP, maybe use ACL ?

It doesn't help.
The problem is in READ to the dataset not the ability to use *one of 
existing* transfer methods.

"Protect resources, not the tools".

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[FRANCIS SOUSA]

Ask your network guys to restrict FTP, maybe use ACL ?


On Sat, Aug 17, 2013 at 4:02 AM, mmjuma  wrote:

> Hi list
>
> Some one in our section, he was able to download RACF data base file
> SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get
> uid and password of some users. He had now access to the file in mainframe.
> I want to understand what happend, and how to protect against such issue.
>
>
>
> Send from Samsung Mobile
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Tony Harminc]

On 3 September 2013 09:41, Costin Enache  wrote:

> The phrase clear text is already padded with spaces to a multiple of 8, but, 
> after encryption, the resulting hash is truncated to the length of the 
> original clear text, minus the padding. This leaves us with an incomplete DES 
> cipher text block at the end, if the last clear-text block was padded. This 
> means that, if for example the last block had one character (say 1=F1) padded 
> to a length of 8 with spaces (F14040.), only the first byte of the 
> resulting DES cipher text will be stored. There are many clear-texts what 
> will generate the same byte on the first position when encrypted with DES. 
> Example: create user COSTIN with phrase Abcd1234Abcd1234a, then try to logon 
> with phrase Abcd1234Abcd1234X

I would think that should be APARable...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

The DES modes are good for protecting a secret plaintext with a DES key, but in 
our case we have a short, known plaintext - the username, which is encrypted 
with the password (or with blocks of the password phrase). So we have a long 
key with a short plaintext, instead of a long plaintext with a short key. IBM 
has tried to sort of adapt the CBC mode to this scenario, but did not word out 
very well.

Costin

On 3 Sep 2013, at 16:42, Paul Gilmartin  wrote:

> On Tue, 3 Sep 2013 14:41:49 +0100, Costin Enache wrote:
>> 
>>> The password phrase hash can be split into blocks of 8 bytes, and each of
>>> them "cracked" independently, also in parallel.
>> Sounds like a half-hearted implementation -- what would have been the
>> additional cost of using larger blocks?
> So I look at:
> 
>http://en.wikipedia.org/wiki/Data_Encryption_Standard
> 
> (Yah, I know; "Wikipedia"), which says:
> 
>Like other block ciphers, DES by itself is not a secure means of encryption
>but must instead be used in a mode of operation. FIPS-81 specifies several
>modes for use with DES.[20] Further comments on the usage of DES are
>contained in FIPS-74.[21]
> 
> And from FIPS-81:
> 
>http://www.itl.nist.gov/fipspubs/fip81.htm
> 
> which seems to be rife with typos, confusing "zero" with "oscar" (not even
> "Oscar"), it would appear that the passphrase handling is using the simplest
> method, ECB, which is susceptible to paralleization.  Other methods, CBC,
> CFB, and OFB would seem to resist parallelization and to be stronger.
> 
>> Not possible directly with DES, but there are many other alternatives 
>> which would be quite secure at no additional cost. I have no idea why 
>> the password phrase is encrypted in this way, considering the available 
>> modern technology already employed by RACF.
> 
> I see.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Paul Gilmartin]

On Tue, 3 Sep 2013 14:41:49 +0100, Costin Enache wrote:
>
>>The password phrase hash can be split into blocks of 8 bytes, and each of
>>them "cracked" independently, also in parallel. 
>>
>Sounds like a half-hearted implementation -- what would have been the
>additional cost of using larger blocks?
>
So I look at:

http://en.wikipedia.org/wiki/Data_Encryption_Standard

(Yah, I know; "Wikipedia"), which says:

Like other block ciphers, DES by itself is not a secure means of encryption
but must instead be used in a mode of operation. FIPS-81 specifies several
modes for use with DES.[20] Further comments on the usage of DES are
contained in FIPS-74.[21]

And from FIPS-81:

http://www.itl.nist.gov/fipspubs/fip81.htm

which seems to be rife with typos, confusing "zero" with "oscar" (not even
"Oscar"), it would appear that the passphrase handling is using the simplest
method, ECB, which is susceptible to paralleization.  Other methods, CBC,
CFB, and OFB would seem to resist parallelization and to be stronger.

>Not possible directly with DES, but there are many other alternatives 
>which would be quite secure at no additional cost. I have no idea why 
>the password phrase is encrypted in this way, considering the available 
>modern technology already employed by RACF.

I see.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

 From: Paul Gilmartin 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, 2 September 2013, 22:09
Subject: Re: RACF Database protection
 

>>The password phrase hash can be split into blocks of 8 bytes, and each of
>>them "cracked" independently, also in parallel. 
>>
>Sounds like a half-hearted implementation -- what would have been the
>additional cost of using larger blocks?

Not possible directly with DES, but there are many other alternatives which 
would be quite secure at no additional cost. I have no idea why the password 
phrase is encrypted in this way, considering the available modern technology 
already employed by RACF.

>>Another flaw, concerning the hash storage, allows for collisions in the last 
>>block, 
>>if the phrase length is not exactly multiple of 8.
>>
>The obvious question, then, is would the method be improved simply by padding
>that last block (with blanks, e.g.; or better characters invalid in the 
>passphrase)
>to a multiple of 8.  Does the passphrase syntax permit trailing blanks so that
>passphrases differing only in the number of trailing blanks are considered
>different?

The phrase clear text is already padded with spaces to a multiple of 8, but, 
after encryption, the resulting hash is truncated to the length of the original 
clear text, minus the padding. This leaves us with an incomplete DES cipher 
text block at the end, if the last clear-text block was padded. This means 
that, if for example the last block had one character (say 1=F1) padded to a 
length of 8 with spaces (F14040.), only the first byte of the resulting DES 
cipher text will be stored. There are many clear-texts what will generate the 
same byte on the first position when encrypted with DES. Example: create user 
COSTIN with phrase Abcd1234Abcd1234a, then try to logon with phrase 
Abcd1234Abcd1234X

>Does the method still operate by storing the user ID encrypted by the (chunks 
>of)
>the passphrase?  Is any weakness introduced by the 7-character (practical)
>limitation of user IDs?

Pretty much the same, with some obfuscation.

Costin


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Paul Gilmartin]

On Mon, 2 Sep 2013 09:44:27 +0100, Costin Enache wrote:

>The password phrase hash can be split into blocks of 8 bytes, and each of
>them "cracked" independently, also in parallel. 
>
Sounds like a half-hearted implementation -- what would have been the
additional cost of using larger blocks?

>Another flaw, concerning the hash storage, allows for collisions in the last 
>block, 
>if the phrase length is not exactly multiple of 8.
>
The obvious question, then, is would the method be improved simply by padding
that last block (with blanks, e.g.; or better characters invalid in the 
passphrase)
to a multiple of 8.  Does the passphrase syntax permit trailing blanks so that
passphrases differing only in the number of trailing blanks are considered
different?

Does the method still operate by storing the user ID encrypted by the (chunks 
of)
the passphrase?  Is any weakness introduced by the 7-character (practical)
limitation of user IDs?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

> I must be missing something.  A brute force attack on a one byte password
> must be prepared for 256 attempts.  The same attack on a two byte password
> must be prepared for 65,536 attempts which is significantly more than the
> 512 you suggest.  How is the increase not exponential?

This is why I wrote "flawed implementation". The first 8-bytes behave as 
expected, meaning that each additional character in the password candidate 
increases the effort exponentially (depending on the alphabet size, which is 
not 256, but much smaller). One would expect that the 9th byte will increase 
the effort also exponentially, but this is not the case. The password phrase 
hash can be split into blocks of 8 bytes, and each of them "cracked" 
independently, also in parallel. Another flaw, concerning the hash storage, 
allows for collisions in the last block, if the phrase length is not exactly 
multiple of 8. This means that, cryptographically, the attack complexity is 
almost the same as for 8-byte passwords (except for the plain text alphabet, 
which for phrases is larger). I'd rather not give out the implementation 
details on the list as everybody seems to be a bit paranoid about releasing 
tech specs about this stuff (aid the hackers, etc.).

Costin




 From: retired mainframer 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, 2 September 2013, 0:16
Subject: Re: RACF Database protection
 

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of Costin Enache
:>: Sent: Sunday, September 01, 2013 12:04 PM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: RACF Database protection
:>:
:>: Small
:>: clarification: The usage of password phrases instead of passwords does
:>: not
:>: increase the complexity of a brute-force attack against the encrypted
:>: hashes,
:>: in case the RACF DB gets compromised (flawed / insecure DES
:>: implementation).
:>: The time required for recovering a 16-byte password phrase is two times
:>: the time
:>: required for an eight-byte password, for a 24-byte phrase three times,
:>: etc.
:>: (the required time does not increase exponentially, as expected).

I must be missing something.  A brute force attack on a one byte password
must be prepared for 256 attempts.  The same attack on a two byte password
must be prepared for 65,536 attempts which is significantly more than the
512 you suggest.  How is the increase not exponential?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[R.S.]

W dniu 2013-09-02 00:16, retired mainframer pisze:

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of Costin Enache
:>: Sent: Sunday, September 01, 2013 12:04 PM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: RACF Database protection
:>:
:>: Small
:>: clarification: The usage of password phrases instead of passwords does
:>: not
:>: increase the complexity of a brute-force attack against the encrypted
:>: hashes,
:>: in case the RACF DB gets compromised (flawed / insecure DES
:>: implementation).
:>: The time required for recovering a 16-byte password phrase is two times
:>: the time
:>: required for an eight-byte password, for a 24-byte phrase three times,
:>: etc.
:>: (the required time does not increase exponentially, as expected).

I must be missing something.  A brute force attack on a one byte password
must be prepared for 256 attempts.  The same attack on a two byte password
must be prepared for 65,536 attempts which is significantly more than the
512 you suggest.  How is the increase not exponential?

http://en.wikipedia.org/wiki/Birthday_attack
Of course, the theory you presented is still valid.
BTW, just to clarify: RACF password is NOT "8 byte password". Only 
subset of possible byte values is accepted (0-9, A-Z, @$#, lately a-z).
Its (as I counted: 10+26+3+26) 65 values per character. So the password 
could be 65^8 = .318 644 812 890 625.
This is simplification, I did not consider shorter passwords (which 
increases the base) and password rules (which decreases the base).


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[retired mainframer]

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of Costin Enache
:>: Sent: Sunday, September 01, 2013 12:04 PM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: Re: RACF Database protection
:>:
:>: Small
:>: clarification: The usage of password phrases instead of passwords does
:>: not
:>: increase the complexity of a brute-force attack against the encrypted
:>: hashes,
:>: in case the RACF DB gets compromised (flawed / insecure DES
:>: implementation).
:>: The time required for recovering a 16-byte password phrase is two times
:>: the time
:>: required for an eight-byte password, for a 24-byte phrase three times,
:>: etc.
:>: (the required time does not increase exponentially, as expected).

I must be missing something.  A brute force attack on a one byte password
must be prepared for 256 attempts.  The same attack on a two byte password
must be prepared for 65,536 attempts which is significantly more than the
512 you suggest.  How is the increase not exponential?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Costin Enache]

Small
clarification: The usage of password phrases instead of passwords does not
increase the complexity of a brute-force attack against the encrypted hashes,
in case the RACF DB gets compromised (flawed / insecure DES implementation).
The time required for recovering a 16-byte password phrase is two times the time
required for an eight-byte password, for a 24-byte phrase three times, etc.
(the required time does not increase exponentially, as expected). The same tech
used for recovering passwords can also crack password phrases. There are also
collisions, meaning that, in specific cases, in addition to the configured
phrase, there will be another two or three distinct ones that also work to 
authenticate
the user (hmm…). The usage of password phrases is of course strongly
recommended, but not for saving the day in case of a RACF DB compromise.

Costin




 From: Walt Farrell 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, 17 August 2013, 19:54
Subject: Re: RACF Database protection
 

On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson  
wrote:

>This exposure has been known--and discussed publicly--for several years.
>It is NOT true that 'passwords are not stored'. If they weren't 'stored'
>at all, then how could RACF validate the password you supply? They are in
>fact stored in encrypted form. The encryption method itself is not a state
>secret. It can be simulated.

Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at all. 
(There is one exception, the "password enveloping" function, but that's a 
different discussion than this one.)

RACF encrypts the user ID using the password as the key, and stores the 
encrypted user ID. The password itself is not saved, in any form.

>
>The brute force method alluded to here starts with a copy of a RACF data
>base. Then generated character strings are fed into an encryption program
>until the encrypted form of some random string matches what's found in the
>data base for a given userid. Voila. The password has been hacked.

No, it's not the "encrypted form of some random string", it's the encrypted 
form of the user ID, when using some random string as the encryption key.

>
>Once upon a time, it would have taken so long to perform this string match
>that passwords would likely have changed in the meantime. Nowadays
>computers all the way down to smart phones have gotten faster while the
>encryption algorithms have remained the same. There is to my knowledge no
>canonical defense for this hacking method. Best you can do is to prevent
>the data base from being copied in the first place.

Where possible, you can switch to the use of password phrases rather than 
passwords. You're right that the brute fore attacks are increasingly simple for 
mere 8-byte passwords, but password phrases give you longer values (minimum 14 
by default, though you can decrease that to 9 with an exit) that will be 
harder. And with commonly available technology it's perhaps impossible today if 
you have only a slightly longer string. 

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Ron Hawkins]

Skip,

There was an method posted many years ago that used a lexicon of common
words, and passwords, to encrypt a UID and match it to the value stored in
RACF. Is this what you are referring to?

The OP of that post mentioned this as an auditing tool, but I recall a
lengthy and robust discussion as to whether it was actually an audit tool,
or a crack. 

I'm no expert, but I would not count this as a brute force crack as the
scope of the attack would be the size of the lexicon, and how well it
matches the user and/or the community. I think it would be true to say that
lax password standards or enforcement would make this an easier crack.

I'm not enamored of brute force crackers. After five years trying to crack a
word 97 document that I forgot the password to I simply gave up. Not running
continuously, but for weeks at a time.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Skip Robinson
> Sent: Saturday, August 17, 2013 10:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] RACF Database protection
> 
> This exposure has been known--and discussed publicly--for several years.
> It is NOT true that 'passwords are not stored'. If they weren't 'stored'
> at all, then how could RACF validate the password you supply? They are in
> fact stored in encrypted form. The encryption method itself is not a state
> secret. It can be simulated.
> 
> The brute force method alluded to here starts with a copy of a RACF data
> base. Then generated character strings are fed into an encryption program
> until the encrypted form of some random string matches what's found in the
> data base for a given userid. Voila. The password has been hacked.
> 
> Once upon a time, it would have taken so long to perform this string match
> that passwords would likely have changed in the meantime. Nowadays
> computers all the way down to smart phones have gotten faster while the
> encryption algorithms have remained the same. There is to my knowledge
> no canonical defense for this hacking method. Best you can do is to
prevent
> the data base from being copied in the first place.
> 
> As for what to do with the 'culprit', did he abscond with data or commit
some
> other mischief? Or did he reveal his activity to management as a wake-up
> call? The news today is replete with tales of 'ethical hackers'.
> Should we lock them up or bestow medals? Motivation is everything.
> 
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   mmjuma 
> To: IBM-MAIN@LISTSERV.UA.EDU,
> Date:   08/17/2013 01:04 AM
> Subject:RACF Database protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Hi list
> 
> Some one in our section, he was able to download RACF data base file
> SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get
> uid and password of some users. He had now access to the file in
> mainframe. I want to understand what happend, and how to protect against
> such issue.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Shmuel Metz (Seymour J.)]

In <520f48c1.1010...@bremultibank.com.pl>, on 08/17/2013
   at 11:56 AM, "R.S."  said:

>Everyone with computer and the db

Presumably the point is that you *don't* have access to his RACF DB.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Shmuel Metz (Seymour J.)]

In <791e2a3e-e500-46bd-98a9-02f34c650...@gmail.com>, on 08/18/2013
   at 08:48 AM, Louis Losee  said:

>It is typically a difficult task to get a list of user ids without
>read access to the RACF database.

It's easy to approximate.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Louis Losee]

Lets be specific here.

On Aug 17, 2013, at 12:30 PM, Skip Robinson  wrote:

> This exposure has been known--and discussed publicly--for several years. 
> It is NOT true that 'passwords are not stored'. If they weren't 'stored' 
> at all, then how could RACF validate the password you supply? They are in 
> fact stored in encrypted form. The encryption method itself is not a state 
> secret. It can be simulated.

The passwords are NOT stored.  The encrypted user id is stored
> 
> 
> The brute force method alluded to here starts with a copy of a RACF data 
> base. Then generated character strings are fed into an encryption program 
> until the encrypted form of some random string matches what's found in the 
> data base for a given userid. Voila. The password has been hacked. 
> 

It is not possible to hack RACF passwords unless the user ids that access the 
system protected by RACF are known.  It is typically a difficult task to get a 
list of user ids without read access to the RACF database.

Even if you manage to come up with a list of user ids, it does you no good 
unless you have read access to the RACF database.  Even if two users have 
identical passwords they would be different in the database so cracking a 
password once does not allow simple checks to see if other users are using the 
same password.
  
> Once upon a time, it would have taken so long to perform this string match 
> that passwords would likely have changed in the meantime. Nowadays 
> computers all the way down to smart phones have gotten faster while the 
> encryption algorithms have remained the same. There is to my knowledge no 
> canonical defense for this hacking method. Best you can do is to prevent 
> the data base from being copied in the first place. 
> 
> As for what to do with the 'culprit', did he abscond with data or commit 
> some other mischief? Or did he reveal his activity to management as a 
> wake-up call? The news today is replete with tales of 'ethical hackers'. 
> Should we lock them up or bestow medals? Motivation is everything. 
> 
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   mmjuma 
> To: IBM-MAIN@LISTSERV.UA.EDU, 
> Date:   08/17/2013 01:04 AM
> Subject:RACF Database protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Hi list
> 
> Some one in our section, he was able to download RACF data base file 
> SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get 
> uid and password of some users. He had now access to the file in 
> mainframe. I want to understand what happend, and how to protect against 
> such issue.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Lizette Koehler]

First, what version of z/OS are you running?

And another thought

I have not touched RACF directly in many years, so this may be old.  Make sure 
that your GLOBAL rules don't undercut your other rules improperly. Smart 
auditors look at the DSMON report to see if your sensitive datasets are 
properly protected. The really smart auditors then look at the DSMON Global 
Access Table Report to see if any of the GLOBAL rules permit access to a 
sensitive dataset. For example, if you have a GLOBAL DATASET rule that allows 
READ access to all SYS1.* datasets, then you likely have a weakness, even if 
other GLOBAL rules specify access of NONE for SYS1.UADS, SYS1.RACF, etc. A 
GLOBAL rule of SYS1.*/READ is only safe if you know ALL the SYS1 datasets which 
should have a UACC of NONE, both now and in the future. While you're looking at 
DSMON, check to make sure that the RACF dataset and its backup are on different 
disk packs.


Could you verify that your GLOBAL rules are setup correctly for us?  


Lizette

-Original Message-
From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of majuma
Sent: Saturday, August 17, 2013 9:48 AM
To: rac...@listserv.uga.edu
Subject: Fwd: RACF Database protection

Hi list,

Some one in our section, he was able to download RACF data base file 
SYS1.RACF.PRIM via ftp to PC, the file is UACC is none.

then he used some tool to get uid and password of some users. I want to 
understand what happend, and how to protect against such issue.



Send from Samsung Mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[R.S.]

W dniu 2013-08-18 06:50, Paul Gilmartin pisze:

On Sat, 17 Aug 2013 12:54:41 -0500, Walt Farrell wrote:

RACF encrypts the user ID using the password as the key, and stores the 
encrypted user ID. The password itself is not saved, in any form.


What happens when the user ID changes?
It won't happen. RACF does not support change name of the object (user, 
group, other profiles). If you really want to change userid, you have to 
delete old one and create new one. It can be a pain for "messy" RACF db, 
and piece of cake for "clean" RACF db.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Lizette Koehler]

Cross Posting to IBMMAIN and RACF

After reading Walt Farrell's response

The passwords are, in fact, not stored at all. (There is one exception, the 
"password enveloping" function, but that's a different discussion than this 
one.)  RACF encrypts the user ID using the password as the key, and stores the 
encrypted user ID. The password itself is not saved, in any form.

It seems that your statement that he got the UID and Password of some users may 
not be complete.

Was your user able to prove to you that he could logon on with those Passwords 
and userids?  If so, then yes, you have a problem.  

Second, if your RACF Database is in UACC(NONE) then how did he  get access?  
RACF should have prevented any READ attempt.  So either the user had a special 
authority or that person used a different id that had the authority to do this. 
 I would review the RACF SMF data to see specifically what this ID did and what 
was used to access the SYS1.RACF.PRIM database.

Could you post the RACF profile for this file?  It would help us to see if 
there is anything that might be missing.  Also, could you post the USERs ID 
with the LU userid command so we can see if there is anything that allowed the 
access?

Did he access the file from a different LPAR that did not have UACC(NONE) on 
SYS1.RACF.PRIM?

Did he access a backup of the database and transfer that the PC?

What was used on the PC that produced the RACF ID and Password?


Lizette


-Original Message-
From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of majuma
Sent: Saturday, August 17, 2013 9:48 AM
To: rac...@listserv.uga.edu
Subject: Fwd: RACF Database protection

Hi list, 

Some one in our section, he was able to download RACF data base file 
SYS1.RACF.PRIM via ftp to PC, the file is UACC is none.

then he used some tool to get uid and password of some users. I want to 
understand what happend, and how to protect against such issue.



Send from Samsung Mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[retired mainframer]

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>: Behalf Of mmjuma
:>: Sent: Saturday, August 17, 2013 1:02 AM
:>: To: IBM-MAIN@LISTSERV.UA.EDU
:>: Subject: RACF Database protection
:>:
:>: Hi list
:>:
:>: Some one in our section, he was able to download RACF data base file
:>: SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get
:>: uid and password of some users. He had now access to the file in
:>: mainframe. I want to understand what happend, and how to protect against
:>: such issue.

There are several steps you should consider.

To limit the potential damage:

Since some accounts have been compromised, they should be revoked.  Have
each user physically come to your desk to have the account resumed and the
password reset.

 Since the passwords were cracked so quickly, I think a dictionary
attack was used.  In any event, the accounts that were compromised obviously
had very weak passwords.  You should create rules that require passwords to
be at or near the max length and to contain letters (both upper and lower
case unless you are using a very old version of z/OS) as well as numbers.

 User IDs used exclusively to run production jobs should not have
passwords.  Users who run these jobs should have surrogate authority to the
production IDs.

To prevent it from happening again:

 If your section mate's job description requires him to test the
effectiveness of your security practices, he did exactly what he was
supposed to but then I expect you would not be asking for help.

 If not, he should be immediately reported to management for
disciplinary action.  In the interim, his access to the RACF database should
be terminated.  Any "high level" privileges such as special, auditor,
operations, etc should also be terminated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Paul Gilmartin]

On Sat, 17 Aug 2013 12:54:41 -0500, Walt Farrell wrote:
>
>RACF encrypts the user ID using the password as the key, and stores the 
>encrypted user ID. The password itself is not saved, in any form.
> 
What happens when the user ID changes?  (We suffer a corporate
standard that user ID _shall_ be (truncated) surname plus first
initial, slight flex allowed, only to avoid collisions.  Guess what.)
Is there any option to allow use of the encrypted UID, which is
relatively stable?  Open Systems admins made the rule; they're
not burdened with DSN prefixes.  (Actually, the rule hasn't been
enforced on mainframes; so far we're under the radar, but what
if?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Tony Harminc]

On 17 August 2013 13:54, Walt Farrell  wrote:

> Where possible, you can switch to the use of password phrases rather than 
> passwords. You're right that the brute fore attacks are increasingly simple 
> for mere 8-byte passwords, but password phrases give you longer values 
> (minimum 14 by default, though you can decrease that to 9 with an exit) that 
> will be harder. And with commonly available technology it's perhaps 
> impossible today if you have only a slightly longer string.

It would be a better idea if IBM didn't require (on z/OS RACF) that
all userids continue to have a password! Why would an attacker bother
to attack the phrase when there is certain to be a short password with
a very restricted character set to attack? Of course you can write a
program to set the encrypted password to a value that is not the
result of encrypting a userid with a valid password. We put this into
our password synch/reset product primarily to make it easy to set
things up so a user with a phrase can have a password that isn't known
to the administrator or the user, but it has the additional advantage
of enlarging the domain of things to attack by "brute force" methods.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Skip Robinson]

I of course defer to Walt. Fervent ignorance is to be eschewed even when 
it's fired in the right general direction. In this case, password per se 
is not stored, but 'something is stored' that could be stumbled upon by a 
deftly written program running at very high speed forever. 

Userids are easily discernible. We run standard RACF utilities to 
determine for example what profiles a userid owns in order to prepare for 
deleting that userid. So userids don't have to be guessed at. They're 
visible in the (purloined) data base. One then 'merely' has to affix a 
random password string, then crunch the zeroes and ones to find a match in 
the copied data base. Certainly longer strings like password phrases will 
take longer to match. But hackers have nothing but time.

As my pal Leonard Woren once said: If you build a better mousetrap, the 
world will build a better mouse. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Walt Farrell 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   08/17/2013 10:54 AM
Subject:Re: RACF Database protection
Sent by:IBM Mainframe Discussion List 



On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson 
 wrote:

>This exposure has been known--and discussed publicly--for several years.
>It is NOT true that 'passwords are not stored'. If they weren't 'stored'
>at all, then how could RACF validate the password you supply? They are in
>fact stored in encrypted form. The encryption method itself is not a 
state
>secret. It can be simulated.

Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at 
all. (There is one exception, the "password enveloping" function, but 
that's a different discussion than this one.)

RACF encrypts the user ID using the password as the key, and stores the 
encrypted user ID. The password itself is not saved, in any form.

>
>The brute force method alluded to here starts with a copy of a RACF data
>base. Then generated character strings are fed into an encryption program
>until the encrypted form of some random string matches what's found in 
the
>data base for a given userid. Voila. The password has been hacked.

No, it's not the "encrypted form of some random string", it's the 
encrypted form of the user ID, when using some random string as the 
encryption key.

>
>Once upon a time, it would have taken so long to perform this string 
match
>that passwords would likely have changed in the meantime. Nowadays
>computers all the way down to smart phones have gotten faster while the
>encryption algorithms have remained the same. There is to my knowledge no
>canonical defense for this hacking method. Best you can do is to prevent
>the data base from being copied in the first place.

Where possible, you can switch to the use of password phrases rather than 
passwords. You're right that the brute fore attacks are increasingly 
simple for mere 8-byte passwords, but password phrases give you longer 
values (minimum 14 by default, though you can decrease that to 9 with an 
exit) that will be harder. And with commonly available technology it's 
perhaps impossible today if you have only a slightly longer string. 

-- 
Walt



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Gerhard Postpischil]

On 8/17/2013 1:54 PM, Walt Farrell wrote:

Where possible, you can switch to the use of password phrases rather
than passwords. You're right that the brute fore attacks are
increasingly simple for mere 8-byte passwords, but password phrases
give you longer values (minimum 14 by default, though you can
decrease that to 9 with an exit) that will be harder. And with
commonly available technology it's perhaps impossible today if you
have only a slightly longer string.


My last employer, before my retirement, addressed the problem by giving 
each employee a gadget that displayed a password that changed about 
every minute. The only drawback was that it required a three-hour drive 
to the office to have it synchronized ever few months. Password phrases 
would have made it even trickier to enter the complete string before the 
algorithm kicked over to a new value?


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Walt Farrell]

On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson  
wrote:

>This exposure has been known--and discussed publicly--for several years.
>It is NOT true that 'passwords are not stored'. If they weren't 'stored'
>at all, then how could RACF validate the password you supply? They are in
>fact stored in encrypted form. The encryption method itself is not a state
>secret. It can be simulated.

Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at all. 
(There is one exception, the "password enveloping" function, but that's a 
different discussion than this one.)

RACF encrypts the user ID using the password as the key, and stores the 
encrypted user ID. The password itself is not saved, in any form.

>
>The brute force method alluded to here starts with a copy of a RACF data
>base. Then generated character strings are fed into an encryption program
>until the encrypted form of some random string matches what's found in the
>data base for a given userid. Voila. The password has been hacked.

No, it's not the "encrypted form of some random string", it's the encrypted 
form of the user ID, when using some random string as the encryption key.

>
>Once upon a time, it would have taken so long to perform this string match
>that passwords would likely have changed in the meantime. Nowadays
>computers all the way down to smart phones have gotten faster while the
>encryption algorithms have remained the same. There is to my knowledge no
>canonical defense for this hacking method. Best you can do is to prevent
>the data base from being copied in the first place.

Where possible, you can switch to the use of password phrases rather than 
passwords. You're right that the brute fore attacks are increasingly simple for 
mere 8-byte passwords, but password phrases give you longer values (minimum 14 
by default, though you can decrease that to 9 with an exit) that will be 
harder. And with commonly available technology it's perhaps impossible today if 
you have only a slightly longer string. 

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Skip Robinson]

This exposure has been known--and discussed publicly--for several years. 
It is NOT true that 'passwords are not stored'. If they weren't 'stored' 
at all, then how could RACF validate the password you supply? They are in 
fact stored in encrypted form. The encryption method itself is not a state 
secret. It can be simulated. 

The brute force method alluded to here starts with a copy of a RACF data 
base. Then generated character strings are fed into an encryption program 
until the encrypted form of some random string matches what's found in the 
data base for a given userid. Voila. The password has been hacked. 

Once upon a time, it would have taken so long to perform this string match 
that passwords would likely have changed in the meantime. Nowadays 
computers all the way down to smart phones have gotten faster while the 
encryption algorithms have remained the same. There is to my knowledge no 
canonical defense for this hacking method. Best you can do is to prevent 
the data base from being copied in the first place. 

As for what to do with the 'culprit', did he abscond with data or commit 
some other mischief? Or did he reveal his activity to management as a 
wake-up call? The news today is replete with tales of 'ethical hackers'. 
Should we lock them up or bestow medals? Motivation is everything. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   mmjuma 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   08/17/2013 01:04 AM
Subject:RACF Database protection
Sent by:IBM Mainframe Discussion List 



Hi list

Some one in our section, he was able to download RACF data base file 
SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get 
uid and password of some users. He had now access to the file in 
mainframe. I want to understand what happend, and how to protect against 
such issue.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Lizette Koehler]

If you have not joined the RACF newsgroup, you can do it at this URL

http://www.listserv.uga.edu/archives/racf-l.html


Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of mmjuma
Sent: Saturday, August 17, 2013 1:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF Database protection

Hi list

Some one in our section, he was able to download RACF data base file 
SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid 
and password of some users. He had now access to the file in mainframe. I want 
to understand what happend, and how to protect against such issue.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Elardus Engelbrecht]

mmjuma wrote:

>Some one in our section, he was able to download RACF data base file 
>SYS1.RACF.PRIM ...

You and that someone should stay away from my z/OS! Your protection of RACF DB 
and all its backups are pathetic. UACC should be NONE (see other's replies).

>... via ftp to PC, 

Your FTP is unprotected! 

>...then he used some tool. 

With any of the available freebies you can download.

>... He was able to get uid and password of some users. 

As others said, only when you completed a brute force attack. No passwords are 
stored at all on the RACF DB and all its backups. Not even IRRDBU00 writes out 
protected fields.

>He had now access to the file in mainframe. 

Fire him. And the RACF admin too.

>I want to understand what happend, and how to protect against such issue.

Do a full review of your machine security. First, UACC=NONE on your RACF DB and 
all its backup. Then your PROGRAM class and FTP, then everything else.

And stay away from my machine.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[R.S.]

W dniu 2013-08-17 10:57, Ted MacNEIL pisze:

It's easy: he has READ to the db. He should have it.

Why should he have it? Nobody needs read access to any password, copy, or 
back-up!

My typo: he SHOULD NOT have it.
Even for backup purposes. (WHEN(PROGRAM(IRRUT200)) is the solution for 
ad-hoc backups).

Regarding passwords: no password is recorded in the db, but having the

db he's able to use brute-force method to find the passwords.

He wouldn't be able to brute-force mine!
Everyone with computer and the db is able to perform brute force attack, 
despite he should or should not.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Ted MacNEIL]

>It's easy: he has READ to the db. He should have it.

Why should he have it? Nobody needs read access to any password, copy, or 
back-up!

>Regarding passwords: no password is recorded in the db, but having the 
db he's able to use brute-force method to find the passwords.

He wouldn't be able to brute-force mine!
In my case, the term 'word' in password is a misnomer.

I won't even tell you how I come up with mine, but letters in my case are rare, 
even in 'long' ones?
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[R.S.]

W dniu 2013-08-17 10:02, mmjuma pisze:

Hi list

Some one in our section, he was able to download RACF data base file 
SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid 
and password of some users. He had now access to the file in mainframe. I want 
to understand what happend, and how to protect against such issue.

It's easy: he has READ to the db. He should have it.
Regarding passwords: no password is recorded in the db, but having the 
db he's able to use brute-force method to find the passwords.
Las, but not least: it is bad idea to download in unecrypted form the db 
over the network, despite he has the READ.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Database protection

[Ted MacNEIL]

I suggest you try the RACF List, but:

1. Protect all database amd their back-ups.
2. He does NOT have access to any passwords. They are not stored. In simple 
terms the userid is encrypted, using the password when first set, and that is 
what is stored. Then, with each sign on, the supplied password is used to 
re-encrypt the userid. If matched sign-on is successful.

There arw more details, but I did say 'simple'.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: mmjuma 
Sender:   IBM Mainframe Discussion List 
Date: Sat, 17 Aug 2013 11:02:29 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: RACF Database protection

Hi list

Some one in our section, he was able to download RACF data base file 
SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid 
and password of some users. He had now access to the file in mainframe. I want 
to understand what happend, and how to protect against such issue.



Send from Samsung Mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN