Your AS/400 is the most secure computer system in the world—when properly configured. Even the most secure system, however, must let people in to use it. Controlling who has access to your system through the use of user IDs and encrypted passwords is one of the most foolproof means of making sure only authorized people can log on. What happens, though, when unauthorized people steal valid user IDs and passwords? You no longer have a secure system. This article demonstrates how your AS/400 passwords can be stolen. It also offers suggestions on what you can do to prevent those thefts.

The security on the AS/400 may be the tightest security on any computer in existence. Through the use of various security levels, object-level security, authorization lists, and one-way encrypted passwords, the AS/400, when properly configured, can achieve the United States government’s highest security rating: C2. This means that an AS/400 configured this way can safely guard our nation’s and our industry’s most valued information from potential hackers and others with malicious intent. Even when it is not configured at its most secure level, this system can still provide nearly foolproof security to prevent unauthorized access to your company’s data. The human animal, however, does not like to be told no, and even the tightest computer security must, by definition, have flaws. Without those flaws, you would have nothing more than an electronic marvel that no one could access. The combination of these two elements can work together to exploit the one weak point of the AS/400: the user logon sequence.

The Past Is Tied to the Present

As legend tells it, once upon a time, a Greek peasant named Gordius drove his oxcart into the public square in the village of Phygia in ancient Greece. What Gordius didn’t know was that an oracle had foretold that the future king would come riding in on an oxcart. Upon seeing this man, the people of Phygia made him their king. To show his gratitude, Gordius dedicated his oxcart to the god Zeus and tied it up with an intricate knot that no one could untie.

Now here’s an example of security in the ancient world. We have a system, the knot, that is impenetrable to all who would attempt to gain illicit access, much like the AS/400.

As with the AS/400’s passwords, this knot provided the highest level of security to thwart all improper attacks.

A More Direct Approach

As I said earlier, though, man is an ornery beast who hates to be told that he cannot do something. Where there is a challenge, someone will come along to take it up.

In this case, that someone was Alexander the Great. At that time, Alexander was a young man who, having just begun his career, wasn’t really all that great yet. During his travels, young Alexander heard the legend of this knot and pointed his elephant toward Phygia, where, as the story goes, he found the oxcart still tied up in the public square. Alexander, although he had spent many years studying under Aristotle, was not so much a great thinker as he was a man of action.

When presented with this challenge, Alexander didn’t waste time trying to tease the rope to give up its mystery and untangle itself. Instead, he took a more direct approach and cut the knot in two with his sword. Incidentally, he was also history’s first hacker.

Methods and Madness

Here was a great example of lateral thinking, or the ability to look at a problem from a different angle to come up with a unique solution. The AS/400’s passwords are much like the Gordian knot in that they too defy all attempts to crack them. The way encryption is used to hide passwords from prying eyes is like the many intricate loops and swirls of the Gordian knot. However, like the Gordian knot, the AS/400 can be made to give up its security if you apply a little lateral thinking and attack the problem in an oblique, rather than head-on, manner. You can be sure that hackers won’t waste their time with a frontal assault. Instead, they’ll look for ways to come in through the back door.

This article will focus on three methods a potential hacker can use to steal your passwords. For a look at another means of allowing someone to sign on to your AS/400 without any user ID or password, check out the sidebar “Default User IDs Can Be a Potential Security Breach.” While it could be argued that the very discussion of these methods will lead to their use and abuse, it can also be argued that not knowing what these potential security violations are could lead to your AS/400 being broken into without your knowing anything about it. Since it doesn’t take a genius to discover these methods, it’s better to be aware of what they are ahead of time than it is to drive yourself to madness trying to figure out what went wrong after it’s too late.

Another History Lesson

Let’s take another trip back in time and look at a famous example of the use of deception to gain illegal access to a secure system. The AS/400 in this case was the city of Troy, and the hackers were the Achaeans. After a 10-year battle between the Trojans and the Achaeans, during which time the Achaeans were unable to gain access to the city, someone among them came up with the idea of building a giant wooden horse and presenting it to the Trojans as a gift. When the Trojans brought the wooden horse inside the gates of the city (penetrating its security), the Achaeans, who had been hiding in its belly, jumped out and destroyed them. The Trojans suffered because they were taken in by a seemingly innocent object.

