Inspección SSL/TLS y ataques Man-in-the-Browser

HTTPS representa actualmente más del 90 % del tráfico web, incluidas las descargas de malware, los canales C2 y la exfiltración de datos. Las herramientas de seguridad perimetral que no pueden inspeccionar TLS solo ven bloques cifrados, lo que crea un punto ciego que los atacantes aprovechan activamente. La inspección SSL/TLS (también denominada interceptación SSL, SSL bumping o inspección profunda de paquetes para HTTPS) permite a las pasarelas de seguridad descifrar, inspeccionar y volver a cifrar el tráfico HTTPS antes de que llegue al endpoint. Esta visibilidad es esencial para el filtrado de contenido web, la prevención de pérdida de datos (DLP) y el análisis antimalware en entornos donde la mayor parte del tráfico utiliza HTTPS.

La inspección SSL es técnicamente un man-in-the-middle controlado, realizado por la propia infraestructura de seguridad de la organización. El proceso es el siguiente: Paso 1: el cliente establece TLS con el proxy (mediante el certificado del proxy firmado por la CA corporativa). Paso 2: el proxy establece una sesión TLS independiente con el servidor real utilizando el certificado auténtico del servidor. Paso 3: el proxy descifra el tráfico del cliente, lo inspecciona, lo vuelve a cifrar y lo reenvía al servidor (y viceversa). El cliente confía en el certificado del proxy porque el certificado de la CA corporativa está preinstalado en todos los endpoints administrados mediante MDM o Group Policy.

No todo el tráfico debería inspeccionarse. Normalmente, las organizaciones excluyen las categorías que contienen datos sensibles desde el punto de vista legal o ético: sitios bancarios y financieros, portales sanitarios, bases de datos de investigación jurídica, URL de transparencia de certificados y OCSP (para evitar interrumpir la validación de certificados) y sitios que utilizan certificate pinning (que rechazarán los certificados vueltos a firmar y harán que la aplicación deje de funcionar). Las exclusiones se mantienen como una lista de bypass en la política de inspección. En algunas jurisdicciones, las leyes sobre supervisión de empleados pueden limitar la inspección de la navegación web personal, por lo que exigen una divulgación clara en las políticas de uso aceptable.

El certificate pinning es una técnica mediante la cual una aplicación incorpora de forma fija el certificado o la clave pública esperados de un servidor específico y rechaza la conexión si el certificado no coincide, incluso cuando el certificado es válido y la entidad de certificación del sistema operativo lo considera de confianza. Esto interrumpe la inspección SSL porque el certificado vuelto a firmar por el proxy no coincide con el valor fijado. Las aplicaciones móviles (aplicaciones bancarias y de pago) utilizan con frecuencia certificate pinning como medida contra ataques MitM. Las empresas deben omitir la inspección para las aplicaciones que usan pinning o dejarán de funcionar. Esto también significa que los atacantes que quieran evadir la inspección SSL desde su malware pueden implementar pinning.

El SSL stripping es un ataque man-in-the-middle en el que un atacante intercepta el tráfico HTTPS y lo degrada a HTTP, lo que le permite leer y modificar el contenido en texto plano. El ataque funciona en conexiones que comienzan como HTTP antes de redirigir a HTTPS: el atacante intercepta la solicitud HTTP inicial, mantiene una conexión HTTP con la víctima mientras establece HTTPS con el servidor legítimo y retransmite el tráfico de forma transparente. Desde la perspectiva de la víctima, el sitio parece utilizar HTTP. HTTP Strict Transport Security (HSTS) protege contra SSL stripping al indicar a los navegadores que utilicen siempre HTTPS para un dominio, incluso si el usuario escribe HTTP.

Un ataque Man-in-the-Browser (MitB) es una forma de troyano bancario que se introduce en el navegador web —como extensión maliciosa o mediante la inyección de un proceso del navegador— y modifica páginas web y transacciones sin que el usuario lo perciba. A diferencia de un MitM de red, MitB opera dentro de la sesión cifrada, en la capa del navegador, por lo que TLS no ofrece protección. El malware MitB (Zeus, SpyEye) puede cambiar importes de pagos, alterar números de cuenta de los destinatarios, capturar contraseñas de un solo uso y modificar formularios silenciosamente después de que el usuario los complete. Las modificaciones se producen después del descifrado TLS y antes de que el usuario vea la página renderizada.

