{"id":31342,"date":"2022-12-08T11:33:57","date_gmt":"2022-12-08T16:33:57","guid":{"rendered":"https:\/\/www.kaspersky.com.au\/blog\/log4shell-still-active-2022\/31342\/"},"modified":"2023-02-14T05:45:02","modified_gmt":"2023-02-13T18:45:02","slug":"log4shell-still-active-2022","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.au\/blog\/log4shell-still-active-2022\/31342\/","title":{"rendered":"Log4Shell a year on"},"content":{"rendered":"<p>A year ago, in December 2021, the Log4Shell vulnerability (CVE-2021-44228) in the Apache Log4j library caused a sensation. Although by the spring it was no longer on the front pages of IT media outlets, in November 2022 it reemerged when it was reported that <a href=\"https:\/\/www.cpomagazine.com\/cyber-security\/iranian-hackers-installed-crypto-miner-in-federal-agency-after-exploiting-unpatched-log4shell-vulnerability\/\" target=\"_blank\" rel=\"nofollow noopener\">cybercriminals had exploited<\/a> the vulnerability to attack a US federal agency and install a cryptocurrency miner in its systems. That\u2019s a good reason to explain what Log4Shell actually is, why it\u2019s too early to write it off, and how to protect your infrastructure.<\/p>\n<h2>What is the Apache Log4j library?<\/h2>\n<p>Because the Java SDK did not initially support logging, developers had to write their own solutions, and by the time the official Java Logging API appeared, there were already quite a few of them. One is Apache Log4j, a popular open-source Java library in development since 2001. It\u2019s by no means the only logging solution in Java, but certainly one of the most popular. Many alternative solutions are essentially offshoots of Log4j that appeared at different stages of the library\u2019s development.<\/p>\n<h2>What is the Log4Shell vulnerability?<\/h2>\n<p>The Log4j library allows to log all system events automatically. It uses a standard set of interfaces for accessing Java Naming and Directory Interface (JNDI) data. In November 2021, it turned out that during logging it\u2019s able to run JNDI commands passed to it by an event, for example, in the Header field of a request, in a chat message, or in the description of a 404 error on a web page.<\/p>\n<p>The vulnerability <a href=\"https:\/\/www.kaspersky.com\/blog\/log4shell-critical-vulnerability-in-apache-log4j\/43124\/\" target=\"_blank\" rel=\"noopener nofollow\">allows<\/a> cybercriminals, at least theoretically, to do whatever they like on the victim\u2019s system (if no additional security measures kick in). In practice, most often attackers used Log4Shell to install illegal miners and carry out ransomware attacks. But there have been more <a href=\"https:\/\/www.zdnet.com\/article\/log4shell-flaw-still-being-used-for-crypto-mining-botnet-building-and-rick-rolls\/\" target=\"_blank\" rel=\"nofollow noopener\">exotic uses for it<\/a> too, including targeted attacks, spreading the Mirai botnet, and even RickRolling \u2014 playing the (annoyingly addictive) \u201cNever Gonna Give You Up\u201d hit by 80s crooner Rick Astley.<\/p>\n<h2>Why is it so dangerous and still a threat?<\/h2>\n<p>Java is one of the main programming languages; it\u2019s used for many backend systems \u2014 from small corporate servers to industrial automation systems and IoT devices. Most of these systems implement logging in one way or another. For years, the easiest way to do this was to use the Log4j library. When, in December 2021, it was reported to contain a vulnerability, experts declared it would be a <a href=\"https:\/\/www.zdnet.com\/article\/log4j-flaw-why-it-will-still-be-causing-problems-a-decade-from-now\/\" target=\"_blank\" rel=\"nofollow noopener\">huge problem for many years to come<\/a>. Here\u2019s why:<\/p>\n<ul>\n<li>Log4j is used in a vast array of Java applications. At the time of discovery, the vulnerability was present in more than <a href=\"https:\/\/security.googleblog.com\/2021\/12\/understanding-impact-of-apache-log4j.html\" target=\"_blank\" rel=\"nofollow noopener\">35,000 packages (artifacts) in Maven Central<\/a> (the largest Java package repository), which represents 8% of their total number. According to experts, <a href=\"https:\/\/www.itpro.co.uk\/security\/zero-day-exploit\/361847\/log4shell-zero-day-vulnerability-numbers-revealed\" target=\"_blank\" rel=\"nofollow noopener\">around 40% of networks worldwide<\/a> were at risk from Log4Shell.<\/li>\n<li>Besides conventional computers and servers, Java is also used in industrial, medical, and other specialized equipment. That equipment, too, is known to make use of the Log4j library.<\/li>\n<li>End users of solutions with Log4j inside, if blissfully unaware that the software contains a vulnerability, may put off updating it.<\/li>\n<li>Developers of solutions that use the Log4j library could well have gone bust long ago, left the market, or otherwise pulled support for their programs. Even if end users wanted to update, that option might no longer be there, while switching to other software may not be so easy.<\/li>\n<li>Log4j is an open-source library, which means that programmers can copy, modify, and use it in their projects. Unfortunately, not all developers strictly adhere to licensing rules, and do not always indicate code authorship. So, in theory, the same vulnerability could be found in a third-party project where officially there\u2019s no Log4j.<\/li>\n<li>Log4Shell was a zero-day vulnerability, meaning that cybercriminals exploited it before information about it was published. There\u2019s <a href=\"https:\/\/www.zdnet.com\/article\/log4j-rce-activity-began-on-december-1-as-botnets-start-using-vulnerability\/\" target=\"_blank\" rel=\"nofollow noopener\">evidence<\/a> to suggest that attackers first tried it out at least nine days before it was made public.<\/li>\n<li>Among the affected programs were VMware products, in particular the popular virtual desktop infrastructure solution VMware Horizon. Many registered attacks penetrated the system through this very software.<\/li>\n<li>Program updates will have little effect in the event that intruders are already inside the system. By no means all attacks begin immediately after penetration, and it\u2019s quite possible that many systems contain backdoors to this day.<\/li>\n<\/ul>\n<h2>Actual damage<\/h2>\n<p>In fairness, we should note that so far no catastrophic consequences of Log4Shell exploitation have been recorded \u2014 or, at least none that the general public has been made aware of. All the same, the vulnerability caused a major headache for developers and security experts, including ruined Christmas holidays for thousands of IT staff worldwide. Companies that are serious about security (both theirs and their clients\u2019) have had to fork out considerable sums to locate the vulnerability in their systems and software, and eliminate it.<\/p>\n<p>Below, we spotlight some of the most notable Log4Shell incidents known:<\/p>\n<ul>\n<li>On December 20, 2021, the Belgian Ministry of Defense <a href=\"https:\/\/www.zdnet.com\/article\/belgian-defense-ministry-confirms-cyberattack-through-log4j-exploitation\/\" target=\"_blank\" rel=\"nofollow noopener\">confirmed<\/a> an attack on its infrastructure using the vulnerability. Understandably, the details were not disclosed.<\/li>\n<li>On December 29, 2021, media reports said that a certain scientific institution in the United States had been <a href=\"https:\/\/www.securityweek.com\/chinese-spies-exploit-log4shell-hack-major-academic-institution\" target=\"_blank\" rel=\"nofollow noopener\">attacked through Log4Shell<\/a>. According to CrowdStrike, the APT group, Aquatic Panda, exploited an unpatched VMware Horizon. The suspicious activity was stopped in time, but the incident itself indicates that serious hacker groups have embraced the vulnerability.<\/li>\n<li>Also in December 2021, news broke about a Log4Shell exploitation on the servers of Minecraft: Java Edition, hosted not by the game publisher (Microsoft). The company <a href=\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2021\/12\/11\/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation\/\" target=\"_blank\" rel=\"nofollow noopener\">confirmed<\/a> the report and drew attention to the simplicity of the attack\u2019s implementation: the cybercriminals transmitted malicious code in a regular in-game chat, which was enough to run it both on the server side and on the vulnerable client. This case is of interest less from the victims\u2019 perspective and more in terms of the technical implementation: under certain conditions, an attack can be carried out simply through an internal chat. This is worrying, since chats now reach far beyond the world of gaming: for many companies, they are the preferred method of communicating with customers. In many fintech and other applications, this is how customer support is delivered.<\/li>\n<li>In June 2022, the US Cybersecurity and Infrastructure Security Agency (CISA) and the US Coast Guard Cyber Command (CGCYBER) <a href=\"https:\/\/www.cisa.gov\/uscert\/ncas\/alerts\/aa22-174a\" target=\"_blank\" rel=\"nofollow noopener\">issued an alert<\/a> that the vulnerability was still being actively exploited. The advisory stated that cybercriminals used a loophole in the same VMware Horizon to penetrate the internal networks of two unnamed government agencies. On top of that, the attackers were said to have gained access to 130GB of sensitive data related to law enforcement.<\/li>\n<li>In November 2022, CISA, jointly with the FBI, <a href=\"https:\/\/www.cisa.gov\/uscert\/ncas\/alerts\/aa22-320a\" target=\"_blank\" rel=\"nofollow noopener\">issued another advisory<\/a> about a Log4Shell attack on one more government agency. The attackers penetrated the system back in February, were detected in April, and remained active in June\u2013July. During this period, they created an account with administrator privileges, changed a legitimate administrator\u2019s password, and uploaded mining software to the server. The attack is believed to be the work of Iranian government-sponsored hackers, so some experts consider the mining to be just a smokescreen to hide their real motives.<\/li>\n<\/ul>\n<h2>How to protect your infrastructure<\/h2>\n<p>Any company can fall victim to Log4Shell, often simply due to not knowing about vulnerabilities in their systems and software. If you\u2019re unsure whether your systems, tools, products, or services use the Log4j library, it makes sense to conduct a <a href=\"https:\/\/www.kaspersky.com.au\/enterprise-security\/cybersecurity-services?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">thorough security audit<\/a>. Other than that, to stay safe, follow these tips from our experts.<\/p>\n<ul>\n<li>If Log4j features in your software you make, use the latest version of the library available on the <a href=\"https:\/\/logging.apache.org\/log4j\/2.x\/download.html\" target=\"_blank\" rel=\"nofollow noopener\">project page<\/a>.<\/li>\n<li>Read the official <a href=\"https:\/\/logging.apache.org\/log4j\/2.x\/\" target=\"_blank\" rel=\"nofollow noopener\">guide<\/a> from Apache Logging Services and follow it where necessary.<\/li>\n<li>If Log4j is used in third-party products, update all vulnerable software.<\/li>\n<li>Use robust <a href=\"https:\/\/www.kaspersky.com.au\/small-to-medium-business-security?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">security solutions<\/a> able to detect attempts to exploit vulnerabilities on servers and workstations.<\/li>\n<li>Monitor suspicious activity inside the corporate perimeter using <a href=\"https:\/\/www.kaspersky.com.au\/enterprise-security\/endpoint-detection-response-edr?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">EDR-class<\/a> solutions or external services like <a href=\"https:\/\/www.kaspersky.com.au\/enterprise-security\/managed-detection-and-response?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">managed detection and response<\/a>. This will allow you to find and kill attacks in the early stages.<\/li>\n<\/ul>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kesb-top3\">\n","protected":false},"excerpt":{"rendered":"<p>A year after discovery, the Log4Shell vulnerability is still making itself felt. <\/p>\n","protected":false},"author":2484,"featured_media":31343,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,2993,2994],"tags":[1343,13,3499,268],"class_list":{"0":"post-31342","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-0days","11":"tag-apache","12":"tag-log4j","13":"tag-vulnerabilities"},"hreflang":[{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/log4shell-still-active-2022\/31342\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/log4shell-still-active-2022\/24965\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/log4shell-still-active-2022\/20461\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/log4shell-still-active-2022\/10462\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/log4shell-still-active-2022\/27531\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/log4shell-still-active-2022\/25295\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/log4shell-still-active-2022\/25614\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/log4shell-still-active-2022\/28172\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/log4shell-still-active-2022\/34362\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/log4shell-still-active-2022\/46545\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/log4shell-still-active-2022\/19881\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/log4shell-still-active-2022\/20467\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/log4shell-still-active-2022\/29588\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/log4shell-still-active-2022\/33272\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/log4shell-still-active-2022\/25653\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/log4shell-still-active-2022\/31051\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.au\/blog\/tag\/vulnerabilities\/","name":"vulnerabilities"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/31342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/users\/2484"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/comments?post=31342"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/31342\/revisions"}],"predecessor-version":[{"id":31565,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/31342\/revisions\/31565"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/media\/31343"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/media?parent=31342"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/categories?post=31342"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/tags?post=31342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}