Unless you’ve been on a remote island without Internet access, you’ve seen the headlines and articles regarding the vulnerability in the logging software called Log4j. Log4j is a Java-based logging library used in many third-party applications. It is also part of Apache Logging Services. Large enterprise that code their own internal applications presumably have coders on staff who know they’ve used this software and are already taking steps to mitigate it. For internal applications, you need to update the Log4j software to the latest versions.
Consultants and small- to medium-sized businesses, however, may not be aware that they have vulnerable software installed that are susceptible to this vulnerability. The Huntress team has prepared a great deal of resources for consultants and businesses that may not have internal teams with resources to determine whether they are vulnerable.
Log4J vulnerability testing tool
Huntress also offers an easy-to-use testing tool that allows you to test internal applications if they are vulnerable. They generate a unique string for your use in testing your internal applications. You can enter the string into a location that normally would need user input, for example a username or a password location. Once you enter the input string, then review the resulting test page of the Huntress team site and review if your applications are vulnerable. If there is no such evidence of external “leaking” it’s a good sign that your internal applications are safe from this style of attack.
Perform this test only on applications and resources that you own or have contractual control over. Testing an application you don’t legally have rights to is a violation of most internet service provider terms and agreement. The Huntress blog points out that attackers are already attempting to use this to enter systems typically using a Lightweight Directory Access Protocol (LDAP) query. Huntress has provided a tool that generates a request that will then be reported to you. Merely cut and paste the payload from the Log4Shell site into your application. John Hammond from Huntress also provided a video showcasing how the vulnerability works.
Test applications that include logging first
The NCC group recommends that you review your software applications and vendors for possible vulnerabilities. Think in terms of applications that include logging and test those applications first, but also think in terms of which applications may rely on LDAP, which runs on a layer above the TCP/IP stack. It provides a mechanism used to connect to, search, and modify internet directories. As Microsoft notes, “A common pattern of exploitation risk, for example, is a web application with code designed to process usernames, referrer, or user-agent strings in logs.”
Microsoft Log4j mitigation advice
Microsoft claims that if you use Microsoft Defender Antivirus on your Windows or Linux devices, it will prevent exploitation. Current exploits have been inserting bitcoin mining software on systems as well as Cobalt Strike Beacon loaders. Microsoft also recommends that you review firewall logs for suspicious commands as well as LDAP queries.
Natively, Windows is not vulnerable to the Log4j exploit, so don’t look for evidence of the attack in your Windows event logs. Rather, look for this in applications that you have purchased or developed as that’s typically where Log4j logging routines are located.
Microsoft recommends that you enable the attack surface reduction rule to block executable files from running unless they meet a prevalence, age, or trusted list criterion. This will protect you while you investigate if your network is at risk.
Watch outbound traffic
Review your options and tools that you can use to monitor outbound traffic. Before the pandemic, most firms used a traditional network behind a firewall that could then be used to review for outbound risks. Now we need cloud-based tools to review outbound connections from geographically disbursed workstations. You may need to reach out to your antivirus or monitoring tool vendors and add solutions to allow you to remotely monitor machines in your network.
Review whether connections are going out from your domain to websites that have been identified in current attacks. Ideally, also review what options you have to block connections from your network to the URLs listed.
The NCC group has identified domains and IP addresses used in the attacks. Keep an eye on this list as it is sure to increase in the days ahead. In addition, reach out to your firewall vendors for their recommendations for queries so you can review your environment for vulnerable systems calling out to servers. You can review the security notices and lists at this site as well.
Events like this will occur again. Review if you have resources and staff that can perform analysis and queries. If you do not have the staff on hand to perform an evaluation whether you do have a potential for such style of attacks, consider adding cloud services and monitoring tools that can track outbound connections and provide you with such information. Small businesses or consultants might consider adding Microsoft Defender for Business, a platform in public preview that can monitor for such egress attacks, or Microsoft Lighthouse, a console that will allow you to monitor multiple businesses for such styles of attacks.
Copyright © 2021 IDG Communications, Inc.