El malware MitB intercepta las API del navegador en la capa de aplicación. En Windows, inyecta código en los procesos del navegador (Chrome, Firefox, IE) mediante la inyección de DLL o el secuestro de COM; después, intercepta funciones de JavaScript y API de manipulación del DOM. Cuando usted visita su banco, el malware intercepta el código JavaScript que representa la página y la confirmación de la transacción, y modifica la cuenta destinataria para sustituirla por la cuenta del atacante. El servidor ve la transacción correcta; los registros HTTPS del servidor no muestran nada inusual. Usted ve la confirmación correcta —con el importe que pretendía enviar—, mientras que la transferencia real llega a la cuenta del atacante.

La defensa contra MitB requiere controles en varias capas. El aislamiento del navegador (Menlo Security, Zscaler Browser Isolation) ejecuta la representación del navegador en una máquina virtual remota en la nube y transmite únicamente los píxeles a la pantalla del usuario; el malware no puede inyectarse en un proceso del navegador que se ejecuta en un entorno remoto. Verificación de transacciones: los bancos confirman los detalles de la transacción (importe + destinatario) mediante un canal fuera de banda (un OTP por SMS que incluye los detalles de la transacción), de modo que usted debe verificar lo que el servidor recibió realmente. Un EDR de endpoint que detecte la inyección de DLL en procesos del navegador puede identificar infecciones de MitB. La lista de extensiones de navegador permitidas evita las extensiones maliciosas.

Las extensiones de navegador maliciosas representan una amenaza importante para los endpoints. Las extensiones tienen permisos amplios: pueden leer el contenido de las páginas, modificar solicitudes, interceptar envíos de formularios y acceder a cookies. Una extensión que se haga pasar por una herramienta útil (bloqueador de anuncios, modo oscuro) puede recopilar credenciales, inyectar anuncios, redirigir el tráfico o actuar como agente MitB. Controles empresariales: use Group Policy o MDM para restringir la instalación de extensiones a una lista de extensiones permitidas y aprobadas. Bloquee la instalación de extensiones desde fuentes distintas de Chrome Web Store o Firefox Add-ons. Audite periódicamente las extensiones instaladas en los endpoints administrados para detectar incumplimientos de las políticas.

Las organizaciones que implementan la inspección SSL deben abordar sus implicaciones para la privacidad de los empleados. Muchas jurisdicciones y leyes laborales exigen notificar claramente la supervisión del tráfico cifrado antes de llevarla a cabo. Entre las prácticas recomendadas se incluyen: publicar una Política de uso aceptable (AUP) que indique explícitamente que el tráfico de red, incluido HTTPS, puede inspeccionarse; hacer que los empleados acepten la AUP durante su incorporación; implementar categorías excluidas para sitios de banca personal y sitios médicos; y conservar los registros del tráfico descifrado únicamente durante el tiempo necesario (normalmente, entre 30 y 90 días). El asesor jurídico debe revisar el programa de inspección antes de su implementación, especialmente en los países de la UE, donde el RGPD establece límites más estrictos para la supervisión de empleados.

Certificate Transparency es un marco (RFC 6962) que exige que todos los certificados TLS de confianza pública se registren en registros CT públicos, auditables y de solo adición antes de que los navegadores confíen en ellos. CT permite a los propietarios de dominios supervisar la emisión incorrecta de certificados: si un atacante consigue convencer de algún modo a una CA para que emita un certificado para su dominio (como ocurrió con DigiNotar en 2011), los registros CT permiten detectarlo casi en tiempo real. Herramientas como crt.sh permiten a los equipos de seguridad buscar en los registros CT todos los certificados emitidos para su dominio. Los navegadores aplican CT al exigir una prueba de inclusión en el registro (marcas de tiempo de certificado firmadas, SCT) integrada en el handshake TLS.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que la inspección SSL/TLS descifra, inspecciona y vuelve a cifrar el tráfico HTTPS en un proxy mediante un certificado de CA corporativa en el que confían los endpoints administrados; el SSL stripping degrada HTTPS a HTTP y se evita mediante HSTS; y los ataques de intermediario en el navegador inyectan código en el proceso del navegador por encima de la capa TLS para modificar transacciones de forma invisible, por lo que requieren aislamiento del navegador o verificación de transacciones mediante un canal fuera de banda. A continuación, analizaremos cómo sustituir protocolos inseguros por sus equivalentes seguros.