In much the same way, your AS/400 is vulnerable to an attack like this by the use of a Trojan horse program designed to mimic your sign-on screen. It is a simple matter to create a CL program that overrides the QDSIGNON display file to another workstation’s display device. When a user attempts to sign on, he types his user ID and password into

the false display file, and the CL program passes that information to a database file or another user’s message queue. The unknowing user sees the display file blink and then reappear with blanks in the user ID field. To this user, it appears as if the login information he keyed in was not accepted for some reason and the AS/400 has redisplayed the sign-on screen. What really happened is that the Trojan horse program ended once it got the information it was after and the real sign-on screen was finally displayed. This is probably the easiest method of stealing user IDs and passwords that doesn’t involve overhearing someone’s password or reading it from wherever the user wrote it down. It doesn’t take a lot of work, and it is easily implemented by anyone with authority to use the Override Display File (OVRDSPF) command and with authority to the QDSIGNON display file in QSYS.

I Saw What You Did!

Another method of stealing passwords and user IDs takes many forms. This technique involves capturing the logon information as it travels along your communication routes by using a communications trace. On the AS/400, communication lines and network descriptors can be traced using the Start Communications Trace (STRCMNTRC) command. Anyone with authority to that command or anyone who has access to the System Service Tools can use it to “watch” a comm line or network interface. When there is activity on that device, the trace captures it and stores the data for later viewing.

For example, let’s say you have users who log on to your AS/400 through your main twinax controller, CTL01. CTL01 might use communication line QTDL43123 (or whatever). If you have a communications trace running for that line, you will see the user IDs and passwords of everyone signing on through that controller come across in plain, unencrypted text. In fact, any method you can imagine of logging on to your AS/400 can be traced, since all routes must ultimately use a communications resource such as a comm line or network interface.

Who’s vulnerable then? Let’s list them:
• Users signing on using twinax.
• Users signing on using TCP/IP.
• Users signing on using AnyNet.
• Users signing on using WinAPPC.
• Users signing on using 802.2.
• Users signing on using Async.
• Users signing on using Novell NetWare for SAA.
• Users signing on using SDLC.
• Users signing on to remote systems using display station pass-through (DSPT).
• Users signing on to remote systems using embedded SQL.
• Users logging in to remote systems using the Intersystem Communications Function (ICF).

• Users who access the AS/400 through ODBC/OLE calls.
• Users performing file transfers from PCs. This is only a partial list, but already it probably covers more than 95 percent of the ways to access your AS/400. The STRCMNTRC command can be deadly to your systems if used by unauthorized or unscrupulous people.

Another Trace Method

Another way to trace security information is through the use of the Trace ICF (TRC-ICF) command. This command is used to debug problems with ICF sessions. While ICF does not share the same level of popularity as other methods of remote

communications, such as TCP/IP, it is still a workhorse in many installations, especially those in which an AS/400 must communicate with a mainframe. The TRCICF command will display the data transmitted in both hex and plain English, much like the STRCMNTRC command. Sensitive information such as user IDs and passwords can easily be retrieved from this trace and used to gain illegal access to both the originating and the remote systems.

Attacking from the Other End

On a PC, it is a simple matter to trace ODBC calls using the trace function built into the ODBC Administrator in Client Access/400. Simply clicking the Trace tab in the ODBC Administration panel gives you access to the tracing function. Someone can start this trace function on the PC, and then, as the unsuspecting user does his daily work, his every action is logged to a trace file on the PC. Later, the hacker can go back to that PC and view the trace file to locate the user ID and password used by ODBC to log on to the AS/400.

The Sneakiest of All

Perhaps the sneakiest method of stealing user IDs and passwords is when someone uses a display file that contains the User-defined Data Stream (USRDFN) keyword to capture information from an AS/400 sign-on screen. User-defined data streams (UDDSs) are another way of manipulating 5250 displays. Using USRDFN, you can actually capture a screen image, just as the Start Copy Screen (STRCPYSCN) command or a PC application such as Paint Shop Pro does. If it can be displayed on a 5250 screen, it can be captured. That image can be stored in a data area or a database file or printed on a report. The source code examples in Figures 1 and 2 show how to create USRDFN screens that capture another screen image. By itself, this technique is harmless and could even be put to many good uses, such as a help desk debug utility for displaying screens on interactive jobs in remote locations.

