Índice analítico[Ocultar][Mostrar]
Log4Shell, unha vulnerabilidade de Internet, afectou recentemente a millóns de máquinas. Log4j, unha peza de software escura pero case ubicua, é o que provoca.
Log4j utilízase para rexistrar todas as accións que ocorren entre bastidores nunha variedade de sistemas informáticos.
Está baseado nunha biblioteca de rexistro de código aberto que é utilizada por empresas e mesmo organizacións gobernamentais na maioría das aplicacións.
Sendo un dos peores buracos de seguridade cibernética xamais descubertos, é fundamental protexer os seus sistemas contra esta vulnerabilidade. Pero como?
Exploremos a vulnerabilidade de Log4j en detalle e todas as solucións posibles para solucionar ela.
Que é Log4j?
Log4j é un open-source marco de rexistro que permite aos desenvolvedores de software rexistrar diferentes datos dentro das súas aplicacións. É un compoñente do proxecto Apache Logging Services, que está a cargo de Fundación de Software Apache.
Centos de sitios web e aplicacións usan Log4j para realizar operacións críticas, como o rexistro de datos para a depuración e outros usos.
Cando introduces ou fai clic nunha ligazón en liña deficiente e recibe un aviso de erro 404, este é un exemplo frecuente de Log4j no traballo. O servidor web que executa o dominio da ligazón web á que intentou acceder infórmache de que non existe esa páxina web. Tamén rexistra o evento en Log4j para os administradores do sistema do servidor.
Ao longo dos programas de software, empréganse sinais de diagnóstico similares. No xogo en liña Minecraft, por exemplo, o servidor usa Log4j para rexistrar a actividade como a RAM total utilizada e as instrucións de usuario enviadas á consola.
Como se produce a vulnerabilidade?
As buscas son unha nova función introducida en Log4j 2.0, que axuda a incorporar información adicional nas entradas de rexistro. Unha destas buscas é a busca JNDI (Java Naming and Directory Interface), que é unha API de Java para comunicarse cun servizo de directorio.
Usando este enfoque, os ID de usuario internos pódense asignar a nomes de usuario reais. Esta consulta expón a vulnerabilidade de RCE recentemente descuberta, xa que un dos tipos de datos proporcionados polo servidor LDAP é un URI que apunta a unha clase Java, que despois carga na memoria e executa a instancia Log4j.
Debido a unha debilidade na validación de entrada da biblioteca Log4j, é posible inxectar un servidor LDAP arbitrario desde unha fonte non fiable. Dado que os desenvolvedores asumen que os datos enviados aos rexistros se tratarán como texto simple, non se leva a cabo ningunha validación de entrada adicional e entran entradas perigosas dos usuarios nos rexistros.
Unha declaración de rexistro pode verse así:
Un usuario malintencionado inseriría agora unha busca JNDI facendo referencia a un servidor LDAP malintencionado nun parámetro URL. A busca JNDI sería a seguinte:
A biblioteca Log4j fala con este servidor LDAP en attacker.com para obter información do directorio, incluídos os valores para Java Factory e Java Codebase.
Estes dous valores inclúen a clase Java do atacante, que despois se carga na memoria e executa a instancia Log4j, completando a execución do código.
Quen está en risco?
A vulnerabilidade de Log4j é incriblemente ampla e afecta ás aplicacións empresariais, aos dispositivos integrados e aos seus subsistemas. As aplicacións afectadas inclúen Cisco Webex, Minecraft e FileZilla FTP.
Non obstante, esta non é unha lista completa. A falla incluso afecta a misión helicóptero Ingenuity Mars 2020, que usa Apache Log4j para a gravación de eventos.
A comunidade de seguridade elaborou un lista de sistemas vulnerables. É fundamental ter en conta que estas listas se actualizan continuamente, polo que se un determinado programa ou sistema non aparece, non asumas que non se ve afectado.
A exposición a esta vulnerabilidade é bastante probable, e aínda que sexa específica pila de tecnoloxía non aplica Java, os executivos de seguridade deben esperar que o fagan os sistemas de provedores críticos, os provedores de SaaS, os provedores de hospedaxe na nube e os provedores de servidores web.
Como comprobar a vulnerabilidade Log4j?
O primeiro paso é determinar se xa se produciu un asalto. Podes facelo comprobando os rexistros do sistema para detectar fragmentos de carga útil RCE.
Se a busca de termos como "jndi", "ldap" ou "$::" produce rexistros, os investigadores de seguridade deberían explorar máis a fondo para ver se se trata dun ataque lexítimo ou só de pegadas dixitais.
Descubríronse moitos asaltos en estado salvaxe que non entregaron ningunha carga útil. Non obstante, foron realizados por expertos en seguridade para determinar cantas aplicacións eran vulnerables a este ataque.
O seguinte paso é usar a biblioteca Log4j para identificar todos os proxectos. Se se usan versións entre 2.0-beta9 e 2.14.1, o proxecto pode ser susceptible.
Dada a dificultade para determinar onde existe esta vulnerabilidade, pode ser preferible presumir que o proxecto é susceptible e que actualizar a biblioteca é o mellor curso de acción para eliminar o perigo de execución de código.
O proxecto non é vulnerable se a versión utilizada é inferior á 2.0-beta 9, aínda que a biblioteca Log4j aínda debería actualizarse porque as versións do rango 1.x son antigas e xa non reciben actualizacións.
Se se descobre un proxecto susceptible, recoméndase que se comprobe para ver se algunha información rexistrada mediante Log4j contén información que o usuario pode cambiar. Os URL, os parámetros de solicitude, as cabeceiras e as cookies son exemplos destes datos. Se un destes está rexistrado, o proxecto está en perigo.
Este coñecemento pode axudarche a afondar máis nos rexistros do sistema e a determinar se a túa aplicación web xa foi atacada.
Existen ferramentas en liña gratuítas que poden detectar se unha aplicación web é vulnerable. Un destes programas é Log4Shell cazadora. É de código aberto e dispoñible en GitHub.
Se se descobre unha área vulnerable de código na aplicación en liña, a carga útil proporcionada pola ferramenta divulgada pódese utilizar para inxectala na aplicación web. A ferramenta de proba revelaría as conexións feitas entre a súa aplicación web e o seu servidor LDAP se se explotase a vulnerabilidade.
Solucións para corrixir a vulnerabilidade de Log4j
O primeiro paso é actualizar Log4j, o que podes facer usando os xestores de paquetes normais ou descargándoo directamente desde este páxina.
Tamén é posible diminuír a explotabilidade da vulnerabilidade configurando a variable de ambiente FORMAT MSG NO LOOKUPS como verdadeiro. Esta contramedida, porén, só é aplicable ás versións de Log4j superiores ou iguais á 2.10.
Consideremos agora opcións alternativas.
1. Solucións para a versión 4 de Log2.17.0j
Recoméndase encarecidamente usar a versión 4 de Log2.15.0j para protexerse contra Log4Shell, pero se isto non é posible, hai outras solucións dispoñibles.
Versións 2.7.0 e posteriores de Log4j: É factible protexerse contra calquera ataque cambiando o formato dos eventos que se rexistrarán mediante a sintaxe de percent m nolookups para os datos proporcionados polo usuario. Esta actualización require editar o ficheiro de configuración de Log4j para xerar unha nova versión do programa. En consecuencia, antes de despregar esta nova versión, hai que repetir as fases de validación técnica e funcional.
Versións de Log4j 2.10.0 e posteriores: Tamén é posible protexerse contra calquera ataque configurando o parámetro de configuración log4j2.formatMsgNoLookups como verdadeiro, por exemplo, ao iniciar a máquina virtual Java coa opción -Dlog4j2. formatMsgNoLookups = true, Outra opción é eliminar a clase JndiLookup do argumento classpath, o que eliminará o vector de ataque principal (os investigadores non descartan a posibilidade doutro vector de ataque).
Amazon Web Services ofrece un hotpatch que "debe utilizarse baixo o seu propio risco". Publicáronse outras "técnicas", como Logout4Shell, que "utiliza esta vulnerabilidade contra si mesma". O experto en seguridade cuestiona a legalidade deste movemento, que implica "piratear unha máquina para arranxalo".
2. O problema foi resolto en Log4j v2.17.0.
Para versións superiores a 2.10: Log4j2.formatMsgNoLookups debe establecerse como verdadeiro.
Para as versións da 2.0 á 2.10.0: execute o seguinte comando para eliminar a clase LDAP de Log4j.
Log4j2.formatMsgNoLookups debe establecerse como verdadeiro na configuración do sistema.
Mitigación en JVM
A mitigación con parámetros JVM xa non é unha opción. Outros métodos de mitigación seguen tendo éxito. Actualiza a Log4j versión 2.17.0 se é posible. Hai unha guía de migración dispoñible para Log4j v1.
Se non é posible realizar unha actualización, asegúrese de que os compoñentes do lado do cliente e do servidor teñan a propiedade do sistema -Dlog4j2.formatMsgNoLookups = true definida.
Teña en conta que Log4j v1 chegou ao final da súa vida útil (EOL) e xa non recibirá correccións de erros. Outros vectores RCE tamén son susceptibles a Log4j v1. Por iso, recomendámosche que actualices a Log4j 2.17.0 canto antes.
3. Medidas de mitigación
Os exploits actuais non poden funcionar aínda que Log4j sexa susceptible nalgúns casos, como se a máquina host está a executar unha versión de Java superior a 6u212, 7u202, 8u192 ou 11.0.2.
Isto débese a unha mellor protección contra a carga remota da clase JNDI (Java Naming and Directory Interface) nas versións actuais, que é necesaria para que o ataque funcione.
Ademais, con versións de Log4j superiores á 2.10, o problema pódese evitar configurando o valor do sistema formatMsgNoLookups en true, proporcionando o argumento JVM -Dlog4j2.formatMsgNoLookups = true ou eliminando a clase JndiLookup da ruta de clase.
Mentres tanto, ata que se solucionen as instancias vulnerables, a vulnerabilidade pódese solucionar mediante as seguintes técnicas:
- Establece a propiedade do sistema log4j2.formatMsgNoLookups como verdadeiro para >=2.10.
- Establece a opción de entorno LOG4J FORMAT MSG NO LOOKUPS como verdadeiro para >=2.10.
- Elimina JndiLookup.class da ruta de clase para a versión 2.0-beta9 a 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Unha boa práctica recomendada é limitar o tráfico de saída a Internet só aos portos adecuados.
Aínda que a maioría dos ataques no campo realízanse a través de HTTP, a vulnerabilidade pode ser explotada a través de calquera protocolo que rexistre os datos de entrada do usuario mediante Log4j.
Non obstante, actualizar a log4j 2.17.0 é o mellor remedio porque alguén pode descubrir un enfoque adicional para o problema. Ademais, moitos editores e fabricantes anunciaron melloras nos seus servizos ou aplicacións.
4. Parche de vulnerabilidade de Log4Shell
Log4j é omnipresente, especialmente agora que se está a explotar a vulnerabilidade. Para resumir, todo o que tes que facer é incluír os seguintes caracteres nos rexistros inspeccionados por Log4j.
E isto descargará e executará o ficheiro Java situado ao final do URL. É tan directo como dramático.
Como sabes, é fundamental actualizar log4j á versión >= 2.17.0 para remediar esta vulnerabilidade de Log4Shell (CVE-2021-44228).
Se isto non é posible:
Para aplicacións que usan versións da biblioteca Log4j 2.10.0 e posteriores, tamén é posible protexerse contra calquera ataque configurando o parámetro de configuración log4j2.formatMsgNoLookups en verdadeiro, por exemplo, mentres se inicia a máquina virtual Java co -Dlog4j2.formatMsgNoLookups = true. opción.
Outra opción é eliminar a clase JndiLookup do argumento classpath, o que eliminará o vector de ataque principal (os investigadores non descartan a existencia doutro vector de ataque).
Nota
As organizacións que dubidan ou non queiran facer axustes nos sistemas susceptibles (ou que non queiran instalar garantías adicionais) deberían pensar en:
- Asegúrese de que todo o tráfico se dirixe a través dun iSensor/WAF/IPS. Isto pode evitar que o asalto acceda ao sistema.
- Limitar a cantidade de tráfico que pode chegar ao sistema susceptible Se o sistema non precisa estar conectado a Internet, restrinxe o acceso a IPS e rangos só esenciais e fiables.
- Reducindo o tráfico de saída autorizado do host. Debido a que este ataque opera conectándose a un servidor deshonesto, todos os enderezos e portos IP superfluos deberían bloquearse nun cortalumes.
- Se o servizo xa non é necesario, debería desactivarse ata que estea preparada unha corrección.
Conclusión
Os fallos de Log4j sorprenderon á nosa comunidade e lembraron a todos o que dependemos do software de código aberto.
Log4j é único. Non é un sistema operativo, nin é un navegador, nin é un software. Pola contra, é o que os programadores denominan biblioteca, paquete ou módulo de código. Só ten un propósito, é dicir, manter un rexistro do que acontece nun servidor.
As persoas que escriben código prefiren concentrarse no que fai distintivo o seu software. Non lles interesa reinventar a roda. Como resultado, confían nunha infinidade de bibliotecas de código existentes, como Log4j.
O módulo Log4j deriva de Apache, o software de servidor web máis utilizado. É por iso que se pode descubrir en millóns de servidores. Polo tanto, aumentan as ameazas de seguridade.
Espero que as solucións anteriores che axuden a manter os teus dispositivos seguros.
Permanece atento a HashDork para obter máis información útil do mundo da tecnoloxía.
Deixe unha resposta