Did the previous administrator leave the machine clean, or did he leave a time bomb somewhere?

Suppose it's the beginning of a new year, and the first time the human resources manager logs into payroll, he unknowingly sends the file of annual salaries to an email address it shouldn't go to, by directly Telnet-ing port 25, something discreet and undetectable.

This scenario is not absurd. Programs to implement this feature are not very complex; the mechanisms to implement them are public and very well-documented on the Internet.

The question I raise is this: If I were a malicious administrator, how would I trigger this code so that information leakage can continue for years without anyone noticing?

There are many options available, and one I find most insidious is to have the i5/OS do the job. Simply hook an exit program onto the "good" command of the payroll software. This program must also stay resident on the machine. This is not the subject of this article, but if you do not check regularly that programs in QSYS are all created only by the user *IBM, it is easy.

The method is particularly insidious because:

• Did you think to use an exit program?
• To list the exit programs attached to each exit point is particularly laborious: WRKREGINF does not output to OUTFILE.
• There is no visible link between the caller and the called program, such as DSPPGMREF info.
• Doing a DSPOBJD or DSPPGM of each program attached to an exit point to see if its attributes are consistent is a boring, long, repetitive task.

To help you easily and regularly analyze the list of programs attached to the exit points, I propose the RTVEXIT command. This command produces the same output as WRKREGINF EXITPNT (*ALL) FORMAT (*ALL) OUTPUT (*PRINT), but with an output to *OUTFILE.

This command produces three files:

• EXTI0100—A list of exit points
• EXTI0200—A basic list of exit programs
• EXTI0300—A detailed list of exit programs

These three files are formatted as much as possible in accordance with the formats of the same name of the Retrieve Exit Information API (QusRetrieveExitInformation).

With these files in hand, you can, for example, regularly verify globally whether something has changed (if you save the results of your previous analysis).

The SQL statement below will generate what's shown in Figure 1:

Select Pgmlib, Count (*) From Qtemp.Exti0200 Group By Pgmlib Order By Pgmlib

Figure 1: Here's a list of libraries that have exit programs.

On this machine, there is an exit program that comes from the library JPLTOOLS. I know it well; this is my test program for the exit point QIBM_QCA_RTV_COMMAND. The purpose of the test is to send a message to the job log each time the command RTVEXIT is used. I'm showing you this just as an example.

How do you check that the 64 exit programs in QSYS are actually IBM programs?

Start with the QSYS program's description:

DSPOBJD OBJ (QSYS / *ALL) OBJTYPE (*PGM) OUTPUT (*OUTFILE) OUTFILE (QTEMP / OBJD)

Join that to the EXTI0200 file to get the answer:

SELECT ODCRTU , COUNT(*) FROM QTEMP.EXTI0200 LEFT JOIN QTEMP.OBJD ON PGM= ODOBNM WHERE PGMLIB ='QSYS' AND (ODOBTP IS NULL OR ODOBTP ='*PGM' ) GROUP BY ODCRTU

Figure 2: Now you know about the 64 IBM exit programs.

Among the 64 exit programs reported in QSYS, 39 come from *IBM and 25 are not available on this machine. So there's nothing to report about exit programs reported in QSYS.

To fully automate the process, there should be a DSPOBJD of each library listed by the first SQL statement, and then improve the join to accommodate the library. It's fairly easy to achieve; I can even do it (send email to This email address is being protected from spambots. You need JavaScript enabled to view it. for more info).

In conclusion, we can say that all tools used to secure a machine can also be used to secure a piracy.

Auditors do not like when the security of a machine is carried out internally. Why? Because it's so easy to add a discreet wart when you know where to set it.

You have clean up your machine by securing your exit points. You must, even if you don't use them. Why? To detect when a malicious user adds one! How? With the system audit journal. If you use pre-V6.1 i5/OS, look at the January 4, 2012, issue of Dan Riehl's newsletter. He exposes how to audit the exit point registry itself.

For IBM i V6.1 and later, add *SECCFG to the sysval QAUDLVL so the system audit journal exposes generic record (GR) entries related to exit points. Then, query your audit journal for these GR entries regularly. It's easy with dedicated software. I know a very good one very well.

Jean-Paul Lamontre has been working on IBM machines since 1976. His first was a 3/15 with 128K RAM (the biggest machine of the county). His first program was an RPG program, no more than 15 lines. It never compiled, and nobody ever understood why.

 

Currently, Jean-Paul divides has work time between two companies.

 

For Cilasoft, which offers the Cilasoft Audit and Security suite, he is the director of development. The Cilasoft suite is a cornerstore to any company's compliance process.

 

For Resolution, which offers Xcase, a database engineering suite, he is the CTO of the IBM i department. Xcase allows developers to modernize a DDS database to DDL, discover and implement implicit relationships, and manage SQL databases using an advanced GUI.

 

Jean-Paul also publishes some free tools on his personal Web site. Most popular are SQL2XLS, SPLF2PDF, and MAIL.