This is the fifth article in an eight article series about getting to speak at DEFCON 22.
So I had just completed submitting to DEFCON 21. At the same time, I had submitted talks to BlackHat and the BSidesLV Underground track.
This is the fourth article in an eight article series about getting to speak at DEFCON 22.
With my newly attained ability to speak publicly I wanted to share what I was doing. Once I had given the talk I didn’t stop the research. I spent the next 4 months working on new tools, new attacks and new techniques, all in Python. I then learned how easy it was to submit talks to cool conferences that I thought I’d never get to attend, let alone speak at and it helped me to develop my voice as a speaker.
It all started with Shmoocon in 2013.
This is the third article in an eight article series about getting to speak at DEFCON 22.
I submitted the talk I wanted to give at DEFCON to the BSidesLV Mentor Program. The Mentor program is a really amazing thing and I can’t sing enough praise for it. I was paired with Nicolle (aka Rogue Clown: https://twitter.com/rogueclown) who was a really amazing mentor. Giving me the information I needed and emotional support I didn’t even know I needed to give a talk publicly.
Glad I could help. Anyone learning to use the new platform is a boon to the mainframe security world!
There’s a really interesting discussion on mainframes and their security stance going on, over twitter at the moment and after @singe has weighed in I felt like I should also weigh in on the issue.
Here’s IBM’s stance:
His points (read here) are quite salient. To paraphrase, with a little work Dominic was able to find an entirely new class of vulnerabilities to the platform and by denying public access to known issues they are blocking off the very people who can help modernize the security on the platform.
He’s absolutely correct but I’d like to come at it from a different perspective with relation to the enterprise.
Most enterprises rely on CVE for scanning for vulnerabilities. This method has been tested and is quite mature. When a new issue comes out from Microsoft, or CISCO, or Oracle your enterprise scanner gets updated and alerts you to systems which didn’t have the patch installed. You then create tickets to patch those systems as they present gaps in your security. For systems where you cannot install the patch (legacy applications, for example) you then have the appropriate level of awareness to know which systems aren’t protected and can understand your risk profile.
Furthermore, under the CVE model you know the appropriate level of risk and attention that a patch needs (can this patch wait until next teusday or do I need to patch it today?).
Now, lets take a look at two (public) issues IBM had in 2012:
Unspecified vulnerability in IBM Tivoli NetView 1.4, 5.1 through 5.4, and 6.1 on z/OS allows local users to gain privileges by leveraging access to the normal Unix System Services (USS) security level.
This is not really that big of an issue. Basically, an OMVS program (specifically: /usr/lpp/netview/v5r3/bin/cnmeunix) can be used in rexx and the spawn call to get root access. What isn’t stated in this issue is the fact that it doesn’t need to be cnmeunix (which is a Tivoli Netview program) but can be used by ANY rexx script with a setuid. Don’t worry though, IBM fixed this problem in secret without telling you about it, other than releasing a secret patch. But it led to people not installing the fix because “We don’t use Netview”.
Unspecified vulnerability in the IBM HTTP Server component 5.3 in IBM WebSphere Application Server (WAS) for z/OS allows remote attackers to execute arbitrary commands via unknown vectors.
This was a massive issue if you’re running websphere on z/OS. Basically it allowed remote command execution through the webserver. I’ve been told it had something do to with CGI and a semi-colon (;) but haven’t been able to test this out (any takers?).
So, in 2012 we have these two issues that need to get patched asap as they present massive risk to core infrastructure. How does IBM communicate this information? They call their engineering contacts and tell them to install the patch. Notice, they didn’t call IT security contacts, they straight up called the operations and engineering people, whom have zero sense of risk.
How do I know this? Because people openly discussed it on a mailing list. Of interest are these choice emails:
Yes, IBM was calling customers to install the patch, the day before Christmas to install these emergency patches.
I enjoy this specifically because it calls out the fact that you had to have signed up for a super secret part of IBMs website.
I like this email because it tells us the specific patches (which you’re not supposed to do according to IBM) and demonstrates the old way of thinking when it comes to security and patching.
Sure, take your time it’s not like this was an actual exploitable issue….. oh wait
And finally, this one calls out the fact that it’s not the mainframers who are at fault but the auditors who grew up in a zero day world putting pressure on their unhackable mainframes. Ironically (and because IBM didn’t disclose it) this vulnerability was actively being exploited in the wild at the time the patch was released. Thus the reason for IBM actually calling their user base to patch it.
Now, imagine if this was a Windows server environment. Microsoft, knowing about a breach and issues with IIS, issues a secret patch and calls their clients. Not all clients get a call, not everyone is signed up for the website. So now there are companies that have vulnerabilities they don’t even know about, because Microsoft wanted to keep the issue a secret. Is that an acceptable practice in your enterprise environment? Why is it appropriate for the mainframe?
If the platform is so secure (as stated by IBM) why are they so afraid of releasing this information publicly? Could it be that it’s all a house of cards?