What Public Cloud Users Need To Know About The Log4j Vulnerability
CISA and cloud security experts alike have flagged the Log4j vulnerability as a ‘drop everything, call all vendors, re-task all developers, everything's on fire’ kind of issue that should be considered an immediate priority.
This week, the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA) released a statement surrounding the "Log4j" vulnerability that has left hundreds of millions of devices exposed to attack since it first came to light a few days earlier:
"This is one of the most serious [vulnerabilities] I've seen in my entire career, if not the most serious," CISA Director Jen Easterly said in the statement. "We expect the vulnerability to be widely exploited by sophisticated actors and we have limited time to take necessary steps in order to reduce the likelihood of damage," she continued.
CISA and cloud security experts alike have flagged this as a ‘drop everything, call all vendors, re-task all developers, everything's on fire’ kind of issue that should be considered an immediate priority.
But what exactly is this urgent Log4j vulnerability that's affecting everything from cloud to security to developer tools?
Log4j is a popular open-source logging utility that is widely used across different cloud and enterprise apps in order to track software activity.
Think of Log4j like a free building block that programmers can borrow and use when they are creating something new, so they don't have to build everything from scratch. Unfortunately, the accessibility of this tool is one of the primary reasons why the damage of it's vulnerability is so wide-reaching. Even if you aren’t leveraging Log4j directly, there’s a good chance the software you’re running in your environment could still be impacted.
When hackers discovered a vulnerability in this open-source logger, they were able to send a message to it from anywhere in the world, allowing them to give commands and seize control of the device to do any number of things. For example, hijack computing power to mine digital currency, target vulnerable machines, auction off access to penetrated networks, and more. And that same vulnerability existed for any organization who had utilized that same open-source building block in the past.
Were public clouds like AWS and Azure affected?
Several cloud companies have revealed that at least some of their services were vulnerable due to the flaw and that they have been rushing alongside a growing pack of threat actors to release patches and protect their customers as quickly and reliably as possible.
AWS has been keeping a regular update log for the Apache Log4j2 issue and stated that "our world-class team of engineers has been working around the clock on our response and remediation. We expect to rapidly restore our full state of defense in depth."
Their response so far includes developing and deploying technologies inside AWS, including a hot patch for applications that may include Log4j. However, even with the hot patch deployed, customers should update to 2.16.0 and check all of their software suites (not just their customer-developed applications), including consulting with vendors to see if they’re impacted, as well. They alsoput together a blog post on how AWS customers can use their services to detect and remediate the Log4j CVEs.
As for Azure, their team has come out and said that, "For the most part, Azure DevOps (and Azure DevOps Server) are built on .NET and do not use the Apache Log4j library whose vulnerabilities have been the focus of so much recent attention." However, the Search feature in both Azure DevOps and Azure DevOps Server does use Log4j as part of its dependency on Elasticsearch, and while Azure DevOps is not vulnerable,they have made several recommendations for Azure DevOps Server 2020, Azure DevOps Server 2019, and Team Foundation Server 2018.
So, what should you do moving forward?
First and foremost, if you believe that your software (or a software that you’re running) is vulnerable, drop everything and fix it immediately.
Upgrade to IMDSv2 on all EC2 instances, rotate all keys if you have discovered a vulnerable Log4j in your environment, and utilize a cloud security software (like Tenacity) to look for an outdated version of AWS Greengrass, Kinesis Data Streams and OpenSearch (formerly Elasticsearch). Also be sure to manually upgrade EnginFrame and CloudHSM.
If you aren’t able to update to a fixed version without breaking your application, protect any public facing IP addresses with a WAF using the AWSManagedRulesKnownBadInputsRuleSet rule.
Unfortunately, attackers will always get creative and look for new ways to exploit vulnerable systems. What is important to ask yourself in the aftermath (or current-math) of all of this is how is your system set up to defend against similar attacks in the future?
It's scary just how many organizations are realizing this week that they don't have a multi-layer system set in place - even when it comes to more common bad actor attacks. For example, you shouldn't just have a securely built home with doors and locks... you should have an entire home security system set in place that tells you when you forgot to lock your window or shut your back door. Deploying multiple layers of security is enough to prevent attackers from burrowing into your organization's network, beyond the individual compromised device that they may gain access to.
CISA Director Jen Easterly said it herself when wrapping up an update with industry leaders earlier this week:
"Take all necessary steps to close easily exploitable weaknesses."
With some attacks, it's that simple.
If your organization needs help ensuring that your public cloud is secure and that the doors and windows of your system are locked tight every night, Tenacity can help. We bring enterprise-grade cybersecurity to everyone, because we believe that securing your public cloud shouldn't break your business.
Safeguarding every budget and security profile without hindering growth... that's Tenacity.