Guru: The Finer Points of Exit Points

June 27, 2022 Bruce Bading

Many years ago, we received a call from an IBM i customer stating that all exit points were gone and the QAUDJRN and receivers were missing. Then the question, “Do you think we’ve been hacked?” Truth was, the exit points weren’t gone; the associated programs had been de-registered. Conclusion, they had most likely been compromised.

The IBM i platform is a very securable system that can be secured (Secure vs Secured – What’s the difference?, WikiDiff), if you take steps to secure it.

On the IBM i, a limited number of functions provide an exit so that your system can run user-created programs to perform additional checking and validation. Exit programs, however, can be difficult to design, and they are rarely foolproof. Exit programs are not a replacement for object authority, which is designed to protect your objects from unauthorized access from any source (Securing your workstations – IBM Documentation). We also often hear the term compensating controls when discussing IBM i security and exit programs are often referred to as a compensating control. So now, let’s look at PCI’s definition of compensating controls. The PCI DSS Appendix B refers to compensating controls as follows.

Compensating controls must satisfy the following criteria:

• Meet the intent and rigor of the original PCI DSS requirement.
• Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Navigating PCI DSS for the intent of each PCI DSS requirement.)
• Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)
• Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.

Reading the above in its clear context, most QSAs do not even consider exit point security a valid compensating control for lack of object authorities. They don’t provide mandatory file/object access control (a PCI and SOX requirement), they are a network control. They don’t go above and beyond other PCI DSS requirements and they don’t fit any of the other requirements for a PCI compensating control.

Here’s an example: PCI DSS 7.2, establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

This access control system must include the following:

• 7.2.1 Coverage of all system components
• 7.2.3 Default “deny-all” setting

Don’t get me wrong, exit programs are part of a system’s overall security, but again, read carefully what IBM states, they are not a replacement for object authority. They can however enhance existing network controls as in the following example:

SECURELIB/OBJA sets the *PUBLIC authority to *EXCLUDE. USERA and USERB are the only accounts that have *CHANGE authority to OBJA. This is a valid mandatory access control. But the administrator of the system does not want USERA and USERB to have ODBC access to OBJA and implements an exit program to enhance the network control by disallowing ODBC access to USERA and USERB.

The same example however would not provide the intent and rigor of a proper access control if the *PUBLIC had *USE authority to OBJA because even an ODBC restriction would leave other access methods available to all users. Some examples would be a command line from a remote server or PC, an unsupported ODBC driver that does not use the standard exit points and DDM/DRDA to name a few. Further, many ODBC drivers allow alias statements. Consider the following example:

The CREATE ALIAS statement (Db2 for i SQL: Creating and using ALIAS names, IBM) defines an alias on a table, view, or member of a database file at the current server.

>>-CREATE--ALIAS--alias-name------------------------------------>
 
>--FOR--+-table-name-+--+-------------------+------------------><
        '-view-name--'  '-(--member-name--)-

In the above example, JOE might be rejected by the exit program if he tried to open an ODBC connection to PAYROLL/EMPLOYEE file. But he may be allowed ODBC network access to the WAREHOUSE/SHIPTICKET file.

JOE would now create an alias with the following SQL statement.

CREATE ALIAS WAREHOUSE/SHIPTICKET FOR PAYROLL/EMPLOYEE

Next:

SELECT * FROM WAREHOUSE/SHIPTICKET

And guess what JOE is looking at.

Employee		Pay/Hr.		MTD		YTD
Tom Adams		35.00		5,600.00		45,000.00
Susan Thompson		25.00		4,000.00		32,125.00
George Smith		18.80		3,008.00		24,185.00

This is not a design flaw of the IBM i or a defect in the exit program, but a design feature of many ODBC drivers.

So now let’s concentrate on DDM/DRDA for a moment. DDM/DRDA security is dependent on several different things. Relational database entries, server authentication entries and DDM TCP attributes among others on the IBM i and connection instances for DB2 Connect in Windows and Linux. The problem with DDM is that many implementations leave DDM open without requiring a password for DDM/DRDA connections (*USERID or *VLDONLY), which is true unauthenticated access. Now consider the following very closely using the exclusionary access example above.

USERA and USERB are the only accounts that have *CHANGE authority to OBJA and the *PUBLIC is *EXCLUDE. ODBC, FTP, Remote Command and even DDM exit programs have been registered to the IBM i exit points to enhance security, but the administrator finds that an HA account has changed data in OBJA through a DRDA connection and he is confident that no one knows the password for this HA service account. He is even more surprised to find that the attack came from a server where it does not even exist. This is what we actually found in a real data breach. If DDM/DRDA TCP/SNA attributes do not require a password and powerful accounts are allowed access through DDM/DRDA, then anyone can launch the attack by using a DB2 SQL connect or DDM SBMRMTCMD to access the system with these accounts without a password (unauthenticated access).

