The Log4j vulnerability is haunting the internet by increasing its risk to 100 hacks per minute. The first three days of the initial breakout saw over 846,000 attacks globally. This serious security flaw has affected every known internet application and, nearly 41% of corporate networks in India are now vulnerable to this security flaw. Major SIEM & SOAR platforms using the log4j library are also at risk.
Is your application at risk? Let’s find out.
What is LOG4J?
Log4j is a java-based logging library that can provide multiple log levels such as FATL, ERROR, INFO, DEBUG, TRACE, etc.
Through Remote Code Execution (RCE), attackers have leveraged a critical zero-day vulnerability in Apache Log4j.
What is Remote Code Execution (RCE)?
RCE is a technique where the attacker can run any commands/code on the victim’s machine.
Analysis of the vulnerability
Say your application is internet-facing and it uses log4j library with JNDI lookup enabled. As a matter of fact, Log4j is JNDI lookup enabled (Java Naming and Directory Service) by default.
If someone sends a request to your application with a malicious website/server address, instead of simply logging the request, log4j will execute the JNDI lookup by resolving the address specified in the request.
The address can point to a malicious server/download and execute shell script/exe, set up crypto-mining software, etc. which can lead to a serious impact.
By injecting any malicious binary, attackers can get access to all the processes which the log4j can access. Most of the logging libraries will have access to file system/databases/environment variables to update the logs. Through this, an attacker can get access to the file system/databases/environment variables and perform any malicious activity.
A sample request data with user-agent value altered by the attacker that points to an LDAP server to access the crypto mining software.
The JNDI lookup in log4j downloads a java object and executes it in the JVM of your machine.
I’m not using the LOG4J library in my application. Should I be worried?
Even though you are not using the log4j library directly in your application, you may be affected.
If you use any of the below packages/software/tools and your application is internet-facing, you are more likely to get affected.
The CISA has released the list of software that are impacted by this security flaw.
- Apache Flink
- Apache Druid
- Apache SOLR
- VMware Unified Access Gateway
- VMware NSX-T Data Center
- VMware vCenter Server
- Splunk Enterprise Docker Container
- Splunk Enterprise Amazon Machine Image (AMI)
- Symantec Endpoint Protection Manager (SEPM)
- Cisco Webex Meetings Server
- Cloudera Cybersecurity Platform
- Fortinet FortiSIEM
A complete list of affected software can be found here: https://github.com/cisagov/log4j-affected-db
AWS is constantly updating their services vulnerable to log4j. Follow this link for regular updates about AWS services https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
How do we fix it?
- Set log4jformatMsgNoLookups to true (Available in version 2.10)
- Upgrade to the latest version. Log4j has released version 2.15 by partially fixing this vulnerability, but this version can be affected by DoS attacks. A new version (2.16) fixing this issue was released.
- Protect your applications with WAF (Web-Application Firewall)
Prodapt’s approach for making applications secure
The DevSecOps frameworks can give your organization the best defensive position to identify vulnerabilities in the development stage (Shift Left) and protect it from ongoing attacks in the production stage (Shift Right).
The DevSecOps framework:
The DevSecOps framework involves shifting security left in the SDLC which enables continuous integration and real-time measures and shifting security right enabling continuous SecOps measures.
Shifting Security Left:
- Shifting Security Left is the practice of moving security practices left into the development lifecycle
- Vulnerabilities can be identified in the design and development stage
- Known threats and attacks can be arrested at the unit test stage
- Secure coding practices result in fewer vulnerability images deployed to production
Shifting Security Right
- Security Shift Right refers to continuous monitoring of the dynamics of production ecosystems
- This helps us to identify abnormal suspicious activities and stop attacks at their initial surface
- The severity of attack and penetration into the ecosystem can be arrested at early stages
- Securing the production ecosystem from risks arising from the base layer packages, periodic upgrades, patches etc.
Techniques to be followed while shifting left and shifting right:
- SCA – Software Composition Analysis
- Scan your packages (open-source and third parties) to ensure your code is composed of in the early stage of SDLC
- SAST -Static Application Security Testing
- Scan your source code and fix the vulnerabilities before pushing the code to the repository
- DAST – Dynamic Application Security Testing
- Scan your endpoints against various attacks and secure them
- Image Scanning
- Scan your application images for malicious base images and privilege escalation
- Continuous monitoring
- Continuously monitor your running containers and production environments to detect any abnormal activity
- Periodical SCA – Software Composition Analysis
- Periodical scanning of packages in your applications in production helps you in upgrading to the patched/latest versions of packages
Incorporate the above recommendations by adopting a DevSecOps culture that results in a SecureSDLC.
A reference pipeline to adopt DevSecOps
Vijay Ramachandran, Director – Delivery, Software Development, Prodapt Solutions
Vijay, an automation evangelist with 18+ years of experience in the Telecom Industry. His Expertise spans Telecom B/OSS, Cloud, Automation, Kubernetes, and DevSecOps. Over the last two years, he has been focusing on developing Frameworks/solutions for the Digital enablement of organizations in a hybrid cloud environment.
I thank Ms. Kavya Rengaraj, for her valuable inputs in shaping up this article.