By: Steven Ng, CIO and EVP of Managed Security Services, Ensign
On 9 December 2021, the critical vulnerability (CVE-2021-44228, also known as “Log4Shell”) in a widely used Apache logging framework service, log4j2 library, was reported to be under active exploitation by threat actors.
Log4Shell’s Impact on the World
As Log4j is one of the most popular open-source Java logging libraries, it is integrated into many applications and services. Due to its widespread usage, this vulnerability impacts many organisations across various sectors globally. Furthermore, as the vulnerability is easy to exploit, the ramifications of this vulnerability are expected to be extensive
Hackers are now actively scanning the internet for affected systems, and malicious tools are being developed to automatically attempt to exploit the vulnerability. The exploit targets the Java Naming and Directory Interface (JNDI) and the Lightweight Directory Access Protocol (LDAP), enabling attackers to load arbitrary Java code on a server, allowing them to take control. This makes it a highly attractive vulnerability for cyber perpetrators. Additionally, while not all services and products are susceptible to the Remote Code Execution (RCE) exploits, they could be vulnerable to the information leakage attack associated with the vulnerability.
In the wake of the vulnerability disclosure, financially motivated actors involved in cryptocurrency mining were among the first to exploit targets. It is anticipated that there will be more monetisation-centred exploitation activities moving forward. This includes data theft, ransomware deployment and multifaceted extortion.
To exacerbate the situation, the vulnerability disclosure happened close to the holiday season, and some organisations might have fewer resources and manpower available to remediate the vulnerability.
While services and products that leverage the Apache logging framework are working on a fix, threat actors are already moving fast to find systems vulnerable to the exploit and gain access to the networks. It is now a race against time for organisations to take proactive measures to contain the situation and safeguard themselves.
Ensign’s Recommendations
Although affected services and products are still working to patch the vulnerability, organisations must take immediate steps to protect themselves against exploitation and mitigate the impact. Here are the key approaches that organisations can take:
Identify
- The vulnerability is highly exploited in the wild, with massive reconnaissance activity. Organisations should assess the use and impact of Apache log4j2 library services in their environment and infrastructure as soon as possible, and identify affected assets, starting with externally facing servers and applications.
- If third-party applications are impacted, organisations need to remain up-to-date and understand the vendor-specific recommended short-term mitigation measures, in addition to the timeframe for when a patch or update path will be made available, as the situation develops.
- Organisations should keep a lookout for the release of scanning templates to identify this vulnerability and leverage internal and external vulnerability scanning tools.
- They should scan the environment to ascertain if this vulnerability exists.
- Additionally, they can use open-source vulnerability toolsets to identify vulnerable log4j instances.
Contain
- Organisations must prioritise mitigation activities and patch applications as soon as the updates are released.
- For external-facing and vulnerable servers, organisations should restrict all Internet outbound traffic to the bare minimum to reduce the risk of RCE.
- Organisations can reduce the attack surface of impacted applications and servers by limiting access to the application interfaces that could be exploited.
Detect
- Organisations should focus on enhancing their visibility to identify attackers exploiting the vulnerability.
- Organisations can also hunt for the log4Shell exploitation with the following steps:
- Search for requests containing reference to the JNDI in available logs.
- Hunt for known Indicators of Compromise (IOC).
- If an organisation identifies any exploitation on the server, it should verify if the server was vulnerable to the log4Shell vulnerability during the timeframes of the suspicious access attempts.
- It should also investigate the identified payload for any malicious activity, for instance, dropped files, encoded commands, Java class loading etc.
- Organisations can check their systems to see if there are signs of compromise from 1 Dec 21 before patching (to 2.15.0).
- Organisations can search for outgoing LDAP connections to destinations not seen before 1 December. If such connections are found, they can search the host for the presence of log4j. If there were DNS queries logged, they would need to review the queries to check for any possible exfiltration via DNS protocol.
- The presence of the indicators listed above may be indicative of an attack.
Remediate
- If a compromised log4j instance is identified, organisations should conduct a forensic investigation, and implement remediation measures, such as removing any potentially malicious artifacts or backdoors.
- An attacker can leverage environment variables that contain credentials or keys to obtain additional infrastructure (on-premises or cloud-based). If a compromised log4j instance is running on a server where credentials are stored, organisations need to rotate and change the passwords or keys that could have been exposed.
