El error de Ghostcat afecta a todas las versiones de Apache Tomcat lanzadas en los últimos 13 años



Los servidores Apache Tomcat lanzados en los últimos 13 años son vulnerables a un error llamado Ghostcat que puede permitir a los piratas informáticos hacerse cargo de los sistemas sin parches. Descubierto por la firma china de ciberseguridad Chaitin Tech, Ghostcat es un defecto en el protocolo Tomcat AJP. AJP significa Protocolo Apache JServ y es una versión optimizada del rendimiento del protocolo HTTP en formato binario.
Tomcat usa AJP para intercambiar datos con servidores web Apache HTTPD cercanos u otras instancias de Tomcat. El conector AJP de Tomcat está habilitado de forma predeterminada en todos los servidores Tomcat y escucha en el puerto 8009 del servidor. Los investigadores de Chaitin dicen que descubrieron un error en AJP que puede explotarse para leer o escribir archivos en un servidor Tomcat.
Por ejemplo, los piratas informáticos podrían leer los archivos de configuración de la aplicación y robar contraseñas o tokens API, o podrían escribir archivos en un servidor, como puertas traseras o shells web (el ataque de "escritura" de Ghostcat solo es posible si alguna aplicación alojada en el servidor Tomcat permite usuarios para subir archivos). La vulnerabilidad de Ghostcat es extensa, por decir lo menos. Afecta a todas las 6.
x, 7.x, 8.xy 9. 9. x ramas de Tomcat. Apache Tomcat 6.x se lanzó en febrero de 2007, lo que significa que todas las versiones de Tomcat lanzadas en los últimos 13 años deben considerarse abiertas a ataques.
Los investigadores de Chaitin dicen que encontraron el error a principios de enero de este año y trabajaron con el proyecto Apache Tomcat para tener parches listos antes de salir a bolsa. Se publicaron correcciones para las ramas Tomcat 7.x, Tomcat 8.
x y Tomcat 9.x, pero no para la rama 6.x, que entró en su fin de vida en 2016.
El equipo de Chaitin también lanzó una actualización de su herramienta XRAY para que pueda escanear redes en busca de servidores Tomcat vulnerables. Los identificadores de vulnerabilidad de Ghostcat son CVE-2020-1938 y CNVD-2020-10487 (utilizados internamente en China). Según una búsqueda de BinaryEdge, actualmente hay más de un millón de servidores Tomcat disponibles en línea.
Según Tenable, el código de prueba de concepto [1, 2, 3, 4, 5] para probar o lanzar ataques de Ghostcat proliferaron en GitHub después de la divulgación pública del error la semana pasada. Según Snyk, las aplicaciones creadas en el marco Spring Boot Java también son vulnerables, ya que vienen con un servidor Tomcat incluido previamente. Según Red Hat, Tomcat también se entrega con otros frameworks y servidores basados ​​en Java, como JBossWeb y JBoss EAP.
Red Hat recomienda deshabilitar el conector AJP en Tomcat si no se usa, o vincularlo al puerto localhost, ya que la mayor parte del uso de AJP es en entornos de clúster y el puerto 8009 nunca debe exponerse en Internet sin estrictas listas de control de acceso. pag VER GALERÍA COMPLETA.

Yorumlar

Yorum Gönder

Bu blogdaki popüler yayınlar

Google podría haber solucionado la falla de robo de código 2FA en la aplicación Authenticator hace años

Resim
El mes pasado, una empresa de ciberseguridad descubrió el primer malware para Android que venía con la capacidad de robar los códigos 2FA (autenticación de dos factores) generados por la aplicación Google Authenticator. El malware, descubierto por investigadores de ThreatFabric, se llamaba Cerberus, y su función de robo de código OTP 2FA aún estaba en desarrollo, pero aún no se había detectado en un ataque del mundo real. Según los investigadores, el malware era un híbrido entre un troyano bancario y un troyano de acceso remoto (RAT). Una vez que un usuario de Android se infectaba, el pirata informático utilizaría las funciones del troyano bancario del malware para robar credenciales para aplicaciones de banca móvil. Si una cuenta estaba protegida por 2FA, y concretamente por la aplicación Google Authenticator, el malware se diseñó para permitir que la pandilla Cerberus se conecte al dispositivo de un usuario manualmente, a través de sus funciones RAT. Los hackers luego abrirían la ...
Devamı

Las tasas de parches OEM de Android han mejorado, con Nokia y Google liderando la carga

Resim
Imagen: Dmitry Bayer Las actualizaciones de seguridad están llegando a los usuarios de Android de manera más rápida y confiable que en años anteriores. En una investigación publicada este mes, la firma alemana de ciberseguridad SRLabs dijo que la brecha del parche de Android se ha reducido de 44 días en 2018 a 38 días hoy. El término retraso de parche de Android, o brecha de parche, se refiere al tiempo desde que Google publica formalmente una actualización de seguridad en su sitio web, y hasta que un proveedor de teléfonos inteligentes (OEM o fabricantes de equipos originales) integra el parche en su firmware. SRLabs dice que recopiló información sobre retrasos en los parches utilizando su aplicación de escáner de seguridad SnoopSnitch instalada en más de 500,000 teléfonos inteligentes Android. Si bien la compañía informó que el retraso del parche se ha reducido en un 15% en los últimos dos años, la brecha del parche varió enormemente entre los proveedores de teléfonos inteligente...
Devamı