Mucho se ha escrito ya sobre el impacto del 'hackeo' de Diginotar, en concreto se ha hecho hincapié en los cientos de dominios afectados (de todo tipo y de diversa índole).
Pero hasta ahora no he sido capaz de encontrar información realmente profunda sobre los matices a nivel PKI de todo este asunto.
Como punto de partida vamos a usar el informe preliminar de la empresa que está llevando a cabo la auditoría de la intrusión (disponible aquí)
Empezamos:
En el punto 3.2 'Compromised CAs' aparece lo siguiente:
'Due to the limited time of the ongoing investigation we were unable to determine whether all CA servers were used by the attacker(s)' que traducido vendría a decir: en realidad desconocemos cuales CAs han sido utilizadas por los atacantes. No obstante dan una lista de CAs comprometidas, y en la lista aparece:
- DigiNotar Root CA
- DigiNotar Root CA Administrative CA
- DigiNotar Root CA G2
- DigiNotar Root CA System CA
¿Perdón? ¿ he leído DigiNotar Root CA ? increíble, una de las CAs comprometidas es la propia CA raíz, el que debería ser el eslabón mas duro e inexpugnable.
Una CA raíz únicamente se emplea en dos ocasiones, o bien para crear CAs subordinadas o en caso de compromiso de esas CAs, para invalidar las CAs subordinadas. Si este eslabón está comprometido, bye bye, no hay otro mecanismo de salvaguarda.
Grosso modo un esquema PKI funciona así:
- Existe una CA raíz 'madre'
- Esta CA raíz crea otras CAs subordinadas (de nivel 2)
- Las CAs subordinadas son las que firman y generan los certificados para usuarios / servidores finales
- Las solicitudes de certificados se tramitan mediante una RA (registration authority)
Y esto pone sobre la mesa otra pregunta mas inquietante: ¿Habrá sido empleada la CA raíz para crear CAs subordinadas pirata? Esta pregunta no es baladí, los certificados SSL 'normales' emitidos durante el hackeo se pueden revocar, pero si alguien tiene un certificado y la clave privada de una CA subordinada, puede crear bajo demanda y sin control los que quiera
Si seguimos leyendo el informe nos encontramos con esto en el punto 4.4:
The most critical servers contain malicious software that can normally be detected by anti-virus software. The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.
The network has been severely breached. All CA servers were members of one Windows domain, which made it possible to access them all using one obtained user/password combination. The password was not very strong and could easily be brute-forced.
Lo que quiere decir que, tanto las CAs subordinadas como la ¡ CA raíz ! eran fácilmente accesibles vía red e incluso todas formaban parte de un dominio Windows.
Y ahora me toca la tarea mas difícil: intentar recuperar la credibilidad del mundo PKI.
A tenor de lo expuesto previamente, supongo -y con razón- que mucha gente puede creer que implementar una PKI es 'un cachondeo' y que no existe rigor alguno en este campo. Pero esto no es así
De entrada, existen dos normativas que regulan como implementar una PKI y que medidas de seguridad hay que aplicar
'Policy requirements for certification authorities issuing qualified certificates' de ETSI
'Program for Certification Authorities' de Webtrust
Para el lector mas curioso, aquí se puede descargar una de las guías de ETSI (ETSI TS 101 456) y aquí se puede ver la guía de Webtrust
Por ejemplo, Microsoft exige que una PKI debe estar certificada con una de esas dos normativas para añadir el certificado de la CA raíz a Internet Explorer
Ambas guías exponen de una forma MUY clara los niveles de seguridad que debe contar una PKI. Diré a modo de ejemplo que la PKI del DNI electrónico (que cuenta con ambas certificaciones) tiene la CA raíz encerrada en una celda (sí una celda con barrotes) Totalmente offline, inaccesible física o electrónicamente
Normalmente, para realizar una auditoría de este estilo se suelen crear 'check lists' con cosas a analizar, aquí se puede ver un típico check list para realizar una auditoría ETSI
De el voy a sacar unos cuantos párrafos:
'The CA shall carry out a risk assessment to evaluate business risks and determine the necessary security requirements and operational procedures. The risk analysis shall be regularly reviewed and revised if necessary'
'The CA shall have a system or systems for quality and information security management appropriate for the certification services it is providing'
'The CA shall ensure that its assets and information receive an appropriate level of protection'
'The CA shall ensure that the CA systems are secure and correctly operated, with minimal risk of failure'
'The integrity of CA systems and information shall be protected against viruses, malicious and unauthorized software'
'Audit logs shall be monitored or reviewed regularly to identify evidence of malicious activity'
'Controls (e.g. firewalls) shall be implemented to protect the CA's internal network domains from external network domains accessible by third parties'
'Continuous monitoring and alarm facilities shall be provided to enable the CA to detect, register and react in a timely manner upon any unauthorized and/or irregular attempts to access its resources'
Según el informe de la intrusión tenemos: Logs borrados e imposibilidad de tener trazabilidad en el uso de la CA, software como Cain & Abel instalado en las propias máquinas, CAs dentro de un mismo dominio Windows, etc etc.
