IBM AS400 security holes from the golden age

  • Home
  • /
  • Blog
  • /
  • IBM AS400 security holes from the golden age

August 17, 2009

IBM AS400 security holes from the golden age

By NickLitten

August 17, 2009

as400, holes, legacy, security

Today, I was talking *techie* to a colleague in I.T. who still calls the IBMi Operating System – ‘The AS/400’. *sigh*

We bumped over a few technology sleeping policemen during the conversation. Software is easy to upgrade. Mindsets are sometimes overlooked. This reminded me of the importance of keeping our skill sets current. If we don’t move with the times, then our knowledge in our field of expertise quickly becomes out of date and hence ‘of less worth’. I never want to be deprecated in favor of a new version of me. I want to make my own Nick Two Point Oh.

Anyway, the gray haired dusty shouldered gentleman in question was proudly proclaiming that the AS400 would be around forever because it was the most secure machine on the planet. Then proceeded to spout some un-verifiable (and almost certainly delusional) points about the AS400 still being used to power Google Servers, the president has one and its the only machine that has never ever had a virus.

Much as I like the IBMi operating system, this made me think “exactly what is it that defines a Virus?”

I’m sure I have written some virus-type code, playing tricks on coworkers, faking signon screens, remote controlling other peoples signons, etc. Does that count as an “as400” virus?

Anyway, Searching for some examples of old AS400 Security Holes, I came across the document (pasted below).

It doesn’t really answer my questions but does discuss a lot of interesting points with reference to securing your system. Although this is talking about the legacy AS400 hardware and OS400 operating system, many of the points are still relevant to the newer IBM Power system running IBMi.

Hope it helps somebody out there:

Question: What commands are used to get auditing turned on? What commands are used to check audit logs?

 Answer: You must create the security auditing journal QAUDJRN if it doesn’t already exist. If it does exist, then you can turn auditing on for specific profiles with the CHGAUD command, or for specific object using the CHGOBJAUD command. You’ll need more detail than I’ve provided here, so refer to the manual Security – Basic V4Rx (SC41-5301) and/or the Tips and Tools for Securing your AS/400.

Question: What is the command to list the applications and their security level?

