As a security-first company who takes the protection and security of our customer data extremely seriously, we’re writing this blog post in response to the Log4j CVE vulnerability that was identified earlier this month. We want to clarify the impact to Reclaim (and customer data), and also explain a bit how a small startup like Reclaim handles these types of incidents, including the approaches and tools we used, as to help other companies navigate this critical vulnerability.

TL;DR

Although the Reclaim platform heavily utilizes Java for our backend services, we can confirm there was NO impact to the Reclaim.ai platform or customer data from this vulnerability; see below for additional details.

Background on the Log4j vulnerability

Log4j is a Java-based logging framework which is pervasively used in modern software applications. On 12/09/21, a vulnerability (CVE-2021-44228) in the Apache Log4j2 logging package was discovered. This vulnerability essentially allows an attacker to remotely execute code, and as one of the most heavily utilized logging packages, the impact is both widespread and severe. It was quickly patched in version 2.15, but the time to implement that patch/update will vary across the Internet.

As Reclaim utilizes a Micronaut-based Java backend, we immediately began our security assessment and prioritized efforts to understand any impact to our platform and customers. Security and protection of customer data is goal zero at Reclaim, as we understand the level of privacy and confidence needed in handling calendar data.

Addressing the internal impact to our codebase

The first thing we wanted to confirm was that Log4j of any version was not in our codebase. We don’t intentionally utilize Log4j2, but there are almost always dependencies pulled in the course of software development that may not be immediately apparent.

The first and easiest approach was using GitHub’s awesome Dependabot, an automated dependency updates tool we use regularly, which was painless since our codebase is hosted in a private GitHub repository. The per-vulnerability view feature based on the Advisory Database confirmed there was no Log4j in our codebase.

The second confirmation came from Snyk.io, a developer security platform, which we’ve implemented for situations exactly like this. It took barely a few minutes to review our Code Analysis report to confirm no Log4j vulnerabilities. They’ve also come up with a cool log4shell command in their CLI to specifically find instances of the vulnerability, although we didn’t even have to try that out.

Finally, to triple check and confirm there were no transitive dependencies, we utilized the Build Scan feature in Gradle. This allowed us to generate a scan report to confirm we weren’t pulling in Log4j at either build or compile time, and confirmed Log4j wasn’t found in any jar.

Here’s a list of the tools we used to analyze our codebase for the Log4j vulnerability:

• GitHub Dependabot
• GitHub Dependabot Log4j Advisory Database
• Snyk.io
• Gradle Build Scans
  

Addressing the internal impact to our Infrastructure

Next up was our infrastructure. Even though our native code doesn’t utilize Log4j, we do utilize things like Docker images and make assumptions that they are up-to-date, properly patched, etc., but those assumptions can trick you up. Since Reclaim is hosted on Amazon Web Services, we were able to leverage existing services provided directly by AWS.

Our primary approach to addressing the impact to our infrastructure was utilizing the newly updated AWS Inspector, which provides real-time scanning of both EC2 Instances and container images stored in ECR. AWS has provided a very detailed blog post on utilizing AWS Inspector and other services specifically to address the Log4j vulnerability. Fortunately for us, there was no Log4j found in any of our infrastructure, although it did surface some other non-critical vulnerabilities in a few container images which we have since addressed.

Finally, we utilized AWS Cloudwatch Insights to run queries against our VPC Flow Logs to look for any suspicious traffic, and we again found nothing. While attackers could have used any port, outbound port 1389 was found to be used in attacks, and outbound usage of this port is less common in legitimate applications.

Here’s a list of the tools we used to analyze our infrastructure for the Log4j vulnerability:

• AWS Inspector
• AWS Cloudwatch Insights

Addressing the impact via sub-processors

The final step was understanding if there was any impact to customer data through our sub-processors. You can find the full list on our Security page. 

Not every sub-processor has access to customer data or confidential Reclaim information, so we prioritized the ones that do. Ultimately, we had a list of about 17 vendors which we would be concerned about if they were impacted by the vulnerability, and set about inquiring to understand (1) if there was any impact at all, and (2) if so, what their resolution plan was. We utilized this super-awesome list of vendors from the CISA to expedite our efforts.

Out of our 17 sub-processors:

• All 17 got back to us within 48 hours, which was amazing!
• 12 were not impacted at all by Log4j at all.
• 4 were impacted (these were biggies like AWS, GitHub, Slack, etc..) but not for anything we directly utilize.
• 1 was impacted by a monitoring agent we use, which was quickly patched and updated by our team.
  

Here’s a list of the tools we used to analyze our subprocessors for the Log4j vulnerability:

• CISA Log4J Impacted Vendor List
• Support email/portals/blog posts from each vendor

Summary

Although this was a bit of an unexpected distraction, that is unfortunately just how the security game is played. We were thankful to have already developed and put in place a Security Incident Response process to help guide us during the analysis, and hope this outline helps others analyze the Log4j vulnerability impact to their own organization. More than ever, we are also grateful for all the amazing tools and timely responses we received from our vendors and the efforts they put forth for their own security preparedness.