System State Programs

Question: All of our boxes run at QSECURITY level 40, and we don’t buy software from vendors that don’t support this security level. Recently, I loaded a software product that did some funny stuff during installation. The installation procedure insisted that I sign on as QSECOFR, and when it completed, it created a 450-page dump. I’m no MI [machine interface] programmer, but looking at this dump, it appears that the vendor started the system service tools (STRSST) and then changed some of their programs to be system state. This has me a little worried, and I’m wondering if there is any way to protect our box from this sort of activity.

Answer: To begin with, I understand your desire to avoid programs that violate system state integrity. While there still may be some legitimate reasons for a vendor to skirt this control, there is no excuse for the vendor to take matters into his own hands and not give the system administrator the benefit of choosing not to load this software. Many system administrators feel very strongly that any changes to system resources are theirs to make (or not to make), and third-party vendors ought to ask permission before making changes that could affect the entire system. After all, if any problems arise as a result of this change, it is the local system administrator who is going to receive the first trouble call, not the software vendor. The local system administrator ought to have the option to review and decide whether to make changes of this scope.

The good news is that the IBM security team is very aware of this kind of problem and has given you some new tools to deal with it. Beginning with V5R1, IBM has made two specific changes that will give you the ability to control whether and when system state programs can run on your box.

First, V5R1 will add new ability to restrict access to the dedicated service tools (DST) and system service tools (SST). Under current releases, a user with *SERVICE special authority in his profile is able to execute the Start System Service Tools (STRSST) command and use all of the tools that it presents. Under V5R1, the system administrator will be allowed to create new user IDs for the service tools that require a valid password in order to invoke DST and SST. These new profiles can be restricted from service tools such as Display/alter/dump, thus preventing any tampering without your knowledge and consent. If you enable password security for DST and SST, you can effectively prevent a

vendor from turning a program into system state without your knowledge. Now, the vendor who sent you this software will have to ask first before poking around under your system’s covers.

The second enhancement that IBM has put into V5R1 is probably the biggest thing for operating system security since the advent of the resource security itself. Beginning with this release, all executable objects in the operating system, the IBM OS/400 Licensed Program Products (LPPs), and any OS/400 IBM PTFs will be signed with digital certificates that ensure the object’s authenticity. Digital signing provides you with ironclad assurances that these IBM-supplied objects are genuine and unmolested. This is an important new development for any shop that has ever been haunted by the sheer number of unverifiable objects that IBM includes in its operating system or LPP build. To inspect these new digitally signed objects, you can ask the system to verify each object as it is restored to your system, or you can run a verification step at any time by running the Check Object Integrity command (CHKOBJITG).

V5R1 also gives you the ability to sign your own objects, if you choose. A new

API allows you to apply your own digital certificate to every object that you create. In the future, I would expect that digital signatures will be quite important for software vendors and in-house development staff alike.

Industrial-Strength Passwords

Question: Last year about this time, there was a big dust-up about the security of OS/400’s password encryption technology. But I haven’t heard a word about it in over a year. Is there still a problem with the encryption of passwords? Can you tell me what is going on?

Answer: A lot! It was over a year ago that someone boasted in an Internet forum that he could break OS/400’s password encryption by using a PC and a readily downloadable password cracking tool from the Internet. Since that time, IBM has been quietly working on some enhancements that, if you deploy them, should cause this password threat to recede considerably. The problem with OS/400 passwords under V4R5 and lower is that the encryption tool actually carries two copies of the password: the standard OS/400 copy and an identical second password that is used by interfaces with PCs and network operating systems through NetServer. It was this second password that was weaker and therefore more vulnerable to attack. And it was this second password that only withstood
6.7 hours of a brute force attack from a Pentium PC running the password-cracking tool before it surrendered a valid password for an existing user profile.

While there were a number of interesting facets to the problem, chief among them was the fact that OS/400 passwords are constructed of a relatively small character set. Password values on OS/400 V4R5 and below can be comprised of the letters A through Z (in uppercase only), the values 0 through 9 (but a digit is not permitted to occupy the first position), and these characters: at symbol (@), pound sign (#), dollar sign ($), percent symbol (%), and underscore (_). This relatively small set of characters, coupled with the small size of the actual password itself (often between six and eight characters), makes OS/400 passwords more vulnerable to a brute force attack than you might have guessed.

Luckily, V5R1 changes all that by allowing you to specify passwords (pass phrases, really) that are up to 128 characters in length and can contain all of the characters in the Unicode set (including embedded blanks and lowercase characters). This new development will make a brute force attack much more difficult, as it increases the size and the range of characters that must be tested.

To affect this change, a new system value called Password Level (QPWDLVL) and four new password values will control how the new password lengths are stored and used. The default value for QPWDLVL will be 0 and will cause your system to treat passwords the same way as it has done under V4, V3, and V2. A QPWDLVL equal to 1 will eliminate

storage of the weaker NetServer password while retaining the original 10-character password length and standard OS/400 functionality. When QPWDLVL is equal to 2, a new 128-byte “pass phrase” is permitted that will significantly enhance password integrity. But even though Password Level 2 looks more secure, it really isn’t. Sure, Password Level 2 adds a new 128-byte password field, but it still retains the old NetServer and old 10-byte OS/400 passwords that were so vulnerable to attack. Effectively, Password Level 2 is really just a stepping-stone that allows you to check your application’s compatibility to Password Level 3.

Password Level 3 is where things start to get real interesting. Password Level 3 eliminates storage of the old OS/400 and NetServer password formats and replaces them completely with the new 128-byte pass phrase. Due to its 128-byte size and increased character set, Password Level 3 will make guessing (and typing!) passwords more difficult than ever before. For those of us familiar with the traditional 10-character passwords, this new 128-byte capability may be difficult to get used to, but the added protection will be well worth the adjustment.

Stopping FTP Attacks

Question: We’ve got someone who keeps coming after our iSeries with FTP. They try to sign on with a variety of profiles and passwords, but thankfully haven’t been successful yet. The invalid attempts come in such rapid succession that it appears that an automatic sign-on program is being used. Isn’t there a way to disable the FTP device so that someone can’t continuously attack our iSeries?

Answer: The iSeries FTP server does not use a device in the traditional OS/400 sense, and therefore you can’t set one to be disabled. But more good news with V5R1 is that a password delay algorithm has been added to the FTP sign-on process. This delay process will steadily increase the time it takes for the iSeries FTP server to respond with a sign-on prompt after an invalid sign-on attempt. This may be a minor irritant to your users, but it will be a major bummer for Internet script kiddies who attempts to invade your FTP server.