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, 性能, 和利用. 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. 虽然这, 本身, 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. 在安全的说法, 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, 等等, until a critical system or service is compromised and the attacker gains elevated privileges within the target.
Protecting Against the Log4j Exploit
幸运的是, protection versus the Log4j vulnerability in most current systems is as straightforward as changing Log4j’s default configuration to not attempt external lookups. 在老系统, it may be necessary to update the Log4j version or disable its logging capabilities. 在大多数情况下, 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. 在这个时候, 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.
