Abusing an SSH Certificate Authority

SSH admite, además de claves sueltas en authorized_keys, un modelo de certificados: una Autoridad de Certificación (CA) firma claves de usuario, y el servidor confía en cualquier clave firmada por esa CA (TrustedUserCAKeys en sshd_config). Es cómodo a escala (no hay que repartir authorized_keys), pero la clave privada de la CA es una llave maestra: quien la posea puede firmarse un certificado para cualquier principal (cualquier usuario), incluido root.

Si durante la post-explotación encontramos la clave privada de una CA (un fichero como ca-itrc, test.key...), el ataque es directo. Generamos un par de claves y firmamos el certificado indicando el principal que queremos suplantar con -n:

ssh-keygen -t rsa -b 2048 -f keypair                       # par de claves propio
ssh-keygen -s ca-itrc -I attacker -n zzinter keypair.pub   # firmar para el principal "zzinter"
ssh -i keypair -o CertificateFile=keypair-cert.pub zzinter@localhost

El servidor valida que el certificado está firmado por una CA de confianza y que el principal está permitido, y nos deja entrar sin contraseña ni clave previa del usuario objetivo. Repitiendo con -n root (si la CA está autorizada para ese principal) se salta directamente a root.

Matices que importan.

• El principal debe coincidir con lo que el servidor espera (AuthorizedPrincipalsFile o el nombre de usuario). En un objetivo real hay que descubrir qué principales acepta cada CA.
• Algunos despliegues mantienen una lista de revocación (RevokedKeys) por número de serie; ahí conviene fijar un serial concreto con -z <n> que no esté revocado.
• Una CA "decomisionada" pero aún confiada por el sshd es justo el fallo: debía haberse retirado de TrustedUserCAKeys y no se hizo, así que sus firmas siguen siendo válidas.

Cómo detectarlo. En el log de sshd, la firma es un Accepted publickey que menciona un certificado (ID <...> (serial <n>) CA <tipo> <huella>), y en concreto uno para un principal privilegiado (root, un admin) cuyo serial no consta en el registro de emisión legítimo de la CA: eso delata una firma no autorizada. En el host, el uso de ssh-keygen -s <clave-CA> (creación de un certificado) por una cuenta que no es la autoridad emisora (auditd sobre execve) es el otro extremo. Certificados de vida muy larga o principales inesperados por CA son indicadores de auditoría.

Defensa. Proteger la clave de la CA como el secreto más sensible (HSM, host aislado); usar certificados de vida corta; restringir principales por CA; mantener y revisar la lista de revocación; y retirar de la confianza cualquier CA que se decomisione.