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
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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online