{"id":20467,"date":"2022-12-21T10:07:40","date_gmt":"2022-12-21T13:07:40","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=20467"},"modified":"2022-12-21T10:07:40","modified_gmt":"2022-12-21T13:07:40","slug":"log4shell-still-active-2022","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/log4shell-still-active-2022\/20467\/","title":{"rendered":"Log4Sheel: o primeiro ano de vida"},"content":{"rendered":"<p>H\u00e1 um ano, em dezembro de 2021, a vulnerabilidade Log4Shell (CVE-2021-44228) na biblioteca Apache Log4j chegou com tudo. Embora no in\u00edcio do ano n\u00e3o estivesse mais nas primeiras p\u00e1ginas dos meios de comunica\u00e7\u00e3o de TI, em novembro de 2022 ressurgiu quando foi relatado que <a href=\"https:\/\/www.cpomagazine.com\/cyber-security\/iranian-hackers-installed-crypto-miner-in-federal-agency-after-exploiting-unpatched-log4shell-vulnerability\/\" target=\"_blank\" rel=\"noopener nofollow\">cibercriminosos haviam explorado<\/a> a vulnerabilidade para atacar uma ag\u00eancia federal dos EUA e instalar um minerador de criptomoeda em seus sistemas. Esse \u00e9 um bom motivo para explicar o que o Log4Shell realmente \u00e9, por que \u00e9 muito cedo para ignor\u00e1-lo e como proteger sua infraestrutura.<\/p>\n<h2>O que \u00e9 a biblioteca Apache Log4j?<\/h2>\n<p>Como o Java SDK inicialmente n\u00e3o suportava registros, os desenvolvedores tiveram que escrever suas pr\u00f3prias solu\u00e7\u00f5es e, quando a API oficial do Java Logging apareceu, j\u00e1 havia algumas delas por a\u00ed. Uma delas \u00e9 a Apache Log4j, uma popular biblioteca Java de c\u00f3digo aberto em desenvolvimento desde 2001. N\u00e3o \u00e9, de forma alguma, a \u00fanica solu\u00e7\u00e3o de registro em Java, mas certamente uma das mais populares. Muitas solu\u00e7\u00f5es alternativas s\u00e3o essencialmente ramifica\u00e7\u00f5es da Log4j que apareceram em diferentes est\u00e1gios de desenvolvimento da biblioteca.<\/p>\n<h2>O que \u00e9 a vulnerabilidade Log4Shell?<\/h2>\n<p>A biblioteca Log4j permite registrar todos os eventos do sistema automaticamente. Ele usa um conjunto padr\u00e3o de interfaces para acessar dados Java Naming and Directory Interface (JNDI). Em novembro de 2021, descobriu-se que, durante o registro, ele \u00e9 capaz de executar comandos JNDI passados \u200b\u200ba ele por um evento, por exemplo, no campo <em>Header<\/em> de uma solicita\u00e7\u00e3o, em uma mensagem de bate-papo ou na descri\u00e7\u00e3o de um erro 404 em um site p\u00e1gina.<\/p>\n<p>A vulnerabilidade <a href=\"https:\/\/www.kaspersky.com.br\/blog\/log4shell-critical-vulnerability-in-apache-log4j\/18633\/\" target=\"_blank\" rel=\"noopener\">permite<\/a> que os cibercriminosos, pelo menos teoricamente, fa\u00e7am o que quiserem no sistema da v\u00edtima (se nenhuma medida de seguran\u00e7a adicional entrar em a\u00e7\u00e3o). Na pr\u00e1tica, os invasores costumam usar o Log4Shell para instalar mineradores ilegais e realizar ataques de ransomware. Mas tamb\u00e9m <a href=\"https:\/\/www.zdnet.com\/article\/log4shell-flaw-still-being-used-for-crypto-mining-botnet-building-and-rick-rolls\/\" target=\"_blank\" rel=\"noopener nofollow\">usos mais ex\u00f3ticos foram reportados<\/a>, incluindo ataques direcionados, espalhando o botnet Mirai e at\u00e9 RickRolling \u2013 tocando o (irritantemente viciante) hit \u201cNever Gonna Give You Up\u201d do cantor dos anos 80 Rick Astley.<\/p>\n<h2>Por que ele \u00e9 t\u00e3o perigoso e ainda uma amea\u00e7a?<\/h2>\n<p>Java \u00e9 uma das principais linguagens de programa\u00e7\u00e3o; usada em muitos sistemas de backend \u2014 de pequenos servidores corporativos aos de automa\u00e7\u00e3o industrial e dispositivos IoT. A maioria desses sistemas implementa o registro de uma forma ou de outra. Durante anos, a maneira mais f\u00e1cil de fazer isso era usar a biblioteca Log4j. Quando, em dezembro de 2021, foi relatado que ela continha uma vulnerabilidade, os especialistas declararam que <a href=\"https:\/\/www.zdnet.com\/article\/log4j-flaw-why-it-will-still-be-causing-problems-a-decade-from-now\/\" target=\"_blank\" rel=\"noopener nofollow\">seria um grande problema por muitos anos<\/a>. Aqui est\u00e1 alguns dos principais motivos:<\/p>\n<ul>\n<li>O Log4j \u00e9 usado em uma vasta gama de aplicativos Java. No momento da descoberta, a vulnerabilidade estava presente em mais de <a href=\"https:\/\/security.googleblog.com\/2021\/12\/understanding-impact-of-apache-log4j.html\" target=\"_blank\" rel=\"noopener nofollow\">000 pacotes (artefatos) no Maven Central<\/a> (o maior reposit\u00f3rio de pacotes Java), o que representa 8% de seu n\u00famero total. Segundo especialistas, <a href=\"https:\/\/www.itpro.co.uk\/security\/zero-day-exploit\/361847\/log4shell-zero-day-vulnerability-numbers-revealed\" target=\"_blank\" rel=\"noopener nofollow\">cerca de 40% das redes em todo o mundo<\/a> estavam sob risco do Log4Shell.<\/li>\n<li>Al\u00e9m de computadores e servidores convencionais, o Java tamb\u00e9m \u00e9 usado em equipamentos industriais, m\u00e9dicos e outros equipamentos especializados. Eles tamb\u00e9m s\u00e3o conhecidos por fazer uso da biblioteca Log4j.<\/li>\n<li>Os usu\u00e1rios finais de solu\u00e7\u00f5es com o Log4j embutidos, se n\u00e3o souberem que o software cont\u00e9m uma vulnerabilidade, podem adiar a atualiza\u00e7\u00e3o.<\/li>\n<li>Os desenvolvedores de solu\u00e7\u00f5es que usam a biblioteca Log4j podem ter falido h\u00e1 muito tempo, sa\u00eddo do mercado ou retirado o suporte para seus programas. Mesmo que os usu\u00e1rios finais desejem atualizar, essa op\u00e7\u00e3o pode n\u00e3o estar mais dispon\u00edvel, enquanto mudar para outro software pode n\u00e3o ser t\u00e3o f\u00e1cil.<\/li>\n<li>Log4j \u00e9 uma biblioteca de c\u00f3digo aberto, o que significa que os programadores podem copi\u00e1-la, modific\u00e1-la e us\u00e1-la em seus projetos. Infelizmente, nem todos os desenvolvedores aderem estritamente \u00e0s regras de licenciamento e nem sempre indicam a autoria do c\u00f3digo. Ent\u00e3o, em teoria, a mesma vulnerabilidade pode ser encontrada em um projeto de terceiros em que oficialmente n\u00e3o h\u00e1 Log4j.<\/li>\n<li>O Log4Shell era uma vulnerabilidade de zero-day, o que significa que os cibercriminosos o exploraram antes que as informa\u00e7\u00f5es sobre o ataque fossem publicadas. H\u00e1 <a href=\"https:\/\/www.zdnet.com\/article\/log4j-rce-activity-began-on-december-1-as-botnets-start-using-vulnerability\/\" target=\"_blank\" rel=\"noopener nofollow\">evid\u00eancias<\/a> que sugerem que os invasores ficaram an\u00f4nimos ao menos nove dias antes de se tornarem p\u00fablicos.<\/li>\n<li>Entre os programas afetados estavam os produtos VMware, em particular a popular solu\u00e7\u00e3o de infraestrutura de desktop virtual VMware Horizon. Muitos ataques registrados penetraram no sistema por meio desse mesmo software.<\/li>\n<li>As atualiza\u00e7\u00f5es do programa ter\u00e3o pouco efeito caso os invasores j\u00e1 estejam dentro do sistema. De forma alguma todos os ataques come\u00e7am imediatamente ap\u00f3s a penetra\u00e7\u00e3o, e \u00e9 bem poss\u00edvel que muitos sistemas contenham backdoors at\u00e9 hoje.<strong>\u00a0<\/strong><\/li>\n<\/ul>\n<h2>Danos atuais<\/h2>\n<p>Para ser justo, devemos observar que at\u00e9 agora nenhuma consequ\u00eancia catastr\u00f3fica da explora\u00e7\u00e3o do Log4Shell foi registrada \u2013 ou, pelo menos, nenhuma que o p\u00fablico em geral tenha conhecimento. Mesmo assim, a vulnerabilidade causou uma grande dor de cabe\u00e7a para desenvolvedores e especialistas em seguran\u00e7a, incluindo o cancelamento de f\u00e9rias de fim de ano para milhares de funcion\u00e1rios de TI em todo o mundo. As empresas que levam a s\u00e9rio a seguran\u00e7a (tanto deles quanto de seus clientes) tiveram que desembolsar somas consider\u00e1veis \u200b\u200bpara localizar a vulnerabilidade em seus sistemas e software e elimin\u00e1-la.<\/p>\n<p>A seguir, destacamos alguns dos incidentes Log4Shell mais \u200b\u200bconhecidos:<\/p>\n<ul>\n<li>Em 20 de dezembro de 2021, o Minist\u00e9rio da Defesa belga <a href=\"https:\/\/www.zdnet.com\/article\/belgian-defense-ministry-confirms-cyberattack-through-log4j-exploitation\/\" target=\"_blank\" rel=\"noopener nofollow\">confirmou<\/a> um ataque \u00e0 sua infraestrutura que utilizou a vulnerabilidade. Compreensivelmente, os detalhes n\u00e3o foram divulgados.<\/li>\n<li>Em 29 de dezembro de 2021, relatos da m\u00eddia disseram que uma determinada institui\u00e7\u00e3o cient\u00edfica nos Estados Unidos havia <a href=\"https:\/\/www.securityweek.com\/chinese-spies-exploit-log4shell-hack-major-academic-institution\" target=\"_blank\" rel=\"noopener nofollow\">sido atacada por meio<\/a> do Log4Shell. De acordo com a CrowdStrike, o grupo APT, Aquatic Panda, explorou um VMware Horizon sem patch. A atividade suspeita foi interrompida a tempo, mas o pr\u00f3prio incidente indica que grupos de hackers s\u00e9rios adotaram a vulnerabilidade.<\/li>\n<li>Tamb\u00e9m em dezembro de 2021, surgiram not\u00edcias sobre uma explora\u00e7\u00e3o do Log4Shell nos servidores do Minecraft: Java Edition, n\u00e3o hospedado pelo editor do jogo (Microsoft). A empresa <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=\"noopener nofollow\">confirmou<\/a> o relato e chamou a aten\u00e7\u00e3o para a simplicidade da implementa\u00e7\u00e3o do ataque: os cibercriminosos transmitiram c\u00f3digos maliciosos em um chat normal do jogo, o suficiente para rodar tanto no lado do servidor quanto no cliente vulner\u00e1vel. Este caso interessa menos do ponto de vista das v\u00edtimas e mais em termos de implementa\u00e7\u00e3o t\u00e9cnica. Sob certas condi\u00e7\u00f5es, um ataque pode ser realizado simplesmente por meio de um chat interno. Isso \u00e9 preocupante, pois os chats agora v\u00e3o muito al\u00e9m do mundo dos jogos. Para muitas empresas, eles s\u00e3o o m\u00e9todo preferido de comunica\u00e7\u00e3o com os clientes. Em muitas fintechs e outras aplica\u00e7\u00f5es, \u00e9 assim que o suporte ao cliente \u00e9 fornecido.<\/li>\n<li>Em junho de 2022, a Ag\u00eancia de Seguran\u00e7a Cibern\u00e9tica e Infraestrutura dos EUA (CISA) e o Comando Cibern\u00e9tico da Guarda Costeira dos EUA (CGCYBER) <a href=\"https:\/\/www.cisa.gov\/uscert\/ncas\/alerts\/aa22-174a\" target=\"_blank\" rel=\"noopener nofollow\">emitiram um alerta<\/a> de que a vulnerabilidade ainda estava sendo explorada ativamente. O comunicado afirmou que os cibercriminosos usaram uma brecha no mesmo VMware Horizon para penetrar nas redes internas de duas ag\u00eancias governamentais n\u00e3o identificadas. Al\u00e9m disso, os invasores teriam obtido acesso a 130 GB de dados confidenciais relacionados aos servi\u00e7os prestados pelas institui\u00e7\u00f5es.<\/li>\n<li>Em novembro de 2022, a CISA, em conjunto com o FBI, <a href=\"https:\/\/www.cisa.gov\/uscert\/ncas\/alerts\/aa22-320a\" target=\"_blank\" rel=\"noopener nofollow\">emitiu outro alerta<\/a> sobre um ataque Log4Shell a mais uma ag\u00eancia governamental. Os invasores penetraram no sistema em fevereiro, foram detectados em abril e permaneceram ativos de junho a julho. Durante esse per\u00edodo, eles criaram uma conta com privil\u00e9gios de administrador, alteraram a senha de um administrador leg\u00edtimo e carregaram o software de minera\u00e7\u00e3o no servidor. Acredita-se que o ataque seja obra de hackers patrocinados pelo governo iraniano, ent\u00e3o alguns especialistas consideram a minera\u00e7\u00e3o apenas uma cortina de fuma\u00e7a para esconder seus verdadeiros motivos.<\/li>\n<\/ul>\n<h2>Como proteger sua infraestrutura<\/h2>\n<p>Qualquer empresa pode ser v\u00edtima do Log4Shell, muitas vezes simplesmente por n\u00e3o conhecer vulnerabilidades em seus sistemas e software. Se voc\u00ea n\u00e3o tiver certeza se seus sistemas, ferramentas, produtos ou servi\u00e7os usam a biblioteca Log4j, faz sentido conduzir uma [security assessment services placeholder]auditoria completa de seguran\u00e7a[\/security assessment services placeholder]. Fora isso, para se manter seguro, siga estas dicas de nossos especialistas.<\/p>\n<ul>\n<li>Se o Log4j estiver presente em seu software, use a vers\u00e3o mais recente da biblioteca dispon\u00edvel na <a href=\"https:\/\/logging.apache.org\/log4j\/2.x\/download.html\" target=\"_blank\" rel=\"noopener nofollow\">p\u00e1gina do projeto<\/a>.<\/li>\n<li>Leia o <a href=\"https:\/\/logging.apache.org\/log4j\/2.x\/download.html\" target=\"_blank\" rel=\"noopener nofollow\">guia<\/a> oficial do Apache Logging Services e siga-o quando necess\u00e1rio.<\/li>\n<li>Se o Log4j foi usado em produtos de terceiros, atualize todos os softwares vulner\u00e1veis.<\/li>\n<li>Use [KESB placeholder] solu\u00e7\u00f5es de seguran\u00e7a[\/KESB placeholder] capazes de detectar tentativas de explorar vulnerabilidades em servidores e esta\u00e7\u00f5es de trabalho.<\/li>\n<li>Monitore atividades suspeitas dentro do per\u00edmetro corporativo usando <a href=\"https:\/\/www.kaspersky.com.br\/enterprise-security\/endpoint-detection-response-edr?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">solu\u00e7\u00f5es de classe EDR<\/a> ou servi\u00e7os externos como o <a href=\"https:\/\/www.kaspersky.com.br\/enterprise-security\/managed-detection-and-response?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">gerenciador de detec\u00e7\u00e3o e resposta<\/a>. Isso permitir\u00e1 que voc\u00ea encontre e mitigue ataques nos est\u00e1gios iniciais.<\/li>\n<\/ul>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kesb-gartner\">\n","protected":false},"excerpt":{"rendered":"<p>Um ano ap\u00f3s ser descoberta, a vulnerabilidade Log4Shell ainda se faz presente.<\/p>\n","protected":false},"author":2484,"featured_media":20479,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655,1656],"tags":[2854,2852,2853,267],"class_list":{"0":"post-20467","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-vulnerabilidades"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/log4shell-still-active-2022\/20467\/"},{"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":"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-au","url":"https:\/\/www.kaspersky.com.au\/blog\/log4shell-still-active-2022\/31342\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/log4shell-still-active-2022\/31051\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/20467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/2484"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=20467"}],"version-history":[{"count":6,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/20467\/revisions"}],"predecessor-version":[{"id":20477,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/20467\/revisions\/20477"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/20479"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=20467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=20467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=20467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}