|TechTip: Audit Your Exit Points|
|Tips & Techniques - Security|
|Written by Jean-Paul Lamontre|
|Friday, 06 July 2012 00:00|
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:
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:
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 email@example.com 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.
|Last Updated on Friday, 06 July 2012 00:00|