Re: Mainframe hacking?
On Sat, 16 Oct 2010 01:43:40 +, Ted MacNEIL eamacn...@yahoo.ca wrote: Copy to tape or to DASD sequential datasets with appropriate conversion. Since it's designed strictly for ISPF, under TSO, isn't that asking a little much? That's like saying a compare utility doesn't copy files. The TSO TRANSMIT command needs that function of IEBCOPY when a PDS is involved, and RECEIVE needs the reverse function. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 15 Oct 2010 21:58:31 -0700, in bit.listserv.ibm-main you wrote: Actually a lot of the old user and system modification code that is still around was not where we normally exploited things. Mostly it was the newer systems that were shipped with a lot of theoretically unused products, code and other appendages that had for the most part never been installed or was quickly uninstalled in the old days. Installed (and for the most part unused) access and always authorized technology programs in LPA and Linklist were always our goto method. I know that I had a hard time figuring out what was on the system and did we really need it in the 1980s when I was doing Virtual Storage Constraint Relief and that was with a lot fewer products. As Brian says elsewhere in this message there is a lot of dead code (IBM products not activated, etc.) that may well be on our systems. Websphere and other web related systems have a whole new host of vulnerabilities. We have gone from hundreds or thousands of allowed users to possibly millions (large banks, various governments, large retailers, etc.) of users who can sign in and access something on our systems. Think about your credit card provider for example. How vulnerable are the applications? Would compromising Websphere give benefit to those who want to make money? Are we vulnerable to such things as SQL injection and buffer overruns in some of the newer packages? Clark Morris I think that it may be that the newer systems programmers were not as concerned about the stuff that was there because I don't think they ever really took the time to think about what was out there and what impact it had/has and what exposures it can cause. A lot of people seem to feel that the technical people of the current age cannot compare to what came before, but that's not really a fair assumption. If you think about it, z/OS is much more complex than what came before. We used to know what everything did because there was not really that much involved. Sure it was millions of lines of code, but compare that to now. Having met a large number of the old and new systems programmers, I can honestly say that there are many that were very bright, and there still are many new ones that are just as bright. I can remember being at sites that personnel were in charge of subsets of the code (modules IEF to IJK for instance). You just can't do that any more today, and thankfully no one has to. If you were to talk about the requirements of establishing and running a sysplex with some of the old people, you would completely blow their minds, just as if you were to try to explain to the systems people today how important the lights on the front of the 370 were to fixing a system problem and getting things going again. The problems are not the personnel, it's the sloppy code and the excess code that is shipped with every installed base. There are many ways into the system with or without RACF. Luckily we with the keys are trust-able. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
snip And, what can you do about 20 year old code with no comments? unsnip- That depends on how much time you can spend researching 20-year-old interfaces :-) My inclination would be to chuck it into the nearest bit-bucket and redesign/recode as needed. WITH DOCUMENTATION! Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I think that there is another bit of wisdom there. First, I don't think mainframe hacking would be very profitable. In my opinion information would be the most valuable, and an inside job would be easiest. Give someone, perhaps disgruntled, a large sum of money and the information might be bought. The thing that interests me is the fact that both user and system people are becoming less and less experienced. I'm even seeing that happen now in most of the places I visit. Some places have heavily customized systems, with lots of system exits. They will soon be in serious horse hockey, and many already are. So if someone should make use of certain resources, some of the most valuable coming from people with the most experience on these lists, and learn the internals, there may be gold in them thar hills. So to speak. :-) Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, October 15, 2010 2:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? --unsnip Lindy, you're correct but I think you forgot the corrolary: as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems. True, we see less and less suspect SVC code and more and more PC code that might be suspect. But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I don't think we can call it hacking if IBM uses such techniques to implement simulators, emulators, virtualization, etc. But other vendors' using the same techniques in order to make it easier for their products to achieve authorization is a different matter, IMHO. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Thursday, October 14, 2010 6:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? Even earlier than that, IBM used a comnination of hardware and software intercepts based around Program Interrupts to implement the Commercial Feature on the 360/44. I still have a copy of the Emulator that was loaded into special areas of 360/44 core that finished the process of implementing thie Commercial Feature, as well as a few other instructions in the General Instruction Set. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
IEBCOPY was developed in the early- to mid-1960s, when EXCP appendages were the leading edge way to do cruel and unusual things in low-level I/O. Such has not been the case since the advent of MVS/XA and a redesigned IOS in 1983. New, or older and still strategic, products typically use the latest and greatest techniques. It would appear that IBM does not yet consider redesigning the 45-year-old IEBCOPY as strategic. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, October 14, 2010 7:24 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1.SVCLIB. Yes. That's true. But, what about the fact that work-alikes (eg: SPFCOPY) don't need them? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Barry, What do you think of contacting Lindy off list to see if we can't get into contact with heavily customized systems with lots of system exits. KRI could help them with their technical expertise... Ray On 10/15/2010 06:46 AM, Lindy Mayfield wrote: I think that there is another bit of wisdom there. First, I don't think mainframe hacking would be very profitable. In my opinion information would be the most valuable, and an inside job would be easiest. Give someone, perhaps disgruntled, a large sum of money and the information might be bought. The thing that interests me is the fact that both user and system people are becoming less and less experienced. I'm even seeing that happen now in most of the places I visit. Some places have heavily customized systems, with lots of system exits. They will soon be in serious horse hockey, and many already are. So if someone should make use of certain resources, some of the most valuable coming from people with the most experience on these lists, and learn the internals, there may be gold in them thar hills. So to speak. :-) Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, October 15, 2010 2:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? --unsnip Lindy, you're correct but I think you forgot the corrolary: as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems. True, we see less and less suspect SVC code and more and more PC code that might be suspect. But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 10/15/2010 5:46 AM, Lindy Mayfield wrote: I think that there is another bit of wisdom there. First, I don't think mainframe hacking would be very profitable. In my opinion information would be the most valuable, and an inside job would be easiest. Give someone, perhaps disgruntled, a large sum of money and the information might be bought. The thing that interests me is the fact that both user and system people are becoming less and less experienced. I'm even seeing that happen now in most of the places I visit. Some places have heavily customized systems, with lots of system exits. They will soon be in serious horse hockey, and many already are. So if someone should make use of certain resources, some of the most valuable coming from people with the most experience on these lists, and learn the internals, there may be gold in them thar hills. So to speak. :-) Lindy Go for it, Lindy! -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
My apologies to this the list. I did not mean for this email to be sent there.. On 10/15/2010 07:42 AM, Ray Overby wrote: Barry, What do you think of contacting Lindy off list to see if we can't get into contact with heavily customized systems with lots of system exits. KRI could help them with their technical expertise... Ray On 10/15/2010 06:46 AM, Lindy Mayfield wrote: I think that there is another bit of wisdom there. First, I don't think mainframe hacking would be very profitable. In my opinion information would be the most valuable, and an inside job would be easiest. Give someone, perhaps disgruntled, a large sum of money and the information might be bought. The thing that interests me is the fact that both user and system people are becoming less and less experienced. I'm even seeing that happen now in most of the places I visit. Some places have heavily customized systems, with lots of system exits. They will soon be in serious horse hockey, and many already are. So if someone should make use of certain resources, some of the most valuable coming from people with the most experience on these lists, and learn the internals, there may be gold in them thar hills. So to speak. :-) Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, October 15, 2010 2:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? --unsnip Lindy, you're correct but I think you forgot the corrolary: as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems. True, we see less and less suspect SVC code and more and more PC code that might be suspect. But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Really ? Would never have guessed. Been there, done that. Shane ... On Fri, 15 Oct 2010 08:05:39 -0500 Ray Overby wrote: My apologies to this the list. I did not mean for this email to be sent there.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Ray Overby wrote: My apologies to this the list. I did not mean for this email to be sent there.. Apology accepted of course. For three and half nanoseconds, it seemed you want to 'hack' into this very discussion list... ;-D ;-D ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Serious question. Who, consulting companies, IBM consultants or partners? Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ray Overby Sent: Friday, October 15, 2010 3:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? Barry, What do you think of contacting Lindy off list to see if we can't get into contact with heavily customized systems with lots of system exits. KRI could help them with their technical expertise... Ray -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 10/15/2010 7:20 AM, Lindy Mayfield wrote: I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Serious question. Who, consulting companies, IBM consultants or partners? Lindy Most management will ignore it until it's too late and then declare it's time to move off the mainframe. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield Sent: Friday, October 15, 2010 8:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Serious question. Who, consulting companies, IBM consultants or partners? Lindy My manager has already been addressing this. We have greatly reduced the number of exits. And we try to use products to do work instead of in-house. As an example, we use CA-OPS/MVS's ability to do IEFUTL functionality for our UTL work instead of a hand coded IEFUTL exit. We also use it to trap the SMF switch to issue the START SMFDUMP command instead of IEFU29. We have a JES2 exit 20; IKJEFF10 (in-house written by me); IKJEFF53 (IBM example); IEFACTRT (IBM example); ARCTVEXT (CA1 example); FTCHKCMD (example modified to make IBM's ftp server respond to some of RUNTCP's commands). But who will do this? - I'd be open to helping sometime. But only for enough pay to make it worth my while to mess with 1099 income reporting. I did the consultant thing some time ago and did not enjoy the paperwork with the IRS. But I don't want to be too successful! Don't want to reach the magic $250,000/yr income and be classified as rich. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Rick brings up a good point: /But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist./ As I see it there are two parts to this. Vendor testing prior to shipping code and Vendor response when problems are reported in the field. I can't really address what Vendors are doing for testing prior to shipping code but I do have experience with reporting zero day vulnerabilities to Vendors when their code is in the field. Zero day vulnerabilities means the Vendor was not aware of the problem before it was reported. The number of vulnerabilities in the latest releases of z/OS (this would include the ISV code) is much higher than most people realize. This implies that whatever testing being done by Vendors is not identifying these problems. When reporting these problems to a Vendor you better hope that they have some policy about repairing these types of problems. IBM has a written policy on integrity (See IBM statement of integrity) and when this type of problem is reported to IBM they have to date fixed or are working on fixing the problem in my experience. Some other Vendors also fall into this category. However, I have had some less than enthusiastic responses from some other Vendors. Rick also makes a couple of other points: /as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems/. I think it is true that there are less people today who have this type of expertise than in the past (in the US at least). However I don't think that it is getting harder to compromise z/OS. For example, I recently (z/OS 1.9 time frame) came up an 11 line rexx exec that exploited a vulnerability with some ISV code. In this case the rexx exec was able to dynamically give any TSO user the RACF privileged authority. This means that access to any RACF protected resource would be allowed with no RACF logging (Note that I could have developed an exploit for CA-TSS or CA-ACF2 instead of RACF if required. These types of exploits are independent of the ESM (external security manager)).While it is true that a higher level of expertise was required to initially develop the exploit if the exploit was published (for example on the internet) the level of expertise required to use the exploit would be much less. I think most, if not all z/OS installations have people that can type in an 11 line rexx exec and execute it. On 10/14/2010 18:48 PM, Rick Fochtman wrote: ---snip-- The whole point, I think, is to get it by the system's guys. Not sure how to do that. So much easier on Windows. Still there are coming more and more freeware MVS utilities, like showmvs. (It can run authorized I think, yes?) I don't think that it is that carefully audited, somebody could slip something into there. Or some ported tool like TSOCMD. It would be very unlikely that something like that would get by you guys, but good sysprogs are getting fewer and fewer, and, as an inside job perhaps, someone may easily trick an admin into installing some useful utility that has been compromised. --unsnip Lindy, you're correct but I think you forgot the corrolary: as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems. True, we see less and less suspect SVC code and more and more PC code that might be suspect. But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
APF (was: Mainframe hacking?)
On Thu, 14 Oct 2010 19:54:44 -0500, John McKown wrote: The SPFCOPY that I remember simply used a magic SVC to set the APF on before calling IEBCOPY and back off afterwards. I've heard of this. And that the magic SVC did extensive checkinf of control blocks to verify that it was properly called by ISPF. Bot that it was possible, in principle, to fool it. But why? couldn't it just perform the equivalent of address TSO 'CALL *(IEBCOPY)' ... and let TSO handle the integrity? Did PDSFAST require APF authorization? On Oct 14, 2010 7:23 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1... Yes. That's true. Didn't other plies in this thread say that the third-party alternatives don't use archaic appendages, thus don't require AC=1. Is there a third-party IEBCOPY replacement that is runs AC=0 and is interface-compatible? If a programmer specified such a product as the COPY utility for SMP/E, and avoided WAIT in DDDEFs, could he run SMP/E in unauthorized state? Would this avoid the unspecified integrity hazard that mandates bizarre RACF authorization for use of SMP/E? I would hope so; isn't it IBM's integrity statement that any way in which a non-authorized program can threaten system integrity will be fixed at highest priority. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
At 10/14/2010 07:54 PM, Rick Fochtman wrote: snip For example, why do IDCAMS and IEBCOPY have to be authorized? The IEBCOPY replacement doesn't have to be authorized. Would it be worthwhile for both vendors and users to see what they can do to reduce the amount of code that has to be authorized? [snip] Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1.SVCLIB. When IEBCOPY was converted from MVT to MVS, the developers at the time wanted to make it run as fast as possible. Also, IEBCOPY might have been a good vehicle for testing/experimenting with those wonderful new interfaces. Certainly, there is no technical reason in the world (at least I don't know of one) why a functionally identical could not be written that did not require authorization... It's probably a matter of It ain't broke, so for god's sake don't fix it! Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Fri, Oct 15, 2010 at 10:43 AM, Ricc Harding ricc.hard...@gmail.comwrote: SPFCopy's magic SVC went thru several iterations to make it secure too. It was one of those SVC's that was written to be serially secure but in a multi-tasking environment when two or more tasks could be set up to run concurrently, then a serially secure task, doing what it did in a secure manner (if it was the only thing running) allowed everyone running in the address space to participate in the authorization. STATUS STOP became very much a requirement for those serially secure tasks to remain such. The truth is that there is no such thing as a secure magic SVC (or PC) no matter how creative its authors are. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I don't think there is shortages in systems programmers yet. I know the last 4 years, there has been maybe 3 or 4 jobs open in the Milwaukee area, out of I figure about 10 z/OS shops. Each opening had plenty of applicants, as far as I can figure. In 5 to 10 years, that could all change, but by then I'll be retired and won't care! There probably are shortages in some areas, and places that most people don't want to move to. -- Eric Bielefeld Systems Programmer Lindy Mayfield lindy.mayfi...@ssf.sas.com wrote: I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Serious question. Who, consulting companies, IBM consultants or partners? Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 10/15/2010 9:28 AM, Paul Gilmartin wrote: On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote: On 10/15/2010 7:20 AM, Lindy Mayfield wrote: I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Most management will ignore it until it's too late and then declare it's time to move off the mainframe. But why, when hit by a Windows exploit, don't they likewise say, It's time to move off Windows._ -- gil Because most managers today know windows and they accept poor security and performance as inevitable; they aren't even aware of alternatives. Why? Because IBM is not telling the story. And, sad to say, neither are we. We are not bragging about the amazing features of z/OS (of course, you gotta' do this in a style of is this cool, or what? as opposed to squatty boxes stink, look at what we do under z/OS). So, take some time to reflect on how this would best be done in your shop. For example, Paul, you would probably not want to extol JCL; on the other hand you would praise the ability to run both z/OS and UNIX (in the guise of z/OS UNIX System Services) on one box. Don't hate EBCDIC, be amazed at the ability to work with EBCDIC, ASCII, and Unicode all on one system. Caveat: of course, there are exceptions to all of the above assertions, and I don't want to belittle those IBM'ers and IBM-main residents who are telling the story inside their companies; nor do I want to disparage those managers who understand the role the mainframe has in their organization. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Each and every time I try to point out new or good points about the z, Iget the same response: It is simply not cost effective! or more simply: It costs too much!. This despite the __documented fact__ that the z does over 80% or the production work at less than 50% of the IT budget. Of course, part of the budget goes for things which cannot be done on the z. Such as desktop PCs running Windows. But they won't consider Linux instead. It would cost too much to retrain. And, they say, it won't work seamlessly with MS Exchange. Which is locked in because management is convinced that it is uniquely irreplaceable. Also, a Linux desktop won't insert proprietary MS software product function . John McKown Maranatha! On Oct 15, 2010 10:48 AM, Steve Comstock st...@trainersfriend.com wrote: On 10/15/2010 9:28 AM, Paul Gilmartin wrote: On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock ... Because most managers today know windows and they accept poor security and performance as inevitable; they aren't even aware of alternatives. Why? Because IBM is not telling the story. And, sad to say, neither are we. We are not bragging about the amazing features of z/OS (of course, you gotta' do this in a style of is this cool, or what? as opposed to squatty boxes stink, look at what we do under z/OS). So, take some time to reflect on how this would best be done in your shop. For example, Paul, you would probably not want to extol JCL; on the other hand you would praise the ability to run both z/OS and UNIX (in the guise of z/OS UNIX System Services) on one box. Don't hate EBCDIC, be amazed at the ability to work with EBCDIC, ASCII, and Unicode all on one system. Caveat: of course, there are exceptions to all of the above assertions, and I don't want to belittle those IBM'ers and IBM-main residents who are telling the story inside their companies; nor do I want to disparage those managers who understand the role the mainframe has in their organization. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersf... For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu w... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Fri, 15 Oct 2010 10:28:21 -0500, Paul Gilmartin paulgboul...@aim.com On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote: Most management will ignore it until it's too late and then declare it's time to move off the mainframe. But why, when hit by a Windows exploit, don't they likewise say, It's time to move off Windows._ The Redmond propaganda machine has been quite effective. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
SPFCopy's magic SVC went thru several iterations to make it secure too. It was one of those SVC's that was written to be serially secure but in a multi-tasking environment when two or more tasks could be set up to run concurrently, then a serially secure task, doing what it did in a secure manner (if it was the only thing running) allowed everyone running in the address space to participate in the authorization. STATUS STOP became very much a requirement for those serially secure tasks to remain such. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Fri, 15 Oct 2010 09:48:01 -0600, Steve Comstock wrote: Don't hate EBCDIC, be amazed at the ability to work with EBCDIC, ASCII, and Unicode all on one system. EBCDIC is easy enough to use. It's just too difficult to avoid. The OS is biased. A fair operating system would let me NFS mount my Solaris data sets xlat(N) and live in ASCII, with no funky tagging of files or autoconversion. Let me tag and autocovert my Legacy data sets when I need the facility. Even as programmers can operate on the Legacy side and deal with ASCII only when necessary, I'd like to operate in ASCII and deal with EBCDIC only when necessary. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote: On 10/15/2010 7:20 AM, Lindy Mayfield wrote: I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Most management will ignore it until it's too late and then declare it's time to move off the mainframe. But why, when hit by a Windows exploit, don't they likewise say, It's time to move off Windows._ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking? (IEBCOPY)
Customers who are need to pay for CA-PDSMAN or SEA PDSFAST just to get acceptable performance when supporting large environments may disagree about IEBCOPY not being broken. Best Regards, Sam Knutson, GEICO System z Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... -Original Message- When IEBCOPY was converted from MVT to MVS, the developers at the time wanted to make it run as fast as possible. Also, IEBCOPY might have been a good vehicle for testing/experimenting with those wonderful new interfaces. Certainly, there is no technical reason in the world (at least I don't know of one) why a functionally identical could not be written that did not require authorization... It's probably a matter of It ain't broke, so for god's sake don't fix it! Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APF (was: Mainframe hacking?)
On 10/15/2010 09:27 AM, Paul Gilmartin wrote: On Thu, 14 Oct 2010 19:54:44 -0500, John McKown wrote: The SPFCOPY that I remember simply used a magic SVC to set the APF on before calling IEBCOPY and back off afterwards. I've heard of this. And that the magic SVC did extensive checkinf of control blocks to verify that it was properly called by ISPF. Bot that it was possible, in principle, to fool it. But why? couldn't it just perform the equivalent of address TSO 'CALL *(IEBCOPY)' ... and let TSO handle the integrity? ... -- gil It used to be the case that since ISPF didn't run authorized that it was impossible to directly invoke authorized utilities from within ISPF dialogs - hence the IEBCOPY kludge. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APF (was: Mainframe hacking?)
ISPF doesn't run APF. It uses the TSO IKJEFTSR function to run properly authorized programs and commands. At least, I think that's how it works. -- John McKown Maranatha! Sent from my Vibrant Android phone. On Oct 15, 2010 1:03 PM, Joel C. Ewing jcew...@acm.org wrote: On 10/15/2010 09:27 AM, Paul Gilmartin wrote: On Thu, 14 Oct 2010 19:54:44 -0500, John McKown wr... ... -- gil It used to be the case that since ISPF didn't run authorized that it was impossible to directly invoke authorized utilities from within ISPF dialogs - hence the IEBCOPY kludge. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / si... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
As a new z/OS applications developer I'm curious as to what types of things use custom user exits et al for. From what I've heard from our sysprogs, our philosophy is to never use inhouse written user exits. Of course there are vendor supplied user exits, but the only inhouse user exit I know of that we use is CICS XDLIPRE, and that's only in our test regions. (And interestingly we just this week ran in to issues with XDLIPRE cause AUEP abends!) Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 10/15/2010 at 7:20 AM, in message 0377b9a583fd0e4aacd676ee33ee994b345e5...@sdkmail13.emea.sas.com, Lindy Mayfield lindy.mayfi...@ssf.sas.com wrote: I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Serious question. Who, consulting companies, IBM consultants or partners? Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ray Overby Sent: Friday, October 15, 2010 3:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? Barry, What do you think of contacting Lindy off list to see if we can't get into contact with heavily customized systems with lots of system exits. KRI could help them with their technical expertise... Ray -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APF (was: Mainframe hacking?)
On Fri, 15 Oct 2010 13:07:54 -0500, John McKown john.archie.mck...@gmail.com wrote: ISPF doesn't run APF. It uses the TSO IKJEFTSR function to run properly authorized programs and commands. At least, I think that's how it works. True, but IKEFTSR did not exist back when the SPFCOPY SVC was needed. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 15 Oct 2010 05:28:21 -0700, in bit.listserv.ibm-main you wrote: IEBCOPY was developed in the early- to mid-1960s, when EXCP appendages were the leading edge way to do cruel and unusual things in low-level I/O. Such has not been the case since the advent of MVS/XA and a redesigned IOS in 1983. New, or older and still strategic, products typically use the latest and greatest techniques. It would appear that IBM does not yet consider redesigning the 45-year-old IEBCOPY as strategic. I am more interested in the idea that we should be urging the reduction of need to run authorized as reducing security exposures. Also what security exposures have been added by the way ziip and zap work? Clark Morris Bill Fairchild Rocket Software rest snipped -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APF (was: Mainframe hacking?)
On 15 October 2010 14:03, Joel C. Ewing jcew...@acm.org wrote: On 10/15/2010 09:27 AM, Paul Gilmartin wrote: On Thu, 14 Oct 2010 19:54:44 -0500, John McKown wrote: The SPFCOPY that I remember simply used a magic SVC to set the APF on before calling IEBCOPY and back off afterwards. I've heard of this. And that the magic SVC did extensive checkinf of control blocks to verify that it was properly called by ISPF. Bot that it was possible, in principle, to fool it. But why? couldn't it just perform the equivalent of address TSO 'CALL *(IEBCOPY)' ... and let TSO handle the integrity? -- gil It used to be the case that since ISPF didn't run authorized that it was impossible to directly invoke authorized utilities from within ISPF dialogs - hence the IEBCOPY kludge. Even stronger - before that it used to be the case that there was no support at all for running APF authorized application programs under TSO. The Terminal Monitor Program itself was not authorized, and so could not invoke anything authorized other than by kludge SVCs and the like. (There were, of course, TSO related *services* that ran authorized, even back in the MVT days, most notably the FIB stuff (SUBMIT/STATUS/CANCEL) and OPER. But none of these involved command processor code running in an authorized state. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-snip--- Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1.SVCLIB. Yes. That's true. But, what about the fact that work-alikes (eg: SPFCOPY) don't need them? --unsnip-- In my experience, SPFCOPY lacks some of the functions of IEBCOPY. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Since the 360/44 emulator broke in during the PSW-swap, it did require hardware modification. How other emulators, simulators, etc. get into action is information I don't have, or have any experience with, so I can't comment. YMMV. Rick --- I don't think we can call it hacking if IBM uses such techniques to implement simulators, emulators, virtualization, etc. But other vendors' using the same techniques in order to make it easier for their products to achieve authorization is a different matter, IMHO. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Thursday, October 14, 2010 6:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? Even earlier than that, IBM used a comnination of hardware and software intercepts based around Program Interrupts to implement the Commercial Feature on the 360/44. I still have a copy of the Emulator that was loaded into special areas of 360/44 core that finished the process of implementing thie Commercial Feature, as well as a few other instructions in the General Instruction Set. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
In my experience, SPFCOPY lacks some of the functions of IEBCOPY. Since it just does copies under the '3' utilities, which of these missing functions are needed? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
--snip I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Serious question. Who, consulting companies, IBM consultants or partners? -unsnip I would say that the first step should be to have ALL customization, exits, etc. very well documented, both their action and the reasons for their actions. The more detail, the better. Given that information at your site, you should be able to choose whatever technical assistance you might require from any of the three groups you've named. Documentation is rather like sex; any is goodness; when it's really good, it's GREAT!. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
---snip--- Rick brings up a good point: /But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist./ As I see it there are two parts to this. Vendor testing prior to shipping code and Vendor response when problems are reported in the field. I can't really address what Vendors are doing for testing prior to shipping code but I do have experience with reporting zero day vulnerabilities to Vendors when their code is in the field. Zero day vulnerabilities means the Vendor was not aware of the problem before it was reported. The number of vulnerabilities in the latest releases of z/OS (this would include the ISV code) is much higher than most people realize. This implies that whatever testing being done by Vendors is not identifying these problems. When reporting these problems to a Vendor you better hope that they have some policy about repairing these types of problems. IBM has a written policy on integrity (See IBM statement of integrity) and when this type of problem is reported to IBM they have to date fixed or are working on fixing the problem in my experience. Some other Vendors also fall into this category. However, I have had some less than enthusiastic responses from some other Vendors. Rick also makes a couple of other points: /as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems/. I think it is true that there are less people today who have this type of expertise than in the past (in the US at least). However I don't think that it is getting harder to compromise z/OS. For example, I recently (z/OS 1.9 time frame) came up an 11 line rexx exec that exploited a vulnerability with some ISV code. In this case the rexx exec was able to dynamically give any TSO user the RACF privileged authority. This means that access to any RACF protected resource would be allowed with no RACF logging (Note that I could have developed an exploit for CA-TSS or CA-ACF2 instead of RACF if required. These types of exploits are independent of the ESM (external security manager)).While it is true that a higher level of expertise was required to initially develop the exploit if the exploit was published (for example on the internet) the level of expertise required to use the exploit would be much less. I think most, if not all z/OS installations have people that can type in an 11 line rexx exec and execute it. unsnip-- Ray, I won't ask you for the REXX code but I hope you've reported this to IBM. Just in case the ISV is exploiting a hole they've found and haven't reported. I firmly believe that ANY integrity exposure should be reported to IBM, as the primary software provider, as well as to any ISV that might be involved, however periphally. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
---snip--- On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote: On 10/15/2010 7:20 AM, Lindy Mayfield wrote: I say heavily customized but that's only a few of my customers. Just about every mainframe shop I've seen, especially those that have been around a while, have enough customization, exits, etc. to be in trouble soon. And, honestly, who will they call? Most management will ignore it until it's too late and then declare it's time to move off the mainframe. But why, when hit by a Windows exploit, don't they likewise say, It's time to move off Windows._ --unsnip-- I once had a guy explain it to me this way: when a manager has complete control over the computer on his desktop, including the power on/off functions, he feels much less vulnerable to outside malevolence. In short, he feels much more in control, never mind that it's a false sense of security. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I would say that the first step should be to have ALL customization, exits, etc. very well documented, both their action and the reasons for their actions. That would have been great 20-30 years ago, but what do you do with the lack of existing doc? Many times it's missing, or the coder didn't think it was important. I don't document code! It was hard to write; it should be hard to read! - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
snip- As a new z/OS applications developer I'm curious as to what types of things use custom user exits et al for. From what I've heard from our sysprogs, our philosophy is to never use inhouse written user exits. Of course there are vendor supplied user exits, but the only inhouse user exit I know of that we use is CICS XDLIPRE, and that's only in our test regions. (And interestingly we just this week ran in to issues with XDLIPRE cause AUEP abends!) unsnip--- Frank, I've used exits to enforce JCL standards, (JES2 and TSO), display information on SYSLOG and JOBLOGs (IEFAACTRT and IEFU8x) and impose a more restrictive set of rules on password formation in RACF. My use was by no means exhaustive but those are a few of the things that exits can do for your shop. We also used an exits to automatically strt SMFDUMP whenever the SMV datasets switched because the current one got full, or the operator issued a SWITCH command. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
---snip-- In my experience, SPFCOPY lacks some of the functions of IEBCOPY. Since it just does copies under the '3' utilities, which of these missing functions are needed? ---unsnip-- Copy to tape or to DASD sequential datasets with appropriate conversion. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-snip- I would say that the first step should be to have ALL customization, exits, etc. very well documented, both their action and the reasons for their actions. That would have been great 20-30 years ago, but what do you do with the lack of existing doc? Many times it's missing, or the coder didn't think it was important. I don't document code! It was hard to write; it should be hard to read! unsnip-- I was trained, and will always maintain, that there is no possible excuse for not inserting meaningful comments into my code. After all, I might be the guy who has to unbutton it and fix it sometime in the future. I might not remember the details that I had in mind when I originally coded it. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I agree that notification of the code owner (ISV or IBM) is the right thing to do for integrity based vulnerabilities. Unlike vulnerabilities that are based upon configuration, IPL parameters or security settings integrity vulnerabilities cannot be remediated by the installation. You have to go back to the code owner in order to fix the problem. For the rexx exec example: -The vulnerability that the rexx exec exploited was the result of a poor design choice by a Vendor. Once the Vendor followed standards as defined by IBM the vulnerability was eliminated. IBM was not notified in this case because 1) It was not IBM code 2) We verified the original vulnerability was eliminated after applying Vendor provided remediation. -Hypothetically speaking, if code was identified that takes advantage of an integrity based vulnerability in order to gain authorization instead of using documented interfaces under installation control, then yes, I think that both code owners should be notified. On 10/15/2010 17:55 PM, Rick Fochtman wrote: ---snip--- Rick brings up a good point: /But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist./ As I see it there are two parts to this. Vendor testing prior to shipping code and Vendor response when problems are reported in the field. I can't really address what Vendors are doing for testing prior to shipping code but I do have experience with reporting zero day vulnerabilities to Vendors when their code is in the field. Zero day vulnerabilities means the Vendor was not aware of the problem before it was reported. The number of vulnerabilities in the latest releases of z/OS (this would include the ISV code) is much higher than most people realize. This implies that whatever testing being done by Vendors is not identifying these problems. When reporting these problems to a Vendor you better hope that they have some policy about repairing these types of problems. IBM has a written policy on integrity (See IBM statement of integrity) and when this type of problem is reported to IBM they have to date fixed or are working on fixing the problem in my experience. Some other Vendors also fall into this category. However, I have had some less than enthusiastic responses from some other Vendors. Rick also makes a couple of other points: /as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems/. I think it is true that there are less people today who have this type of expertise than in the past (in the US at least). However I don't think that it is getting harder to compromise z/OS. For example, I recently (z/OS 1.9 time frame) came up an 11 line rexx exec that exploited a vulnerability with some ISV code. In this case the rexx exec was able to dynamically give any TSO user the RACF privileged authority. This means that access to any RACF protected resource would be allowed with no RACF logging (Note that I could have developed an exploit for CA-TSS or CA-ACF2 instead of RACF if required. These types of exploits are independent of the ESM (external security manager)).While it is true that a higher level of expertise was required to initially develop the exploit if the exploit was published (for example on the internet) the level of expertise required to use the exploit would be much less. I think most, if not all z/OS installations have people that can type in an 11 line rexx exec and execute it. unsnip-- Ray, I won't ask you for the REXX code but I hope you've reported this to IBM. Just in case the ISV is exploiting a hole they've found and haven't reported. I firmly believe that ANY integrity exposure should be reported to IBM, as the primary software provider, as well as to any ISV that might be involved, however periphally. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Copy to tape or to DASD sequential datasets with appropriate conversion. Since it's designed strictly for ISPF, under TSO, isn't that asking a little much? That's like saying a compare utility doesn't copy files. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I was trained, and will always maintain, that there is no possible excuse for not inserting meaningful comments into my code. After all, I might be the guy who has to unbutton it and fix it sometime in the future. I agree with you. But, obviously, not everybody did. That was my point. And, what can you do about 20 year old code with no comments? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Frank The issue - the word used correctly for once! - with exits - or perhaps just one of the issues with exits - is that they, in effect, become part of the executing code of the product. And the issue - still using the word in one of its correct meanings - with executing code is that somebody has to maintain it. When you buy a product, you buy a promise that it will do what the salesman said it can do. I presume - although it's not a situation I have encountered in my sheltered existence - that if a product happens actually to exploit an exit provided by another product - presumably with some sort of provision in the implementation that other products can also exploit the same exit - starting to get tricky isn't it? - the promise extends to the exit code. If your installation considers implementing an exit, just as with any in-house code, a responsible function within the installation needs to own the exit code so that, even if the author is let go, there will always be someone among the suits who takes care that the knowledge needed to support that little exit is also not lost - just as I would expect applies to massive application suites. It's because needing to establish that responsibility in an installation can become rather tricky that some installation do not even contemplate trying to deal with it - your installation seeming to be one. Actually this is an issue with which I - as I mentioned having had a sheltered existence - have not had to deal with directly but it's what I have picked up from those who have and I hope I picked it up more or less correctly. Incidentally, you may be a *new* z/OS application developer but are you not an *old* VSE application developer and isn't there a similar issue in the VSE world? - Interestingly enough regarding exits, VTAM offers some exits as documented in the SNA Customization manual, What's really interesting is that VTAM development has somewhat muddied the water by providing sample exits which become so popular that VTAM development actually committed to maintenance of the supplied sample exits. Two such exits are the ISTEXCCS and ISTEXCSD, essentially dynamic connection definitions - to some extent a function available without needing support from the exit since the exit was introduced - and dynamic LU definitions. There is even some sort of session management exit out there upon which I believe VTAM development smiles benevolently! - On review, I noticed you mentioned CICS. Didn't the CICS autoinstall function start as an exit for customers to use as they thought fit which got transformed into some standard code provided by CICS development - or something like that - not unlike what happened to those VTAM exits? Chris Mason On Fri, 15 Oct 2010 12:28:20 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: As a new z/OS applications developer I'm curious as to what types of things use custom user exits et al for. From what I've heard from our sysprogs, our philosophy is to never use inhouse written user exits. Of course there are vendor supplied user exits, but the only inhouse user exit I know of that we use is CICS XDLIPRE, and that's only in our test regions. (And interestingly we just this week ran in to issues with XDLIPRE cause AUEP abends!) Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Fri, Oct 15, 2010 at 6:02 PM, Rick Fochtman rfocht...@ync.net wrote: ---snip--- On Fri, 15 Oct 2010 07:24:08 -0600, Steve Comstock wrote: But why, when hit by a Windows exploit, don't they likewise say, It's time to move off Windows._ --unsnip-- I once had a guy explain it to me this way: when a manager has complete control over the computer on his desktop, including the power on/off functions, he feels much less vulnerable to outside malevolence. In short, he feels much more in control, never mind that it's a false sense of security. Rick Go into his office, shrink his C drive by 10GB, install Grub and Ubuntu or another Linux desktop, and let him try it. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Actually a lot of the old user and system modification code that is still around was not where we normally exploited things. Mostly it was the newer systems that were shipped with a lot of theoretically unused products, code and other appendages that had for the most part never been installed or was quickly uninstalled in the old days. Installed (and for the most part unused) access and always authorized technology programs in LPA and Linklist were always our goto method. I think that it may be that the newer systems programmers were not as concerned about the stuff that was there because I don't think they ever really took the time to think about what was out there and what impact it had/has and what exposures it can cause. A lot of people seem to feel that the technical people of the current age cannot compare to what came before, but that's not really a fair assumption. If you think about it, z/OS is much more complex than what came before. We used to know what everything did because there was not really that much involved. Sure it was millions of lines of code, but compare that to now. Having met a large number of the old and new systems programmers, I can honestly say that there are many that were very bright, and there still are many new ones that are just as bright. I can remember being at sites that personnel were in charge of subsets of the code (modules IEF to IJK for instance). You just can't do that any more today, and thankfully no one has to. If you were to talk about the requirements of establishing and running a sysplex with some of the old people, you would completely blow their minds, just as if you were to try to explain to the systems people today how important the lights on the front of the 370 were to fixing a system problem and getting things going again. The problems are not the personnel, it's the sloppy code and the excess code that is shipped with every installed base. There are many ways into the system with or without RACF. Luckily we with the keys are trust-able. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Yes. Like one of the previous posters to this thread the company I work for used to offer a service of testing the site's defenses that we called a System Access Security Audit (SASA). This audit was completely unlike our normal System Audit which we still perform. The current System Audit checks the entire system (including security) for problems, performance issues, etc. and offers a lot of advice on what can be done to make things better, but the SASA's weren't concerned with fixing anything, just getting in and obtaining physical proof that we were there. I think we performed a little over 100 of them, and we were NEVER unsuccessful. As you can imagine, we didn't always/ever play by the Marquis of Queensbury rules, actually there were NO rules, but as I said, we were ALWAYS successful. After we had the first few under our belt, we even offered the sites a deal up front where they could choose and option that would get them the audit for free if we were unsuccessful, but pay a premium price for the SASA if we were successful. No sites ever took us up on the double or nothing option. I'm not saying that it was always easy to gain access, but I can't really say that it was overly difficult either. The easiest ones were those that we were allowed (or obtained) physical access to the site. On the other hand, a good portion of the code for VTAM, NCP, SNA and TCP (and several of the main subsystems (CICS, IMS, etc.)) was developed with the help of the people on the team. My expertise came into play once we got access to the hardware via one of the installed teleprocessing systems. Does what we did constitute hacking? I guess it depends on how you look at it. We never destroyed anything (at least not something that we couldn't fix). We didn't do it for free, and no small animals were harmed in the process. Several people were VERY unhappy with finding out they were vulnerable but I don't think anyone was ever fired for it. I think what may have upset people most was that we had to tell them that (except for the places that were really screwed up and did something really dumb like left terminals already signed on and open for us) there was almost nothing they could do about making it COMPLETELY secure in the future. No one wants to pay that much, find out they really ARE vulnerable and then be told that, short of shutting off their network and just running BATCH jobs, (although depending on their hardware service vendor and options even that would get us access to their physical tape and DASD hardware), that we would have gotten in and exposed their data regardless of what they did, or will do, in the future. It's not that we didn't show a huge number of places that they COULD make significant changes and improvements that would make it less vulnerable, but time and resources were always on our side. Remember, it's not like the casual teenage kid with a modem and Wii or a PS/3 is going to have a chance of getting in. I was happy when we finally stopped (in 2008) offering the service, it was not exactly what one would term exciting. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Done that many times during security assessments at customers sites. for example, Look at your SYS1.UADS dataset and compare it to RACF. You probably will find users that are defined in your UADS dataset, but not in RACF. More then that, IBM's ships UADS dataset with few users that probably not defined in your racf... There are many other ways we use, but this is not the proper place to discuss them ;-) ITschak On Thu, Oct 14, 2010 at 7:14 AM, Ron Hawkins ron.hawkins1...@sbcglobal.netwrote: Ed, Your dates may be a little out. The site where I was an Operator turned on RACF in 1983. I remember because we were able to browse SYS1.UADS and get everyone's passwords after the conversion. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, October 13, 2010 9:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Mainframe hacking? --- On Wed, 10/13/10, Ricc Harding ricc.hard...@gmail.com wrote: From: Ricc Harding ricc.hard...@gmail.com Subject: Re: Mainframe hacking? To: IBM-MAIN@bama.ua.edu Date: Wednesday, October 13, 2010, 3:56 PM When I worked for a large computer manufacturing company in 1984, I would go ---SNIP- Were the shops using any security product ie RACF/ACF2/Top Secret ?I suspect at that point in time they probably did not. I certainly did not know of any installations that were using them, except perhaps 1 and I think that one got the ACF/2 free (UIC). Also I think at that time from my rather poor memory was that even with a security package the systems were just not locked as they should have been. Somewhere in the late 80's (if memory serves me) companies really got serious about security. Of course if people posted the passwords with stickem notes then all bets are off on any security package. My vague recollection is that the first few years of RACF were pretty bad (for security) I just remember hearing people saying RACF can't ddo this or that and * could. My impression of these complaints were at best poor as even the product that claimed to be able to do the requested item was at best iffy and was very prone PTF retrofits and zaps on top of IBM modules. I am not so much as defending RACF (or any of the other products) as saying IBM had not put in SAF entirely every where it needed to go. I guess I would make this statement as far as any security product. If IBM doesn't make the insertion of the SAF call trying to insert any vendors codes is doomed to failue. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I didn't see anyone explicitly mention social engineering. IMO this may be an easier way to get a not-very-technical user's id, but then you are back to how to hack with a normal user TSO account. But if a system guy gave out a password for an reason then, well, you know. What about digging through the trash? Dropping some USB sticks around with interesting programs on them? A few people mentioned some few months back how to get a program authorized from a non-authorized library (or something like that), but nobody gave any details. For sure no script kiddies should ever get in, and if they did they wouldn't know what to do. One thing I didn't see in this thread, was what is the purpose of this hacking. What is to be gained? Sensitive information would be one thing I can think of. Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Wed, 2010-10-13 at 18:38 -0400, Rick Fochtman wrote: I ALWAYS left the IBMUSER active on the system but the first thing I also did was to change to password to some very obscure value. A *very* long time ago, before a few ibm-mainers were born, there was an early public-access packet switching network named Telenet. You could point your modem at a local phone number, type in the five-or-six digit number of a Telenet subscriber, and be connected to their system wherever it may be. You could stay up all night typing in random subscriber IDs to see what you would get. It didn't take long to discover that the first three digits of a subscriber ID was the telephone area code of the subscriber. That cut down on the search space quite a bit. Area code 212 (New York City) was a target-rich environment! There were a fair number of TSO systems that were Telenet-attached, and some of those had IBMUSER accounts with default or stupid passwords. (That particular complacency wasn't limited to MVS administrators. There were other systems, foreign to me, which permitted easy access.) No, I never stayed long; got the heck OUT of there in fact. Login... holy $#!+... logoff. What were they thinking? -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
At 10/13/2010 10:26 AM, Greg Shirey wrote: I liked this article, and it's fairly recent. (Jan 2010) http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1 Greg I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F23465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
What would constitute a root kit for MVS? Perhaps an SVC with some hidden functionality? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 5:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F23465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-Some code that is executing in an authorized state - Supervisor state - PSW key 0-7 - Ability to issue MODESET SVC (APF authorized) -This code would have one of the following flaws: - Store into requester provided storage address while in an authorized state (usually means running in a system psw key (0-7)) - Branch to a requester provided storage address - Returning control to the requester in an authorized state SVCs, PC routines, and system exits all would have this potential. On 10/14/2010 10:43 AM, Lindy Mayfield wrote: What would constitute a root kit for MVS? Perhaps an SVC with some hidden functionality? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 5:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F23465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
d...@lists.duda.com (David Andrews) writes: You could stay up all night typing in random subscriber IDs to see what you would get. It didn't take long to discover that the first three digits of a subscriber ID was the telephone area code of the subscriber. That cut down on the search space quite a bit. Area code 212 (New York City) was a target-rich environment! re: http://www.garlic.com/~lynn/2010n.html#73 Mainframe hacking in 90s and there were summaries of wardialing ... dialing every number in an area code/region ... looking for modems ... and then taking signatures of the modems the connected systems (some areas had 3% of numbers with some sort of modem connection). in the late 90s, with the PDD-63 http://en.wikipedia.org/wiki/Critical_Infrastructure_Protection there was some amount spent in the financial industry meetings (in the white house annex) about Y2K remediation ... but a really hot topic was the ISACs (information sharing database of vulnerabilities and exploits) ... which had bunch of stuff ... a lot with mainframe dataprocessing ... since a lot of financial industry is mainframe based. Of major concern (and a lot of discussion) was constructing the ISAC in such a way that it wouldn't be subject to FOIA http://en.wikipedia.org/wiki/Freedom_of_Information_Act_%28United_States%29 Financial ISAC website http://www.fsisac.com/ launced in 1999 http://www.fsisac.com/faq/ since 9/11 ... public facing tends to be much more about terrorists I was tangentially involved with the (original) cal. data breach notification act ... having been brought in to help wordsmith the electronic signature legislation. Several of the participants were heavily involved with consumer privacy issues and had done detailed, indepth surveys and found that the NO.1 issue was identity theft, namely the accound fraud form where cardholder details from data breach was being used by criminals for fraudulent financial transactions. The issue at the time was that little or nothing appeared to being done about the problem (not even being publicized) ... so they seemed to think that the publicity from databreach notifications might motivate the institutions to provide corrective actions and countermeasures. A major issue was that institutions will put in place security measures to counteract bad things (risks) happending to the institutions. The problem with the account fraud scenario ... is that typically the fraudulent financial transactions were against consumer accounts ... not against the institution ... and therefor the institutions had nothing at risk and therefor little motivation to provide security. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I would think it means code that front-ends one of the First Level Interrupt Handlers, rather like the one that CA was using in 1996 (are they still using it?) to front-end program interrupts so that various CA products could easily become authorized by merely executing a particular invalid operation code. Doing this in the program FLIH made disassembling their code a little tricky, because the program new interrupt routine runs with DAT off, so it was not a no-brainer to find and display their code in storage. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield Sent: Thursday, October 14, 2010 10:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? What would constitute a root kit for MVS? Perhaps an SVC with some hidden functionality? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 5:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F23465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Some of this sounds like the magic svcs that I've seen people use for testing. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ray Overby Sent: Thursday, October 14, 2010 6:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? -Some code that is executing in an authorized state - Supervisor state - PSW key 0-7 - Ability to issue MODESET SVC (APF authorized) -This code would have one of the following flaws: - Store into requester provided storage address while in an authorized state (usually means running in a system psw key (0-7)) - Branch to a requester provided storage address - Returning control to the requester in an authorized state SVCs, PC routines, and system exits all would have this potential. On 10/14/2010 10:43 AM, Lindy Mayfield wrote: What would constitute a root kit for MVS? Perhaps an SVC with some hidden functionality? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 5:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F2 3465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
The returning in an authorized state ones are exactly that. The others are typically the result of poor coding and/or design. On 10/14/2010 11:43 AM, Lindy Mayfield wrote: Some of this sounds like the magic svcs that I've seen people use for testing. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ray Overby Sent: Thursday, October 14, 2010 6:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? -Some code that is executing in an authorized state - Supervisor state - PSW key 0-7 - Ability to issue MODESET SVC (APF authorized) -This code would have one of the following flaws: - Store into requester provided storage address while in an authorized state (usually means running in a system psw key (0-7)) - Branch to a requester provided storage address - Returning control to the requester in an authorized state SVCs, PC routines, and system exits all would have this potential. On 10/14/2010 10:43 AM, Lindy Mayfield wrote: What would constitute a root kit for MVS? Perhaps an SVC with some hidden functionality? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 5:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F2 3465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Yes Ed, these sites all had RACF installed and yes, it still required the VTOC data set is RACF protected bit to be flipped for the data set protection call to even be made. The needed resource manager calls became more apparent as the resources which were being protected grew. The ACF2 protectall vs RACF protectnone philosophy soon became the guiding light to making RACF actually usable as a security system by also implementing protectall. However APF authorization still allows the keys to the kingdom with no trace for the clever programmer. And vendor PC calls are now the new point of entry for system penetration attempts since they have all but replaced most of the user written SVC's. The landscape changes but the dirt is still the same. The new hacker's lament might be so many entry points to choose from and so little time to play. Vigilance and automation in security checking are the keys to catching the silly things but the clever programmer still must have the integrity and character to NOT do what they have both the ability and opportunity to do. Quis custodiet ipsos custodes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
... oh, and the software company (front for criminal organization) apparently was selected on the basis of being the low bidder. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
At 10/14/2010 12:24 PM, Chris Craddock wrote: (as Bob knows) it is impossible to create/install a malicious FLIH or SVC or PC without already having the keys to the kingdom anyway. That is the foundation of integrity and the reason why the installation has to appropriately protect system datasets and APF libraries. Well that's just the problem, Chris, isn't it... The keys to the kingdom really are not well guarded. That's what my 2006 post was all about. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
The whole point, I think, is to get it by the system's guys. Not sure how to do that. So much easier on Windows. Still there are coming more and more freeware MVS utilities, like showmvs. (It can run authorized I think, yes?) I don't think that it is that carefully audited, somebody could slip something into there. Or some ported tool like TSOCMD. It would be very unlikely that something like that would get by you guys, but good sysprogs are getting fewer and fewer, and, as an inside job perhaps, someone may easily trick an admin into installing some useful utility that has been compromised. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 7:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? At 10/14/2010 12:24 PM, Chris Craddock wrote: (as Bob knows) it is impossible to create/install a malicious FLIH or SVC or PC without already having the keys to the kingdom anyway. That is the foundation of integrity and the reason why the installation has to appropriately protect system datasets and APF libraries. Well that's just the problem, Chris, isn't it... The keys to the kingdom really are not well guarded. That's what my 2006 post was all about. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
p...@voltage.com (Phil Smith) writes: Long ago and far away, a friend was looking at the VSE microfiche and found an undocumented SVC that stored the top half of a register value in the address contained in the bottom half of the register. He promptly wrote a program that used that SVC to gain control of the system. (He was working at IBM, so this was an internal thing.) re: http://www.garlic.com/~lynn/2010n.html#73 Mainframe hacking? http://www.garlic.com/~lynn/2010n.html#76 Mainframe hacking? at the end of last century there is infamous case of large financial institution (with large number of ATM machines) outsourcing the Y2K remediation of their backend financial transaction processing system to a software company ... which they found out much later was a front for a criminal organization (eventually tripping across some very peculiar pieces of code that would do some stealthy transactions, that could be triggered by very specific combination of entries from ATM machine). oh, and pieces of relative recent linkedin mainframe discussion http://www.garlic.com/~lynn/2010l.html#28 Mainframe Hacking -- Fact or Fiction http://www.garlic.com/~lynn/2010l.html#37 Mainframe Hacking -- Fact or Fiction http://www.garlic.com/~lynn/2010l.html#51 Mainframe Hacking -- Fact or Fiction http://www.garlic.com/~lynn/2010l.html#55 Mainframe Hacking -- Fact or Fiction -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Thu, Oct 14, 2010 at 11:13 AM, Bob Shannon bshan...@rocketsoftware.comwrote: I would think it means code that front-ends one of the First Level Interrupt Handlers That's how Amdahl implemented SE and SP assist years ago. I think IBM did it to implement the IEEE floating point instructions so that they would work on processors that lacked the hardware. Of course these were not malicious implementations. (as Bob knows) it is impossible to create/install a malicious FLIH or SVC or PC without already having the keys to the kingdom anyway. That is the foundation of integrity and the reason why the installation has to appropriately protect system datasets and APF libraries. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Lindy Mayfield wrote: What would constitute a root kit for MVS? Perhaps an SVC with some hidden functionality? Long ago and far away, a friend was looking at the VSE microfiche and found an undocumented SVC that stored the top half of a register value in the address contained in the bottom half of the register. He promptly wrote a program that used that SVC to gain control of the system. (He was working at IBM, so this was an internal thing.) -- ...phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I would think it means code that front-ends one of the First Level Interrupt Handlers That's how Amdahl implemented SE and SP assist years ago. I think IBM did it to implement the IEEE floating point instructions so that they would work on processors that lacked the hardware. Of course these were not malicious implementations. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
hi, if you are interested in details on this concern refer to http://www.fedtke.com/download.htm - select english - select the IT SECURITY FORUM best stephen --- Dr. Stephen Fedtke Enterprise-IT-Security.com Seestrasse 3a CH-6300 Zug Switzerland Tel. ++41-(0)41-710-4005 www.enterprise-it-security.com ++NEWS++ SF-LoginHood provides state-of-the-art password, phrase and login security for z/OS ++NEWS++ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-The sad news is that integrity exposures exist today in every z/OS system. There is no need to install anything other than what you already have installed. -These integrity exposures have already gotten past the system's guys. - Current systems programmers (in general) do not have the expertise required to identify these problems. There are exceptions of course. :-) -Yes, installing shareware code can lead to introducing integrity exposures if you are not careful. On 10/14/2010 12:24 PM, Lindy Mayfield wrote: The whole point, I think, is to get it by the system's guys. Not sure how to do that. So much easier on Windows. Still there are coming more and more freeware MVS utilities, like showmvs. (It can run authorized I think, yes?) I don't think that it is that carefully audited, somebody could slip something into there. Or some ported tool like TSOCMD. It would be very unlikely that something like that would get by you guys, but good sysprogs are getting fewer and fewer, and, as an inside job perhaps, someone may easily trick an admin into installing some useful utility that has been compromised. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Cole Sent: Thursday, October 14, 2010 7:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? At 10/14/2010 12:24 PM, Chris Craddock wrote: (as Bob knows) it is impossible to create/install a malicious FLIH or SVC or PC without already having the keys to the kingdom anyway. That is the foundation of integrity and the reason why the installation has to appropriately protect system datasets and APF libraries. Well that's just the problem, Chris, isn't it... The keys to the kingdom really are not well guarded. That's what my 2006 post was all about. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 14 Oct 2010 05:56:48 -0700, in bit.listserv.ibm-main you wrote: I didn't see anyone explicitly mention social engineering. IMO this may be an easier way to get a not-very-technical user's id, but then you are back to how to hack with a normal user TSO account. But if a system guy gave out a password for an reason then, well, you know. What about digging through the trash? Dropping some USB sticks around with interesting programs on them? A few people mentioned some few months back how to get a program authorized from a non-authorized library (or something like that), but nobody gave any details. For sure no script kiddies should ever get in, and if they did they wouldn't know what to do. Someone who understands WebSphere/Eclipse/etc. might be able to get information they shouldn't. What vulnerabilities are set up by use of ziip and zap? My vague understanding is that use of either involves running in SRB mode but I admit I am out of my depth. One thing I didn't see in this thread, was what is the purpose of this hacking. What is to be gained? Sensitive information would be one thing I can think of. Think like a criminal out to make money. Then think banks, on-line order sites, etc. Lindy Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Ricc, Yes, APF authorization still allows the keys to the kingdom. That is why installations are expected to severely limit update access to APF authorized load libraries, the SETPROG MVS command, all datasets in the PARMLIB concatenation and all libraries defined as system level PROCLIBS. If a general user has write auth to an APF authorized dataset, your system, by definition, is unsecure. That is why IBM and ISV's provide integrity statements and take seriously all reports of integrity holes. This is also why IBM refuses to provide any sort of details on integrity APAR's, so that shops without the appropriate PTF's applied are less likely to be compromised. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Ricc Harding ricc.hard...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 10/14/2010 12:10 PM Subject: Re: Mainframe hacking? Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Yes Ed, these sites all had RACF installed and yes, it still required the VTOC data set is RACF protected bit to be flipped for the data set protection call to even be made. The needed resource manager calls became more apparent as the resources which were being protected grew. The ACF2 protectall vs RACF protectnone philosophy soon became the guiding light to making RACF actually usable as a security system by also implementing protectall. However APF authorization still allows the keys to the kingdom with no trace for the clever programmer. And vendor PC calls are now the new point of entry for system penetration attempts since they have all but replaced most of the user written SVC's. The landscape changes but the dirt is still the same. The new hacker's lament might be so many entry points to choose from and so little time to play. Vigilance and automation in security checking are the keys to catching the silly things but the clever programmer still must have the integrity and character to NOT do what they have both the ability and opportunity to do. Quis custodiet ipsos custodes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield Sent: Thursday, October 14, 2010 12:25 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? The whole point, I think, is to get it by the system's guys. Not sure how to do that. So much easier on Windows. Still there are coming more and more freeware MVS utilities, like showmvs. (It can run authorized I think, yes?) I don't think that it is that carefully audited, somebody could slip something into there. Or some ported tool like TSOCMD. It would be very unlikely that something like that would get by you guys, but good sysprogs are getting fewer and fewer, and, as an inside job perhaps, someone may easily trick an admin into installing some useful utility that has been compromised. And much easier in the UNIX environment where there is even more ignorance about why to not do: exattr +ap -F BIN myEvilProgram which could be hidden in the installation script. Or even in the compiled program where it couldn't be seen. And installed with SMP/E when running with SUPERUSER authority. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On 14 Oct 2010 07:24:01 -0700, in bit.listserv.ibm-main you wrote: At 10/13/2010 10:26 AM, Greg Shirey wrote: I liked this article, and it's fairly recent. (Jan 2010) http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1 Greg I read that article, and it is a good one. Interestingly (to me at least), on the article's third web page, there is an excerpt from a post I made here in 2006. It's nice to know that someone is paying attention. My entire post can be found at: http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=IBM-MAINP=R63457X=147B1F23465267AA41Y=dbcole%40colesoft.com I think the information in that post are highly relevant to the current thread. For example, why do IDCAMS and IEBCOPY have to be authorized? The IEBCOPY replacement doesn't have to be authorized. Would it be worthwhile for both vendors and users to see what they can do to reduce the amount of code that has to be authorized? Clark Morris Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Why some programs are authorized Was: Mainframe hacking?
This has been a curiosity of mine of late. Why are on some systems, for example DELETE and LISTCAT authorized in IKJTSOxx? And some systems they aren't? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris Sent: Thursday, October 14, 2010 8:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? For example, why do IDCAMS and IEBCOPY have to be authorized? The IEBCOPY replacement doesn't have to be authorized. Would it be worthwhile for both vendors and users to see what they can do to reduce the amount of code that has to be authorized? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why some programs are authorized Was: Mainframe hacking?
On Thu, 14 Oct 2010 20:43:31 +0200, Lindy Mayfield lindy.mayfi...@ssf.sas.com wrote: This has been a curiosity of mine of late. Why are on some systems, for example DELETE and LISTCAT authorized in IKJTSOxx? And some systems they aren't? I don't know the answer to LISTCAT. For DELETE, some operations that DELETE performs require APF-authorization, but most do not. IBM has never (as far as I know) shipped the default IKJTSOxx with DELETE in it, so it's probably only in IKJTSOxx on those systems where the users make use of those authorized functions of DELETE from TSO. If you need those functions, and do not have DELETE in IKJTSOxx, then you would have to run IDCAMS in batch to perform the functions. (And in response to another message, those functions of DELETE, and authorized functions of some other IDCAMS commands, are (I believe) why IDCAMS runs authorized.) -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why some programs are authorized Was: Mainframe hacking?
I thought that IEBCOPY being authorized was due to a (possible archaic) facility to invoke certain I/O appendage routines. IDCAMS and its subcommands must be able to invoke auth services to satisfy certain invocations - no surprise to find it in AUTHPGM. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield Sent: 14 October 2010 19:44 To: IBM-MAIN@bama.ua.edu Subject: Why some programs are authorized Was: Mainframe hacking? This has been a curiosity of mine of late. Why are on some systems, for example DELETE and LISTCAT authorized in IKJTSOxx? And some systems they aren't? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Clark Morris Sent: Thursday, October 14, 2010 8:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking? For example, why do IDCAMS and IEBCOPY have to be authorized? The IEBCOPY replacement doesn't have to be authorized. Would it be worthwhile for both vendors and users to see what they can do to reduce the amount of code that has to be authorized? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Lindy Mayfield The whole point, I think, is to get it by the system's guys. Not sure how to do that. So much easier on Windows. Still there are coming more and more freeware MVS utilities, like showmvs. (It can run authorized I think, yes?) I don't think that it is that carefully audited, somebody could slip something into there. One thing that might be argued in its defense is that you get all of the source code for it -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
--snip-- I would think it means code that front-ends one of the First Level Interrupt Handlers That's how Amdahl implemented SE and SP assist years ago. I think IBM did it to implement the IEEE floating point instructions so that they would work on processors that lacked the hardware. Of course these were not malicious implementations. Bob Shannon Rocket Software unsnip Even earlier than that, IBM used a comnination of hardware and software intercepts based around Program Interrupts to implement the Commercial Feature on the 360/44. I still have a copy of the Emulator that was loaded into special areas of 360/44 core that finished the process of implementing thie Commercial Feature, as well as a few other instructions in the General Instruction Set. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
---snip-- The whole point, I think, is to get it by the system's guys. Not sure how to do that. So much easier on Windows. Still there are coming more and more freeware MVS utilities, like showmvs. (It can run authorized I think, yes?) I don't think that it is that carefully audited, somebody could slip something into there. Or some ported tool like TSOCMD. It would be very unlikely that something like that would get by you guys, but good sysprogs are getting fewer and fewer, and, as an inside job perhaps, someone may easily trick an admin into installing some useful utility that has been compromised. --unsnip Lindy, you're correct but I think you forgot the corrolary: as good sysprogs get scarcer, so do the numbers of people capable of compromising the code. As the systems get more and more complex, it's harder and harder to devise the mechanisms to compromise those systems. True, we see less and less suspect SVC code and more and more PC code that might be suspect. But as these types of problems grow, I'm sure that IBM and REPUTABLE vendors are working to close any holes that might exist. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
snip For example, why do IDCAMS and IEBCOPY have to be authorized? The IEBCOPY replacement doesn't have to be authorized. Would it be worthwhile for both vendors and users to see what they can do to reduce the amount of code that has to be authorized? unsnip- IIRC, IDCAMS uses s select few functions that require system authorization, for integrity protection. Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1.SVCLIB. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Hi Lindy, Oh yeah, social engineering is one that does get tried often. If I only had a few nickels for every time somebody has cold called saying that they are from IBM, or one of our ISVs, or even someone claiming to be from big name companies that we may or may not do business with. They are always friendly, and very persistant. They always want to verify account information or talk to the boss, or promise the results of a survey, or prizes, or whatever to get information. Lots of time they will try to find out info about the configuration of the shop - both hardware and software. I always ask them for THEIR information. Usually, they can't get off the phone fast enough! Then I pass the word around to the co-workers that another phisher is lurking. Linda - Original Message - From: Lindy Mayfield lindy.mayfi...@ssf.sas.com To: IBM-MAIN@bama.ua.edu Sent: Thursday, October 14, 2010 5:55:01 AM Subject: Re: Mainframe hacking? I didn't see anyone explicitly mention social engineering. IMO this may be an easier way to get a not-very-technical user's id, but then you are back to how to hack with a normal user TSO account. But if a system guy gave out a password for an reason then, well, you know. What about digging through the trash? Dropping some USB sticks around with interesting programs on them? A few people mentioned some few months back how to get a program authorized from a non-authorized library (or something like that), but nobody gave any details. For sure no script kiddies should ever get in, and if they did they wouldn't know what to do. One thing I didn't see in this thread, was what is the purpose of this hacking. What is to be gained? Sensitive information would be one thing I can think of. Lindy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1.SVCLIB. Yes. That's true. But, what about the fact that work-alikes (eg: SPFCOPY) don't need them? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
The SPFCOPY that I remember simply used a magic SVC to set the APF on before calling IEBCOPY and back off afterwards. Did PDSFAST require APF authorization? Sent from my Android/Vibrant phone. And much of the text was spoken and transcribed, with some post editing. John McKown Maranatha! On Oct 14, 2010 7:23 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: Also, IIRC, IEBCOPY uses I/O appendages that require authorization, since they are loaded from SYS1... Yes. That's true. But, what about the fact that work-alikes (eg: SPFCOPY) don't need them? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu w... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Thu, 14 Oct 2010 23:58:25 +, Linda Mooney wrote: I always ask them for THEIR information.  Usually, they can't get off the phone fast enough! Then I pass the word around to the co-workers that another phisher is lurking. Give me your number; I'll have someone get back to you. CLICK -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Thu, 14 Oct 2010 18:38:45 -0500, Rick Fochtman wrote: Even earlier than that, IBM used a comnination of hardware and software intercepts based around Program Interrupts to implement the Commercial Feature on the 360/44. I still have a copy of the Emulator that was loaded into special areas of 360/44 core that finished the process of implementing thie Commercial Feature, as well as a few other instructions in the General Instruction Set. :-) Millicode! As Shmuel would say, ObQoheleth. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mainframe hacking?
I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
If you mean a total outsider, __cracking__ into a z/OS or z/VM or z/VSE system using some sort of Internet connection, then I've not heard of such a thing. However, given that the vast majority of successful cracking attacks are never reported, the likelihood of a company telling the world that their z mainframe was cracked makes winning the PowerBall look like a cinch. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Mc Sent: Wednesday, October 13, 2010 7:19 AM To: IBM-MAIN@bama.ua.edu Subject: Mainframe hacking? I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
whether the mainframe has been hacked or not Well, do you really think either IBM or a customer would admit that a mainframe system had been hacked? In the old days some shops left the IBMUSER Id active on the system. I'm sure that such incompetence still exists. With TCP/IP, USS, Java, and a billion or so hackers worldwide, the risks are higher than ever. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I can say that someone has tried to hack us, but has been unsuccessful. Here's what happens, the hacker gets an IP address and a userid, but as of today the most that has happened is that the userid being used is revoked. We see the messages on SYSLOG and the IP address coming in is then blocked at the firewall. *George Rodriguez* *Specialist II - IT Solutions* *Application Support / Quality Assurance* *PX - 47652* *(561) 357-7652 (office)* *(561) 707-3496 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-332* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Six Consecutive Years* On Wed, Oct 13, 2010 at 8:18 AM, Joe Mc joe.m...@yahoo.com wrote: I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Home of Florida's first LEED Gold Certified School Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Joe Mc wrote: I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? What mainframe platform? I'm serious, because 'mainframe' is ambigious. For z/OS, *cracking* into it may be difficult. But see [1] below. With 3270 emulator, 'hacking' *could* be possible by installing 'screen scraper' and/or keystroke logger software. Did that happened? Hmmm, good question. If you do bad design on your web pages hosted by, for example WebSphere, some bad*ss could overwrite your page(s) with some nasty message(s) like this one: 'A L33T was here.' So in theory, it is possible, but if you can get me real practical incident(s) [2], I would really like to find out about it. [1] - There are 'tiger team' companies who can *hack* or *crack* upon request and after paying a fee. [2] - Real incidents, not some rotten fruits from lame bored reporter. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
If you mean gaining access to sensitive MF data, then yes there have been several reports. The successful attack vectors were (trusted?) Windows servers. If you mean gaining access directly, then I personally have not seen any credible reports. I am told that intrusion reporting has been mandated by law for several years. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Mc Sent: Wednesday, October 13, 2010 7:19 AM To: IBM-MAIN@bama.ua.edu Subject: Mainframe hacking? I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Although it is an intrusion (with serious consequences) I wouldn't count guessing a userid/password a crack. Likewise gaining access by cracking an attached squatty box. Gaining access programmatically/directly is another issue. -Original Message- Elardus Engelbrecht Joe Mc wrote: I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? What mainframe platform? I'm serious, because 'mainframe' is ambigious. For z/OS, *cracking* into it may be difficult. But see [1] below. With 3270 emulator, 'hacking' *could* be possible by installing 'screen scraper' and/or keystroke logger software. Did that happened? Hmmm, good question. If you do bad design on your web pages hosted by, for example WebSphere, some bad*ss could overwrite your page(s) with some nasty message(s) like this one: 'A L33T was here.' So in theory, it is possible, but if you can get me real practical incident(s) [2], I would really like to find out about it. [1] - There are 'tiger team' companies who can *hack* or *crack* upon request and after paying a fee. [2] - Real incidents, not some rotten fruits from lame bored reporter. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I am told that intrusion reporting has been mandated by law for several years. Of the specifics or just the result? I would think that if there had been a successful crack due to software limitations (i.e. bug) we would have seen a fix via Red Alert. A successful crack via a configuration lapse (incorrect/incomplete setup etc.) is another thing and IIRC there is/were RedBooks/White Papers/SHARE sessions and the ever popular consulting firms that may address/specify the most likely issues. -Original Message- Hal Merritt If you mean gaining access to sensitive MF data, then yes there have been several reports. The successful attack vectors were (trusted?) Windows servers. If you mean gaining access directly, then I personally have not seen any credible reports. I am told that intrusion reporting has been mandated by law for several years. -Original Message- Joe Mc I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
I liked this article, and it's fairly recent. (Jan 2010) http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1 Greg Joe Mc wrote: I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
Joe, I am not aware of any successful attack on a mainframe system as a result of a software defect. I am aware of some cases where access was gained to a system by virtue of not changing the default password on a system-supplied userid. I am also aware of some cases where an employee / former employee divulged information permitting an unauthorized person to gain access to a system. John P. Baker Chief Software Architect HFD Technologies -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Mc Sent: Wednesday, October 13, 2010 8:19 AM To: IBM-MAIN@bama.ua.edu Subject: Mainframe hacking? I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
joe.m...@yahoo.com (Joe Mc) writes: I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? once I took the bait on such a taunt prior to virtual memory being announced for 370 ... an internal document found its way into the hands of somebody from the press (sort of a corporate pentagon papers thing). there was big investigation and afterwards all the corporate copiers were retrofitted with an (unique) ID-tag that would show up on every page copied. for an example see the bottom of each of these scanned pages from gray presentation http://www.garlic.com/~lynn/grayft84.pdf somewhat as a result, the future system project (was going to replace all 370, as different from 360/370 as 360 had been different from prior generations) went to vm370-based software copy documents ... with some additional security features added to vm370s that hosted the future system documents. misc. past posts mentioning future system http://www.garlic.com/~lynn/submain.html#futuresys One weekend I had some benchmark time in machine room that contained one such vm370 ... and some of the people responsible (for special security addons supporting super-secure softcopy future system documents) taunted that even if I was left alone in the machine room ... I still wouldn't be able to access the documents. I countered that it would take less than five minutes ... most of the time was making sure the system was disabled from any access external to the machine room ... and then I flipped a bit in storage ... so anything/everything entered was accepted as valid password. old reference to use of virtual machine systems for security ... of course, I didn't learn about these guys until much later: http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml as to virus ... there is xmas that occured on bitnet almost exactly a year before morris worm on internet. bitnet was corporate sponsored higher educational network ... using similar technology to that used in the (mostly vm370 based) internal network (which was larger than the arpanet/internet from just about the beginning until possibly late 85 or early 86) ... misc. past posts mentioning bitnet (/or EARN) http://www.garlic.com/~lynn/subnetwork.html#bitnet misc. past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet reference from vmshare archives http://vm.marist.edu/~vmshare/browse?fn=CHRISTMAft=PROB -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
- I am aware of integrity exposures (violations of the IBM statement of integrity) on the latest release(s) of z/OS, in fact, the software I use has found many on the latest releases of z/OS and ISV products. - Exploits based upon these integrity exposures would be successful (i.e. - access allowed, no audit trail of activity) - This would require access to z/OS (inside attack), and would take some sophistication to develop an exploit, but the use of the exploit would not take any sophisticated knowledge. In one case, for a vulnerability my software found in an ISV product, I was able to develop an 11 line REXX Exec that could be executed from TSO and give the user RACF Privileged access. That is access to any dataset on the system with no security system SMF records being generated. - The fact that this exploit would require insider status is not something that should be dismissed because a 2008 Strategic Counsel survey, commissioned by CA, found that the percentage of internal attacks is increasing -- from 15% of all breaches in 2003, to 42% in 2006, to 44% in 2008. And in a 2010 PacketMotion Survey of US Government Agency Representatives, 59% felt that employees were the biggest threat! - The fact that the successful hacks were not publicized does not surprise me. My experience is that successful hack information is closely guarded and not disclosed. Organizations do not want it known that they have been successfully attacked. - I have a lot more information on my website: www.vatsecurity.com http://www.vatsecurity.com and information on the software I have developed, the Vulnerability Analysis Tool, which does a vulnerability scan on z/OS systems and finds many, many z/OS and ISV system integrity vulnerabilities. Ray Overby Key Resources, Inc. Ray.Overby.kr-inc.com On 10/13/2010 09:26 AM, Greg Shirey wrote: I liked this article, and it's fairly recent. (Jan 2010) http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1 Greg Joe Mc wrote: I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
When I worked for a large computer manufacturing company in 1984, I would go with their corporate audit team to attempt to penetrate their in house MVS systems. We would, depending on the site managers wishes, either attempt to access critical data from normal TSO userid's, or we would attempt to access the mainframe without any TSO id's given to us. In the case of working without any TSO id's we still had physical access to terminals and programmers offices, so unlocked desks and trash cans were fair game. In 8 audits of sites all over the world, we never failed to gain access to critical data. The ways in which we penetrated the systems lead to many of the changes implemented in the way RACF was suggested to be used. We also had lists of hundreds of ways to penetrate the system from unauthorized userids, using clever attacks and unprotected control elements or restricted utilities. Since 1984 the list of areas that can be exploited to gain access to data, both protected and unprotected, has grown proportionally and though the systems can be secured much more tightly now, any system that is accessible by users who are not inside a secured area, in my humble opinion, can be hacked, if you define hacked as gaining unauthorized access to sensitive data. We sometimes sat down with dumps and disassembled user written SVC's and exit modules to exploit programming errors. A patient hacker can gain access eventually. I think, the time, knowledge, and effort to do this today, is simply not worth the potential penalties when caught after the fact IMHO. Those who have the knowledge to do the break in's are usually employed in positions to stop the break in's. but with zIIP's and IFL's and zAAP's there are just getting to be so many places to keep track of -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
---snip--- In the old days some shops left the IBMUSER Id active on the system. I'm sure that such incompetence still exists. With TCP/IP, USS, Java, and a billion or so hackers worldwide, the risks are higher than ever. --unsnip--- I ALWAYS left the IBMUSER active on the system but the first thing I also did was to change to password to some very obscure value. Which was never revealed to ANYONE. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
---snip-- I'm getting into a rather heated argument with a non mainframe colleague about whether the mainframe has been hacked or not. Legitimate hacking, not a disgruntled employee doing something illegal and not loss of tapes or other media. I'm talking the mainframe platform. Thoughts? M. McHenry Pittsburgh, Pa. -unsnip I've never seen an actual illicit entry into a mainframe z/OS, MVS or OS/390 system, although I've seen several Denial of Service attacks. They didn't actually get into the system but they prevented legitimate entry. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
