Guru: IBM i Unauthenticated Access

April 25, 2022 Bruce Bading

One of the greatest threats to any network, host, or server is unauthenticated access where an attacker can gain local or remote access with no credentials that can lead to a Critical rating with the following descriptions (CVSS v3.1 User Guide (first.org).

Confidentiality Impact Complete (There is total information disclosure, resulting in all system files being revealed.)

Integrity Impact Complete (There is a total compromise of system integrity, and a complete loss of system protection resulting in the entire system being compromised.)

Availability Impact Complete (There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.)

Access Complexity Low (Specialized access conditions or extenuating circumstances do not exist.

Authentication is not required to exploit the vulnerability.

The above descriptions of Confidentiality, Integrity and Availability (CIA) Impact Metrics are from the CVSS 3.1 Calculator (first.org). CVE 2022-23307 impacting log4j version 1.2 will list these CIA impacts.

On the IBM i, there are other more serious protocols and services that can lead to unauthenticated access with the same Impact Metrics that are often overlooked and exist on the majority (> 50%) of all systems we assess.

The worst unauthenticated access vulnerability on most IBM i systems exists when DDM/DRDA set to *USRID, *NO, or *VLDONLY. Any of these three values will allow unauthenticated access to your IBM i with a low complexity and authentication not required that can result in a complete compromise of system Confidentiality, Integrity, and Availability. You can check the current setting with the following command:

CHGDDMTCPA and prompt with F4. 
Autostart server . . . . . . . . >		*YES                      
Lowest authentication method . . >		*USRID   
Lowest encryption algorithm  . . >		*DES          

The above presents 2 vulnerabilities, unauthenticated access, CVSS rating 10, and a weak encryption algorithm *DES, CVSS rating 7.5.

DDM/DRDA is open architectures (Inside IBM’s Distributed Data Management architecture | IBM Journals & Magazine | IEEE Xplore). DB2 Connect is one example developed by IBM, but being open architectures, anyone can develop a client for any OS. The following connection string used by DB2 Connect is an example of unauthenticated access.

DB2 connect to my400db USER QSECOFR USING ‘   ‘. 

USING followed by ‘  ‘ signifies NO PASSWORD, and will connect QSECOFR or any “USER” with no credentials (unauthenticated access). Even using exit programs won’t protect you from this low complexity attack because several powerful profiles such as your HA profiles are usually allowed through the exits unauthenticated resulting in a complete loss of Confidentiality, Integrity, and Availability.

Another unauthenticated attack vector exists if your QAPPNRMT configuration list specifies a SECLOC value = *NO for any remote connections. Text from this value’s help states that “The local system is not a secure location.” The exposures are default profiles in your communications subsystems and their authorities and privileges. Several times we find that QUSER has been changed to have *ALLOBJ special authority and is a default profile in QSYSWRK, the subsystem generally used by SNA communications. Other communication subsystems can be configured and can likewise contain powerful default profiles. Best practice is to delete the QAPPNRMT configuration list or set the SECLOC values to *YES or *VFYENCPWD.

A third unauthenticated attack vector we generally detect is Network Attribute *JOBACN set to *FILE or *SEARCH. While not as bad as *SEARCH, *FILE can send a remote job to a corresponding profile on a remote system where possible malicious code can run depending upon the receiving user’s privileges. More dangerous is *SEARCH, which will search through the Network Job Table, and depending upon entries in your Network Job Table, powerful special authorities may be available. Regardless, *JOBACN provides unauthenticated access to your system and it is a best practice to set *JOBACN to *REJECT.

Anonymous NFS exports are another critical risk we often find. Network vulnerability scanners detect and report these vulnerabilities as a High Risk Vulnerability (Exploiting NFS share [updated 2021] – Infosec Resources (infosecinstitute.com). The IBM i can export (share) numerous file systems including the Root (/), QOpenSys, User Defined File Systems (UDFS), QSYS.LIB, QDLS, and QOPT (optical) systems. Unauthenticated access can pose a risk if you don’t explicitly specify ANON=-1 on your EXPORTFS options. Specifying the UID of a powerful profile on the ANON keyword can create a Critical risk. If you don’t specify the ANON=uid keyword, all unknown requests will be processed under the default AS/400 NFS user profile, QNFSANON which is still anonymous and unauthenticated, and could present a critical risk if your admins have done something crazy like giving QNFSANON powerful special authorities, or access to confidential information. To view your exports, sign onto your system with *IOSYSCFG and CALL QZNFRTVE. Ensure you are viewing detailed messages and press F1 on any of the exports to display options.

Configuring NetServer with a Guest Profile can present another unauthenticated vulnerability if you have any confidential data on your system and you are not implementing proper access controls.

So before you think Log4j is your biggest unauthenticated access vulnerability, a vulnerability scan can detect these and many more risks. All compliance frameworks require unique accounts and role-based access. So while your IBM i may be one of the most securable systems, it is not secure if you don’t practice good security hygiene and scan often for vulnerabilities and fix them. Lastly, if you think the IBM i can’t be hacked, this busted myth led to several breaches while I served as Senior Cybersecurity Consultant for Rochester Lab Services and a couple since forming BFB Security, an IBM Business Partner specializing in IBM i Cybersecurity. If your systems are not secure, the time to remediate is now. If your systems 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: SIEM Is Only Part Of IBM i Cybersecurity

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