The old saying “The Price of Liberty is Eternal Vigilance” can be updated today to read “The Price of Online Access is Eternal Vigilance”. We just got hit over the head with a reminder of the importance of eternal vigilance with the discovery of the log4J Java security vulnerability. For the last several years, millions of applications using Java and the log4j logging component have been vulnerable to attack. Malicious users can use that vulnerability to extract data from targeted systems, load and execute malware on those systems and even completely take over the servers. The vulnerability is so severe and widespread that it has received a rating of 10 on the 1-10 CVSS scale (Common Vulnerability Scoring System) from the Apache Software Foundation.
The good news is the software patches and remediation guides to eliminate this vulnerability are readily available (see links below for a start). But even if you are not a Java user, this problem is an important wakeup call.
In the IBM i world, we have often relied on “security through obscurity” – we think maybe we are safe because we are not huge targets like Microsoft and Unix/Linux. Or, we feel safe because we do not connect our IBM i systems directly to the internet. Unfortunately attacks like log4shell can pierce those safety nets. If your IBM i happens to be on the same network as a machine that is vulnerable and connected to the internet, the log4j vulnerability could be used to discover IBM i credentials and to access the IBM i.
To reduce your risk and keep your systems safe, you need multiple layers of protection. Some of the steps you can take:
- Eliminate the use of Basic Authentication (in which user credentials that grant native access to the IBM i are passed in API calls). Replace it with encrypted token authentication.
- Add third party authentication via technologies like OAuth.
- Restrict APIs and other methods of access to just the minimum number of resources necessary to accomplish assigned tasks.
- Add multifactor authentication to all access (including 5250 emulator access).
- Be careful when providing the ability for programs on your internal systems to call out to outside systems. Calling out provides an opportunity for a hacker to get malicious code on your machine. For example, the log4shell vulnerability requires the ability to call out to the potential hacker’s system to do its damage.
- Set up logging and monitoring of APIs and other kinds of outside access to your systems.
- Check out the guides provided by your vendors (eg. Microsoft, Google, IBM, etc. – see below) to learn more about protecting your systems.
- Take good care of your security people who have the very difficult (and often thankless) job of keeping your systems safe.
The value provided by the interconnections of our systems is incalculable. It makes our modern way of life possible. Yet, that same interconnectedness is what creates the potential risks we face. As IT professionals, it is critical for us to remain “eternally vigilant” to protect our online liberty (and the precious data of our company and our customers).
To get the latest version of log4j with the security patches: https://logging.apache.org/log4j/2.x/download.html
Microsoft’s log4Shell remediation document: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
The IBM i Rochester lab’s guidance by Jesse Gorzinski: https://techchannel.com/Trends/12/2021/log4shell-part-1
