Log4j and Great Update
You may have read in the news recently about a major defect that has been discovered in the log4j library that could compromise the security of thousands of web applications. The problem has existed for a long time but it has only recently been found. The developers have reacted quickly to release an update but this problem is going to be around for the long time.
So what happened?
Log4j is a logging library that's commonly used in Java applications. It’s job is to allow developers to write information to a log file while an application is running so it is possible to monitor what the application is doing and fix bugs. Every application needs logs to allow developers and log4j became extremely popular for Java based applications because it's free, open source and managed by Apache who provide a lot of great free software.
Now that this defect has been detected, a new version of log4j has been released and so applications need to be updated to use it. It’s important to understand how these dependencies work, in most modern Java applications you have your code and the dependencies. The dependencies are any third party library that the developers used to speed up the development. In most applications the majority of the code is dependencies because there’s no point in a developer writing code to connect to a database, receive a web request or write a log, these are things everyone has to do so we use standard libraries.
A library like log4j might be one of the first libraries a developer includes because it's so useful and until now it had no major flaws to worry about. In most projects the dependencies will be scanned against a known list of vulnerabilities to highlight possible risks. The problem is that these scans will only show the risks known about at the time, a new vulnerability could be discovered later and change the risk that a library represents. It is simply not possible to automatically scan code for risks because code scanning tools can only spot obvious problems, not the complex ones that hide in a large code base. In a library like log4j that is used by thousands or organizations there would have been millions of scans and lots of highly skilled developers looking at the code but no-one spotted the problem. .
This is the problem with most security testing, it's a point in time and you only know what was known then. It's only now that the risk is known and organisations need to react.
What do you need to do?
In a Java application your dependencies are managed by a tool, probably Maven or Gradle. To change a dependency you need to edit the configuration to set the new version and run a build command. The build command will download the version of the dependency you set and compile the code. That should just work but sometimes there are compatibility issues that need to be debugged. Once your code is compiled you can test it and release it.
The challenge is that these steps are simple for an experienced developer who knows the application but it’s not always that easy. For older applications you might find you change the log4j version but other dependencies are no longer available, meaning you have to make multiple upgrades just to make the code run, if that's even possible. If your organization built an application then the team who worked on it might have moved on, if they were contractors or consultants then who in the organization can still make this change? If there is no-one actively working on the code then who can make this update without breaking everything else?
This is why the log4j threat is so significant. Anyone who has a Java application could be vulnerable and if you don’t have an inhouse development team then it can be hard to know if you’re even exposed.
If you have a development team in house then stop them working on whatever they’re doing now and ask them to upgrade any log4j usage.
What if I don’t have developers?
If you don’t have any developers who can help and you need to get some quickly. At Perrio we have already worked with our clients to make the upgrades to their log4j instances. If you need help then get in touch and we can talk about it. We take security very seriously and we want to help.
What about next time?
If you have in-house software but no developers then you have a risk to manage. This is not the first major defect in a common library and it won’t be the last. Unfortunately software is never really done, without regular patching and updating you are running a major risk that your systems are not secure.
For a lot of organizations it is not practical to employ a team of developers. Instead you need some clear processes to handle these situations. You need a list of your applications, access details for the code and engineers on standby who can step in quickly. The way we work is to offer support to our clients to update their applications for them. We also provide our clients with a runbook that they can provide to other engineers to make these changes. We don’t like lock-in so we make sure the next engineers have a clear understanding of how an application works.
If you don’t know what technology is in your organization then contact us. We can help you to understand what's there, how they work together and what the risks are. Then we can help you plan the mitigation approach and see the opportunities that exist.
Contact us to talk about the log4j risks
