OCI, Terraform & IaC: Creating Compartments for CIS Foundation Architecture
In this third blog post series, we will be creating four main compartments Security Compartment Network Compartment App/Dev Compartment Database ... Read More
Learn more about why Eclipsys has been named the 2023 Best Workplaces in Technology and Ontario, Certified as a Great Place to Work in Canada and named Canada’s Top SME Employer!
Learn more!It has been 4 years and almost 3 months that on September 19th (19s as it is commonly known due to the day 19th and S of September) of 2017 at 1:15 PM CT, México City got hit by one of the deathliest earthquakes. México City is still in the process of removing and fixing buildings that were damaged by that earthquake.
In an analogy of an earthquake, the IT industry on Friday, December 9th, 2021 ( 9D) got shook by the security vulnerability with the given descriptor “Log4Shell”. It is being called one of the most susceptible security flaws of the last decade. With the lasting outcome of this vulnerability to last for years, Tenable mentions that “attackers will go after the low-hanging fruit exposed by the vulnerability, will evolve over time to take the form of more complex attacks“.
Apache Log4j is a Java-based open-source logging utility. It is part of the Apache Logging Services and Log4j is one of several Java logging frameworks. Log4j is used in everything from online games to enterprise software and cloud data centres. Log4Shell was identified in Microsoft’s Minecraft and the Log4j team was made aware of this security vulnerability, CVE-2021-45046.
The vulnerability makes it possible for an attacker to be able to inject text into log messages or log message parameters into server logs that load code from a remote server. The targeted server will then execute that code via calls to the Java Naming and Directory Interface (JNDI).
JNDI interfaces with a number of network services:
Log4Shell brings into light two practices of concern:
Apache release Log4j 2.16.0. This version disables by default the Java library’s primarily exploitable functionality: JNDI message lookups, it also disables all JNDI support by default and removes message lookup handling entirely, hopefully preventing further exploitation. Log4j 2.16.0 requires Java 8. For that reason, organizations that use Java 7 will need to upgrade to Java 8 before being able to update to the patched version of Log4j.
Apache advises that if patching is not immediately possible, there are three mitigation routes that can be taken to thwart attempts to exploit this vulnerability:
Mitigation | Applicable Versions |
---|---|
Set log4j.formatMsgNoLookups or Dlog4j.formatMsgNoLookups to true | Log4j 2.10 or greater |
Use %m{nolookups} in the PatternLayout configuration | Log4j 2.7 or greater |
Remove JdniLookup and JdniManager classes from log4j-core.jar | All Log4j 2 versions |
Oracle released Oracle Security Alert Advisory – CVE-2021-44228 and MOS note Apache Log4j Security Alert CVE-2021-44228 Products and Versions (Doc ID 2827611.1), where it details the impact of the security vulnerability to its products and the patches that are available to them. There are about 160 products that are either under investigation or with a patch already available, I do want to highlight that the Oracle Database is not affected by this CVE, but products like EM, TFA, EBS, API Gateway, and ODI are. As this MOS note is evolving as vulnerabilities are identified and patched, my recommendation would be that you monitor it frequently and that you apply the patch to your environment as soon as possible.
I also want to highlight what the MOS note mentions regarding OCI:
“The Oracle Cloud operations and security teams are evaluating this Security Alert as well as all relevant third-party fixes as they become available. They will apply the relevant patches in accordance with applicable change management processes. This MOS article will be updated to reflect the application of the required patches in the Oracle clouds.”
It is estimated that Log4j has about 400,000 GitHub requests, meaning that this logging feature is included in a high number of web applications and used by a variety of cloud services like Apple, Amazon, and Google (documented in Log4jAttackSurface). Similar to the earthquake in México City, the full scope and impact of this vulnerability will be seen throughout the years.
The biggest recommendation is to patch or minimize the vulnerability of your products that use Log4j as soon as possible so that you won’t be the low-hanging fruit for Evil Bob to hack your environment.
In this third blog post series, we will be creating four main compartments Security Compartment Network Compartment App/Dev Compartment Database ... Read More
In my previous post, I talked about the setup of Terraform and a primer on what it is. In this blog post, I will create a simple resource in OCI. One ... Read More