Some of our customers rely on GiveSignup | RunSignup as a Tier 1 application for their business and have asked us to comment on if we were impacted, and if so, how we have mitigated the widely publicized Apache Log4j vulnerability (also known as “Log4Shell”) that went public on December 9, 2021. This article will summarize the incident.

Our security and operations professionals follow PCI DSS certified processes that are designed to constantly monitor for and protect our systems against malicious attacks and bad actors on the internet. Most software vulnerabilities are discovered and quickly mitigated without much fanfare. Occasionally, a widespread or high-risk exploit will make the news — and that is the case with the Log4j exploit that surfaced last week.

What Is Log4j?

Log4j is an open-source utility made available by the Apache Foundation and incorporated into thousands of software applications and services. Log4j provides logging services that developers depend on to capture the behavior of their applications for monitoring and debugging purposes. Log4j is a Java-based package, so it is primarily used in Java-based applications.

What Is the Vulnerability?

The Log4j package had a previously undiscovered security vulnerability that allowed data sent to it with a special sequence of characters to fetch additional software from an external source and run that software. This is a particularly serious vulnerability that, once exploited, could be used to steal data or exert control over a website or application. The serious nature of the vulnerability, coupled with the widespread use of Log4j, resulted in this particular vulnerability, gaining worldwide attention.

Was GiveSignup | RunSignup Impacted, and What Was Done?

The GiveSignup | RunSignup platform is primarily written in PHP (not Java), so the Log4j package was not used directly in our software. However, one of our servers that we use to monitor our services had a third-party monitoring package that does use Log4j. The server was not impacted or exploited, but it was receiving probes from the internet testing if it had been patched.

The vulnerability was taken seriously upon it going public, and we began evaluating the best remedy for our environment. At the same time, our normal defenses were able to identify potential attackers who were scanning the internet looking for servers to exploit. We became aware of the severity of the security gap around 9:50 p.m. EST on Friday night. Within 20 minutes of learning about the vulnerability, our CTO had already blocked IP addresses that were scanning our servers looking for unpatched Log4j vulnerabilities. By 10:59 p.m. EST, a change control had been logged, and the remediation steps suggested by Apache were implemented. We continued to monitor the situation throughout the weekend.

No attempts were made to actually execute malicious code on our servers. Recommended remediation steps were swiftly applied. In our case, we did not wait for the third-party product we were using to issue a security patch, as we were able to disable a companion module (JNDI Lookup) that a malicious attack would require to exploit the vulnerability.  

This swift response is part of the culture of our engineering team, and serious incidents are dealt with quickly. Most incident responses like this one go unnoticed by customers and even our own employees — so it’s great to be able to highlight our team’s reaction to this highly publicized vulnerability. Just another day tending to the product we love, for the customers we respect.