Cyber Intelligence Weekly (Dec 19, 2021): Our Take on Three Things You Need to Know

Welcome to our weekly post where I will be sharing some of the major developments on the future of cybersecurity that you need to know about. Make sure to follow my LinkedIn page as well as Echelon’s LinkedIn page to receive updates on the future of cybersecurity!

You can also Subscribe to receive Cyber Intelligence Weekly in your inbox each week.

Before we get started on this week’s CIW, I’d like to highlight my cybersecurity predictions article for 2022. If you think 2021 has been a wild year, I think we need to hang on to our hats going into 2022! Check out my article and let me know what you think!

Away we go!

1. Log4j Fallout Continues & New Vulnerabilities Uncovered

Log4j and the critical Log4Shell vulnerability were the focus of IT and cybersecurity teams everywhere this past week, and for good reason. The widespread nature of the vulnerability, as well as the impact and ease of exploitation made this a truly unique issue. Businesses rushed to determine the extent of the attack surface, apply patches from vendors, and perform other emergency mitigations.

Many organizations have had to scramble to understand their software inventory, and many have realized that they have Log4j running in their environments, and they have been working hard to apply patches, or they are waiting for vendors to supply updates and releases to software in their stacks. To help organizations understand if the software they use incorporates Log4j, the Cybersecurity and Infrastructure Security Agency (CISA) has published a long list of software providers and to what extent their software is affected by this vulnerability.

Unfortunately, just when we thought Log4j 2.16.0 fixed all major issues and most of the world spent the entire week patching, a new ‘High’ rated denial of service (DoS) vulnerability (CVE-2021-45105) was found and then subsequently fixed in Log4j 2.17.0 as well as an issue that was found earlier this week, CVE-2021-45046, that was also subsequently fixed in Log4j 2.16.0. To be fair, CVE-2021-45046 is not nearly as bad as the Log4Shell CVE-2021-44228. It only applies to non-default configurations and only allows the Java process to terminate, it does not allow for remote code execution. But this just goes to show us that this is a new and evolving situation. With this much heightened attention on the application itself, there will likely be much more news to come.

2. What Management Should be Asking About Log4j/Log4Shell

IT and cybersecurity teams everywhere are likely experiencing fatigue and burnout from long hours and a constant barrage of bad news. However, it is important to realize that this entire race may be more of a marathon than a sprint.

Log4j is a piece of open-source software that is maintained by a few non-profit volunteers, with many more now pitching in. Despite that, it is used widely by large for-profit conglomerates and corporations around the world that make up the backbone of the internet. CVE-2021-45105 will not be the last vulnerability found within Log4j, and many many software vendors are still rushing to update their applications with the latest versions of Log4j. Needless to say, we are in the very early stages of a long marathon that may never find perfect resolution any time soon.

Because of all these complexities, it is important for IT and cybersecurity leaders to communicate accurately to business leaders and stakeholders about this entire situation. If you are a business leader, here are some questions you should be asking your IT and cybersecurity leaders about Log4j:

• What is Log4j/Log4Shell and to what extent are we affected? – This question is critical to understand if your team has identified all aspects of your environment that may be running Log4j and if they are able to mitigated or not.
• Who is leading our response to this, and do we have the right technical resources on staff? – It is important to understand who is leading the response to this issue, and if the team feels confident that they have all the right resources in play.
• Would we know if we were being attacked or breached through this vulnerability? – While fixing these issues, how is IT and cybersecurity monitoring for active exploitation? Business leaders should ensure that the organization is logging to detect if Log4j vulnerabilities are being actively exploited in their environment.
• Have we assessed the impact of this vulnerability on our vendors and service providers? – We all know that businesses don’t run on their own today, they rely on the help of many key outsourced services and technology. While you can outsource the function, you cannot outsource the risk.
• What are we doing to prevent burnout of our people? – As we noted above, this whole situation will take some time to play out and there will be new issues and vulnerabilities found regularly. How are we ensuring that we are protecting our people who have been working day and night during the holiday season to help us mitigate these risks? Losing them would only make matters worse.

3. Microsoft and Mandiant Observe Exploitation of Log4Shell in the Wild

Last week, both Microsoft and Mandiant reported exploitation of the new Log4Shell vulnerability in the wild. Microsoft has noted that they have observed the CVE-2021-44228 vulnerability being used by multiple nation-state groups originating from China, Iran, North Korea, and Turkey. They note that they have seen “experimentation during development, integration of the vulnerability to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.”

What is most concerning is that Microsoft has also stated that HAFNIUM, who they have defined as a threat actor group operating out of China, has been seen utilizing the vulnerability to attack infrastructure. They note that in these attacks, the HAFNIUM attributed systems were observed using a DNS service typically associated with testing activity to fingerprint systems.

The involvement of the HAFNIUM group is concerning, given that this group was behind the mass exploitation of Exchange servers near the beginning of 2021. There are likely far more vulnerable systems to Log4j than there are Exchange servers in the world, and this could be very problematic if the same threat actor group starts exploiting Log4j vulnerabilities en masse.