Radoslaw,
* I find your posts informative and helpful.
* I think your English is very understandable
* I respect your expertise
My initial post was an attempt to get a stalled discussion moving in a
more positive direction. I don't normally post but I felt that mainframe
vulnerability discussions are important for our industry. We, as a
group, need to be able to discuss this issue without resorting to name
calling and childish behavior.
The work that I do includes finding exploitable code based
vulnerabilities running in the wild on z/OS systems. These
vulnerabilities are on mainframe systems in many sectors, including
Financial Institutions and Government. These installations report the
vulnerabilities they find and the ISV's fix them. This is a fact.
Individuals like Bill Johnson can say that I am lying. You can say what
I am saying is FUD - however, neither of these things changes the fact
that I continue to find exploitable code vulnerabilities in z/OS. More
and more people are being exposed to this fact every day.
Based on the work I have done on mainframe code vulnerabilities, I have
concluded that there is a serious problem in our industry. The code that
runs in production in all sectors has poorly written code, that if
exploited, would compromise all data on those systems. Should I just
ignore this problem or try and do something about it? The numbers of
vulnerabilities tells me there are some fundamental problems with how
software development is being done in our industry. The lives of people,
organizations, and governments would be adversely affected if the code
vulnerabilities I have found were not reported and fixed by the vendors.
I have decided that I cannot just stand by and do nothing. The industry
needs to do better. We need to do better.
In response to "What exactly hacking scenario can provide RACF db to the
hacker?" there is a class of vulnerabilities called TRAP DOOR. A TRAP
DOOR vulnerability will branch to an address specified by an
unauthorized user (key 8 problem state not apf authorized) in an
authorized state (PSW KEY 0-7, Supervisor state, JSCBAUTH bit set). This
type of vulnerability usually exists in SVC and PC routines. The address
I pass will have code to get into PSW Key 0 (code is different depending
upon the entry environment). Once in PSW Key 0 I can a) Suppress all SMF
records to hide what I am doing b) Frontend the SAF Router to force all
AUTH and FASTAUTH calls to "allow and no log" (this is for any ESM not
just RACF) c) Copy the ESM data base to another data set d) Create a
reverse shell to send it out to an IP of my choice or e) download to
windows or mac and then attach to email or f) email directly from
mainframe. Please note that once I get to PSW KEY 0 my code is now
working as an extension of z/OS. Whatever z/OS can do my code can do.
With no forensic evidence to see what I did. Or I could create ESM
credentials for Bill Johnson or Radoslaw and let it get logged to you;-)
. Just as a FYI about 35% of the "several hundred" code vulnerabilities
that I have found are TRAP DOOR vulnerabilities. This represents a
significant percentage of total number of vulnerabilities. This is a
statically viable example.
The following is for Bill Johnson which would have been covered in the demo:
* The SVC or PC routine can be issued by any user on the mainframe
system.
* The vulnerable code is executed before any SAF calls are made by the
SVC or PC routine (i.e. - ESM cannot help you)
* The ESM's:
o Cannot identify this vulnerable code is on the system
o Cannot tell you when the vulnerable code is exploited
o Cannot provide you the information to get vulnerability remediated
* The payload code does not require an APF authorized library. The
authorization is inherited from the caller (the SVC or PC routine).
* No extra-ordinary ESM authorities are required - any id would do
* No extra-ordinary z/Os authorizes are required
* Suppressing SMF is for all SMF record types not just ESM records
types (i.e. - types 14 and 15)
It would be easier for this discussion if I could just create a CVE in
the national vulnerability data base. Then I could just point you to it
and you could research this for your self. However, that is not how our
industry works. Everything is secret. I used terms like "if an exploit",
"if job reads you RACF db", "unintended consequences" to allow
conversation without telling everyone enough information to create an
exploit. That is the dilemma: How can we have meaningful conversations
about vulnerabilities without exposing too much information? My answer
is to classify the vulnerabilities. At this point we should be able to
have meaningful conversation about any "TRAP DOOR" vulnerabilities.
In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: People are responsible for a TRAP
DOOR code vulnerability as well. However it is the people responsible
for writing and maintaining the code not necessarily the installation
running the code. A subtle but important distinction.
I would like to think at the end of the day that the work that I do is a
valuable service to our industry as well as to the institutions that run
mainframes regardless of whether you do business with me or not.
Ray Overby
On 5/29/2019 5:25 AM, R.S. wrote:
That's classical FUD.
Frightening people.
"if an exploit", "if job reads you RACF db", "unintended consequences".
What exactly hacking scenario can provide RACF db to the hacker?
Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user
attribute, even UPDATE to RACF db. But it's problem of people.
Mistakes, lack of time, lack of control, lack of skills. Not a
platform weakness.
It's typical that assurance/lock/gun salesmen tend to talk about
risks, threats and dangers. They create a vision.
My English is poor, but I can observe it for two of debaters here.
It's visible. I don't like social engineering.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
