It’s only Monday, and it’s already been a busy week. Since the Apache Log4j vulnerability shook the Internet starting last Thursday, we have taken measures to investigate our platform and support our customers.

Our Obsidian product and platform are not directly impacted by the vulnerability, as the components we use within our product either do not use Log4j, have a version of Log4j deemed to be out of scope, or have mitigating controls in place. But what about the business-critical applications covered by the Obsidian platform and beyond—what about SaaS as a whole? How does that play into all this?

What is the Log4j vulnerability?

Apache Log4j is a ubiquitous, open-source Java logging library used widely across a huge variety of enterprise and open-source software. Last week, it was publicly disclosed that a security flaw existed in this library. The vulnerability was named Log4Shell and given the identifier CVE-2021-44228.

The Log4Shell vulnerability allows for the remote execution of malicious code on servers running Log4j without any authentication and an easy to craft payload, effectively providing attackers a silver bullet to take control of these systems, steal sensitive data, and install their own software. Ransomware, long-living backdoor implants, data stealing malware, cryptocurrency miners, and other attacks are already being observed in large quantities across cyberspace. For security and IT teams, it has been a trying past few days.

How does this impact SaaS?

Let’s be clear, most of what teams have been focused on in their war rooms fall into two categories:

1. Proprietary applications
2. Vendor applications

The race to patch proprietary applications has been underway as security teams weigh their options, deciding whether downtime or vulnerability is the lesser of two evils. Most organizations have already migrated their vendor applications to SaaS, meaning that teams are actively surveying vendors and requesting impact statements.

The importance and impact of your SaaS applications in the wake of the Log4j vulnerability should not be overlooked. In fact, our Obsidian threat researchers have already observed multiple malicious requests against Salesforce and Okta tenants. Even in cases where SaaS isn’t the vulnerability, it can oftentimes be an attacker’s end objective. This was evidenced during SUNBURST last year when attackers made lateral movements to set up camp in Microsoft 365 tenants and exfiltrate sensitive data.

Security teams should also keep in mind that SaaS environments are complex, interconnected ecosystems with various add-ons, integrations, injected codes, API usage, and other extensions to core platforms. Unfortunately for those of us who have already had long weekends, every component that could have Log4j is potentially vulnerable and requires examination.

What steps can I take to protect my SaaS environment?

When a situation like Log4Shell occurs, the first order of business is connecting with your peers, contacts, and anyone you know. There has already been an immense amount of knowledge shared throughout the cybersecurity community, reminding us that at the end of the day, we are all in this together.

Secondly, inventory your environment and make sure you understand what you have. While this sounds simple, we all know it is not. And if you are on the hook to patch, please patch (or mitigate). There are lots of great resources out there that help, including a mitigation blog from our partner, CrowdStrike.

Next, get technical. Start assessing what’s going on with your SaaS:

1. As the list of indicators of compromise around malicious IP addresses, domains, and hostnames continues to grow, you can validate whether or not you have SaaS activity attributed to those IOCs. For example, is that malicious IP address now successfully logging into your Microsoft 365 accounts? These identifiers are searchable in the Obsidian platform across all connected applications.
2. Monitor logs for adversaries attempting to exploit the service, specifically looking at fields like user-agents or HTTP headers that include ${jndi or an obfuscated version of that string. Obsidian customers can create a custom query or simply select the Logj4 Saved Search on the Activity page, which will (if applicable) identify associated attacker activity within the activity timeline.
3. Understand your integrations, OAuth apps, and API usage. For example, have you installed Slack apps that were written in Java? What else could potentially be vulnerable and connected into your key systems? A thorough review is necessary here.
4. Identify Okta components in your environment that may be vulnerable and patch them accordingly with guidance from this article published by the Okta Security team.

With such a rapidly evolving and severe issue, we at Obsidian will continue monitoring the emerging intelligence and vendor communications. We are also engaged and involved in various cyber threat intelligence communities. We will share information as we get it, and we hope the community continues to do the same. 

As the saying goes, never let a good crisis go to waste, and this Log4j debacle clearly qualifies. Let’s all harden, let’s improve, let’s collaborate, let’s educate. Good luck out there – we’re with you.

Customers, partners, and those of you looking for more information are free to reach out with questions to support@obsidiansecurity.com. 

If you’d like to learn more about Obsidian’s comprehensive SaaS threat and posture management offering, please read our solution overview.