After nearly two years of adopting major network and security changes wrought by COVID-19 and hybrid work, weary IT network and security teams didn\u2019t need another big issue to take care of, but they have one: Stemming potential damage from the recently disclosed vulnerability in open source Java-logging Apache Log4j software. \u00a0\nLog4j or Log4Shell has been around a long time\u2014it was released in January, 2001\u2014and is widely used in all manner of enterprise and consumer services, websites, and applications. Experts describe the system as an easy-to-use common utility to support client\/server application development.\n\nThe Log4j weakness, defined in CVE-2021-44228 \u00a0and CVE-2021-45046 in the National Vulnerability Database, basically lets an unauthenticated remote actor take control of an affected server system and gain access to company information or unleash a denial of service attack.\nThere is a remedy to the problem, so organizations should immediately upgrade to Log4j Version 2.17.0 to be protected against both CVEs, experts say.\nStill, the impact of the vulnerability could be extensive because it has been in the wild so long and becaise Log4j is so widely used. The Log4j library is embedded in almost every internet service and application including Twitter, Amazon and Microsoft, according to Check Point.\u00a0\n\u201cLog4j worms could damage critical infrastructure, and it is a national security threat already,\u201d said Tom Kellermann, head of Cybersecurity Strategy for VMware. \u201cBad nation state actors are already exploiting it as we speak.\u201d\nFor example, Check Point says it has seen over 2.8 million attempts to exploit the vulnerability and over 46% of them were made by known malicious groups as of Dec. 16. \u201cWe have so far seen an attempted exploit of over 47% of corporate networks globally,\u201d Check Point stated.\nCisco\u2019s Talos security research unit stated that it has seen attempts to place the Log4j Java Naming and Directory Interface (JNDI) attack string in email. \u201cAt this time we have not identified widespread email campaigns attempting to use email messages to trigger the vulnerability. It is potentially recon as many threat actors and researchers are essentially trying everything in an attempt to find something that eventually hits log4j,\u201d the group stated.\n\u201cThe biggest issue for enterprise customers is the amount of systems that could be impacted because logging systems are so widespread and while Internet facing servers might be highly vulnerable, it\u2019s the downstream servers linked to them that are also problematic,\u201d said Nick Biasini, head of outreach with Cisco Talos. \u201cIn addition organizations batch process logs that may not be processed for weeks so the exploit effects will be felt a long time out.\u201d\n\u201cThe Log4j vulnerability is extremely widespread and can affect enterprise applications, embedded systems and their sub-components,\u201d Jonathan Care a research director at Gartner Research said in a statement. \u201cJava-based applications including Cisco Webex, Minecraft, and FileSilla FTP are all examples of affected programs, but this is by no means an exhaustive list. The vulnerability even affects the Mars 2020 helicopter mission, Ingenuity, which makes use of Apache Log4j for event logging.\u201d\u00a0\nCare noted that the security community has created lists cataloging vulnerable systems and it includes major network players such as Cisco, Juniper, Arista, Palo Alto, and VMware as well as other big industry players such as IBM, AWS, and Google.\n\u201cHowever, it\u2019s important to note that these lists are constantly changing, so if a particular application or system is not included, don\u2019t take it as assurance that it isn\u2019t impacted,\u201d Care stated.\u00a0 \u201cExposure to this vulnerability is highly likely, and even if a particular tech stack does not use Java, security leaders should anticipate that key supplier systems\u2014SaaS vendors, cloud hosting providers and web server providers\u2014 do,\u201d Care stated.\nRemediation\nThere are a number of things enterprises can do to respond to the Log4j vulnerability, experts said.\n\u201cEnterprise users should deploy the Log4j 2.16 patch immediately, but they can also microsegment outbound traffic to prohibit new connections,\u201d said Kellermann.\u00a0 \u201cThey also need to monitor for abnormal traffic flows in those environments and expand their threat-hunting capacity.\u201d\nVMware said that it has responded to the Log4j situation in a number of its products. For example NSX Distributed IDS\/IPS and NSX Network Detection and Response (NDR) signatures have been released that detect Log4J exploit attempts, including obfuscation methods seen in the wild. These signatures will detect and prevent attempts to exploit vulnerabilities regardless of origination, VMware stated.\nCisco, Palo Alto, AWS and others have also responded to the vulnerability.\nGartner\u2019s Care said cybersecurity leaders need to make identification and remediation of this vulnerability an absolute and immediate priority.\n\u201cStart with a detailed audit of every application, website and system within your domain of responsibility that is internet-connected or can be considered public-facing. This includes self-hosted installations of vendor products and cloud-based services,\u201d Care stated. \u201cPay particular attention to systems that contain sensitive operational data, such as customer details and access credentials.\u201d\nOnce this audit is complete, turn your attention to remote employees, and ensure that they update their personal devices and routers, which form a vital link in the security chain, Care stated.\n\u201cThis will likely require a proactive, involved approach, as it is not sufficient to simply issue a list of instructions, given vulnerable routers provide a potential entry point into key enterprise applications and data repositories,\u201d Care stated.\u00a0 \u201cYou\u2019ll need the support and cooperation of the broader IT team.\u201d\nThe US Cybersecurity and Infrastructure Security Agency (CISA) recommends organizations take three additional, immediate steps regarding this vulnerability:\u00a0\u201cItemize any external facing devices that have log4j installed; Make sure that your security operations center is actioning every single alert on the devices that fall into the category above; and Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts.\u201d\nOther Log4j activities\n\nIBM\u2019s X-Force created a scan tool to detect Log4Shell. You can access it, at no cost, here: https:\/\/github.com\/xforcered\/scan4log4shell.\nMicrosoft stated that because this vulnerability is in a Java library, the cross-platform nature of Java means the vulnerability is exploitable on many platforms, including Windows, macOS, and Linux. As many Java-based applications can leverage Log4j 2 directly or indirectly, organizations should contact application vendors or ensure their Java applications are running the latest up-to-date version. Developers using Log4j 2 should ensure that they are incorporating the latest version of Log4j into their applications as soon as possible to protect users and organizations.\nMicrosoft also stated that Azure App Service and Functions does not distribute Log4J in the managed runtimes such as Tomcat, Java SE, JBoss EAP, or the Functions Runtime. However, applications may use Log4J and be susceptible to this vulnerability. Customers are recommended to apply the latest Log4j security updates and re-deploy applications.\nCisco Talos has released seven new ClamAV signatures for CVE-2021-44228 and CVE-2021-45046. A new Snort Signature ID, 58795, has also been released.