Una mirada Faast a Apple buscando a Poodle

Los dominios de Apple han sido tradicionalmente un buen sitio donde buscar ejemplos de vulnerabilidades y debilidades. No es casualidad que desde hace mucho tiempo fuera donde probábamos los trucos de Foca para después reportarles los bugs que íbamos localizando en sus servidores. Hoy en día sigue siendo un buen sitio para ello. El volumen de servidores y tecnologías es muy alto, y siempre es fácil ejemplos de cosas nuevas en ellos.

Figura 1: Buscando un caniche en Apple

Buscando a Poodle

En este caso, quería probar el plugin de detección de Poodle que habíamos construido para nuestro servicio de pentesting persistente Faast, así que lo lancé sobre el dominio de Apple.com a ver si alguno de los certificados digitales era vulnerable a esta nueva técnica de ataque. Ya sabía yo que lo más probable era que sí, como se demostraría al poco de comenzar el escaneo, así que configuramos la plataforma para hacer la parte de descubriento y análisis pasivo, es decir, solo leyendo configuraciones de cliente sin lanzar ningún módulo de explotación. Para descubrir si algún servidor es vulnerable a Poodle solo hace falta analizar la configuración del certificado y comprobar si se puede hacer el downgrade de la negociación.

Figura 2: Un par de ejemplos vulnerables a Poodle descubiertos con Faast

La discusión en la red es que al fin y al cabo, no parece que sea extremadamente fácil explotar Poodle para alguien sin gran control en la red, pues al igual que en ataques similares en el pasado en los que hay que controlar un padding, hace falta encajar un entorno de man in the middle con una inyección client-side de JavaScript que permita al atacante controlar el relleno en el flujo de datos en el CBC para poder descifrar después la información que se envía detrás del padding.

Content Security Policies

Pensando en ello, la mejor forma de fortificar la plataforma frente a Poodle sería hacer una fortificación de todas las conexiones a los servicios web mediante un HTTPs - para evitar una inyección con el mismo ataque man in the middle en las conexiones que no lleven esa protección y, a ser posible, sacar partido de las Content Security Policies para evitar inyecciones en client-side no deseadas dentro de las webs.

El uso de las CSP no está demasiado extendido aún en todos los servicios de Internet, pero nosotros en Faast lo buscamos y alertamos a nuestros clientes de que su sitio podría estar un poco más seguro si fortifica la plataforma añadiendo unas políticas de contenido ajustadas a la estructura del sitio, evitando la carga de contenido script inline o la carga de plugins desde ubicaciones terceras, etcétera. 

Figura 3: Algunos dominios sin fortificación CSP en Apple.com

En el caso de Apple, no aparecen demasiados sitios con CSP activado, y por supuesto, los dos ejemplos de certificados vulnerables a Poodle no están en la lista de los que la aplican, con lo que las inyecciones client-side están un poco menos protegidas que en otros que sí lo aplican. Por supuesto, a pesar de eso seguiría siendo difícil inyectar en el cliente si no hay un bug, pero siempre se puede sumar alguna debilidad extra.

Contenido Mixto HTTP & HTPPS

Otra de las cosas que mira Faast es si en una sesión HTTPs algún contenido se envía por HTTP, rompiendo la privacidad de la conexión y permitiendo a un atacante que esté haciendo man in the middle inyectar en el cliente algún código. Apple no tiene demasiado cuidado de esto, y basta con ir a cualquier app de la App Store para ver cómo las imágenes se cargan desde la caché en la CDN bajo conexiones inseguras, haciendo que salten las alertas en el navegador.

Figura 4: Contenido mixto HTTP - HTTPs en iTunes

En el caso del servidor de imágenes, podemos ver que a pesar de que permite una conexión HTTPs, luego carga contenido por HTTP, lo que permitiría esa inyección en un entorno de man in the middle. Al final no estoy diciendo que sea fácil la explotación de Poodle en Apple, ni mucho menos, sino que en los grandes entornos es fácil encontrar puntos débiles en los servidores.

Figura 5: Contenido HTTP servido en algunas conexiones HTTPs

En este caso se han dado unas características curiosas porque al final, el certificado que esta en el servidor images.apple.com no está creado para ese dominio, ya que lo único que sucede es que comparten el mismo servidor www.apple.com e images.apple.com con un certificado emitido para la CDN de Akamai en Reino Unido, que es el CPD que me está sirviendo tanta la web de www.apple.com como images.apple.com a mí en España.

Figura 6: El certifiado que ser sirve en https://images.apple.com

Al final, como se puede ver, cuando sale un bug tipo Poodle, el que la seguridad de tu infraestructura esté fortificada en todos los puntos o no ayudará a que sea más fácil explotar esa vulnerabilidad...o no. Así que la recomendación es siempre la misma, aplica las reglas de la fortificación de sistemas siempre que puedas: Mínimo Punto de Exposición, Mínimo Privilegio Posible y Defensa en Profundidad. La seguridad de tus sistemas te lo agradecerán.

Saludos Malignos!