Re: More of LOG4J
On 31/1/22 2:28 pm, Tom Brennan wrote: Yes, it's probably just me still interested in the details of the hack. So bear with me and I promise to be quiet soon. So if they had a non-admin id, they certainly could have setup 443 as a client to dump an unprotected RACF DB to a remote server. None of that would need root access and could easily go undetected. Then once cracked, they could look for an admin id that had SPECIAL/OPERATIONS/UID=0 or whatever they wanted, and simply logon using the hacked password. That makes sense so far. What doesn't make sense is the references to getting ACEE bits or UID=0 by various means. So maybe those references (like the ASM code snip that calls SVC 242) were never really used and this hack was as simple as: See my other post for details and links to the exploit source code which sets the ACEE bits. 1) Get network TCPIP access to a mainframe, either because the ports are publicly available, via a compromised VPN company PC, etc. 2) Get a non-admin userid that can be logged onto via TSO, SSH, or whatever, perhaps also from a compromised company PC. It's my understanding that Logica stupidly used default accounts and passwords for FTP which is how Anakata first gained access. After that he had control of several user accounts. Nobody knows how this happened. It could have been social engineering or an insider threat. He learned and z/OS and tested the exploit using Hercules and a pirated copy of the AD/CD. 3) Run some code under that id to dump the RACF DB to a remote server 4) Look for admin userids in the DB and crack a password 5) Logon to an admin userid through the same TCPIP method as #1 6) Do more bad stuff as root or SPECIAL, trying not to leave tracks. Come to think of it, I seem to remember maybe 10 years ago or more, wasn't it Thierry Falisard (sp.) who came up with a dictionary ripper program that caused everyone (including me) to go check their RACF DB read protection? On 1/30/2022 6:52 PM, Bob Bridges wrote: I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was
Re: More of LOG4J
Yes, it's probably just me still interested in the details of the hack. So bear with me and I promise to be quiet soon. So if they had a non-admin id, they certainly could have setup 443 as a client to dump an unprotected RACF DB to a remote server. None of that would need root access and could easily go undetected. Then once cracked, they could look for an admin id that had SPECIAL/OPERATIONS/UID=0 or whatever they wanted, and simply logon using the hacked password. That makes sense so far. What doesn't make sense is the references to getting ACEE bits or UID=0 by various means. So maybe those references (like the ASM code snip that calls SVC 242) were never really used and this hack was as simple as: 1) Get network TCPIP access to a mainframe, either because the ports are publicly available, via a compromised VPN company PC, etc. 2) Get a non-admin userid that can be logged onto via TSO, SSH, or whatever, perhaps also from a compromised company PC. 3) Run some code under that id to dump the RACF DB to a remote server 4) Look for admin userids in the DB and crack a password 5) Logon to an admin userid through the same TCPIP method as #1 6) Do more bad stuff as root or SPECIAL, trying not to leave tracks. Come to think of it, I seem to remember maybe 10 years ago or more, wasn't it Thierry Falisard (sp.) who came up with a dictionary ripper program that caused everyone (including me) to go check their RACF DB read protection? On 1/30/2022 6:52 PM, Bob Bridges wrote: I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. -- 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:
New alternate res pack clarification
Hello Below is my IEASYMxx SYMDEF(='') I have created a alternate res pack with the name OSRESB and the currently running is OSRESA. Already RES volume dataset are indirectly cataloged. With new RES I have done all the cloning plus IPLtext and getting root volumes copied. Is there is any work needs to be done to get the new RES volume recognized as part of Symbolics ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 31/1/22 10:52 am, Bob Bridges wrote: I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. They got access to root so can change any file in the system with impunity. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. -- 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: More of LOG4J
I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: > Ho Tom, > > Once they got root, they were able to unload racf DB that was not well > protected and run an (open source) password cracker. They had time to > get many user passwords. No user SVC was involved, not needed. I don't > know where David collects his information, but the breach is well > documented in many reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 31/1/22 4:09 am, Itschak Mugzach wrote: Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. Wrong! The "John the Ripper" cracking of RACF data bases was a separate incident. Although, there could be a correlation. No user SVC was involved, not needed. I never claimed there was. You have incorrectly connected my comment about "magic SVC's" to the Logica breach. I don't know where David collects his information, but the breach is well documented in many reports. One of my colleagues was a member of the OMVS development team at the time of the Logica breach and we have discussed it at length. He was part of the investigation team and to this day he is convinced Anakata was not working alone. He was also surprised there was so much information about it in the public domain. A large portion of the source code of the attack is in the public domain. I know Tom is a more than capable C programmer so I suggest taking a look at the meat of the hack. Elevation to root exploited a NetView REXX exec called CNMEUNIX which enabled him to invoke "setuid 0" to get root. Getting root gives you admin control in z/OS UNIX but you're not running authorized and certainly can't steal the RACF data base. The interesting code is DeFeeStRaTe.C [1] which exploits an APF-authorized zFS module, IOELMD10. It's a classic clobber the return address (R14) and run my shell code exploit, similar to return-to-libc exploits on Linux systems where a hacker calls code in kernel space and then overflows a buffer with malicious code which gets control still in kernel space. Check out the "shellcode_full" string which contains the code which is called from the APF authorized code. That's where MODESET is called and the ACEEFLG3 bits are set. At this point the attacker has the keys to the kingdom. [1] https://github.com/mainframed/logica/blob/master/DeFeNeStRaTe.C * * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
AFAIK, UID(0) (via CNMEUNIX) has nothing to do with reading (downloading) the unprotected RACF Database. There is another factor ... the uneducated/inexperienced administrators did not protect a multi-session product (IIRC, it was TPX). As well, the hackers found a bug in NVAS ... changing a non-display field on the screen allowed them to bypass certain controls. On 2022-01-30 18:18, Tom Brennan wrote: Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. Best, ITschak -- 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: More of LOG4J
Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. Best, ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 9:39 PM Tom Brennan wrote: > Hi Itschak, > > Yes, like you I've written SVC's, although I never came across one of > these "magic" ones. I've also written code to mess with the ACEE bits > similar to that hack sample. But this was under control of APF, with > auditor and management approval. > > My question is how the user got that far, and I haven't yet figured that > out from the blog page. For example, how did they get an address space > going where they could even run the code to set the ACEE bits. And did > they implement the SVC 242 or was it there already. I just don't have > enough information to lay blame, or don't fully understand the blog. > > On 1/30/2022 12:07 AM, Itschak Mugzach wrote: > > Tom, > > > > This is an old trick that allows a program to call SVC to switch to > > supervisor mode and key zero. Once you are there, you can do almost > > everything. for example, login to another user without specifying a > > password, use the bypass userid, and so on. > > > > However, David only mentions a facility that is quite common, but hasn't > > proved it was used in an illegal operation. > > > > Best, > > ITschak > > > > -- > 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: More of LOG4J
Hi Itschak, Yes, like you I've written SVC's, although I never came across one of these "magic" ones. I've also written code to mess with the ACEE bits similar to that hack sample. But this was under control of APF, with auditor and management approval. My question is how the user got that far, and I haven't yet figured that out from the blog page. For example, how did they get an address space going where they could even run the code to set the ACEE bits. And did they implement the SVC 242 or was it there already. I just don't have enough information to lay blame, or don't fully understand the blog. On 1/30/2022 12:07 AM, Itschak Mugzach wrote: Tom, This is an old trick that allows a program to call SVC to switch to supervisor mode and key zero. Once you are there, you can do almost everything. for example, login to another user without specifying a password, use the bypass userid, and so on. However, David only mentions a facility that is quite common, but hasn't proved it was used in an illegal operation. Best, ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Free SMPE installation product
On Sun, 30 Jan 2022 10:24:39 -0600, Marna WALLE wrote: >Another suggestion, if you don't have Shopz access... We provide a dummy FMID >that has been pre-installed and is in a z/OSMF portable software instance >format here >https://www.ibm.com/support/z-content-solutions/serverpac-install-zosmf/ >(under Try It). And, it has some dummy PTFs with it too, with dummy FIXCATs, >included. > Excellent! In days of yore for self-training/testing I have created/installed/deleted entire dummy products from instream data. How easily can it be tailored? Ideal would be a single SET statement with heavy reliance on DD DATA,SYMBOLS=JCLONLY setting HLQs. >If you already have that installed (or really, any small FMID, not just the >sample above), you could BUILDMCS it easily. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECEIVE ORDER
I was plodding along, restarting after network glitches. But, I think there's now a server issue? DATE 01/30/22 TIME 08:20:03 SMP/E GIMJVCLT OUTPUT SMP/E 36.108 httpGet fileUrl="https://deliverycb-bld.dhe.ibm.com/2022012586733/PROD/SMPPTFIN/ 2022025122815996352.36of39" localFile="/Z23NTS/ORD3-25January2022-11.50.44.1 75/SMPPTFIN/2022025122815996352.36of39" fileUser="S4880d83" filePw=" ***" retryCnt="10" retryInt="60" Starting download from URL: https://deliverycb-bld.dhe.ibm.com/2022012586733/PRO D/SMPPTFIN/2022025122815996352.36of39 to local file: /Z23NTS/ORD3-25January2 022-11.50.44.175/SMPPTFIN/2022025122815996352.36of39 smpeCC:07 smpeRoutine:GIMJVGET smpeMsgLen:44 smpeMsg:StatCode:500 RsnPhr ase:Internal Server Error terminate smpeCC:02 smpeRoutine:GIMJVTRM smpeMsgLen:00 > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Tuesday, January 25, 2022 3:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RECEIVE ORDER > > Thank you, my last bit there was just whining. > I'm now working from a sandbox, (3 active LPARs total) , capped at 9 MSU > and I think we may have dropped the contracted bandwidth with our MFaaS > host. > > I just have to hope I can get it all down without interrupting network > glitches. > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Pommier, Rex > > Sent: Tuesday, January 25, 2022 3:03 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: RECEIVE ORDER > > > > Dave, > > > > I don't think that has anything to do with using HTTPS at all. That is all > > I've > > used since it's been available and I want to say it took a few hours to > > download my entire order last time I got one. I think there's something > else > > going on at your shop that is severely limiting the transfer rate. > > > > Rex > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Gibney, Dave > > Sent: Tuesday, January 25, 2022 4:56 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: RECEIVE ORDER > > > > That was the last suggestion I needed, at least to get an order accepted, > built > > and starting to retrieve. So far, it took 2 hours to pull the first 1 of 39 > > chunk > > down. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > On > > > Behalf Of Kurt J. Quackenbush > > > Sent: Tuesday, January 25, 2022 5:30 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: RECEIVE ORDER > > > > > > > GIM69233I FTP FAILED, ATTEMPT 01 OF 10. FTP WILL BE RETRIED IN 60 > > > > SECONDS. > > > > > > > > The ordering connection is HTTPS, but the download seems to still be > > > FTP. > > > > > > I suggest you try using HTTPS for the download and avoid FTP altogether. > > > Add this to your specification: > > > > > > downloadmethod="https" > > > downloadkeyring="javatruststore" > > > > > > For more information: > > > > > > https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?top > > > ic=guide-preparing-secure-internet- > delivery__;!!JmPEgBY0HMszNaDT!7b- > > > JV-9ekUYftwtKOuzK3wqBOv5sK9FjRjiy4RZTBDzZS-p25h2eR02AjznAIw$ > > > > > > Kurt Quackenbush -- IBM, z/OS SMP/E and z/OSMF Software > Management > > > Chuck Norris never uses CHECK when he applies PTFs. > > > > > > > > > -- > > > 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 > > > > -- > > The information contained in this message is confidential, protected from > > disclosure and may be legally
Re: Free SMPE installation product
Another suggestion, if you don't have Shopz access... We provide a dummy FMID that has been pre-installed and is in a z/OSMF portable software instance format here https://www.ibm.com/support/z-content-solutions/serverpac-install-zosmf/ (under Try It). And, it has some dummy PTFs with it too, with dummy FIXCATs, included. If you already have that installed (or really, any small FMID, not just the sample above), you could BUILDMCS it easily. -Marna WALLE z/OS System Installation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
+1 *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 3:27 PM Seymour J Metz wrote: > That only works if there is such an SVC. A competent auditor would red > flag it immediately. Alas, not every auditor is competent :-( > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] > Sent: Sunday, January 30, 2022 3:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: More of LOG4J > > Tom, > > This is an old trick that allows a program to call SVC to switch to > supervisor mode and key zero. Once you are there, you can do almost > everything. for example, login to another user without specifying a > password, use the bypass userid, and so on. > > However, David only mentions a facility that is quite common, but hasn't > proved it was used in an illegal operation. > > Best, > ITschak > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere > Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux > and IBM I **| * > -- > 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: Directories on ft server with Hebrew names
SMP (without the E) used flaky member names. You couldn't specify them in your JCL, but then there was no reason to. Also, some RYO utilities that Gerhard (ז״ל) and I used quite heavily used a hyphen in a member name as a wildcard; I was quite unhappy when IBM made that illegal. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Saturday, January 29, 2022 9:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Directories on ft server with Hebrew names On Sun, 30 Jan 2022 00:34:36 +, Seymour J Metz wrote: >Cut and paste is quite useful in dodging keyboard issues, as are various >character map applications. Whiler my keyboard is configured as US >International, that still doesn't give me, e.g., Hebrew, so I rely on pasting >Hebrew text from other applications. Most of the virtual keyboard and >character map applications that I've seen cover quite a few languages. > Similarly useful are graphic file managers such as ISPF which allow users and admins to manipulate files difficult to access from keyboard or command line. In self-training long ago, I created with STOW some members with "invalid" names then deleted them with ISPF prefix commands. TSO or JCL just said, "Syntax Error". I suspect that if Gadi were to "pax -w" his desktop folders then "pax -r" on z/OS, pax -r might perform a fictitious ISO8859-1 -> IBM-1047 translation. Then if he did a "ls" via ssn, ssh would undo the translation and he'd see Hebrew names. Less hope for ISPF 3.17. -- 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: More of LOG4J
An SVC runs in supervisor mode; that's a much stronger privilege than UID(0). It's trivial to write such an SVC, but any competent auditor would shoot you down if you suggested it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Sunday, January 30, 2022 2:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J The badcyber.com page points to a program calling a magic SVC. Maybe that's what David is referring to? But I didn't read/understand enough to see if they used UID=0 somehow to implement that SVC, or if they had to rely on it already being in place, or if this program was used at all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
That only works if there is such an SVC. A competent auditor would red flag it immediately. Alas, not every auditor is competent :-( -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] Sent: Sunday, January 30, 2022 3:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Tom, This is an old trick that allows a program to call SVC to switch to supervisor mode and key zero. Once you are there, you can do almost everything. for example, login to another user without specifying a password, use the bypass userid, and so on. However, David only mentions a facility that is quite common, but hasn't proved it was used in an illegal operation. Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning root zfs to other lpar
That's how I do it: //ADRDSSU EXEC PGM=ADRDSSU,REGION=0M,TIME=1439 //SYSPRINT DD SYSOUT=* //LOOKHERE DD DSN=hlq.HFS.BACKUP.ZOS23.SERVICE.ROOT, // DISP=(NEW,CATLG), // SPACE=(TRK,(50858,1000),RLSE),UNIT=3390,VOL=SER=ZFSBK1 //SYSINDD * DUMP DATASET(INCLUDE( - OMVS.ZOS23.SERVICE.ROOT - )) - PROCESS(SYS1) - ALLDATA(*)ALLEXCP - TOL(ENQF) OPT(4) WAIT(0,0) - CANCELERROR COMPRESS - OUTDD(LOOKHERE) > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jake Anderson > Sent: Sunday, January 30, 2022 12:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Cloning root zfs to other lpar > > Hello Group > > I am trying to move maintenance root zfs which is 5000 cylinder in size. > The environment what we have is two monoplex. I tried doing dump the > root > into a shared DASD(MOD-27) but it fails with D37. > > What's the best way to clone a zfs from one monoplex environment to > another > ? Our DASD are shared > > Jake > > -- > 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
Cloning root zfs to other lpar
Hello Group I am trying to move maintenance root zfs which is 5000 cylinder in size. The environment what we have is two monoplex. I tried doing dump the root into a shared DASD(MOD-27) but it fails with D37. What's the best way to clone a zfs from one monoplex environment to another ? Our DASD are shared Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Tom, This is an old trick that allows a program to call SVC to switch to supervisor mode and key zero. Once you are there, you can do almost everything. for example, login to another user without specifying a password, use the bypass userid, and so on. However, David only mentions a facility that is quite common, but hasn't proved it was used in an illegal operation. Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 9:57 AM Tom Brennan wrote: > The badcyber.com page points to a program calling a magic SVC. Maybe > that's what David is referring to? But I didn't read/understand enough > to see if they used UID=0 somehow to implement that SVC, or if they had > to rely on it already being in place, or if this program was used at all. > > https://github.com/mainframed/logica/blob/master/Tfy.source.backdoor > > On 1/29/2022 10:27 PM, Itschak Mugzach wrote: > > David, > > > > I am 40+ years developer in assembler. I believe I wrote and used SVCs > > before you. If you read my previous emails you would see that > modernisation > > is a must. However, you haven't given any sample of breach caused by > > standard mvs code, while I gave two. > > > > -- > 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
