Únase a nosotros en un seminario web el miércoles 15 de diciembre en el que los expertos de Zscaler ThreatLabz proporcionarán orientación sobre los últimos detalles de la vulnerabilidad Apache CVE-2021-44228, así como sobre las mejores prácticas para mitigar el impacto de futuras vulnerabilidades.

Recientemente, se ha descubierto una vulnerabilidad de día cero (CVE-2021-44228) en la popular biblioteca de registros Apache Log4j, lo que podría permitir que un atacante ejecutara el código remoto completo. Hay evidencia de que esta vulnerabilidad se está explotando de forma desenfrenada. Esta biblioteca de registros es comúnmente utilizada por las aplicaciones empresariales y los servicios en la nube, con numerosos despliegues empresariales que soportan aplicaciones privadas. Desde entonces, Apache ha lanzado una actualización de seguridad y ha proporcionado configuraciones recomendadas para versiones anteriores que mitigan el impacto de la vulnerabilidad. Recomendamos encarecidamente a todos los administradores de TI que actualicen su software de inmediato si aún no lo han hecho.

Zscaler ha confirmado que la vulnerabilidad CVE-2021-44228 no ha afectado a sus servicios. Lea la publicación de asesoramiento sobre amenazas de ThreatLabz si desea obtener más detalles técnicos sobre esta vulnerabilidad. Si le preocupa que le pueda haber afectado, ejecute un análisis complementario de la superficie de ataque de Internet para ver si tiene alguna superficie de ataque externa que utilice Apache.

Dada la amplia adopción empresarial de Apache Struts y otras ofertas relacionadas, esta vulnerabilidad tiene el potencial de replicarse durante meses y potencialmente años, ya que las bandas de ransomware y los cibercriminales la aprovechan para causar daños incalculables. Desafortunadamente, este tipo de descubrimiento no es nada nuevo y, al igual que Heartbleedy Shellshock anteriormente, sirve para poner de manifiesto el riesgo inherente a nuestro mundo digital interconectado.

Lo que también tengo claro es que si se depende de las VPN y los cortafuegos para proteger su empresa, se corre un riesgo mucho mayor de sufrir daños que si se utiliza una verdadera arquitectura de red de confianza cero. En primer lugar, consideremos por qué los cortafuegos y las VPN suponen un riesgo significativo cuando se utiliza una versión vulnerable de Apache en una aplicación interna:

• Las soluciones de seguridad de red heredadas publican aplicaciones en Internet para permitir el acceso, lo que facilita que los atacantes las identifiquen mediante herramientas disponibles gratuitamente, como Shodan, para convertirlas en objetivo de explotación.
• Los cortafuegos y las VPN colocan a todos los usuarios en la red para que accedan a las aplicaciones, lo que permite a un atacante o a un usuario comprometido desplazarse lateralmente por la empresa para distribuir ransomware o robar datos una vez que se ha establecido un punto de apoyo inicial a través de una vulnerabilidad. El acceso a una aplicación nunca debe requerir acceso a la red.
• Se ha hablado mucho sobre cómo la pandemia aceleró nuestro movimiento colectivo hacia las plantillas híbridas, y no lo voy a repetir, excepto para decir lo siguiente: los cortafuegos y las VPN no solo presentan un riesgo significativo, sino que son lentos, obsoletos y complejos para que una plantilla remota acceda a una aplicación privada. Nadie quiere una solución arriesgada que ofrezca una experiencia de usuario mala.

Teniendo en cuenta esto, yo preguntaría: ¿cuántos de ustedes siguen utilizando cortafuegos y VPN? Ahora es el momento de desarrollar un plan para los próximos tres, seis o nueve meses, ya que no se puede hacer de la noche a la mañana, pero es una de las decisiones más importantes que puede tomar para minimizar el riesgo de su negocio.

Cuatro sencillos pasos para reducir el riesgo con una arquitectura de confianza cero:

Se ha escrito mucho acerca de qué es la confianza cero y sus beneficios inherentes a la seguridad en comparación con los enfoques heredados, pero permítanme hacer un resumen usando la vulnerabilidad Apache como marco.

