I clearly remember the day that news of the Log4J vulnerability broke. In typical form it was a Friday obviously. On top of this I was down in Bristol visiting my office and I was heading back home that day. Ordinarily this would have been fine, but I was driving (which for me involved around 7 - 8 hours of driving depending on traffic). One of the elements of my job is to help get content out quickly regarding any new significant threats and vulnerabilities that may come about. So while driving, it was an attempt to co-ordinate this effort. Thankfully the team did an amazing job. You might have thought that was the end of it, but unfortunately that was on the beginning!

You see in terms of how the whole Log4J vulnerability played out, it was not good unfortunately. There were numerous mixed messages going about. And then there were the numerous findings after the original fix was implemented. You can see this in the blog that I created to cover the information regarding the vulnerability (well rather vulnerabilities). Now I want to make it clear, the developers and maintainers of the Log4J library did an amazing job. They should be highly commended for all the effort that they put in. These people do it on a voluntary basis and as a result also have their own jobs to see to as well. So the fact that they managed to get issues fixed and out so quickly is highly commendable (not to mention the stress that they must have been going through).

Old Habits Die Hard

One of the most frustrating things that I saw is the industry’s approach the issue. We attempted to solve it using old methods and thinking. What do I mean by this? Well let’s break the issue down. Log4J is a Java based logging library, used by many Java based applications and services. This includes organisations who develop their own software using Java. One may assume that for those organisations, they would simply need to identify which of their software was using the vulnerable version of Log4J. This would entail investigating their source code and developing a list of dependencies. This is often referred to as producing a Software Bill Of Materials (SBOM). There are in fact several tools that will allow you to do this (such as the amazing OWASP Dependency Track, that I highly recommend).

But coming back to the problem that our saw with our industry’s approach to the problem. There was little to no mention of this. Instead, what I saw was the old scanning at the network layer and file system layer. I even Tweeted a thread about this:

Now granted, for 3rd party applications this would be a suitable means to try determine if you were affected. But what I saw, and I could be entirely wrong here, was a blanket approach that didn’t distinguish between 3rd party software and an organisation’s own software. I saw network layer security, and other more traditional methods attempting to solve and an application security problem.

And here’s the crux. Organisations should have not been caught in this situation. If you cast your minds back to September 2017, you will remember the news of the Equifax breach. The cause of that breach, ironically, was a Java framework called Apache Struts. Why is this important? Companies should have noticed the importance of auditing the dependencies that they use. Had they done this, the issue of finding and address vulnerable versions of Log4J would have been relatively painless to do.

FUD

Fear, Uncertainty and Doubt (FUD). This is something that we often have with a hot security issue/topic. And in the case of the Log4J vulnerability this was no exception. There was unfortunately a lot of FUD doing the rounds, especially by those equating Log4J to Java:

Unfortunately I think that this is something that isn't going to go away in any hurry. But none the less it is frustrating to see. Especially when it's used as a marketing means.

The Software Supply Chain Problem

I’ve been quite vocal about this, and for a reason. Software supply chains are, in my opinion, one of the biggest areas of risk to an organisation. The usage of open source libraries and frameworks has exploded during recent years. And this is a good thing! I love open source. But this does present an advantage to malicious actors. Firstly more software means more vulnerabilities, this is unfortunately a simple fact of software development, vulnerabilities will exist (and this is not a criticism). This means more for attackers to target. The other problem is that it’s not becoming increasingly difficult to work out legitimate packages form malicious or compromised packages. So this means organisation’s, now more than ever before, need to build an up to date inventory of all the software libraries and frameworks that they use within their own software. This will mean that they will be able to quickly and effectively know where they are vulnerable and where the relevant updates need to happen. And the holy grail of all of this is to even have automation built in to drive down the time to remediation even more.

Conclusion

So why does this mater? Well if you cast your eyes to this awesome site that SonaType have created:

This site tracks the download statistics of the vulnerable versions of Log4J. And let’s just say it is not a pretty picture. At the time of writing for this blog, there has been 34,553,722 downloads of the vulnerable versions of Log4J since December 10 (when the news of the vulnerability broke). That accounts for 47% of all downloads of Log4J! And this is one of the reasons why I decided to write this blog. We doing the same thing over and over, and then expecting it to solve the problem. It is not! We get caught up in the excitement, create these tools and scanners and then once the excitement dies down, move onto the next thing. The problem being is that the problem still exists. And more importantly we haven’t questioned ourselves why it still exists. I also want to make it clear, this is not a criticism of the community/industry, but rather my own observations and opinions and thoughts on how we can try make things better.