Log4Shell

We have lived a really interesting week from the security point of view because we have known the most widespread cybersecurity vulnerabilities in recent years. There are lots of vulnerabilities day in and day out but most of them are not as important as the vulnerabilities discovered last week in a piece of free and open source software called log4j. These vulnerabilities are very important because log4j is widely used by lots of applications as well as the vulnerabilities discovered are really critical.

Log4j is used by thousands of websites and apps. In fact, there are companies who don’t know yet how many websites and apps are using this piece of code, which is really dangerous because they don’t know yet the extent of these vulnerabilities in their services. Actually, log4j is mainly used for logging information which is a functionality needed by most web applications. In addition, these vulnerabilities are extremely easy to exploit but it is also easy to protect against these vulnerabilities because updating servers or disabling log4j is simple.

As I write this article, there are three Log4j vulnerabilities. The first vulnerability publicly disclosed is CVE-2021-44228, which is a Remote Code Execution (RCE) vulnerability and it is the most critical vulnerability. This vulnerability is critical because Apache log4j Java library doesn’t properly validate input thus attackers can execute arbitrary code loaded from LDAP servers. The second vulnerability discovered is CVE-2021-4104, which is also a RCE vulnerability. However, this one is less critical than the first one because this vulnerability only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. In addition, Log4j 1.2 reached end of life in 2015. Finally, the third vulnerability is CVE-2021-45046, which is a Denial of Service (DoS) vulnerability. This is the less critical one.

Source: Swiss Government Computer Emergency Response Team

These three vulnerabilities have to make us think about the software supply chain. There are lots of developers who use libraries which are never updated. In fact, most of them don’t know if they are using vulnerable software. What’s more, there are lots of companies who don’t have a software inventory. Therefore, they don’t know what servers they have to update. In addition, there is now a lack of developer resources that updating software will be longer than it used to be.

I’m wondering where is the Zero Trust that all security companies were telling us in webinars. Why does Log4j have access to outside servers? Log4j should never have been able to communicate with outside servers. We should learn as much as possible with this event. Zero Trust is not a project with a start and a finish because environments are constantly changing. This is why we should always think about inventory. Zero Trust is the new implementation of security but it is a process that will never finish.

To sum up, there is lots of work to do. Updating servers is one task to do. Deploying WAF appliances and upgrading signatures is also a task to do. However, security management is a process where we have to take lots of things into account.

Regards my friends! Do you have any thoughts about this event?