Re: Secret Service Guide
The PEMODE password is calculated from the system serial number (CEC, 12 characters), current date, and a mutate table which is specific to the SE software main release version and MCL. The only secret part is the serial number ... I guess it was never intended to be a very secret method, but rather to avoid people damaging things. Costin From: Charles Durrett charles.durr...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, March 21, 2012 3:55 PM Subject: Re: Secret Service Guide On Saturday, March 17, 2012 10:11:20 AM UTC-5, R.S. wrote: MP3000 Service Guide is SY24-6155 - easily found online. It even has the default Support Element logon passwords - Woo-Hoo! Thank you for the hint. BTW: the passwords are well known and have always been documented. Default passwords for HMC are: SERVMODE for user SERVICE PASSWORD for other documented users (*) There is also undocumented user PEMODE, I would like to know his password, but AFAIK it's time and s/n dependent. PEMODE account is also present in a z890 Service Element - the signon panel 'leaks' enough information to tell if an account is setup on the machine. The variable password with the account *might* be implemented per the 1994 IBM US patent 5682475 - METHOD AND SYSTEM FOR VARIABLE PASSWORD ACCESS. If so then the password search space is narrowed. (*) I haven't checked two new (z196) Ensemble users -- Radoslaw Skorupka Lodz, Poland ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Secret Service Guide
I write that the S/N is secret, as it is the only thing specific to a certain installation. The method is present on all the SEs in the world, and the tables on all the SEs with the same MCL - this makes them not so secret. But the S/N is unique, known by IBM and the client - it may be not enough, but it is all we have. In a secure setup, it hardly matters, as is not intended to protect the system against external attacks, just against technical misuse by legitimate users. Of course, the HMCs are a different topic, but not for this thread. Costin From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@bama.ua.edu Sent: Thursday, March 22, 2012 12:33 PM Subject: Re: Secret Service Guide Well, I cannot agree. Serial number is know as well as the date. The only secret part is the method, algorithm. BTW, disclaimer: I wish I knew the PEMODE password, but I didn't look for it. I was looking for Service Manuals. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2012-03-22 11:35, Costin Enache pisze: The PEMODE password is calculated from the system serial number (CEC, 12 characters), current date, and a mutate table which is specific to the SE software main release version and MCL. The only secret part is the serial number ... I guess it was never intended to be a very secret method, but rather to avoid people damaging things. Costin From: Charles Durrettcharles.durr...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, March 21, 2012 3:55 PM Subject: Re: Secret Service Guide On Saturday, March 17, 2012 10:11:20 AM UTC-5, R.S. wrote: MP3000 Service Guide is SY24-6155 - easily found online. It even has the default Support Element logon passwords - Woo-Hoo! Thank you for the hint. BTW: the passwords are well known and have always been documented. Default passwords for HMC are: SERVMODE for user SERVICE PASSWORD for other documented users (*) There is also undocumented user PEMODE, I would like to know his password, but AFAIK it's time and s/n dependent. PEMODE account is also present in a z890 Service Element - the signon panel 'leaks' enough information to tell if an account is setup on the machine. The variable password with the account *might* be implemented per the 1994 IBM US patent 5682475 - METHOD AND SYSTEM FOR VARIABLE PASSWORD ACCESS. If so then the password search space is narrowed. (*) I haven't checked two new (z196) Ensemble users -- Radoslaw Skorupka Lodz, Poland ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN
Password Phrase Encryption Algo?
Hi, Does anybody have a clue how the PASSPHRASE is encrypted in RACF? It looks very much like SHA (SHA-1 I hope), it depends on both the username and password, but how is it build? Yes, I have asked in the RACF list already :) Br, Costin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Password Phrase Encryption Algo?
Of course. The final result looks like SHA-1, but several operations could take place before - DES, etc. At the end it is a cryptographic operation. The corect question would be - how are the passwords hashed, and potentially encrypted, for RACF passworh phrases? From: Kirk Wolf k...@dovetail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, March 19, 2012 4:17 PM Subject: Re: Password Phrase Encryption Algo? Sorry if I'm being pedantic, but SHA-1 is not an encryption algorithm - it is a cryptographic hash function. http://en.wikipedia.org/wiki/Cryptographic_hash_function On Mon, Mar 19, 2012 at 9:09 AM, Costin Enache e_cos...@yahoo.com wrote: Hi, Does anybody have a clue how the PASSPHRASE is encrypted in RACF? It looks very much like SHA (SHA-1 I hope), it depends on both the username and password, but how is it build? Yes, I have asked in the RACF list already :) Br, Costin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Password Phrase Encryption Algo?
Well, the standard DES crypto for RACF (iSeries also) is using the password as the key to encrypt the username (profile name). In a practical sense, it is like hashing - the key is never stored on the system, so it cannot get stolen. It is also quite strong, but the algo is outdated and crippling it by dropping 8 bits makes it even weaker; the character set is also relatively small, enabling easy cracking. A decent AES, with mixed case and large charset, would quicly resolve the classical issue. Costin From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Sent: Monday, March 19, 2012 5:34 PM Subject: Re: Password Phrase Encryption Algo? On Mon, 19 Mar 2012 16:19:37 +, Costin Enache wrote: Of course. The final result looks like SHA-1, but several operations could take place before - DES, etc. At the end it is a cryptographic operation. The corect question would be - how are the passwords hashed, and potentially encrypted, for RACF passworh phrases? A one-way hash should be preferble to encryption because there should be no possibility that the key could be stolen. A dual-key ciphersystem with one key discarded is comparable to a one-way hash. From: Kirk Wolf Sent: Monday, March 19, 2012 4:17 PM Sorry if I'm being pedantic, but SHA-1 is not an encryption algorithm - it is a cryptographic hash function. http://en.wikipedia.org/wiki/Cryptographic_hash_function On Mon, Mar 19, 2012 at 9:09 AM, Costin Enache wrote: Does anybody have a clue how the PASSPHRASE is encrypted in RACF? It looks very much like SHA (SHA-1 I hope), it depends on both the username and password, but how is it build? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: EMC/RSA SecurID products hacked
There is only one way to compromise the OTP tokens and that is to get the seed used to generate the OTP codes. The compromise is permanent, for the entire lifetime of the token, as one can generate any OTP code. First of all, RSA should not have kept the seeds after the delivery of the tokens to the clients - there is no need to do so. Why did they store the seeds? Claiming to do so for helping client who misplace the seeds would be hilarious. That RSA probably does not have such a great network and system security would not be such a surprise, we have seen this before with Cisco, Microsoft and other players. One wouldn't dare to have a look at IBM, of course. We had clients looking into multiple factor authentication and we have always recommended staying away from tokens that come pre-programmed, with the secret seed burned in the factory (regardless if they come from USA or Guangdong). Pre-programmed tokens are as safe as their production facility and this could potentially be safe, but not verifiable, which in security means clearly unsafe. OTP tokens can be made secure and this can be easily achieved by programming the client's own seeds - it is however amazing how hard is to actually get such tokens, most of the known producers do not offer them. We have finally found one manufacturer that offers (not only on the web page and product catalog, but also has the product) customer programmable OTP tokens - it took us 4 months to get there. Costin --- On Fri, 3/18/11, john gilmore john_w_gilm...@msn.com wrote: From: john gilmore john_w_gilm...@msn.com Subject: EMC/RSA SecurID products hacked To: IBM-MAIN@bama.ua.edu Date: Friday, March 18, 2011, 2:30 PM EMC's RSA product SecurID, which some of your networks almost certainly use, has been hacked. An APT has, that is, been directed at RSA. What exactly has been compromised is unclear. RSA may not know; and even if it does it is, understandably, reluctant to say much. It has said that it is “confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers.” In the two situations in which I have been asked for my opinion I have, however, suggested that much less confidence would be prudent, at least in the short term. RSA is not stupid about these things; and any breach of its own security was therefore the work of talented, dangerous people. RSA will be able to repair the damage done, but it is not clear just how soon it will be able to put any necessary countermeasures in place. John Gilmore Ashland, MA 01721-1817 USA -- 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: z/OS Virus Checker zLinux Virus Checker
Oh. Yes, I thought commercials are not that popular here :) We also provide in-depth IT security assessments for mainframe systems, have been doing this for quite some years. We offer some specialized tools as well, for example for offline / regular RACF password auditing (but no, no such animal as a z/OS virus checker). More information at http://www.detack.com/en/hms.html Costin Enache / Detack GmbH --- On Fri, 3/4/11, Jan Vanbrabant vanbrabant...@gmail.com wrote: From: Jan Vanbrabant vanbrabant...@gmail.com Subject: Re: z/OS Virus Checker zLinux Virus Checker To: IBM-MAIN@bama.ua.edu Date: Friday, March 4, 2011, 8:56 AM Don't see anything like a forum in the sitemap of your web site. J On Fri, Mar 4, 2011 at 7:21 AM, Dr. Stephen Fedtke max_mainframe_...@fedtke.com wrote: hi all, i almost missed this discussion. if you are interested in further arguments and details in this field Vulnerability Analysis and Scan on z you should also refer to the it security forum on our website. we completely solve this problem for over a decade. 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++ At 14:04 29.01.2011 -0600, you wrote: Elardus, Please let me add some information in response to your posting: There is a difference between a Virus and a System Integrity Exposure.The System Integrity Exposure is the Root Cause that a Virus exploits.There may be many Viruses, especially in Windows Systems, which exploit the same Root Cause.The PC Virus checkers look for the signatures of Virus code either executing or in directories and then take action to remove them.The Virus Checkers cannot fix the Root Cause -- in the case of Windows, only Microsoft can do that.But, it would be better if Microsoft would fix the Root Cause because then the Virus programs would become ineffective. IBM's Statement of Integrity clearly states that if a System Integrity Vulnerability (the Root Cause) is reported to IBM, they will fix it.Microsoft does not make this commitment and this is why the z/OS Operating System is a much more securable system than Windows. However, z/OS is not immune to these threats because it too has system integrity vulnerabilities.In your posting, you state that there are many alternatives to our Vulnerability Analysis Product for the ethical hacking/penetrating/scanning for defects and exposures.In fact, IBM purports to provide this capability from their Tivoli zSecure unit.On their zSecure Audit Website, they state: Security zSecure Audit includes a powerful system integrity analysis feature. Reports identify exposures and potential threats based on intelligent analysis built into the system.That's a pretty powerful and absolute statement. But, since Tivoli is part of IBM you can be assured that their Quality Assurance Unit regularly tests their software against revisions to the IBM z/OS Operating System and, if any integrity exposures were found, they would have reported the vulnerabilities to IBM z/OS Development and Development would have fixed them.That would just be the normal course of business within IBM. But, then, how can you reconcile the fact that our VAT product has located SIXTY SEVEN (67) new system integrity vulnerabilities in z/OS within the last two years.And, our clients have reported them to IBM, IBM has accepted them as errors, issued APARS for all of them and issued PTFs for almost all of them.So, obviously, the IBM Tivoli zSecure Audit package is not catching these errors.And, if IBM, is not catching these in their own code, what about the ones introduced by the rest of the Independent Software Vendor products and locally developed or otherwise obtained code on your system?There is a big vulnerability here that cannot be ignored. An exploit of a z/OS (or ISV) system integrity vulnerability would allow the illegitimate user to obtain control in an authorized state and use this state to change his security credentials to obtain access and be able to modify any RACF protected resource on the system with no SMF journaling of the access.We have found these integrity exposures in code that is in operation on every z/OS system in existence.That is something to be concerned about and to act on. I have no idea of the comparison between the cost of our Vulnerability Analysis Tool versus the competition.We would be happy to discuss that with you -- we believe it is inexpensive compared to the benefits which include not only a reduction of risk and exposure to data loss and modification which would result in exposure of company secrets
Re: New HMC to Old SE
Dear List, Is there anybody who could shed some light on this matter? Alternatively, are there any specifications the communications protocols between the HMC and SE (the SNMP API is somewhat documented, but who knows how to use it..)? If I'm posting in the wrong section, please let me know. Costin On Mon, 24 Jan 2011 09:16:21 -0600, Brian Peterson brian.peterson.ibm.m...@comcast.net wrote: On Mon, 24 Jan 2011 06:04:55 -0800 (PST), in bit.listserv.ibm-main, Costin Enache wrote: Hi, Is is possible to connect a new, Linux-based HMC (v2.10.2) to an old, really old, OS/2-based SE (v1.6.1)? I have tried to do this, via Add Object Definition, the HMC tries to communicate with the SE on TCP port 58787, but the SE does not listen on this port. Please don't suggest upgrades, this is a research project, with scrap hardware (MP3000), no vendor support, etc., I have to use what I already have around. Br, Costin According to the z10 Technical Guide Redbook (page 304), the HMC v2.10.2 can connect down to SE version 1.6.2, which is definitely an OS/2 SE. http://www.redbooks.ibm.com/redbooks/pdfs/sg247516.pdf I'm posting this response via the listserv so that perhaps others will have a better answer, as your query was originally posted via usenet and not the listserv where most folks read IBM-MAIN. There certainly may be others on this list who either have had past or current MP3000 experience and who might offer better suggestions. 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: New HMC to Old SE
The machine is a Multiprise H50, not sure what is the latest level of the SE - could be 1.6.2. It currently has 1.6.1. Is the SE code update to 1.6.2 or later (whatever is the latest supported on MP3000) freely available, or is it restricted to IBM customers with support contracts? Costin --- On Fri, 1/28/11, R.S. r.skoru...@bremultibank.com.pl wrote: From: R.S. r.skoru...@bremultibank.com.pl Subject: Re: New HMC to Old SE To: IBM-MAIN@bama.ua.edu Date: Friday, January 28, 2011, 1:11 PM Hi, Is is possible to connect a new, Linux-based HMC (v2.10.2) to an old, really old, OS/2-based SE (v1.6.1)? Yes, it is possible. I did it, but the level of OS/2 SE is also important (*). I connected it to SE v1.7 or 1.8 (one of the last OS/2 based levels available). It works. I also tried to connect OS/2 HMC (also last level) to Linux SE - and I couldn't. Honestly I've never checked if it would be possible. (*) I vaguely remember some IBM presentation, AFAIR the said about new HMC support down to 9672 G6 SE. HTH -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.248.328 zotych. -- 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: New HMC to Old SE
Thanks for the advice, I'll post only via the listserv. This calls for driver DR26W (1.6.2), and I currently have DR24Q on the SE (1.6.1). Does anybody else have experience with this? I dream of an easy setting on the SE, to activate the required services :) Currently both the SE and HMC have the same security domain and all services (Enable Console Services) are enabled. Costin -- 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
