Certificados Digitales inseguros en dominios de Apple: BEAST, Lucky13, Perfect Secrecy o Bar Mitzvah

En una de las pruebas que hemos realizado con diversos plugins que el servicio de Pentesting Persistente Faast para verificar la seguridad de los certificados digitales hemos podido localizar rápidamente algunas debilidades en algunos certificados digitales que está utilizando la compañía. Apple y su dominio apple.com es uno de esos mega-dominios que algunas compañías tienen. Seguramente Apple pase varias auditorias al año, pero sus dominios son tan grandes y dinámicos que están en constante crecimiento y cambio.

Por estas razones, las herramientas clásicas de escaneo no son tan flexibles como para poder escanear este tipo de dominios. En una charla sobre bug bounties y Google a la que asistimos recientemente, comparaban a Google y su dominio google.com como un universo, el cual crece y cambia tan rápido que ni el propio Google puede controlarlo. Debido a este tipo de situaciones las grandes empresas optan por los famosos programas de bug bounty y por la necesidad de realizar un Pentesting Persistente como se hace con Faast.

¿Qué prueban los plugins de certificados digitales de Faast?

Las pruebas que se realizan sobre los certificados digitales son varias y podemos recopilarlas por las vulnerabilidades, recomendaciones y notificaciones que el sistema proporciona al usuario. A continuación se muestra el listado de vulnerabilidades detectadas por estos plugins:

• Poodle SSL. Apple ya lo sufrió en su sistema operativo y lo parchearon de urgencia, además de que le apareció en varios certificados usados en Apple.com.

• CRIME. La compresión DEFLATE permite a un atacante obtener las cabeceras de las peticiones web en texto plano a través de este ataque, evolucionado de BEAST. CVE-2012-4929.

• Lucky 13. Con este ataque a TLS se puede obtener el cuerpo de los mensajes que circulan por la conexión a partir de ataques basados en leaks de tiempo.

• OpenSSL CCS (Change Cipher Spec) Injection. Bug de seguridad definido en el CVE-2014-0224.

• Insecure Renegotiation Enabled. Este bug fue presentado hace tiempo y abre los ataques de TLS-Renegotiation CVE-2009-3555. Faast también comprueba si está deshabilitada la renegociación segura.

Figura 1: Dominios de Apple.com con certificados que tienen renegociación segura deshabilitada

• BEAST. El archifamoso ataque descrito por Thai Duong y Juliano Rizzo para descifrar conexiones SSL controlando un padding.

• RC4 Cipher Suites habilitada. Estos algoritmos abren la puerta a los ataques de Bar Mitzvah. 

• FREAK. También hablamos de esto, ya que se tuvo que parchear en todos los sistemas operativos de Apple. El bug de FREAK se basa en los algoritmos de cifrado de exportación EXP.

Otras vulnerabilidades que se verifican, pero que tienen que ver con el certificado y no con el protocolo que se utiliza son las siguientes:

• Caducidad del certificado. Es importante detectar, sobretodo si tenemos muchos dominios, cuales certificados se encuentran caducados o tienen fecha próxima a su caducidad.  

• Certificado emitido para otro dominio. Esto es algo más común de lo que a priori podíamos pensar. En muchas organizaciones se reutilizan ciertos certificados, provocando que el navegador u otras aplicaciones no puedan validar realmente la identidad del certificado.

• Caducidad cercana del certificado. Como se mencionó anteriormente, se evalúa el tiempo de validez del certificado. Hay que recordar que a Apple ya se le caducó el certificado digital de uno de los servidores de Software Updates el año pasado y esta detección temprana lo hubiera resuelto.

Figura 2: Certificado de Apple.com que se caducó

• Certificado autofirmado. Esto es algo común en ciertas organizaciones. Estamos enseñando mal a nuestros usuarios realizando estas acciones, ya que generalmente el navegador va a inidicar que no se ha podido validad la identidad del certificado, mientras que el usuario aceptará la conexión. Esto puede ser un vector a técnicas MiTM.

• KeyStrength débil. En algunas ocasiones las claves utilizadas para realizar el cifrado son demasiado cortas, convertiéndose en débiles. Esto también es evaluado por Faast.

• Certificado inválido. El certificado puede presentar ciertos campos con un mal formato o alguna cadena de confianza no válida.

Por último, en notificaciones y recomendaciones el servicio de Faast comprueba lo siguiente:

• SSLv3 y SSLv2 habilitado. Esto es una mala práctica, la cual puede desembocar en una vulnerabilidad como Poodle. Como hemos dicho, esto ya afectó a Apple en el pasado.

• TLS 1.2. deshabilitado. Es altamente recomendable que TLS 1.2 esté habilitado en el sistema, Faast lo revisa.

Por supuesto, Faast se encuentra en constante desarrollo y nuevos plugins se implementan y se añaden al flujo. Últimamente tenemos mucho trabajo con el tema de certificados, ya que las útlimas vulnerabilidades nos hacen estar entretenidos con ello.

¿Qué se ha localizado?

En la siguiente imagen vemos de un vistazo rápido el que se ha detectado con Faast. El número que aparece al lado de cada vulnerabilidad o debilidad indica sobre cuantos dominios se ha encontrado este fallo.

Figura 3: Resultados de BEAST

Algunos de los dominios con más detecciones por parte de Apple son support.apple.com, discussions.apple.com, areas.apple.com, manuals.info.apple.com o tips.apple.com. Estos dominios son vulnerables, por ejemplo a BEAST. 

Figura 4: Certificados digitales vulnerables a Lucky 13

Otros dominios como locate.apple.com o idmsa.apple.com, el cual es utilizado durante una sesión con el Apple ID, también son afectados, por ejemplo por Lucky 13. Además, estos dominios tienen habilitados el algoritmo RC4 los cuales son criptográficamente inseguros y vulnerables a ataques de Bar Mitzvah.

Figura 5: Certificados digitales vulnerables a ataques de Bar Mitzvah

Seguiremos estudiando la evolución constante de estos dominios y de los certificados digitales que tienen instalados. Hay que recordar que en el pasado ya hicimos una evaluación sobre certificados digitales de Apple y encontramos Poodle. Nosotros apostamos por un pentesting persistente para todas las organizaciones, pequeñas y grandes, y pensar en que el pentesting no es cuestión de auditorias puntuales al año, si no es una necesidad del día a día.