Is

[Guest.Visitor]

The Monday Morning Update from 26th June reported an AS/400 Security Alert, whereby "a deceptively simple 17-line RPG program" could read the user id and password of the last user to sign on to the AS/400. We are applying the PTFs to fix this, but would like to test the security problem before we apply the PTF and then again after we apply it, to ensure that the problem is fixed. Is this RPG program available? L.

[Guest.Visitor]

Is

Liam, It'd be easier to pull your own teeth with pair of pliers. IBM is not going to publish the code. The best you might find is someone who will send it to you via e-mail. Don't think MC would allow it to reside on their forum. Reason: IBM is stingy with their OS. Also, the fact that this code could get distributed or used on a machine without the proper PTF puts too many companies at risk. The liability factor of making this available is enormous. Later, Bret

[D.Handy]

Is

Liam, We are applying the PTFs to fix this, but would like to test the security problem before we apply the PTF and then again after we apply it, to ensure that the problem is fixed. Numerous of us outside of IBM have tested it -- it is fixed by the PTF's. I don't believe it is in the public interest to post the source again. Too many sites have not applied the PTF, and some (unsupported) releases are still being run which do not even have the PTF available (eg V3R7). Sorry, Doug

[Guest.Visitor]

Is

The phrase "deceptively simple 17-line RPG program" seemed like an odd way to state the problem since the information can be retrieved with a "deceptively simple" OS/400 command. Steve

[D.Handy]

Is

Steve, The phrase "deceptively simple 17-line RPG program" seemed like an odd way to state the problem since the information can be retrieved with a "deceptively simple" OS/400 command. I found it an odd description since 11 of the 17 lines in essence dealt with pointers or were used to call a MI builtin or C library function. I suspect a rather small proportion of the RPG community could really explain what each of those 17 lines were for. Even the EVALs. But it is kinda ironic the 17-line RPG program created an immediate uproar while the 1-line OS command or 10-line MI program posted 3 days earlier caused (relatively) little reaction. To be fair, many users don't have authority to the command (although probably most programmers and operators do -- or did), and most people don't realize an interface to the MI compiler in OS/400 is freely available. Doug

[Guest.Visitor]

Is

>The phrase "deceptively simple 17-line RPG program" seemed like an odd way to state the problem since the information can be retrieved with a "deceptively simple" OS/400 command.<<

As the "phraser", I can justify the statement . The OS/400 command that would display the passwords (DMPSYSOBJ) is shipped with the default *PUBLIC authority set to *EXCLUDE. Explicit *USE authority is given to QSYSOPR, QPGMR, QSRV, & QSRVBAS. While the exposre from DMPSYSOBJ was alarming, an AS/400 shop that is security concious would have their risk minimized by the default authority of the DMPSYSOBJ command. The deceptively simple 17-line RPG program was of greater concern because it required no additional authorities beyond what any common user has (programmer or otherwise) already has. jte

[Guest.Visitor]

Is

Doug, I did not see the MI or OS command/code you are talking about. Was it removed before it got circulated? Is it still there and a problem. Hey MC, if it is still there, can we get it removed? Thanks, Bret

[Guest.Visitor]

Is

John - Very well, um, phrased! :-) I would have thought the DMPSYSOBJ command would be more dangerous but I see your point. FWIW, Steve

[D.Handy]

Is

Bret, I did not see the MI or OS command/code you are talking about. Was it removed before it got circulated? Is it still there and a problem. It wasn't on this forum. It was posted on a "mailing list" devoted to MI programming. Currently, there are no archives available publicly available, so only those of us who were subscribers at the time would have received the messages (and anybody they shared it with). It is not picked up by things like deja. Since the list is devoted to MI, I suspect it has fewer followers than most AS/400 related forums. For the fun of it, I just sorted my archives by author and counted roughly 65 contributors since the list started. A rather small subset of those account for most of the messages. I have no idea how many people just read the list. I haven't checked places like 2600 to see if they got wind of it. But I'd recommend you assume they did, and at least apply the PTF's. They do work. IBM also recommends people change their passwords. Doug

[Guest.Visitor]

Is

Doug, PTFs were applied shortly after their clandestine announcement. You know, the ones that say "Security PTF: No further explanation." I generally waith till the weekend and do a good backup and then apply. Our workforce has to change passwords every 60 days, so I don't go out and make everybody create a new one, like I did in the early days. I figured out how to use DSPUSRPRF to an *OUTFILE and do all kinds of things to profiles by reading the *OUTFILE in CL and applying changes globally. Testosterone level went down over the years, and I quit doing this and put it off on the user. Later, Bret

[Guest.Visitor]

Is

John, I've run the DMPSYSOBJ command for my own user profile, as in: DMPSYSOBJ OBJ(LIAM) CONTEXT(*MCHCTX) OBJTYPE(*USRPRF) but I can't make very much sense of the output. Is the password encoded in the output? If so, do you need to be a rocket scientist to read it? On a related topic, wasn't there some recent news about a programmer who had "cracked" the AS/400's encryption algorithm? Liam.

[D.Handy]

