Pendant que tout le monde regarde la panne WiFi et les certificats NDES expirés, je lis le registre.
La rafale de courriels autour du problème Intune m'a montré exactement où sont les serveurs NDES. Et qui a accès admin à eux.
Il s'avère que l'admin sur SCCM est aussi l'admin sur NDES. Plus facile comme ça, right? Le même compte partout. J'ai déjà ces credentials du compromis SCCM.
Local admin sur le serveur NDES. J'ouvre HKLM\software\microsoft\cryptography\mscep\.
La ruche du registre qui dit à NDES quels modèles utiliser pour l'inscription. Voyons ce qu'on a.
EncryptionTemplate et SigningTemplate pointent vers les modèles par défaut. Simple client auth. Modèle utilisateur. Authenticated Users peut le demander.
Ce n'est pas un choix sûr. C'est une invitation.
Je lis la clé privée du certificat de service NDES. Je suis admin, c'est lisible. Je modifie le registre pour pointer vers le modèle utilisateur au lieu des défauts. J'accorde à mon compte des permissions de lecture sur la clé privée du certificat de service — j'ai besoin de l'utiliser.
Redémarrage IIS. Personne ne surveille les redémarrages de service sur la boîte NDES. Le service redémarre, lit la nouvelle configuration du registre, et maintenant je contrôle quel modèle il utilise.
Maintenant je fais quelque chose de différent que ce que fait Intune.
NDES est une autorité d'enregistrement. Elle détient deux certificats spéciaux : l'un pour déchiffrer les demandes d'inscription, l'un pour les co-signer au nom de quelqu'un d'autre. Quand Intune envoie une demande SCEP via NDES, NDES utilise ce certificat co-signature pour dire « Je cautionne cette demande. Émets le certificat ».
La magie c'est que NDES ne valide pas ce qui est dans la demande. Il la signe juste. L'AC fait confiance à NDES, donc l'AC fait confiance à tout ce que NDES signe.
Je demande des certificats directement au serveur NDES. Je demande des certificats d'authentification avec des noms de sujet correspondant à chaque compte d'admin domain dans l'environnement. Des noms normaux et des noms de compte privilégiés. J'utilise le certificat d'autorité d'enregistrement de NDES lui-même pour m'inscrire au nom de chacun.
NDES signe les demandes. L'AC émet les certificats. Ils sont cryptographiquement valides et sont des certificats d'authentification domain admin.
J'ai maintenant des credentials Kerberos pour chaque domain admin dans l'organisation, émis par leur propre autorité de certification.
Je change le registre back. Je remets les ACLs du certificat de service comme elles étaient. Je redémarre IIS encore une fois.
Puis je laisse une signature. Nouvelle clé de registre dans HKLM : HKLM\software\Hiro_was_here.
Tout le reste a l'air normal. Le serveur NDES répond correctement. Les modèles sont où ils devraient être. Les certificats de service sont où ils devraient être. Personne ne sait que j'étais là jusqu'à ce qu'ils cherchent dans le registre.
Mais j'ai des credentials d'admin domain que l'organisation elle-même a émis via son PKI.
Si tu es un défenseur, voici ce qui vient d'arriver.
La chaîne de compromis
- Consolidation de privilège d'admin cross. Le même compte est admin sur SCCM et NDES. Compromise un, tu as les deux.
- Conception de modèle faible. Un modèle utilisateur avec inscription Authenticated Users, simple client auth. Accessible à n'importe qui dans le domaine.
- Configuration de registre non surveillée. La ruche du registre NDES est writable par local admin. Changer quel modèle NDES utilise demande local admin, mais personne ne le surveille.
- Exposition ACL de clé privée. La clé privée du certificat de service NDES est lisible par local admin. Si tu es admin, tu peux l'utiliser.
- Aucune surveillance sur redémarrage de service. Le redémarrage IIS est une opération normale. Aucune alerte quand ça arrive.
- Certificat d'autorité d'enregistrement sans validation. NDES signe tout ce que tu lui demandes de signer. Il ne valide pas le nom de sujet dans la demande. Il dit juste « NDES approuve ça » en la co-signant. L'AC fait plus confiance à la signature de NDES qu'à la valeur réelle du sujet.
- Aucune trace d'audit. Personne ne surveille qui demande des certificats via NDES ou quels noms ils demandent.
Chacun d'eux est un gap connu. Ensemble, ils laissent un attaquant avec local admin émettre des certificats d'authentification pour n'importe quel compte dans le domaine.
Ce qu'il faut vérifier cette semaine
Regarde ton déploiement NDES :
- Qui a admin sur le serveur NDES? Est-ce le même compte qui a admin sur SCCM, ou serveurs de backup, ou DNS? Réduis le chevauchement. Tier les admins.
- Quel modèle NDES utilise? Pas les défauts. Audit le modèle. Il ne devrait pas permettre à Authenticated Users de s'inscrire.
- Surveille les changements de registre. La configuration NDES est dans HKLM. Alerte sur les writes à
HKLM\software\microsoft\cryptography\mscep\. Si le registre change, sache-le immédiatement. - Surveille les redémarrages de service. Le redémarrage IIS sur un serveur NDES devrait déclencher une alerte. Les redémarrages inattendus sont un tell.
- Surveille les demandes de certificat via NDES. Log chaque certificat qui se fait inscrire via le service NDES. Corresponds le demandeur au nom de sujet. S'ils ne correspondent pas, quelque chose ne va pas.
- Surveille l'utilisation du certificat d'autorité d'enregistrement. Le certificat de service NDES devrait seulement être utilisé par le service NDES. Si quelque chose d'autre lit sa clé privée, c'est un compromis.
Le principe de fermeture
L'autorité d'enregistrement est puissante parce que l'AC fait confiance à sa co-signature. Mais l'AC y fait confiance seulement parce que NDES est supposé être protégé. Si NDES roule sous un compte admin standard, si le registre est writable, si les modèles sont faibles, s'il n'y a pas de surveillance — alors NDES n'est pas protégé.
Le certificat d'autorité d'enregistrement devient une credential qui accorde l'émission de certificat. Protège-le comme tu protèges l'AC elle-même.
La plupart des organisations ne le font pas.
Hiro out.