¡Eh, ese no es mi servidor!

A menudo se nos acercan clientes e investigadores preguntando por qué certificados legítimos y de confianza se sirven de repente en hosts de algún país lejano. Casi todos los casos que investigamos se debían a que los principales proveedores de redes de distribución de contenidos (CDN), como Cloudflare y Akamai, no actuaban de forma intencionada cuando se trataba de solicitudes de indicación de nombre de servidor (SNI) nulas.

Cuando usted solicita"https://example.com", su cliente, normalmente un navegador web, inicia un protocolo TLS. Como parte de este proceso, el cliente informa al servidor remoto del nombre de host al que desea conectarse(ejemplo.com). Este paso permite al servidor asignar el nombre de host solicitado al certificado SSL apropiado antes de establecer una conexión segura.

Un servidor bien implementado suele devolver un certificado ficticio/por defecto si la solicitud SNI es nula. Sin embargo, muchas implementaciones sirven un certificado válido para otros dominios (legítimos) que coinciden con esa búsqueda nula.

¿Por qué ocurre esto?

Cuando se ve un certificado en un host fuera de los rangos esperados, es un fuerte indicador de que el host está actuando como proxy, redirigiendo a un rango CDN o a un servidor legítimo.

Dado que los certificados TLS se emiten a nivel de dominio en lugar de estar vinculados a direcciones IP específicas, un administrador puede configurar un proxy para que retransmita de forma transparente el tráfico entre el cliente y el servicio TLS legítimo. Siempre que el cliente proporcione el SNI correcto, el proxy puede pasar datos sin cambios, preservando la integridad del protocolo TLS. Esto hace que el proxy sea indistinguible del servidor TLS legítimo.

Por ejemplo, en las dos capturas de pantalla siguientes, a la izquierda, vemos un host en Rusia que ejecuta el servidor multijugador Sliver C2 en el puerto 31337, lo que en sí mismo es sospechoso, pero a la derecha, si nos desplazamos hasta el puerto 443, vemos un servicio HTTP(s) que ejecuta un certificado legítimo (y de confianza) para microsoft.com.

El certificado es genuino, pero el host que presenta este certificado definitivamente no es propiedad de Microsoft - esto es simplemente un truco - un servidor proxy a uno de los varios hosts de Akamai sirviendo el certificado TLS de Microsoft.com cuando un cliente no proporciona ningún SNI. En este caso, es posible que el actor haya configurado el puerto 443 para reenviarlo a Microsoft como forma de hacer que el host parezca legítimo en una inspección rápida.

Puedes intentarlo tú mismo buscando direcciones IP que sirvan certificados TLS válidos sin requerir un SNI. Akamai y CloudFlare son buenos puntos de partida, ya que gestionan una parte significativa del tráfico HTTPS de Internet y a menudo no responden con certificados falsos. Una vez que haya encontrado un servidor con un certificado TLS que desee replicar, puede utilizar una herramienta como socat de esta manera:

Esto crea una tubería entre el puerto local 443 y el puerto 443 en el servidor remoto - ahora, su servidor parece autoritativo para cualquier certificado TLS que estaba siendo servido desde la dirección IP desnuda del servidor remoto. Abajo, ya he establecido un túnel entre el localhost y 184.24.14.218, que actualmente está sirviendo un certificado para "intel.com". A continuación, ejecutamos un curl contra localhost con el dominio intel.com establecido como SNI. Observe que no hubo advertencias de certificado durante esta solicitud.

¿Pero es malo? Es difícil de decir. No podrás ver ni manipular los datos que se transfieren entre el cliente y el servidor proxy, pero alguien podría usar esto para parecer "más legítimo" ante un extraño. La realidad es que esto podría ser cualquier cosa, desde un actor malicioso tratando de parecer legítimo hasta simplemente una extraña configuración de enrutamiento/proxy. La cuestión es saber cómo funciona TLS cuando veas certificados apareciendo en lugares desconocidos para no acabar yendo por demasiados agujeros de conejo.

Para un análisis rápido, miramos todos los certificados descubiertos en direcciones IP desnudas dentro de AS16625 (AKAMAI-AS), uno de los sistemas autónomos de Akamai. A continuación, buscamos esos certificados duplicados en redes ajenas a Akamai, concretamente en puertos diferentes de los utilizados por Akamai. Por ejemplo, si se encontraba un certificado en el puerto 443 de Akamai pero aparecía en el puerto 4444 de un host que no era de Akamai, se contabilizaba. Además, sólo incluimos los hosts que no eran de Akamai que servían el certificado coincidente y que también devolvían el encabezado de servidor "Akamai Ghost".

Con estas reglas en su lugar, encontramos algo menos de 7.000 hosts distintos en Internet haciendo proxies 1:1 a varios hosts de Akamai sirviendo certificados TLS legítimos en la IP desnuda.

Perspectiva de Censys

Aunque la aparición de certificados legítimos en sistemas remotos inesperados es motivo de investigación, no siempre indica actividad maliciosa. Con miles de hosts actuando como proxies y siendo vistos por escáneres con certificados TLS legítimos, este comportamiento es una de las excentricidades únicas de Internet. Mientras que algunos de estos proxies probablemente se desplegaron intencionadamente como medio para hacer pasar un servidor de control de malware por un sistema legítimo de terceros, otros son probablemente el resultado de proxies sin mantenimiento que redirigen a direcciones IP que han cambiado de propietario.