The Log4j Vulnerability

I’m not sure how much this has permeated outside of the tech world, but at the end of last week there was a major security ‘zero-day’ vulnerability in a software library used by lots of enterprise software, potentially including agileBase.

[Update: it is now in the national news]

This post is to inform customers, who may be concerned and want to know what we’ve done about it.

A little background – the issue is with a Java library called log4j, used for writing messages to log files. If an attacker can force certain messages to be logged, they can cause the server to execute any code they like. For those interested in a more technical explanation, here’s some info: https://www.lunasec.io/docs/blog/log4j-zero-day/

As soon as we became aware of this, on Friday morning, we researched mitigation techniques and put in place the recommended measure at the time, disabling the problematic log4j option on our primary server.

By the afternoon, it was clear what the most robust mitigation measure was, so we implemented this across all servers (primary, development, test etc.) as well as reaching out to customers who host agileBase on their own infrastructure. Where we had access to these, we proactively patched those servers too.

After taking these immediate actions, we also looked into what our level of risk was. Whilst most of agileBase’s server-side code is written in Java, our code doesn’t directly call the log4j library, so many potential avenues of attack would be closed.

However, we do use many third party elements in our stack, any of which could use the library and indeed we did find a vulnerable version of log4j present in the list of dependencies, so at least one of those elements does potentially use log4j, opening up possible lines of attack (now closed due to the above mitigations).

Searching our logs shows no suspicious activity and the protections put in place ensure that no hack will take place due to this in future. Additionally, www.greynoise.io hosts a searchable list of IP addresses affected by this issue and we can confirm that none of our servers’ addresses show up in it.

Additional learning

With any security incident, there’s the opportunity to look at our existing tools and processes to see where they may be improved.

All of the third party dependencies we use are already automatically updated, when new minor versions are released, so we expect a new version of log4j to roll through soon.

However we have now also implemented vulnerability scanning of every agileBase development update using tools from Anchore, which will create a software bill of materials (SBOM) for serverside code and carry out vulnerability scanning, to catch any other software supply chain attacks like this.

This is also a good opportunity to remind customers to enable two factor authentication on their accounts. Since most agileBase functionality is behind a login, the easiest way for an attacker to take advantage of any new vulnerabilities is to appropriate someone’s username and password. Two factor authentication helps protect against that.

If anyone has any further questions, please do contact support@agilechilli.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: