La creación del certificado falso usado por TheFlame, ridiculiza la estructura PKI de Microsoft (I)

Microsoft examinó el certificado falso. Comprobó que las extensiones oficiales habían sido borradas. Lo lógico quizás hubiera sido que tuviese el valor 1.3.6.1.4.1.311.2, que define que el certificado está creado para firmar código. Pero no. Entonces, ¿por qué la cadena de certificación lo dejó pasar?

A la izquierda, las extensiones de un certificado usado para firmar un programa cualquiera. A la derecha, el certificado falso de TheFlame

Lo que han detectado son dos problemas por separado, además de otros adicionales. Vayamos por partes.

Un certificado debe estar restringido en su uso a través de las extensiones Extended Key Usage. Así, un certificado puede ser usado para autenticar un servidor a través de SSL o para cifrar un correo (S/MIME). En el RFC 5280 donde se especifica la implementación, no se aclara totalmente el cómo hacerlo. Microsoft eligió la manera equivocada. En resumen, el certificado final hereda EKU (Extended Keys Usage) “por omisión“, debido a que las autoridades certificadoras superiores se lo proporcionan “indirectamente“.

Si se examina la cadena de certificación del certificado usado por TheFlame, se comprueba que finalmente, el certificado puede llegar a servir para firma código, aunque no posea un campo EKU explícito. ¿Y por qué “puede llegar“? Microsoft considera que si no se define el uso específico del certificado EKU, se puede decir que es “bueno para todo“, pero, si uno de los certificados “padre“, define alguna EKU, no puede usarse para algún uso diferente al de los ya definidos.

Con estos descubrimientos en la PKI de licencias de Terminal Server de Microsoft, los atacantes ya podían firmar código a partir de una licencia de Terminal Server. El código pasaría como totalmente válido (creado y validado por Microsoft) en Windows 2003, XP… y sin necesidad de colisión ni nada parecido. Podrían enviar una petición de firma a un servidor de licencias, y usar la clave privada de esa clave pública para firmar un programa y que pareciese totalmente de Microsoft. Es por esta razón que en la alerta de Microsoft se afirmaba que el ataque era posible también “sin necesidad de colisión“. Y esto ha ocurrido hasta que apareció Vista y el service pack 3 para XP. Esto es un absoluto desastre.

Ahora bien… en Windows XP Service Pack 3, Vista, 2008 y 7, este método no sería válido, porque cambió la forma en la que se manejaban las extensiones. En los certificados, se puede marcar un campo como crítico. Los campos definidos como críticos (en la interpretación gráfica de los certificados, aparece con un signo de admiración), hacen que el certificado falle en su validación si no están establecidos convenientemente. O sea, si a la hora de dar por válido un certificado que está siendo usado para firmar código, se encuentra en su interior una extensión crítica que dice que es para otro uso, se daría por inválido el certificado (pero solo en sistemas post-Vista, no en los anteriores).

Los certificados de licencias de Terminal Server suelen tener la extensión “Hydra” marcada como crítica. Así que si los atacantes querían un certificado para firmar que funcionara en todas las versiones, tenían que eliminar por completo ese campo crítico (así a la hora de validarlo, no se encontraría con que el certificado hacía una función, pero en su interior decía que estaba destinado a otra) y que aun así el certificado siguiese siendo válido.

¿Qué hicieron entonces los atacantes? Lo veremos en la siguiente entrega.

Investigadores consiguen hacer que cualquier certificado SSL parezca válido

Sergio de los Santos

Twitter: @ssantosv