Funny credit card story. Here in Israel, a company had all cc on an encrypted hd. The person used the desktop took the hd home, booted from the hd and copied all data. Then, from Thailand, he tried to blackmail his employee.
What value encryption offers in this vase? בתאריך יום ג׳, 7 במאי 2019, 15:49, מאת Carmen Vitullo <cvitu...@hughes.net >: > I'll also add, in spite of being flamed, SNA networks we're pretty secure, > it wasn't till TCP/IP and OPENMVS that we started having to rethink > security I know SNA was not 100% secure but that's why VTAM messages were > scrutinized by operators, sysprogs , automation and security, you don't see > that level of logging in an open environment. I can view my PC's logging, > but it's usually after the fact it is viewed. > and to Tom's point there not fixing stupid, I worked for an outsourcer > that also sanitized and collected bank and credit reporting agencies data > and sold this data to anyone in the need, a salesman had all Credit bureau > data on his laptop, he left that laptop in an unsecure conference room, > that laptop was stolen and all customer data was stolen, that led to this > company encrypting all company laptop hard drives, and a nice lawsuit to > boot > > > > > Carmen Vitullo > > ----- Original Message ----- > > From: "Tom Brennan" <t...@tombrennansoftware.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Tuesday, May 7, 2019 12:09:37 AM > Subject: Re: mainframe hacking "success stories"? > > For the mainframe, one of the words I like to use is "Integrity". The > hardware designers and programmers did not want to let any error, no > matter how small, go unnoticed. A quick example: On a real 3278 > terminal if you tried to type on top of a protected field, the box made > a clicky noise and locked the keyboard from further input until you > pressed Reset. This is Integrity, protecting the data entry clerk from > missing even a single character on that COBOL coding form. > > Same with the OS of course - with all the logging and SMF and error > recovery and message manuals a mile long. You don't see anything close > to this in Windows and Linux/Unix. In fact, on those platforms it's > sometimes the opposite... Call a subroutine, forget to check the return > code, and the program continues on as if nothing happened - good luck. > On the mainframe, if I call an SVC and it fails I get an abend by > default with a decent message. That's just one small part of the > built-in integrity the mainframe has over the other platforms. > > One of my old jokes working with Unix/Linux was: If you got an error > that makes no sense, check to see if the disk ran out of space. I was > surprised how often this turned out to be true. > > Over the years one of the bigger Windows/Unix hacks has been buffer > overflows, I believe based on string copies with no supplied length (you > keep copying bytes until you hit a zero). But variable fields on the > mainframe typically had a length byte or halfword - so we avoided one of > the bigger hacking issues. Well, until USS came along and C started > being used for mainframe coding. > > But this all makes no difference when you find passwords.txt on a > sysprog's laptop because the security folks decided the password needs > to be changed each month to something impossible to remember. That's > more the point I'm trying to make. > > On 5/6/2019 6:52 PM, Bill Johnson wrote: > > A plethora of reasons. > > Lack of emphasis on security by MSFT. More interest in selling the next > release than securing each release. > > Buggy code. Went to a security seminar once where it was stated that > MSFT code had one bug for every 25 lines of code. IBM was around one bug > every 250 lines and NASA was one bug every 10,000 lines. Called KLOC. > > MSFT is also more available. There are millions of possible targets. > That’s why Safari was less exposed to hack than IE. IE had a much larger > install base so was more targeted. > > Many other reasons. > > Hackers tend to target the easier platform. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Monday, May 6, 2019, 9:27 PM, Tom Brennan <t...@tombrennansoftware.com> > wrote: > > > > Ok, but why is Windows easier to hack than the mainframe? > > > > Personally, I'd find a mainframe far easier to hack because I know a > > little bit about control blocks, APF auth, SVC's, subsystems, address > > spaces, RACF, etc., and I know far less about the equivalents on > > Windows. But of course the first step is to get any kind of userid, and > > that's done by pretty-much the same methods - regardless of platform. > > > > On 5/6/2019 1:18 PM, Bill Johnson wrote: > >> It’s why banks stay on the mainframe. Security. > >> > >> > >> Sent from Yahoo Mail for iPhone > >> > >> > >> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > >> > >> Bill, would you care to back that sweeping generalization up with some > detail? > >> > >>> On May 6, 2019, at 22:06, Bill Johnson < > 00000047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >>> > >>> Completely different. Hacking Microsoft is way easier. > >>> > >>> > >>> Sent from Yahoo Mail for iPhone > >>> > >>> > >>> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls < > mainfr...@bigendiansmalls.com> wrote: > >>> > >>> Which is how 80% of all the hacks today start. Find purchase and > advance your position. This is how the game is played. It was as classic of > a hack as anything today. > >>> > >>>> On May 6, 2019, at 21:43, Bill Johnson < > 00000047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > >>>> > >>>> Still never would have occurred without a valid userid. > >>>> > >>>> > >>>> Sent from Yahoo Mail for iPhone > >>>> > >>>> > >>>> On Monday, May 6, 2019, 3:18 PM, Charles Mills <charl...@mcn.org> > wrote: > >>>> > >>>> No. > >>>> > >>>> From the link you cite: > >>>> > >>>> "According to various sources, the hackers succeeded in finding (and > exploiting) at least 2 previously unknown errors enabling them to raise > their authorisations in the system. One of them was an error in an IBM HTTP > server and the other one was an error in the CNMEUNIX file, which in the > default configuration has SUID 0 authorisations (which means that by > leveraging on the errors it contains, one is able to execute commands with > the system administrator’s authorisations)." > >>>> > >>>> His "user" access to InfoTorg was not a problem for the mainframe. > (It was a problem for the MPAA lawyer whose account he accessed, but not > for the mainframe in general.) The above mainframe security vulnerability > was. > >>>> > >>>> Charles > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >>>> Sent: Monday, May 6, 2019 11:17 AM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Re: mainframe hacking "success stories"? > >>>> > >>>> The Pirate Bay hack acquired a valid mainframe userid and password > off of a Microsoft laptop. In effect, not really a mainframe hack. He just > logged on. https://badcyber.com/a-history-of-a-hacking/ > >>>> > >>>> Sent from Yahoo Mail for iPhone > >>>> > >>>> > >>>> On Monday, May 6, 2019, 1:21 PM, Charles Mills <charl...@mcn.org> > wrote: > >>>> > >>>> #1: Noooooo. It was a legitimate mainframe hack (assuming you > consider USS a legitimate part of the mainframe, which it has been for 20 > years or so). It was an exploit of CGI buffer overrun. > >>>> > >>>> #2: It drives me nuts to hear mainframers explain away mainframe > breaches. "It wasn't really a mainframe hack, they got in through USS." "It > wasn't really a mainframe hack, they re-used a Windows password." "It > wasn't really a mainframe hack ... whatever." If your CEO was standing in > front of the press explaining how your company let x million credit card > numbers go astray, would it matter HOW they got into your mainframe, or > only that they DID?" If your mainframe is vulnerable to a USS hack, or a > shared Windows password, or whatever, you need to fix THAT, or risk having > to explain to your CEO why he got fired (like Target's) for letting all > those credit card numbers go astray. > >>>> > >>>> Charles > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Johnson > >>>> Sent: Sunday, May 5, 2019 10:00 AM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Re: mainframe hacking "success stories"? > >>>> > >>>> Wasn’t really a mainframe hack. It was a laptop hack that acquired > legitimate mainframe credentials. > >>>> > >>>> > ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>>> > >>>> > >>>> > >>>> > ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>>> > >>>> > ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>>> > >>>> > >>>> > >>>> > ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>> > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > >> > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