Is

Liam, I've run the DMPSYSOBJ command for my own user profile, as in: The DMPSYSOBJ referred to in the other post was for a 1-line equivalent of the infamous 17-line RPG program. It had nothing to do with an individual profile. It (without the PTFs loaded) provided the cleartext userid/password of the last signon in your subsystem. Or at least part of the time it did. If the last subsystem operation was displaying a signon screen instead of someone pressing Enter at one, you did not get a password and had to try again later. Is the password encoded in the output? No; it is not even stored in the user profile object. And if you did dump the right object, you'd find it is encrypted and "impossible" to read. Even if you knew the encryption algorithm, you could not decrypt it. It uses so-called one-way encryption. You *cannot* decrypt it. To validate a password, the system encrypts your guess and compares the encrypted values. do you need to be a rocket scientist to read it? No, but it helps if you understand how 56-bit DES encryption works. It is just one of the steps involved in the process. You can find more information on how DES works here. On a related topic, wasn't there some recent news about a programmer who had "cracked" the AS/400's encryption algorithm? Yes, this happened last year. But even armed with the encryption algorithm, you *cannot* directly decrypt the password. The "crack" uses brute force and the power of modern PCs. Using a Pentium III 600MHz or so, a program will just sequentially try all possible permutations of valid password characters trying to get the encrypted values to match. Eventually it gets a hit. In theory this could have been done even back in OS/400 V1R1M0, but the encryption algorithm was not publicly known then. And even if it were, the computing power available to (most) crackers was a tiny fraction of what it is today. This power is what makes brute-force attempts at matching practical. To make this work, you also obviously need the encrypted value you are trying to match against. As mentioned above, it is not stored in the user profile. In V4R5 the DMPSYSOBJ command was modified so that even if you were to dump the right object, you would not get the encrypted values. There are still other ways to get it, with sufficient authority, but DMPSYSOBJ won't be one of them starting with V4R5. Moral: Brute-force cracking is real. If a person were to take a dictionary of words and "common" sequences (like appending a digit) then produce a table with the equivalent encrypted value, it would be possible to match "weak" passwords against the table yielding the decrypted value instantly. This is why you never want to use a real word variant for your password. It is by far best to use what appears to be a random sequence of characters. Sorry Liam, but you've proved my point. We've gone from allegedly trying to validate the PTF is applied correctly to information on decrypting a password. This belies your original question. Doug

[Guest.Visitor]

Is

Doug, Well said. jte

[Guest.Visitor]

Is

Doug, If by "belie" you mean that my query has a false basis, then frankly I'm offended. The progression of the topic from my original query to a more general line of dicussion of passwords seems natural to me, especially in a professional forum like Midrange. I, and my clients, are eager to 1/ ensure that these PTFs work, and 2/ to follow-up any other known security threats. L.

[D.Handy]

Is

Liam, If by "belie" you mean that my query has a false basis, then frankly I'm offended. Perhaps I should have left that part unsaid. Diplomacy was not always my strong point. Whatever your intentions, the information would also be valuable to those with less than honorable intentions. Hopefully you can see my perspective. I've been trying to answer the questions in a manner which discusses the vulnerabilities without putting less diligent site more at risk. I, and my clients, are eager to 1/ ensure that these PTFs work, and 2/ to follow-up any other known security threats. For item 1, I'll offer the stock phrase "trust us on this one". There were enough people outside of IBM (including me) who have the three methods all exploiting the same exposure (DMPSYSOBJ cmd, MI pgm, or RPG pgm) that you can be sure there has been independent verification the PTFs work. The problem is that they only work if applied. Lots of shops will not get the PTFs until the next time they do a cume (I'm assuming it will be on a cume), and lots more stay at least one cume behind or worse don't do it at all. Therefore I'll reiterrate my stance that I don't believe it is in the public interest to post it again at this time. For item 2, there is a lot more to cover than is practical for this forum. It is a large topic. I'd suggest you may want to follow up privately with John Earl -- security is a specialty of his. Regarding the specific mention of last year's discovery of the encryption algorithm leading to the ability to brute-force match a password, I'd be alot more concerned about plugging other holes which are much easier to exploit. I'm very aware of how the brute-force thing works -- I even have a copy of the PC program (object code only) which does it. Pretty impressive; but in fairness to IBM, most people won't have the knowledge and/or authority to get an important prerequisite -- the encrypted password to match against. However, if you have any PC's connected to the AS/400 (or other non-PC systems with a link like TCP/IP), then I strongly suggest you need to understand exit point programming. Or buy a package from someone who does. Unfortunately, the other side is starting to learn about exit programs too. As a case in point, see article 3 in the May 2000 issue of Phrack, at http://www.phrack.com which proves these people are getting more sophisticated. Worrying about the password crack program while staying on level 30 or not implementing exit programs and proper object authorities is like straining at a gnat while swallowing a camel. Get to at least level 40, secure your objects, use the SECTOOLS menu, and implement exit programs (purchased if necessary). Oh, and install the PTF's. Until you do these things, your system is *not* secure. "Trust me on this one." Doug