The HLASM code with the WTO messages was test code. The sploit is all in the C
code. It’s recursive and takes a while to grok. Very clever.
> On 31 Jan 2022, at 22:56, Tom Brennan wrote:
>
> On 1/30/2022 11:11 PM, David Crayford wrote:
>
>> See my other post for details and links to the expl
On 1/30/2022 11:11 PM, David Crayford wrote:
See my other post for details and links to the exploit source code which
sets the ACEE bits.
Thanks, I did see your post and then mentioned the source code below
which I believe is what you are talking about. That's when talk of SVC
242 came up (
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
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 cou
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 t
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 progra
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. Alt
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-
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 Mug
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 i
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
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
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'
] 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
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
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:
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.
*| **Itschak Mugzach | Director | Se
On 29/1/22 11:53 pm, Itschak Mugzach wrote:
It seems you haven't read the link you sent... This article says exactly
what I claim. It was a UUS (aka UNIX) vulnerability that helped them get
UID 0. This is how it started.
You've changed direction now from open source to z/OS UNIX. Are you
aware
It seems you haven't read the link you sent... This article says exactly
what I claim. It was a UUS (aka UNIX) vulnerability that helped them get
UID 0. This is how it started.
ITschak
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Conti
Le 29/01/2022 à 16:12, Itschak Mugzach a écrit :
David,
Prove your claim reg. "Enterprise software". Give at least one sample. My
claim is already proved. Nordea bank was penetrated from USS, LOG4J is an
open source.
ITschak
here is an article about the Nordea hack.
https://badcyber.com/a-hi
David,
Prove your claim reg. "Enterprise software". Give at least one sample. My
claim is already proved. Nordea bank was penetrated from USS, LOG4J is an
open source.
ITschak
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Mo
On 29/1/22 12:53 am, Phil Smith III wrote:
pipeline every time we merge into our development branch or master.
I know YOU know this, David, but it bears stating explicitly: none of these
tools would (did) detect the log4j vuln.
I'm cognizant to that. Humans find vulnerabilities. In the cas
Subject: Re: Country of development was Re: More of LOG4J
On 1/27/2022 6:03 PM, Clark Morris wrote:
> On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan
> wrote:
>
>> Those are things we don't like to talk about :) And even less talked
>> about: What's to stop a tru
Not only that. Many of the vulnerabilities are zero day. This means that
they were not known at the time you packed your product. LOG4J is a great
example for a 0D. As such, as Phill mentioned, they will not be discovered
by any toll you have.
ITschak
ITschak Mugzach
*|** IronSphere Platform* *|
David Crayford wrote:
>It's company policy where I work to perform code scans using Synopsis
>tools such as Black Duck and Polaris. These tools scan for license
>issues, vulnerabilities, compliance etc. Polaris is so sophisticated
>it flagged a violation because it had detected I was using an S
On 1/27/2022 6:03 PM, Clark Morris wrote:
On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan
wrote:
Those are things we don't like to talk about :) And even less talked
about: What's to stop a trusted ISV or even IBM from being hacked or
having a rogue employee that does the same?
Does the cou
On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan
wrote:
>Those are things we don't like to talk about :) And even less talked
>about: What's to stop a trusted ISV or even IBM from being hacked or
>having a rogue employee that does the same?
Does the country where the software is developed matt
On 27/1/22 10:19 pm, Mike Schwab wrote:
On Thu, Jan 27, 2022 at 10:12 AM David Crayford wrote:
On 27/1/22 2:35 pm, ITschak Mugzach wrote:
At Solarwind, twice the
size of Rocket, the toxic code was injected during the build process, by
someone(s) penetrated long before they started to interfe
On Thu, Jan 27, 2022 at 10:12 AM David Crayford wrote:
>
> On 27/1/22 2:35 pm, ITschak Mugzach wrote:
>
> > At Solarwind, twice the
> > size of Rocket, the toxic code was injected during the build process, by
> > someone(s) penetrated long before they started to interfere with code. BTW,
> > the
Or something similar to this:
https://www.theverge.com/2022/1/9/22874949/developer-corrupts-open-source-libraries-projects-affected
Sebastian
On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan
wrote:
>Those are things we don't like to talk about :) And even less talked
>about: What's to stop a
On 27/1/22 2:35 pm, ITschak Mugzach wrote:
memento Solarwind... David, I like your confidence.
What I am confident about is that if any vulnerability is discovered our
infosec team will use BlackDuck to detect all of our products that need
to be patched.
At Solarwind, twice the
size of Ro
memento Solarwind... David, I like your confidence. At Solarwind, twice the
size of Rocket, the toxic code was injected during the build process, by
someone(s) penetrated long before they started to interfere with code. BTW,
the Solarwind attack was based on a vendor code, not open source.
ITschak
On 27/1/22 3:36 am, ITschak Mugzach wrote:
It is a nightmare to vendors and clients
looking for potential security issues.
Not if they invest in state of the art tooling. Black Duck and Polaris
make short work of scanning for vulnerabilities.
FRom other hand, open source is here
to stay.
On 26/1/22 11:31 pm, Kirk Wolf wrote:
Good companies have policies and processes for approving any open source used internally. What's the alternative, write everything from scratch? Surely there will be no vulnerabilities there:-)
It's company policy where I work to perform code scans
On 27/1/22 4:35 am, Tom Brennan wrote:
Those are things we don't like to talk about :)
Indeed!
And even less talked about: What's to stop a trusted ISV or even IBM
from being hacked or having a rogue employee that does the same?
Absolutely nothing. Any executable code that runs authorized
Kirk Wolf wrote:
> Sorry, I agree that the entirety of what you wrote was more balanced. I
reacted (poorly) to this part:
"Same with open source: using random code from an unknown author would have
been unthinkable; now it's common."
>I don't think that this is common. Mostly projects use p
Many people are worried, which is why sandboxed application environments are
becoming so popular.
On Wed, Jan 26, 2022, at 2:35 PM, Tom Brennan wrote:
> Those are things we don't like to talk about :) And even less talked
> about: What's to stop a trusted ISV or even IBM from being hacked or
>
Those are things we don't like to talk about :) And even less talked
about: What's to stop a trusted ISV or even IBM from being hacked or
having a rogue employee that does the same?
On 1/26/2022 11:41 AM, Gibney, Dave wrote:
If I was a long term bad actor, or perhaps a nation/state, I might c
> -Original Message-
> > From: IBM Mainframe Discussion List On
> > Behalf Of Kirk Wolf
> > Sent: Wednesday, January 26, 2022 11:25 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: More of LOG4J
> >
> > Phil,
> >
> > Sorry, I agree t
nframe Discussion List On
> Behalf Of Kirk Wolf
> Sent: Wednesday, January 26, 2022 11:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: More of LOG4J
>
> Phil,
>
> Sorry, I agree that the entirety of what you wrote was more balanced. I
> reacted (poorly) to this part:
&
I was told about LOG4J V2 (2.1.x for example) from other people that ran
the scanner on 2.5 systems. It is a nightmare to vendors and clients
looking for potential security issues. FRom other hand, open source is here
to stay.
In short, mainframe modernization has its price.
ITschak
ITschak Mugz
Phil,
Sorry, I agree that the entirety of what you wrote was more balanced. I
reacted (poorly) to this part:
"Same with open source: using random code from an unknown author would have
been unthinkable; now it's common."
I don't think that this is common. Mostly projects use popular open
Kirk Wolf wrote:
>Is that really what you think is going on?
>The economics of open source are about *reuse*. The overwhelming majority
of software these days is built with it for that reason. Good developers
are very careful about what open source that they use.Good companies
have policie
On Tue, Jan 25, 2022, at 4:33 PM, Phil Smith III wrote:
> >
> Forty years ago, vendors barely spoke to each other; now we OEM and embed
> each other's products. Same with open source: using random code from an
> unknown author would have been unthinkable; now it's common.
Is that really what you
> Let's say that an organization wanted to prohibit open source. How would
you go about it?
As others have noted, this is a bigger lift than you might think. The open
source revolution means that we're all dependent on it now, whether we like
it or not. Your PC, phone, and car all depend on it
On 19/1/22 12:41 am, Kirk Wolf wrote:
Since I would guess that a majority of ibm-mainers would agree that open source
is confusing and dangerous, here's a question:
Let's say that an organization wanted to prohibit open source. How would you
go about it?
Good question. First off, you won't
dovetail.com]
Sent: Tuesday, January 18, 2022 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J
Since I would guess that a majority of ibm-mainers would agree that open source
is confusing and dangerous, here's a question:
Let's say that an organization wanted to prohibit ope
behalf of
PINION, RICHARD W. [rpin...@firsthorizon.com]
Sent: Tuesday, January 18, 2022 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J
Would one consider the CBT Tape to be open source? I've used CBT programs in
many places I've worked at.
-Original Message-
@LISTSERV.UA.EDU
Subject: Re: More of LOG4J
On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf wrote:
> Since I would guess that a majority of ibm-mainers would agree that
> open source is confusing and dangerous, here's a question:
As someone who installed and modified JES2 exits from t
On Tue, 18 Jan 2022 10:41:41 -0600, Kirk Wolf wrote:
>Since I would guess that a majority of ibm-mainers would agree that open
>source is confusing and dangerous, here's a question:
>
>Let's say that an organization wanted to prohibit open source. How would you
>go about it?
>
>Kirk Wolf
>Dove
Kirk, No way! This is under the title of mainframe modernisation. There are
so many services that are based on open source as well as many vendor
products. Open source is part of our life. Now we have to deal (and live)
with it.
What I am saying is that there are thousands of java jar files in USS
A lot of the discussion comes down to management of risk.
1. If we have a problem will we be able to get it fixed.
1. Check the forums and see how the product is treated
2. Are there people in the community who help out with questions
2. If we find we cannot use this product at any
I'm not in that majority, but if getting rid of all things open-source
became a mandate, I'd communicate to management what Stuart Holland used
to tell me: First shut down things like SSH, anything that uses
OpenSSL, USS programs, etc. It would be a mess.
And like someone else here mentioned
On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf wrote:
Since I would guess that a majority of ibm-mainers would agree that
open source is confusing and dangerous, here's a question:
As someone who installed and modified JES2 exits from the CBT tape,
modified HASP with British Rail and other contri
er
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Kirk Wolf
Sent: Tuesday, January 18, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J
Since I would guess that a majority of ibm-mainers would agree that open source
is confusing and dangerous, here
uesday, January 18, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J
Since I would guess that a majority of ibm-mainers would agree that open source
is confusing and dangerous, here's a question:
Let's say that an organization wanted to prohibit open source. H
Since I would guess that a majority of ibm-mainers would agree that open source
is confusing and dangerous, here's a question:
Let's say that an organization wanted to prohibit open source. How would you
go about it?
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
-
ttp://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: Tuesday, January 18, 2022 2:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: More of LOG
67d-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 18, 2022 2:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J
Thanks David,
1. Even if you are right about the version numbers, we still have 5
different versions here.
2. Your claim about the sub-version is interesting.
Blessed are the innocent
*| **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
Le 18/01/2022 à 09:09, Itschak Mugzach a écrit :
Raphael,
That's exactly my point. How do you maintain the life cycle of open source?
each project publishes updates, according to either
* fixed calendar
* feature based calendar
* vulnerability fixes
How can you explain that so many vendor pr
Raphael,
That's exactly my point. How do you maintain the life cycle of open source?
How can you explain that so many vendor products include old open source
versions?
ITschak
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Mo
Le 18/01/2022 à 08:28, Itschak Mugzach a écrit :
See your offering such as BASH. It is
downloaded and installed. no service exists. Do you expect the user to
check every day if there is a new version?
no, that would be the job of the site administrator
-
Thanks David,
1. Even if you are right about the version numbers, we still have 5
different versions here.
2. Your claim about the sub-version is interesting. So Z/OS 2.4, just
fir example, all RSU levels are the same. I don't think so, and so do the
NVD administrators. Read the ra
On 17/1/22 10:34 pm, ITschak Mugzach wrote:
Hi,
We took the time to dive into the wider issue of open source and z/os. USS
is a scary jungle!
Only to the ignorant.
Without many details on the how, we discovered that on our z/os 2.3 there
are 19 (!) different versions of Apache Ant: 1.5.3,
Reason to stay away from it as much as possible
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
ITschak Mugzach
Sent: Monday, January 17, 2022 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: More of LOG4J
** EXTERNAL EMAIL - USE CAUTION **
Hi,
We took the time to
Hi,
We took the time to dive into the wider issue of open source and z/os. USS
is a scary jungle!
Without many details on the how, we discovered that on our z/os 2.3 there
are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, 1.7.0,
1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8
67 matches
Mail list logo