However, this tool can be used as a mole, buried deep in your AS/400, where it steals the most precious of your secrets.

But I’d Know Something Funny Was Going On, Right?

Actually, no. By retrieving the 5250 sign-on screen image just after the user enters his security information and presses the Enter key, the program capturing that image could retrieve the display fields after AS/400 security validation has occurred. Unlike the Trojan horse method, in which the user must sign on twice, this method never alerts the user to any problems, since the login process is not interrupted.

There are at least three simple methods for using a program such as this to rob your users of their passwords. If someone had authority to change user profiles, he could place this program as the initial program to call when users sign on. If he didn’t have authority to change profiles but was able to change the initial program already assigned to a profile, the program containing the UDDS could be placed inside the initial program as the first program called. Finally, and perhaps the most damaging of all since it could potentially affect everyone on your system, this program could be placed in a routing entry in your interactive subsystem (usually QINTER). Under this scenario, every user signing on to an interactive session would be targeted by this program.

What Can Be Done?

Prevention and auditing are the best things you can do to combat these methods of hacking into your AS/400. Use the following list as a guideline to developing your own controls.

Use object-level security to secure the QDSIGNON sign-on screen display file, or whichever display file you may be using as the signon display, and then restrict its authority to *PUBLIC *USE only. Only the security officer profile should have access to

change this file. This will keep someone from being able to use Override Display File (OVRDSPF) on it.Use object-level security to secure STRCMNTRC and TRCICF. Once again, only the security officer profile should be able to use these commands. If you have a developer with a legitimate need to use one of these commands, you can grant temporary authority to it and remove it once the task is completed.

For PCs, you can remove the ODBC Administrator Icon from the Client Access/400 (CA/400) folder. In Windows 95 with the V2R3M3 version of CA/400, just highlight the icon and press the Delete key. If you are using the new release of CA/400, V3R1M3, use the Settings function from the Windows 95 Start menu to remove the icon

from the Programs menu. If you feel the need, you can even remove the Dynamic Link Library (DLL) used by the ODBC trace function. It is named ODBCTRAC.DLL and is in the C:WINDOWSSYSTEM folder. Make sure you empty the recycle bin to permanently remove these objects from your PC once you delete them.

The technique that uses a UDDS is going to be harder to secure. The best approach to take for this is to verify that only authorized, trusted individuals can change user profiles. Also, make sure that initial programs are not part of a group profile. If they are, a programmer-type person who is also part of that group could replace the original initial program with one containing the UDDS program. Once again, use object-level security to protect these programs from unauthorized access.

Secure your subsystem routing entries using the commands that can add and change them: Add Routing Entry (ADDRTGE) and Change Routing Entry (CHGRTGE). Only the security officer profile should have access to these commands.

Do not allow your users to have *ALLOBJ special authority. It can be a real bother to have to grant authority to objects all the time, especially to your developers, but, by limiting who has this authority, you remove a major weakness in your system security.

Review programs that use adopted authority to ensure that you are not inadvertently granting authority to one of those commands you don’t want unauthorized users to have access to (see “Object Security by Adoption” in this issue of Midrange Computing).

Review user profile initial jobs, looking for anything out of the ordinary. Be especially vigilant for programs you are unfamiliar with. IBM even provides you with some free security tools to help with this task. See “Track System Security with IBM’s Free AS/400 Security Tools” in this issue of Midrange Computing.

Use the system security auditing feature to track what goes on in your system. Don’t let problems catch you unaware.

A Secure AS/400 Is a Happy AS/400

I hope the information presented in this article will get you thinking about other ways your system security can be breached. Although the methods presented here are probably the most common techniques used to rob your users of their passwords, they are by no means the only ones. It’s a good idea to always keep in mind the lesson taught to us by Alexander the Great—if someone wants something bad enough, he will find a way to get it. Developing and practicing good, common-sense security practices, however, can keep your system safe.