This is a prime example of security by obscurity. The administrator thinks that his HA account is the only account that is allowed through the DDM exit program even though DDM does not require a password. But that’s where he is wrong. Anyone with access to other systems that have a connection to the system where OBJA resides can simply issue a DB2 SQL Connect statement with this profile because no password is required.

So in the case of DDM, exit program security does not even enhance DDM security unless DDM also requires a password (Elements of distributed relational database security – IBM Documentation).

Additionally, most exit programs only monitor for unauthorized intrusions, but SIEM admins may not even have the context of what is and is not authorized. They may not protect what is becoming a security hot topic, extrusion events (remember PCI DSS). Regarding TCP/IP, they do not protect user defined ports, sockets and services other than the well-known services running on defined ports such as ODBC, FTP, Remote Command, etc. SSH is a good example, there is no exit point for OpenSSH and never will be.

Further, exit programs do not protect your data from application and administrative users already on the system who may find open access to critical system components and data through some well know attack vectors such as default passwords, improper use of access controls, excessive privileges, adopted authority, profile hijacking and other methods available to those already on the system. Remember that the IBM i Knowledge Center states that “Exit programs are not a replacement for object authority”.

Following is a real example of issues that exit programs didn’t prevent. Working with a large enterprise on thousands of *IOSYSCFG users that another consultant told them couldn’t be removed, we had already designed and tested a secure profile swap to make it work and had planned to remove 15,000 *IOSYSCFG over the next weekend when all users lost access to systems across the globe for more than 2 hours. A Ponemon Institute report (2016 Cost of Data Center Outages) estimates the cost of system downtime at almost $9,000 per minute. The business panicked and asked us to back out our changes.

We replied that we had not implemented the change yet and would not implement it until the following weekend. Turns out a line of business manager had changed a host table entry through navigator trying to fix her local printer through the very *IOSYSCFG we were planning on removing, and because exit points allowed it, she succeeded in bringing the company down and burst into tears when she found what her mistake had done. We backed out the host table change and met with the VPs of business that afternoon and moved our remediation implementation up to that night. Next morning, everything worked fine and if we had done it sooner, the company could have saved millions of dollars in system downtime.

Data Loss Protection needs to move beyond the traditional DLP gateway to a more data-centric DLP which addresses access control at the database level and monitors for all known and unknown attack vectors. Those wishing to remain out of the data breach headlines must move beyond endpoint protection, firewalls and periphery defenses that have been the bastions of the past and begin adopting defense in depth strategies that are the only true way to protect their valued assets. Most of the data breaches widely publicized recently have occurred because some attack vector that lay undetected by the system administrators was discovered by the thieves and used to exploit the vulnerability to successfully launch the attack. It has happened on the IBM i and can unless you secure your system. The IBM i CIS Benchmarks (CIS IBM i Benchmarks, cisecurity.org) are a good place to start.

We must all stop living in the deniability that “it won’t happen here” bubble. I’m sure that’s what the last poor CIO said before the breach occurred and the exit paper (really happened) showed up on his desk. Good luck shopping those resumes.

In retrospect:

• Exit point programs are not a replacement for access controls and lack of privilege access management, only an enhancement to existing controls.
• Not all services have exit points available.
• User defined ports do not have exit points associated.
• Exit programs can only enhance the security of a server only if that server or service also requires password authentication and access controls.
• Unauthenticated access can’t be stopped by exit programs as attackers will use well known accounts if credentials aren’t required.

True mandatory access controls are the only real exclusionary access method available and should be implemented as much as possible to provide least privilege necessary for a particular user or users access requirements (Implementing resource security – IBM Documentation). Compensating controls if used must provide a password in order to meet the rigor and intent of a required PCI DSS control and be well documented.

For those at risk, the time to remediate is now. For those that have been breached, the time to remediate was yesterday.

Bruce Bading is a senior security consultant with more than forty years of information security experience and 25 years of corporate c-suite experience. He is an expert on IBM i security and has helped some of IBM’s largest clients meet their security and compliance requirements in today’s complex technology and business environments. Bruce has exceptional communications skills, has worked with diverse audiences at all business levels to provide training and education and has led dozens of large enterprise risk management projects for the world’s largest organizations. He is a member of the Information Systems Audit and Control Association, a CIS benchmark author, and professional threat hunter.

Editor’s Note: Bruce is one of a number of new Guru experts that we are working with to keep the Guru column going within The Four Hundred. We look forward to the coming in-depth security coverage that Bruce can give as you work to secure your IBM i platforms in these interesting times.

RELATED STORIES

Guru: IBM i *USRPRF Security

Guru: SIEM Is Only Part Of IBM i Cybersecurity

Guru: Would You Rather See a Fire Marshal or a Fire Fighter?

Guru: IBM i Unauthenticated Access