If you’re working, well, anywhere, you are likely impacted by the Log4j vulnerability.  It should be keeping information security teams working round the clock, trying to patch systems as quickly as humanly possible.

Understanding the Log4J vulnerability

Last Friday, news broke regarding the Log4j vulnerability, and has been making waves in the InfoSec community. If cybersecurity is not your area of expertise, here is our attempt at a helpful analogy. 

Imagine that I have the ability to hypnotize your employees when they read a magic phrase. Once your employee reads it, that employee will install whatever software (malicious or not) I ask. Now imagine if that employee’s  job is to read anything posted or entered into your public facing internet resource. If they read my magic phrase, they’ll do exactly what I ask. That is kind of how this vulnerability works. 

The only difference is that the magic phrase is a specially crafted string (less than 20 characters), and the employee is Log4j, which is a tool packaged into business systems everywhere that will read logs and heed the instructions included in the magic phrase.

Why is this so dangerous?

Log4J is a tool that is embedded in many systems, most notably Apache Struts, but many others. Coding is complicated. Developers often use established libraries of code for further development. Imagine building a house. You hire a builder. That builder brings tools, but likely did not make those tools. Log4j in this scenario is a commonly used nail. In other words, the vulnerability is tied to a fundamental ingredient in many applications, typically related to internet-facing resources.

 The vulnerability itself is so dangerous because it is:

1. easy to use (a magic phrase in a chat can literally take down a server); 
2. open ended in that the vulnerability allows the attacker to have malicious code (of virtually any variety) run within the impacted network; 
3. it is not easy to find all the places you have potential exposure (or bad nails); and 
4. it is virtually guaranteed that you have a vendor/partner/service provider that has been impacted by this vulnerability, which can ultimately impact your security. 

Your company’s security is at risk if those third parties are not properly remediating the situation.

Where we are in the lifecycle of Log4J

The Log4j vulnerability is the first step in a real attack. Remember, it allows an attacker to get code executed within the victim network, but it will still have to retrieve that code from outside of the victim network. Accordingly, an interim step to help mitigate potential exploitation of this vulnerability is to prevent impacted systems from outbound communications to the internet. 

Allowing inbound communications would allow an attacker to still use the magic phrase, but preventing outbound communications can prevent delivery of the intended payload (the malicious code that the attacker uses the Log4j vulnerability to execute). 

Right now, malicious hackers and good hackers (i.e., security researchers) are finding out how this can be weaponized. That research will continue for a long time. Some of that innovation will include ideas on how to exploit the vulnerability, others will identify places where people seemed to have not noticed that Log4j was enabled in their stack.

What should you be doing now?

1. Ensure your internal or external teams are identifying which business systems are potentially impacted by Log4j, that your organization has memorialized the steps they have taken, and that the assessment is fulsome (remember, part of the difficulty here is finding all the systems that utilize Log4j). This is not just about applying a patch to Apache servers, but understanding how your team actually validated its assessment of risk exposure. CISA is maintaining a resource of potentially impacted products and services available here (GitHub - cisagov/log4j-affected-db).
   
   
2. Evaluate your rights regarding vendors, third parties and service providers. Do your contracts allow you the right to question their security? Can you get a timeline on Log4j remediation? Ask for a risk assessment? Get assurances on Log4j remediation? Some vendors and third parties may give you this without contractual obligations, but now is the time to check your contracts and update them in case you don’t have it covered now but wish you did.
   
   
3. Regardless of what the contract says, ensure that you are asking your vendors, third parties and service providers about their exposure and their efforts to remediate. At minimum, we would recommend asking (and being prepared to answer) the following questions:

• What has your organization done to assess its risk exposure to the Log4j vulnerability?
• Which systems were identified as potentially impacted?
• When did you learn about the vulnerability and what steps did you take to mitigate its impact?
• Did you (or did you consider) shutting down internet access from that system during your remediation efforts and why or why not?
• How long were any vulnerable systems accessible to or from the internet?
• Aside from remediation, what specific steps did your organization take to determine if the vulnerability was leveraged?
• Have you reviewed relevant logs (and what were they) to determine whether the string associated with the vulnerability was found? How far back do these logs go?
• Did you otherwise look for evidence of malicious remote execution potentially associated with this vulnerability?
• Have you preserved and reviewed relevant logs and forensic evidence of remediated servers for purposes of assessing whether it was leveraged?
• What patches from what providers were applied to which systems in response to this vulnerability?

Hopefully the answers to these questions are all positive. But watch for artful phrasing of answers that do not answer the bottom line on remediation and risk. Evaluate the answers and understand your recourse if the answers are not satisfactory: can you withdraw from a relationship, find the third party in breach of the agreement, or force faster remediation?