References Application Display Programming V4R1 (SC41-5715, CD-ROM QB3AUK00) AS/400 Security—Reference V4R2 (SC41-5302, CD-ROM QB3ALC01) OS/400 Communications Management V3R7 (SC41-3406-02, CD-ROM QBKANG03)

Default User IDs Can Be a Potential Security Breach

It is possible to set up a subsystem in a manner that allows users to log on to your AS/400 without requiring them to enter a user ID or password. Why would you want to do this? You might have a situation in which you need to have a multitude of users who are restricted to very specific tasks and areas of your AS/400, but for whom you don’t want to set up individual profiles. This could be due to a high turnover rate in a given department, or perhaps you have a secure public terminal to allow some type of inquiry. Whatever the reason, you should know that this method is available and be familiar with how it works. That way, you can monitor for its use in any situation that you weren’t expecting.

The default in the USER parameter on the Create Subsystem Description (CRTSBSD) command is *RQD, which means a valid user ID and password are required to use this subsystem. This means you must explicitly enter a valid user ID and password when you sign on. However, by placing a default valid user profile in that field, you are telling the system to use that profile for any job running in that subsystem. You could then set up default workstation device entries in that subsystem description, using the Add Workstation Entry (ADDWSE) command. Now, when a workstation device of that name attaches to the AS/400 (and it can be a partial name using the asterisk wildcard character), it will automatically be routed to that susbsystem. This workstation can now start an interactive job by having someone press the Enter key. No user ID or password is required, since one has already been entered in the USER parameter of the
subsystem description.

This technique works only at security levels of 30 or below. If you are using security auditing, an audit entry will be placed in the audit journal of type AF, subtype S. For levels 40 and 50, this method of logging on to your AS/400 is not supported. To prevent this type of unauthorized access, you should regularly review your subsystem descriptions for discrepancies and limit who has authority to change subsystem descriptions.
—SO

*****************************************************************

* *

* To Compile : CRTDSPF FILE(xxx/CAPSGND) SRCFILE( xxx/QDDSSRC) + *

* SRCMBR(xxx/CAPSGND) *

* *

*****************************************************************

A R CAP01

A OVERLAY

A IMGFLD 1919 B 1 2

A R DUMMY USRDFN
_

*****************************************************************

* *

* To Compile: CRTDSPF FILE(xxx/CAPSGND2) SRCFILE( xxx/QDDSSRC) + *

* SRCMBR(xxx/CAPSGND2) *

* *

*****************************************************************

A R CAP01 USRDFN

A R DUMMY

A IMGFLD 1919 B 1 2

Figure 1: Display files used to capture a screen image with the UDDS

/*********************************************************************/

/* */

/* To Compile: */
/* PGM( xxx/CAPSGNINF) SRCFILE(xxx/CAPSGNINF) + */
/* SRCMBR(CAPSGNINF) */
/* */

/*********************************************************************/

PGM

DCLF FILE(*LIBL/CAPSGND)

DCL VAR(&BUFFER) TYPE(*CHAR) LEN(7) +

VALUE(X’00020780730462’)

DCL VAR(&USERID) TYPE(*CHAR) LEN(10)

DCL VAR(&PASSWORD) TYPE(*CHAR) LEN(10)

/* Override Required When Using User Defined Data Stream With */
/* A Field Value Greater Than 100(Default Screen Field Size). */

OVRDSPF FILE(CAPSGND) TOFILE(LIBNAME/CAPSGND2) +

LVLCHK(*NO)

/* Set 5250 Data Stream Buffer To Send Proper Line Controls */

CHGVAR VAR(%SST(&IMGFLD 1 7)) VALUE(&BUFFER)

/* Send/ Recieve Screen Image Capture With User Defined Data Stream */

SNDRCVF RCDFMT(CAP01)

/* Send Signon Information To Designated User Message Queue */

CHGVAR VAR(&USERID) VALUE(%SST(&IMGFLD 453 10))

CHGVAR VAR(&PASSWORD) VALUE(%SST(&IMGFLD 533 10))

SNDMSG MSG(‘The Following Signon Information Has +

Been Retrieved: +

User ID:’ |> &USERID |> ‘Password:’ |> +

&PASSWORD) TOMSGQ(HACKER)

ENDPGM

Figure 2: CL program to capture a screen image