Protect Yourself from the Log4j Vulnerabilities

Updated: December 22, 2021.

Apache Log4j vulnerabilities have been in the news lately for good reason. Log4j is used in hundreds of common IT products, the vulnerabilities are very easy to exploit, and they potentially give attackers access to your systems. As the frequency of attacks continues to increase, it is important to quickly determine if you have vulnerable products.

Below are corrective actions you should take right away to help protect your systems from the Log4j software flaws and similar vulnerabilities.

NOTE: The following is provided "as-is", with no guarantees or warranties either expressed or implied.

Log4j vulnerabilities are actively being exploited and impact hundreds of IT products.
1. The most serious vulnerability, "Log4Shell", allows Remote Code Execution (RCE). This means attackers can easily compromise machines and spread throughout your network.
2. Many servers and hardware devices / appliances may be vulnerable due to use of Java software components that include Log4j.
3. Additional vulnerabilities have been discovered, such as a Denial of Service (DoS) attack that can slow down or prevent proper operation of vulnerable machines and a data exfiltration attack that can leak sensitive data (including usernames and passwords). More vulnerabilities may be discovered in the future.
For Peerless Managed Service Provider (MSP) customers, we are not aware of any products we use that would put you at risk. However, it is critical that you check your own IT products.
Check all of your IT products, prioritizing those accessible via the Internet, followed by those only accessible on your internal networks.
1. Refer to your product vendors' Log4j security advisories or contact your vendors.
  1. Extensive lists of IT products, whether or not they are impacted, and their Log4j security advisories can be found at the following links. Please click on the source link for each product, as information may have changed.
    (https://github.com/cisagov/log4j-affected-db)
    (https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592)
    (https://github.com/NCSC-NL/log4shell/tree/main/software)
    (https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#affected-products)
  2. Advisories from some common product vendors are in the next section of the article; however, they represent only a few among hundreds of vendors with affected products.
  3. Additional Log4j advisories can be found by searching for “log4j vendordomain.com”, “log4j vendorname”, and “log4j productname”.
2. Check your servers and devices for impacted products and the “log4j-core” JAR file. Ensure any found versions of Log4j meet or exceed what is recommended on the official Apache Log4j Security Page. (https://logging.apache.org/log4j/2.x/security.html)
3. Leverage automated scanning and other tools to detect and/or remediate Log4j vulnerabilities.
4. The presence of Log4j may show up in a basic filesystem search, but could also be hidden deep within software. Complex scripts are more likely to be able to detect the vulnerability.
  Note that automated remediation may break product functionality; therefore, official vendor fixes may be preferable.
  The following publicly available resources cannot be guaranteed safe or bug free, so use carefully and AT YOUR OWN RISK:
Advisories from some common product vendors. These only represent a few among hundreds of vendors with affected products.
1. Microsoft: (https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/)
  1. Check Virtual Machines (VMs) in Azure for impacted products and the “log4j-core” JAR file.
  2. Azure and Office 365 infrastructure / products themselves have been remediated and are actively being monitored by Microsoft.
2. Amazon Web Services (AWS): (https://aws.amazon.com/security/security-bulletins/AWS-2021-006/)
  1. Check Virtual Machines (VMs) in AWS for impacted products and the “log4j-core” JAR file.
  2. AWS infrastructure / products have been remediated and are actively being monitored by Amazon.
3. Cisco: (https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd)
  1. Cisco WebEx Meetings Server must be updated.
  2. Cisco WebEx Apps is not vulnerable.
  3. Cisco AnyConnect is not vulnerable.
  4. Cisco Unified Communications Manager must be updated.
  5. Cisco Unified Communications Cloud has been remediated.
  6. Cisco Meraki products are not vulnerable.
  7. Cisco Umbrella has been remediated.
  8. Cisco Duo (Commercial and Federal) has been remediated.
4. Aruba: (https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-019.txt)
  1. Aruba Silver Peak Orchestrator is the only impacted product.
5. Ubiquiti: (https://community.ui.com/releases/UniFi-Network-Application-6-5-55/48c64137-4a4a-41f7-b7e4-3bee505ae16e)
  1. UniFi Network Application is remediated via a new version. (https://www.ui.com/download/unifi/)
6. SonicWall: (https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032)
  1. SonicWall Email Security is the only impacted product.
7. Datto: (https://www.datto.com/blog/dattos-response-to-log4shell)
  1. Datto products do not appear to be impacted.
8. Webroot:
  1. Webroot products do not appear to be impacted.
9. Polycom: (https://support.polycom.com/content/support/security-center.html)
  1. Some Polycom software are impacted.
10. Salesforce: (https://status.salesforce.com/generalmessages/826)
  1. Slack has been remediated.
  2. Salesforce cloud services have been remediated.
  3. Salesforce on-premises software must be updated.
11. ServiceNow: (https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0870307) [Login Required]
  (https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1000959) [Login Required]
  1. ServiceNow cloud does not appear to be impacted.
12. OpenVPN: (https://openvpn.net/blog/openvpn-not-affected-by-log4j)
  1. OpenVPN products do not appear to be impacted.
13. Atlassian: (https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html)
  1. Atlassian cloud products have been remediated.
  2. Atlassian on-premises products (ex. Jira, Confluence) do not appear to be impacted with the serious Log4Shell vulnerability, except for Bitbucket Server and Data Center which must be updated.
Follow the latest instructions provided by the product vendor or the official Apache Log4j Security Page, whichever is more recent and works best for your situation.
1. The official Apache Log4j Security Page: (https://logging.apache.org/log4j/2.x/security.html)
  1. At this time, the instructions state to either patch Log4j to a newer version; or
  2. "... remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class";
  3. "Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability."
2. Note that many vendors' original instructions were based earlier mitigations or earlier versions of Log4j that are not complete or do not address subsequent vulnerabilities. It is important to keep checking for updated vendor instructions as the situation evolves.
3. The original mitigations were determined to not work in all circumstances, but can provide some protection prior to the more thorough solutions above:
  1. Setting system property “log4j2.formatMsgNoLookups” to “true”.
  2. Setting environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” to “true”.
4. Subscribe to notifications from your product vendor on security advisories.
5. Patches and mitigations may be updated as threats and vulnerabilities change.
Expect that vulnerable products may have already been compromised before you were able to update / mitigate them and before any cybersecurity tools or capabilities you have were able to protect them.
1. No one wants to imagine this very real possibility, but every machine accessible from the Internet has been under aggressive attack. Even machines not directly accessible from the Internet could have been attacked through other means. The last thing you want is to have already been compromised and not even know it.
2. If you have reason to think you have been compromised and are a U.S. company, consider notifying the Government, which may provide you with assistance and resources. (https://www.fbi.gov/resources/victim-services/seeking-victim-information/seeking-victims-of-log4j-vulnerability)
3. Peerless experts can assist you with a quote for consulting, prevention, detection, investigation, remediation, and/or recovery. We also provide solutions and services for other cybersecurity and compliance needs. (https://offer.getpeerless.com/get-started)
4. Utilize firewalls and other network logging resources to look for suspicious activity, especially concerning outbound LDAP (389,1389,636,1636/tcp) and outbound Java RMI (1099/tcp,udp) connection attempts [successful or not] from your networks to the Internet.
5. Examine cybersecurity product reports, alerts, and events for suspicious activity and unauthorized connections, both outbound and inbound.
6. Examine logs on affected servers, machines, and devices for suspicious activity and unauthorized connections, both outbound and inbound.
7. Conduct virus scans, malware scans, and vulnerability scans on affected servers, machines, and devices.
8. Look at least as far back as December 1, 2021.
Peerless strongly recommends doing the following to strengthen cybersecurity and prevent Log4j and similar attacks from being successful.
1. IMPORTANT: The following measures should be tested, as they may impact connectivity and functionality. Previous configurations should be documented and/or backed up, so that any changes can be reverted.
2. Peerless experts can assist you with a quote for consulting on or performing any of the following activities. We also provide solutions and services for other cybersecurity and compliance needs. (https://offer.getpeerless.com/get-started)
3. Logging: Firewalls and other network logging resources are an excellent way to inform your specific cybersecurity measures, as they provide a sense of what is normal traffic for your network. Use this information to build your firewall rules and restrict unauthorized traffic to / from your network.
4. Egress Filtering: Implement firewall rules that prevent your servers (and any other device) not requiring unlimited Internet access from making requests to the Internet.
  1. Malware typically creates outbound Internet connections to retrieve payloads and operate remote command-and-control services. Therefore, blocking these outbound connections may prevent malware from functioning or allowing access into your networks.
  2. First, create a “Deny All” rule from the Source(s) to the Internet or “Any”/0.0.0.0 if you intend to restrict all access not explicitly allowed by a higher priority rule.
  3. Then, create Allow rules from the Source(s) to any needed Destinations. For example:
    1. Internal Networks or specific destinations.
    2. DNS (53/tcp) and DNS (53/udp) to its configured DNS server addresses.
    3. Microsoft Update (if patches are not internally deployed).
  4. If you specifically wish to block the currently known "Log4Shell" exploits, block outbound LDAP (389,1389,636,1636/tcp) [except to legitimate LDAP servers] and outbound Java RMI (1099/tcp,udp).
5. Ingress Filtering: Implement firewall rules that only permit connections to your servers (and any other device) from known and authorized sources using expected protocols.
6. Filtering: Enable Log4j blocking rules on any Web Application Firewalls (WAF) and other filtering products for network / application / cloud services.
7. Antivirus / Anti-Malware: Ensure this is installed on all devices and is kept up-to-date.
8. Patches / Mitigations: Implement vendor-recommended patches and mitigations for all affected products.
9. Security Updates: Promptly install vendor security updates.
10. DNS Filtering: This can prevent outbound connections from your systems to known malicious servers, such as those used by Log4Shell attackers. Similar to firewall egress filtering, this can prevent attacks from creating outbound connections from your devices to download and execute a payload.
11. Multi-Factor Authentication (MFA/2FA): Implement wherever practical. MFA/2FA is the most effective measure to prevent the compromise of user accounts across different systems, software, and services.
12. "Zero Trust" Architecture: This is a security design philosophy and holistic approach that utilizes numerous protections across your users, devices, applications, systems, and networks. (https://csrc.nist.gov/publications/detail/sp/800-207/final)
13. Least Privilege / Role-Based Access Control (RBAC): Leverage user groups and other permissions to restrict individual user access to only the systems, software, and data they need.
14. Defense-in-Depth: Leverage managed routers, switches, and software-defined networks (SDN) to implement VLANs, Access Controls Lists (ACLs), and/or network segmentation to prevent the spread of malware from one part of the network to another or even one device to another. This is known as “Defense-in-Depth”.
15. Monitoring: Detect attacks and compromises using a Security Information and Event Management (SIEM), Security Orchestration and Response (SOAR), Extended Detection and Response (XDR), Managed Detection and Response (MDR), Intrusion Detection Systems (IDS), and similar automated monitoring products.
Technical information.
1. Malware typically creates Internet connections to retrieve payloads and operate remote command-and-control services.
2. Some malware prefer using the outbound web ports of HTTP (80/tcp) and HTTPS (443/tcp), as almost all devices with Internet access are permitted to access the web. However, any number of protocols and ports are known to be used.
3. Log4Shell malware has specifically been using outbound LDAP (389,1389,636,1636/tcp) and outbound Java RMI (1099/tcp,udp). Once the Log4Shell malware has compromised a machine, LDAP / RMI are no longer needed, so the payload it installs will likely communicate over other protocols and ports.
4. Blocking these inbound and outbound connections can sometimes prevent the malware from executing, infecting a machine, and spreading throughout your networks.
5. Technical Articles: