Over this past week, you may have heard mention in the news about the “Log4j” issue. Log4j refers to a common software utility that’s commonly found on many web services. Its intended use is for logging the health and activity of those web services for administrators, providing insights into the services’ health, performance, and utilization. Log4j is not just used for Internet-facing, public web services – many server applications and services companies use Log4j inside their own networks, leveraging its diagnostic logging capabilities.
The Log4j Vulnerability
Last week, a vulnerability was identified in how Log4j stores its log information. A malicious individual or program can create and send a bad request to a listening web service. The web service rejects the request, and dutifully uses Log4j to log the request for later administrative review. Log4j can evaluate log references and build cross-references for supplemental information, creating what’s referred to as “external lookups”. There are legitimate uses for this – for example, a bad user account login entry could helpfully supplement with details about the user account being queried, like the user’s full name, to help the administrator understand and categorize the issue.
The Log4j vulnerability exploits the “external lookups” function by tricking it to make an external lookup to a malicious web service the attacker created and controls. While that, by itself, doesn’t compromise the system, it does permit the attacker to then attempt to use other known exploits and have each of those exploits target other systems, using Log4j’s system-privilege account. In security parlance, this whole process is what’s referred to as a “kill chain” – exploiting a weakness in one system to gain a foothold, then using that weakness as the next step to compromise the next system, and so on, until a critical system or service is compromised and the attacker gains elevated privileges within the target.
Protecting Against the Log4j Exploit
Fortunately, protection versus the Log4j vulnerability in most current systems is as straightforward as changing Log4j’s default configuration to not attempt external lookups. In older systems, it may be necessary to update the Log4j version or disable its logging capabilities. In most cases, this doesn’t impact business operations – administrative logs are not typically visible to regular users, and administrative logs are usually not critical to a system’s normal business operations.
Because of the widespread use of Log4j, many Internet service vendors (Software-As-A-Service providers; SaaS) and Internet web sites and even internal-network software applications that use Log4j are potentially vulnerable. Aldridge has used our Remote Management and Monitoring (RMM) toolset; part of our IT Outsourcing services; to assess and inventory our managed clients’ environments and have identified that fewer than 3% of monitored systems may require adjustment, and less than 10% of those systems are potentially Internet-facing.
Our Aldridge Services team is actively touching each identified Log4j system and updating the configurations to disable the external-lookups vulnerability per each software manufacturers’ current recommendations. At this time, we are not expecting the recently-identified Log4j vulnerability to cause any service interruptions or additional security issues for your organization. Cloud software manufacturers are also already updating their systems and releasing software patches. Your Aldridge Client Success Manager will reach out with additional information if we will need to work together regarding any potentially-impacted software in your environment.