No, Apache Isn’t Vulnerable to the log4j Vulnerability
The log4j library has been in the news recently, and it’s not the good news either. While the details of the vulnerability have been very well documented by others, it’s summarized as allowing arbitrary code execution through maliciously crafted messages. These messages cause the Java virtual machine to look up classes from an LDAP server (yes, really!) and load them. This is obviously no good, but unless you’re familiar with Java, you might be concerned what is and isn’t vulnerable; this article aims to clarify that. But wait, who? log4j is a library developed by the Apache Software Foundation. They…
The post No, Apache Isn’t Vulnerable to the log4j Vulnerability appeared first on Seiden Group.
December 2021 Security Alert
By now, we hope you have heard about the Log4j2 vulnerability, and that it can affect your IBM i if you are using Log4j2 in any of your applications.
Log4j2 Vulnerability – Need to check if Log4j2 is being used
As with any security vulnerability, one of the best things to do is keep up to date with PTFs. You should be regularly applying IBM PTFs to your system so that known security fixes are installed. If you don’t have the experience to put PTFs on, or you just don’t wish to do it for any reason, we can put PTFs on to your system, either one time, or better on a regular cadence. Contact Ron Dolan at [email protected] for more information.
IBM has no mitigation published except for WAS 8.5 and 9.0. But it is, likely other products of IBM i affected but have not been published yet. All systems are likely affected. Manual remediation is required if using Log4j with custom applications. Get your developers on it to find out if they are using Log4j2 using the instructions below. While we are on the subject, the IBM Product Security Incident Response (PSIRT) website is something to follow. We will be providing updates as they come as well to all our PTF customers.
Review current security bulletins from the IBM Product Security Incident Response (PSIRT) site. https://www.ibm.com/support/pages/node/732299
At this time the CVE-2021-4428 is not listed as an IBM i Apache vulnerability.
https://www.ibm.com/support/pages/node/1170946
The system administrator would determine if they are using the Apache Log4j2 <=2.14.1 modules. (assuming manual download & classloading)
qsh
find /qibm/proddata -name log4j-core-2*.jar
find /qibm/userdata -name log4j-core-2*.jar
F6 to spool output
NIST link below shows how to resolve at this time.
CVE-2021-44228 is still being investigated by the NIST.
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Apache.org is tracking as well.
https://logging.apache.org/log4j/2.x/security.html
There is some great details and an explanation about how it is used to exploit data here https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
Remember, security isn’t a one-and-done process, it’s an ongoing process that must be constantly updated as new vulnerabilities arise. Speaking of which, have you ever had an IBM i security assessment done? You would be surprised at how many security issues we find when we do a security assessment or penetration test. My customers think they are secure, then we show up and show them things that are wrong. Don’t let your security be compromised, the job you save may …
The post December 2021 Security Alert first appeared on iTech Solutions Group.
Keeping your old #IBMi #RPGcode poses many risks! Here are just a few ways maintaining #LegacyCode is holding you back: ? RPG can be vulnerable ☁️ With RPG you’re not cloud-ready ? And RPG is too slow to keep up with business demands Let’s get started:
Keeping your old #IBMi #RPGcode poses many risks! Here are just a few ways maintaining #LegacyCode is holding you back:
? RPG can be vulnerable
☁️ With RPG you’re not cloud-ready
? And RPG is too slow to keep up with business demands
Let’s get started: hubs.la/Q0104f2_0 pic.twitter.com/DpEZoPb6oF
– Profound Logic (@ProfoundLogic)10:01 – Dec 13, 2021
An update on the Apache Log4j CVE-2021-44228 vulnerability – IBM PSIRT Blog
Dec 12, 2021 9:10 pm EST
Categorized: Critical Severity
Share this post:
IBM is actively responding to the reported remote code execution vulnerability in the Apache Log4j 2 Java library dubbed Log4Shell (or LogJam). We are investigating and taking action for IBM as an enterprise, IBM products and IBM services that may be potentially impacted, and will continually publish information to help customers detect, investigate and mitigate attacks, if any, to their IBM products and services.
IBM Enterprise
IBM is continuing to inventory our products and systems potentially impacted by the vulnerability. As necessary, we are updating to Log4j version 2.15, which fixes the vulnerability, and applying mitigations in the interim, even in cases where additional control layers such as network controls and web application firewalls have prevented exploitation of this vulnerability.
IBM Software and Systems Products
IBM is continuing a product-by-product analysis for Log4j impacts. If an IBM Software or Systems product is impacted, there will be a bulletin posted on this blog as a remediation or fix becomes available. Such on-premise IBM products will then have to be updated by the customer.
IBM Consulting
IBM Consulting will continue to work directly with its clients in support of the remediation of custom applications and services through its normal delivery center and platform support processes.
IBM Security
The IBM X-Force team of hackers, responders, researchers, intelligence analysts and investigators are actively engaged in the response to Log4jShell. Detection and Indicators of Compromise (IOCs) for IBM Security tools are being published on the
.
The IBM Managed Security Services (MSS) organization also is reviewing all systems to eliminate the vulnerability. The team is tracking patch releases for impacted platforms that IBM Security Services manages. Clients may see Security Advisory tickets and requests to patch managed devices in the MSS portal.
Assistance for customers suspecting potential compromise also is available 24/7 via IBM Security X-Force’s US hotline
| Global hotline (+001)
.
IBM Cloud and as-a-Service Products
For IBM Cloud services, IBM is remediating managed as-a-service Cloud offerings as applicable, even in cases where additional control layers such as network controls and web application firewalls have prevented exploitation of this vulnerability.
Clients of IBM Cloud’s Classic and VPC Virtual Machine services are responsible for remediating any Log4j vulnerabilities in code running inside those Virtual Machines. IBM Cloud based virtual machine images and package repositories are being updated wherever they contain the vulnerable code.
For the portion of IBM Cloud services using Java technologies, IBM is continuing to assess and remediate any remaining services using Log4j and validate that mitigating controls remain effective.
IBM’s recommendations to its clients:
At this time, IBM recommends organizations running Apache Log4j take the following actions:
Check for vulnerable versions of Apache Log4j in your environments and applications.Implement latest patch to production environments as soon as possible. Monitor IBM PSIRT for security bulletinsMonitor for vendor patches as they become available
IBM X-Force also has provided an analysis of the Log4j vulnerability, which can be found on the
IBM Security Intelligence blog
.
Per the Apache Log4j security vulnerability advisory, the following temporary mitigations may provide interim protection for clients who are unable to upgrade Log4j in their workloads quickly:
In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Users of IBM’s Cloud Internet Services, powered by Cloudflare, may use the Web Application Firewall feature to mitigate attacks against their own workloads hosted in IBM Cloud, by detecting and blocking requests that attempt to exploit the vulnerability. More details are available at
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/
IBM recommends that users of IBM Cloud’s firewall services, including Fortigate, Juniper vSRX, Security Groups, and Network ACLs, should configure their firewalls to block unauthorized outbound connections to mitigate against this and similar vulnerabilities. In addition, Fortigate has released IPS rules to detect and block this specific vulnerability (
https://www.fortiguard.com/outbreak-alert/log4j2-vulnerability
), as has Juniper (
). If you are using a next generation firewall appliance from another supplier, IBM recommends contacting the firewall vendor for specific guidance for mitigating the Log4j vulnerability.