Answer: The WRKOBJ command will allow you to see (option 5) and change authority to specific objects. Use the WRKOBJ on the application library itself to determine who can even see an application (assuming that for your system ‘An Application’ means some small number of say (less than 5) libraries. If the *PUBLIC authority on the library is set to *EXCLUDE, then only those User Profiles or Group Profiles that are specifically authorized to the library will be able to use the application. Be aware that this is where the similarity to UNIX directory structure ends. If *PUBLIC authority to a library is *USE (read only), this does not mean that the public is restricted to read only access for objects in the library. Once someone has a minimum of *USE to a library, authority to objects in the library is governed by the authority of each individual object (Some could be *EXCLUDE, some could be *USE, and others could be *CHANGE, etc.)

Question: How do I limit Command line access to normal users i.e. in the USER class? I want them to interface with the system via Menu only. Can this be set system wide for all USER class members?

Answer 1. There is a parameter on the CRTUSRPRF/CHGUSRPRF command called LMTCPB (Limited capability user). When this parameter is set to *YES, the user is prevented from entering commands at an AS/400 command line. You could do a DSPUSRPRF with *OUTFILE, then use that file to do a MASS CHGUSRPRF cmd.

Note that this restriction is not absolute. The user would still be able to enter commands using the Client Access remote command and the FTP rcmd facility (prior to V4R1). To block command entry from these sources you would have to use the corresponding exit points

Question: How do I use adopted authority in a CL program?


Question: Can you reset the QSECOFR password through DST? Is this the only way?

Answer: Yes . You can also reset it using another user ID if that user ID has the required authority (is the equivalent of another security officer).

Question: Is there a way to check/zap/reset the DST passwords short of a scratch reload? Will a scratch reload reset the DST passwords?

Answer: This procedure works well

1. Put the system in manual mode.

2. Sign on to the DST sign-on screen with the DST security capability password. QSECOFR

3. Select option 5 (Work with DST Environment) from the Use Dedicated Service Tools menu.

4. Select option 9 (Change DST passwords) from the Work with DST Environment menu. Note: The menu option may be different depending on which release of OS/400 your system is running.

5. Select option 4 (Reset System Default Password) from the Change DST Password menu. This option resets QSECOFR’s password back to the default of ‘QSECOFR’.

6. F3 TWICE BACK TO MAIN MENU( NOT DST MENU!!!)—1 EXIT DST, and go back to main menu with option 1: IPL system.Your QSECOFR password will be reset and is QSECOFR.

Some more on this ..

Just a brief note…there are ways to regain access to your system if DST and QSECOFR are both lost. However, bypassing the security should probably be performed via supportline <don’t laugh>. The odds are that the DST passwords or even the operating system has not been secured.

Also, be careful if you educate a user on hacking security. The last thing you want is a misunderstanding that leads to any form of legal problems!

FYI — we always get a letter on company stationary from a corporate officer before we will reset security.

Question: In the future we will be running an application that will need the HTML Server up and access to the Internet. Of course IBM Security Manuals just say go to QSECURITY 40. What insights for problems does anyone have about Level 40 security to say standard RPG jobs that adopt user authority. How does it change profiles authority or authority lists. (12/99)

Answer 1: Going to level 40 affects more than just RPG programs that adopt authority…..Level 40 effects *every* object on the system. The best way to see where you are in prepping for such a change is to turn on the audit journal and watch it for a period of time. I did this earlier this year. Started monitoring the audit journal and it was over 60 pages of stuff printing out for the AF entries alone……You will be amazed at what will show up initially on the reports!

Another thing to watch for are vendor packages that are not level 40 compliant. ASC’s SEQUEL product had to be upgraded to be Level 40 compliant.

Answer 2: The good news is that a level 30 to level 40 jump does not involve changes to any profiles or authorization lists, and has absolutely no effect on programs that adopt authority.

QSECURITY Level 40 has two principle benefits over level 30 security. First, some well known holes regarding Job Descriptions were plugged, and second the differences between System State and User State programs are enforced (a potentially big hole most likely to be exploited by your application vendors).

The JOBD hole that level 30 addresses has two manifestations. The first is that a user could submit a job using an existing JOBD and have it run under the user profile that is named in the JOBD. If you have any JOBD’s on your system with user profiles attached, or if anyone has the ability to restore a JOBD with a user profile attached, then your level 30 system is vulnerable to this situation (hint: IBM ships JOBD QBATCH with User Profile QPGMR attached). The second is where a JOBD can be specified on a Subsystem’s Device description so that users could get on to the system without actually signing on (there was a thread out here last week about doing this for a printer support terminal). At level 40 this is no longer allowed.

The other major hole that QSECURITY Level 40 plugs is a problem where (mostly MI) programs can illegally acquire authority though the misuse of pointers. At Level 40 the MI instructions that allow this are restricted from “user domain” programs (It’s actually more involved than this, but this is the quick explanation :). At level 40 some third party software may have a problem (Hawkeye is the only one that I’ve seen recently that uses these unsanctioned interfaces, and even they have a work around for it). As others have mentioned, you should turn on the Security Audit Journal (QAUDJRN) to log any potential violations prior to actually moving to QSECURITY level 40. This can be done easily with the CHGSECAUD command (it creates QAUDJRN and a receiver, and handles receiver rolling for you). You need to monitor for *AUTFAIL and *PGMFAIL, but don’t get fooled into thinking that every authority failure entry (Journal Type AF) is a level 40 violation. You need only be concerned with types B,C,D,J,R, & S. My prediction is that the number of these entries will be few.

Section 2.4 in the Security Reference Manual will give you all the details you need.

Question: Is there a URL out there that shows step by step the requirements forchanging from QSECURITY 30 to 40? Pros/Cons? Anyone who’s gonethrough this? Is it worth it? (1/2000)

Answers: Try this:

One “gotcha” was with vendors. Some of them had programs that are sensitive to the security level. When we planned our upgrade the second question I got from several vendors was “what security level will you be running?”. I told them security level 40 and they changed the distribution CD. All of my vendors’ technical folks knew about security level 40; all knew what the impact (if any) was to their product(s) right off the bat. I’d suggest a “poll” of you vendors would be in order before “throwing theswitch”. You may have to re-install some products.

Question: What should I do if I find a security vulnerability (or something that looks like a vulnerability) in an AS/400? (6/2000)

Answer: It is best to use the normal support channels. Anyone can report errors free of charge via ECS or via (note this website does not exist – jsut like the precious old AS400) and then selecting problem reporting. Users must first register at the Web site and need a customer number and machine serial number. Users are also free to report these problems through their business partners which many times also have a support contract.

Be sure to clearly state that the problem is a security problem and your opinion of its severity.

Also at the Web site, users can select PTF Maintenance and view/search for all HIPER and/or data Integrity PTFs for a particular release. User’s should also able to order or download PTFs from this Web site.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Join the IBM i Community for FREE Presentations, Lessons, Hints and Tips