Enumerating User IDs (was: CANCEL TSO Logon?)
On Mon, 5 Jan 2015 09:48:28 -0600, Tony's Basement Computer wrote: DoS, revoke all the non-Special and non-Protected users. -Original Message- From: Vernooij, CP (ITOPT1) - KLM What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? And here we have a cultural divide. Open systems folks are quite sensitive to the possibility of enumerating user IDs; less sensitive to exhaustive password search, and feel that revoking a user's ID upon detecting password probing invites that form of DoS. If I hadn't noticed my coworker's ID when I inadvertently typoed it, I'd have unwittingly revoked him with repeated password tries. One interesting approach in a product (ISTR from Simware?) was to increase the login processing latency after each password rejection. And YA product (ISTR IBM VM/370?) logically locked the terminal on detected probing. This caught me once (wasn't mischief, merely clumsiness). I left my terminal emulator connected to the disabled port, opened a new window, and logged in successfuly with the next port in the hunt. YA DoS potential. It's interesting (if I believe the news reports and Obama) that North Korea was able to hack Sony in retribution. This appears to be not a shotgun blast but a narrowly targeted attack. It could have been any one selected of many victims. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- 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: Enumerating User IDs (was: CANCEL TSO Logon?)
SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
Philip is larger than life and very into himself. He's keynoting at SHARE. Come see him in person. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony's Basement Computer Sent: Monday, January 05, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
On Mon, Jan 5, 2015 at 8:57 AM, Tony's Basement Computer tbabo...@comcast.net wrote: Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. Agreed. What I found interesting was that the vulnerabilities presented all related to the Unix side and add-ons related to the web world. I think the only exception to this was the comments related to job submission related to FTP. In the presentation, I did not see (perhaps i missed it) was how to obtain root (special) access to a z/OS system. All of the thing presented seemed to assume you were dealing with a logon id which already had considerable capabilities. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- 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: Enumerating User IDs (was: CANCEL TSO Logon?)
I do not believe you will get RACF SMF and console messages for this type of probing. It is my understanding that TSO performs a RACROUTE REQUEST=EXTRACT to obtain the data to fill in the various fields in the logon panel. When retrieving or replacing fields, the RACF manual explicitly states: *Logging* of RACROUTE REQUEST*=*EXTRACT invocations is not done except indirectly. *Logging* can occur during field access checking if the RACROUTE REQUEST=AUTH request exit requests it. Therefore I do not believe any logging would be performed. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 10:18 AM, Joel Ewing jcew...@acm.org wrote: On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did someone provide the magic VTAM command? I ask from ignorance because I didn't watch 100% of the video and I'm not connect literate. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Monday, January 05, 2015 6:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- 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: Enumerating User IDs (was: CANCEL TSO Logon?)
On 5 January 2015 at 19:19, Tony's Basement Computer tbabo...@comcast.net wrote: Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did someone provide the magic VTAM command? I ask from ignorance because I didn't watch 100% of the video and I'm not connect literate. His (incredibly annoying if you're an old non-hip guy like me) tumblr page is chock full of GIFs of logon screens with their publicly reachable IP addresses. So anyone could just TN3270 to any of those. Even if they support TLS, that protects the data in transit, but it's unlikely that authentication by the TN3270 client is required. I have no idea how he got the addresses, and presumably some have been fixed by now, but doubtless not all. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
Something like this?ICH408I USER(MYPSWD99) GROUP( ) NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- 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: Enumerating User IDs (was: CANCEL TSO Logon?)
I don't see those on my LPAR for the situation we are talking about -- invalid userid but no password entry yet. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Monday, January 05, 2015 4:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
I have no idea how he got the addresses I suspect by scanning. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Monday, January 05, 2015 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 5 January 2015 at 19:19, Tony's Basement Computer tbabo...@comcast.net wrote: Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did someone provide the magic VTAM command? I ask from ignorance because I didn't watch 100% of the video and I'm not connect literate. His (incredibly annoying if you're an old non-hip guy like me) tumblr page is chock full of GIFs of logon screens with their publicly reachable IP addresses. So anyone could just TN3270 to any of those. Even if they support TLS, that protects the data in transit, but it's unlikely that authentication by the TN3270 client is required. I have no idea how he got the addresses, and presumably some have been fixed by now, but doubtless not all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
The problem is, that when TSO populates the logon panel, it does not do a(RACROUTE REQUEST=INIT (RACINIT) but rather does an RACROUTE REQUEST=EXTRACT (RACXTRT) against the user id specified to populate the fields on the logon panel. This does not result in any RACF message or SMF record, but TSO does use the RC to inform the user if the user id specified is defined or not. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 6:05 PM, Frank Swarbrick 002782105f5c-dmarc-requ...@listserv.ua.edu wrote: Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- 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
Re: Enumerating User IDs
So what TSO logon should be doing if the userid is invalid or not authorized for TSO is not give any error indication on the logon screen but populate the panel fields with plausible default values that look as if a RACF TSO segment was found and force the user to supply the password field before giving a failure message. Doesn't sound like a big change to implement, but what do I know. J C Ewing On 01/05/2015 07:20 PM, Lou Losee wrote: The problem is, that when TSO populates the logon panel, it does not do a(RACROUTE REQUEST=INIT (RACINIT) but rather does an RACROUTE REQUEST=EXTRACT (RACXTRT) against the user id specified to populate the fields on the logon panel. This does not result in any RACF message or SMF record, but TSO does use the RC to inform the user if the user id specified is defined or not. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 6:05 PM, Frank Swarbrick 002782105f5c-dmarc-requ...@listserv.ua.edu wrote: Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. ... -- 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: Enumerating User IDs
I watched the flick and agree with a lot of what he said. He obviously has no scruples about disclosing any and all information, but isn't that how Open Source software protects itself? And if someone opens their TN3270 port to the public internet, whose fault is that really? One thing he said right off was that SPECIAL effectively has full system access. I hope auditors understand that. Years ago I had the cleanup job of removing OPERATIONS auth from as many users as possible, and I told the auditors they needed to look at SPECIAL users too. They argued that SPECIAL was out-of-scope for the project :) I had to laugh a bit when he made fun of names like ISPF and RACF, just like we make fun of grep and awk. But he's correct in putting down mainframe people (me included) who haven't fully learned some of the basics like netstat and nslookup. However, I'm not sure he understands as much as he thinks he does. For example, I saw my name while browsing his tumblr page - he made fun of an ibm-main post where Skip mentioned we had quickly applied IBM security PTF's, but it would take some time to roll out to production. I'm not sure he understands change control and the related risk assessment. What I REALLY DON'T LIKE is that he seems focused on providing automated hacking solutions. That goes well past a simple lack of scruples. Tony Harminc wrote: His (incredibly annoying if you're an old non-hip guy like me) tumblr page is chock full of GIFs of logon screens with their publicly reachable IP addresses. So anyone could just TN3270 to any of those. Even if they support TLS, that protects the data in transit, but it's unlikely that authentication by the TN3270 client is required. I have no idea how he got the addresses, and presumably some have been fixed by now, but doubtless not all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Enumerating User IDs (was: CANCEL TSO Logon?)
On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