En este caso, los investigadores de seguridad de Alibaba Cloud descubrieron una vulnerabilidad de día cero, lo que significa que, sin una actualización de seguridad de emergencia, cada cliente que ejecuta una versión vulnerable está en peligro. No solo está en peligro, sino que la vulnerabilidad permite la ejecución completa de código remoto y se permite el acceso completo del administrador al servicio subyacente de Apache y a todos los datos que contiene. Para explotar esta vulnerabilidad, un atacante primero debe encontrar la aplicación en sí. Para impedir que los atacantes lo hagan debería hacer lo siguiente:

1. Minimizar su superficie de ataque y hacer que las aplicaciones sean invisibles: adoptar una arquitectura de confianza cero, como Zscaler Zero Trust Exchange y, específicamente, Zscaler Private Access (ZPA), le permite hacer que todas sus aplicaciones internas sean completamente oscuras e invisibles para Internet. Cuando están ocultas detrás de la plataforma de confianza cero, los atacantes no pueden encontrarlas y explotarlas, y se protegen incluso versiones vulnerables de Apache de esta y futuras vulnerabilidades, algo imposible con las VPN y los cortafuegos heredados.
    

2. Asegurarse de que solo los usuarios autorizados puedan acceder a las aplicaciones: la ciberseguridad es más eficaz cuando se consigue una defensa en capas como parte de una plataforma integrada. Zscaler va más allá de hacer invisibles las aplicaciones vulnerables y solo permite a los usuarios autorizados acceder a las aplicaciones autorizadas en la política en función de una identidad inmutable de proveedores líderes como Azure AD, Okta, Duo o Ping. Si un atacante no está autorizado a acceder a una aplicación vulnerable, se le impediría hacerlo.
   
   Si un atacante logra establecer un punto de apoyo dentro de la red de una empresa, ya sea a través de la explotación de la vulnerabilidad de Apache o de otros medios, inevitablemente continuará su ataque intentando moverse lateralmente para comprometer sistemas adicionales, instalar ransomware y exfiltrar datos. Por lo tanto, usted debería:
    

3. Evitar el movimiento lateral con microsegmentación de usuario a aplicación y de aplicación a aplicación: ZPA desvincula el acceso a las aplicaciones del acceso a la red conectando directamente a los usuarios con los recursos a través de un túnel inverso que nunca pone a los usuarios en la red. Cuando el acceso a la aplicación no requiere acceso a la red, se evita cualquier posible propagación lateral de una infección, incluso si se ha establecido un punto de apoyo inicial. Además, Zero Trust Exchange extiende la misma política de confianza cero a las cargas de trabajo de la nube pública a través de Zscaler Workload Segmentation para detener el movimiento lateral dentro de un centro de datos o entorno de nube. En cualquier caso, la plataforma Zscaler evita que un solo servidor infectado sea utilizado para comprometer a toda la empresa.
    
4. Inspeccionar el tráfico de entrada y de salida. La visibilidad y la supervisión son los pilares de la confianza cero. Al inspeccionar todo el tráfico (tanto cifrado como no cifrado) se puede bloquear el peligro inicial cuando los atacantes intentan acceder a su entorno desde Internet, y se pueden detener las actividades posteriores a la explotación, como la comunicación con servidores de comando y control o la exfiltración de datos. Zscaler Internet Access (ZIA) de confianza cero hace ambas cosas. ZIA Advanced Threat Protection inspecciona tanto el tráfico de Internet a servidor como el de servidor a Internet en busca de indicadores de peligro asociados a vulnerabilidades conocidas, lo que ayuda a bloquear, detectar y mitigar los ataques.

Si quiere proteger a su empresa de las vulnerabilidades de día cero, retire sus cortafuegos y VPN y adopte una verdadera arquitectura de confianza cero con Zscaler Zero Trust Exchange.

Solicite hoy mismo una demostración personalizada de Zero Trust Exchange para comenzar su viaje.

Ejecute un análisis gratuito de superficie de ataque de Internet para ver si tiene alguna superficie de ataque externa que utilice Apache.

Únase a nuestro seminario web el miércoles 15 de diciembre para obtener más detalles y orientación especializada sobre la vulnerabilidad de Apache.