Two CyCognito Log4j2 Testing Modules

We here at CyCognito have been talking about the importance of visibility, specifically external visibility into your attack surface and the vulnerabilities and security gaps in that attack surface, for several years now. The SolarWinds and Accellion attacks, the MS Exchange zero-day and the Colonial Pipeline ransomware, and now the Apache Log4j vulnerabilities (aka Log4Shell) each prove just how important this contextualized visibility really is. When something like Log4j is uncovered it’s imperative to know what your attack surface looks like the way your attackers do and respond quickly to combat them. To help you understand how we do that and how we ourselves respond when a critical vulnerability like this is uncovered, here’s a quick timeline of when how we responded and a technical walk-through of our Active Detection Module and other steps we’ve taken to keep our customers and our own infrastructure protected.

Query-Based Response

When news hit of CVE-2021-44228 on Friday, December 10, CyCognito security researchers swung into action building a response plan. By Saturday night we had released a post explaining the issues, describing the actions we were taking, and guiding our customers on how to take action using insights from the CyCognito platform to find and eliminate this issue in their environments before attackers could take advantage of the critical vulnerability in the ubiquitous Apache Log4j open source code. The first part of that response was what we dubbed our “QUERY-BASED RESPONSE”.

While this was happening, CyCognito analysts began compiling a list from GitHub, threat intelligence sources and our own research to determine what enumerated platforms, services, and applications were affected and that list of Technologies Impacted by Log4j2 went live immediately. Next, our developers pushed an in-platform message to users of the CyCognito platform that provides customers with a passive query they can run in the platform to filter on the technologies from the vulnerable products list and see if they are present in their attack surface.The message includes the ability to automatically search their organization’s attack surface for vulnerable assets because the CyCognito platform already has detailed classification and fingerprinting information about all technologies in the customer’s external attack surface.

The underlying query and the list of impacted technologies are continuously updated as new vulnerable technologies are identified. And, as of December 17, looks like: 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}

It should also be noted that when news broke that a second related vulnerability (CVE-2021-45046) affected assets with log4j2 already patched to version 2.15.0 the existing Query-Based Response was already detecting that issue based on technologies known to be impacted. And while writing this post a third vulnerability (CVE-2021-45105) which affected patch levels below 2.16.0 with an exploit using infinite recursion in lookup evaluation that results in a denial of service was uncovered (FYI: your current version should now be 2.17.0). If there is a bright side in this messy situation with three vulnerabilities and patches in a week is that the two subsequent exploits result in denial of services rather than remote code execution. And that is not much of a bright side. 

Active Detection Module

CyCognito’s second response was to develop an “ACTIVE DETECTION MODULE” because of shortcomings in the Query-Based Response, notably, false positives.  While the query is fast and runs against existing data, it could not distinguish between vulnerable and not vulnerable systems. In other words, it was a perfect place to start in self-assessment, tracing, and prioritization of the external attack surface, but wasn’t accurate enough after vaccines and cures were applied. We needed a 100% accurate test! So we built an LDAP system (Step 0) that could benignly receive responses from vulnerable systems and we used the CyCognito anonymous botnet to send challenges to all active IP addresses (Steps 1 and 2). Each challenge is sent from the botnet with a unique identifier (UID) that maps to the IP address being challenged (Step 3).

An interesting aspect of this Log4Shell exploit is that the challenge is “contagious.” Systems will pass the logged message to other systems they are connected to which means it acts like an attack (Step 4). Perhaps the first implementation of the vulnerability as a contagious inoculation was Cybereason’s LogOut4Shell. The primary difference the CyCognito solution has is that no code is being placed on or changed on the vulnerable systems. When they are vulnerable they contact our LDAP system telling our platform the UID they are responding to (Step 5).  And the CyCognito platform system correlates response UIDs with our IP list to show a Log4j vulnerability with 100% confidence (Steps 6 & 7).

Thus it’s time to cure, vaccinate, quarantine, or mask those systems that respond because we are 100% confident they are exploitable.

To respond as quickly as possible the CyCognito system has tremendously flexible and powerful workflows to assist. As always at CyCognito we are here to help and if you have any questions please contact us.