Chrome advirtió el día 17 de que se actualizaba para revocar una serie de certificados digitales. Mozilla advirtió el día 22 de marzo de que actualizaba su navegador porque había incluido en él certificados fraudulentos. El día 23 es Microsoft la que confirma que debe actualizar su lista de certificados porque incluye varios inválidos. ¿Qué significa todo esto? ¿Qué pasa con los certificados?
¿Para qué sirven los certificados?
SSL debería cumplir dos funciones. Establecer una conexión cifrada sobre un canal público y también autentica al servidor. Nos ayuda a estar seguros de que el servidor es quien dice ser y también que pertenece a la empresa a la que debería pertenecer. Para la parte de autenticación, los servidores con SSL activo ofrecen al navegador un certificado para que lo compruebe, que es como una especie de DNI. En él, una autoridad (Verisign, Comodo…) certifica con su firma que la clave pública realmente pertenece al sitio.
El sistema de confianza en certificados tiene una estructura de árbol invertido y las raíces son estos certificados. El sistema confiará en todo lo que emitan. Si esto no ocurriese de esta forma y los navegadores o sistemas operativos no contasen con una serie de certificados raíz por defecto, no podríamos confiar en la identidad de las páginas, puesto que nadie lo acreditaría. Por el contrario (y como ocurre en realidad) se introducen demasiadas autoridades certificadoras en las que se confía (demasiados «Estados» que emitan el DNI), estas se vuelven el punto débil de la cadena, puesto que se confía en ellas y a su vez, en todo lo que ellas confíen. Un árbol con demasiadas «raíces» es más difícil de controlar. Además, las autoridades certificadoras confían en autoridades intermedias que le alivian el trabajo.
Qué ha pasado
Tanto Chrome como Mozilla como Internet Explorer (a través de la Trusted Root Certification Authorities Store) incluyen de serie una serie de certificados raíz en los que se confía, emitidos por autoridades certificadoras. Varios de estos certificados pertenecientes a Comodo han sido revocados porque se ha comprobado que han sido emitidos de forma fraudulenta sin su consentimiento.
Según ha anunciado Comodo (en una nota de prensa tardía, una vez que ya se había descubierto el asunto), un atacante con IP de Irán se hizo con usuario y contraseña de una autoridad secundaria de Comodo en el sur de Europa. El atacante utilizó estos datos para hacerse pasar por esa autoridad secundaria y emitir certificados fraudulentos de páginas como login.live.com, mail.google.com, http://www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org… Traducido: un atacante quería obtener certificados de esos dominios para hacerse pasar por ellos. Pero… ¿cómo puede ser, si ya existen? ¿Para qué emitir certificados válidos de dominios a los que no puedes suplantar? Esta es la segunda parte del problema: para que esto le sea útil al atacante, necesita:
* Emitir certificados válidos. Lo consiguió comprometiendo a esta entidad de Comodo.
* Que se le muestren como válidos a la víctima en su navegador. Esto es lo que hacen ya de por sí los navegadores con sus certificados raíz. Ahora que la mayoría los han revocado, esto no sería tan sencillo.
* Interponerse en el sistema DNS de la víctima. Bien por pharming, por «hombre en el medio», troyanos o por cualquier otro método que redirija la resolución de dominios de la víctima.
Así, el atacante redirige a «otro» dominio a la víctima, e instala ahí el certificado que ha robado. A partir de ahí, podría o bien suplantar a la otra página o bien redirigir a la víctima a la original. El asunto es que, en cualquier caso, tendría acceso a toda la información, cifrada, que se transmita entre la víctima y el dominio al que quiere acceder. Aunque estuviese cifrada, aunque aparezca el candado en el navegador al visitar esta página, o la barra de navegación en verde, e incluso se compruebe la cadena de certificación… no solo el navegador dará por legítima la página, sino que el atacante podrá leer toda la información cifrada que se transmite.
Si unimos que el ataque a Comodo no habrá sido «sencillo» (se trata de uno muy sofisticado y dirigido), que la IP proviene de Irán, que el atacante emitió certificados para páginas muy conocidas, y que necesita además, para que esto sea efectivo, tener acceso a un cambio en los DNS… todo apunta a un ataque que, cuando menos, inquieta.
ssantos@hispasec.com
Más información:
The Recent RA Compromise
http://blogs.comodo.com/it-security/data-security/the-recent-ca-compromise/
Stable and Beta Channel Updates
http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html
Microsoft Security Advisory (2524375)
http://www.microsoft.com/technet/security/advisory/2524375.mspx
03/06/2008 Mitos y leyendas: «Compruebe el candadito del navegador para estar seguro» I (Phishing)
http://www.hispasec.com/unaaldia/3510
Deja una respuesta