Sysadmins and DevOps have a had a very demand in 2020 due to the pandemic. They are always on the alert for new things cropping up, however, Log4j is not something that a simple patch can solve. To make things more complicated, it’s the holiday season, and IT teams are usually short-staffed during this time of the year. Right from Apple to Google, this bug has kept everyone awake.

By Prakash Advani, CEO, picoNETS, and Rajeev RK, CTO, picoNETS

How did it happen?

Log4j is a modular, open-source logging library that is designed to add logging and log management functionality to any project that wants to build in this functionality without developing it from scratch. The Original Java Development Kit (JDK) didn’t have a logging API hence Log4j and other similar libraries were created, and over time, Log4J became one of the most popular among them. The Log4j library is used by hundreds of thousands of projects, both commercial and open-source, including major projects such as Elasticsearch, Kafka, Flink and other frameworks. It is especially popular as a foundational component of major Java-based enterprise applications as they embed this into their application.

Read CISO MAG’s coverage of Log4j flaw here.

How are hackers exploiting this zero-day vulnerability?

The vulnerability works in ways very similar to an SQL injection attack. Basically, when data needs to be written into log files, it is passed through various portions of the Log4J framework, before finding its way into the final log destination. Some of these components have the ability to process special strings in the log data and trigger certain actions based on them. One such action is misused in this attack, which may force the server running Log4J to connect to a malicious data source (like an LDAP server under the attacker’s control) and use it pass executable code (Java Classes) back to the server, which then executes them as if they were local. This malicious class then can potentially install a backdoor or allow the attacker to compromise the server and steal the data or misuse server resources for his own ends.

The Apache Software Foundation has already said the severity is now critical. If it isn’t fixed, it could lead to a data breach. Many bots are now searching websites for vulnerabilities, so enterprises are strongly advised to fix them.

A new ransomware family called Khonsari is taking advantage of this vulnerability and attaching systems that are not patched. Also, this vulnerability can be used to force the system to mine cryptocurrencies. So just patching the servers may not be enough, as some backdoors may have already been deployed in the duration that the vulnerability was active.

What mitigation strategies can be applied?

Customers using an Application Firewall (like a WAF integrated with a CDN) would usually be protected from this. CDN’s are typically the first line of defense against public data coming into servers (ingress data). However, many times, app developers consider logging data streams as low bandwidth/value streams and don’t route it through CDNs. In this case, the developers will need to fix this both by patching Log4J and by disabling the remote data pathways everywhere except for in the specific parts of the application where they are legitimately used.

The challenge is that Log4j may be in multiple places; it may be embedded into other third-party applications or components, so knowing what to patch may not be very straightforward for a server administrator. Especially if it is integrated into third-party components, you are dependent on the component or module author to release a patched version before you can update the same on your servers.

How is the open-source community reacting?

The open-source community takes security very seriously. Whenever there are vulnerabilities found, they are able to fix it quickly. A typical zero-day bug like this usually has a patch or mitigation ready in a matter of hours or days, and downstream users can start applying the patches/mitigations without waiting for the typical bug-fix/patch release cycles typically followed by most commercial software vendors. The big advantage of open source is that many more organizations and independent developers and security experts can review the code, find bugs faster and help fix them.

For example, Jfrog has already released an open-source tool to scan for this vulnerability.

About the Authors

Prakash Advani is the CEO and Rajeev RK is the CTO at picoNETS, a deep edge CDN.  picoNETS is happy to help customers with Log4j concerns. Prakash is a serial entrepreneur, advisor, mentor, and jury member. He has been a Jury member with INSEAD Venture Competition, NASSCOM Product Conclave, IIT E-Summit, and Dewang Mehta IT Awards. He has mentored startups through Reliance GenNext Hub, Conquest BITS Pilani, and as an Entrepreneur-in-Residence with INSEAD.

Rajeev RK is an Opensource evangelist with over 25 years of experience in free and open source technologies and platforms. An Alumnus of Troy University, Rajeev is a Red Hat Certified Engineer. He has worked extensively as OpenSource Consultant and Trainer. He is also the creator of the Bihar Public Grievance Redressal System, winner of the Web Ratna Silver Icon Award, 2012. As our  Chief Technology Officer, he brings with his particular expertise in solution architecture and the integration of diverse technologies across various verticals.

Disclaimer

Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.

The post Expert Opinion: Key Questions About Log4j Answered appeared first on CISO MAG | Cyber Security Magazine.