Apache Log4j | Are you vulnerable?

By Jim Wachhaus | December 12, 2021
Official message about Log4j impact on the CyCognito Platform.
There is no direct impact of the Log4j vulnerability to the CyCognito platform.
Read the official message here.

The least you need to know right now:

  • There is a vulnerable version of the Apache Software Foundation Log4j logging utility, starting with version 2.0 released in July 2014
  • This vulnerability is actively being exploited in the wild, and is trivial to exploit.
  • Exploiting this vulnerability allows remote code execution (RCE).
  • There is a patch available and you should immediately patch your systems.
  • A configuration change may also mitigate the vulnerable versions (if you can’t patch).
  • There is no direct impact of the Apache Log4j vulnerability to the CyCognito Platform. CyCognito will continue to monitor and investigate the situation as third-party component vendors communicate status.
  • To protect your systems, you need to know what is affected.
  • See also some Frequently Asked Questions (FAQ) and answers for more details.
  • The information in this blog was last updated on 25 January 2022 at 8:25pm ET.

You can’t protect what you don’t know about

While much has been written about the issue, why it’s bad and how to fix it, this blog post is going to quickly touch on the last bullet point which is knowing what technologies and components make up your attack surface and quickly understanding if (and how badly) you’re affected.

Right now the race is on between threat actors actively attempting to exploit affected systems and cybersecurity experts trying to assess their attack surface for systems to fix. Large companies will have hundreds or thousands of web applications and hundreds of thousands or millions of assets that are internet-facing. If those systems are running Java based software then they are likely vulnerable to attack. Do you know where your assets are?
image1-V2Like COVID, this vulnerability isn’t likely to go away anytime soon. Right now it’s a pandemic-level event with rapid spread.

Eventually systems will be “inoculated” against the exploit but, there is going to be a long tail on this while security teams catch all of the many services, platforms, and applications running Java that are vulnerable. 

The easiest and fastest way to identify all of those targets is to use tools that mimic the discovery tactics that threat actors are using. In this case, attack surface management platforms can give affected organizations an edge and free up valuable (and soon to be overworked) personnel trying to respond to this cyber tsunami by automating the discovery and testing process. 

From our CEO and offensive security expert, Rob Gurzeev: “Every few months, sometimes years, another critical and widespread vulnerability is discovered. The reason it takes some organizations months and sometimes years to close security gaps (even those as notorious as Heartbleed, and likely this one) is because finding every machine and application that is vulnerable across large attack surfaces is a time-consuming and tedious manual challenge. A couple of years ago, we found a Heartbleed vulnerability in the authentication server in the Defense and Space department of a Fortune 500 company. And we found it years after the vulnerability was discovered. I suspect it will take months and years for some organizations to find all of their log4j2 vulnerabilities.” 

The longer-tail part of this “Log4Shell” pandemic/endemic is going to be the reckoning that software developers, software vendors and large enterprises that build their own apps will face in trying to patch their own software packages in a way that doesn’t render logging incomplete or break applications.

Recommendations and immediate next steps

There is no “one size fits all” solution to this issue yet, so at CyCognito we built a Log4j testing module that will actively test whether any software built or deployed by your company is affected.

Our security research and analyst teams recommend a few immediate actions:

  • CURE: Patch the Log4j versions that you know about, and patch software which uses Log4j as patches are available
  • VACCINE: Inoculate any log4j applications (use caution and read the details; this also requires a restart)
  • TEST: Test suspected assets for the vulnerability, including custom-built apps
  • TRACE: Investigate your external attack surface (with an EASM platform like CyCognito) to understand if and where you are using specifically vulnerable software. Here’s a list of software we know about so far.
  • QUARANTINE: If you find a vulnerable system that can’t be patched or vaccinated consider taking them offline or putting them behind a firewall and keep monitoring them for signs of compromise.

How CyCognito customers are tracing their vulnerable machines

We’ve made it quick and easy for customers of our platform to identify assets that may be vulnerable to Log4Shell (or any new vulnerability). For Log4Shell, specifically, we've created a new Log4j Advisory Dashboard that showcases potentially vulnerable assets.

To manually search your inventory of external assets in the CyCognito platform, follow these steps:

  1. Log into the CyCognito Platform.
  2. Choose the Assets tab.
  3. Select IP Addresses.
  4. Paste this query into the search box (updated 22 Dec 21 4:15pm ET):
    service contains_any {logstash, flink, druid, struts, solr, atlassian, jboss, vmware, metabase, cisco:sd-wan_vmanage, cisco:identity_services_engine, cisco:unified_communications_manager, ibm:curam_social_program_management, sysaid, coldfusion, spark, epolicy_orchestrator, tapestry, oracle:e-business_suite, kaseya:virtual_system_administrator, manageengine:adaudit_plus, graylog, ibm:websphere_portal, couchbase:couchbase_server, forcepoint:email_security, github_enterprise, netiq:access_manager, linoma:goanywhere_mft, graylog}
  5. Press ENTER.



Be prepared for the next Log4Shell (or Heartbleed or Solarwinds or…)

The best way to address this vulnerability (and any future hair-on-fire vulnerability exploit) is to have access to a comprehensive internet-facing asset inventory, along with the ability to quickly test your internet-exposed assets for exploitability of both existing and new vulnerabilities.

This visibility will relieve the stress during the impact analysis phase of response. It will allow your teams to quickly get into patch-or-mitigate mode.

Using an external attack surface management platform which can perform automated tests on assets to validate both the vulnerability and the fix will allow internet security teams to quickly and confidently address the issues and resume business as usual.

About Jim Wachhaus

Jim Wachhaus, Director of Technical Product Marketing, has been in technical roles on cybersecurity products for over two decades and is passionate about the discipline of cyber system defense.

Contact Author:
  • linkedin
  • email

Join our Live Webinar

Finding Apache Log4j Vulnerabilities In Your Attack Surface

December 21, 2021 | 9 AM PST

Register Now