Peu d'entreprises ont le luxe de disposer d'une équipe de professionnels à plein temps. PKI à temps plein. Les entreprises qui confient cette tâche à une personne ayant une fonction principale distincte, telle que l'ingénierie AD, sont plus typiques. C'est pourquoi je constate que de nombreux praticiens de PKI n'ont pas la compétence PKI comme premier ensemble de compétences. Il est facile de comprendre comment une mentalité de "faire en sorte que ça marche" peut finir par s'insinuer dans les processus opérationnels d'une PKI . Trop souvent, l'efficacité opérationnelle l'emporte facilement sur l'efficacité technique. Trop souvent, l'efficacité opérationnelle l'emporte facilement sur les risques de sécurité perçus.
Mais lorsqu'une approche du type "faites en sorte que ça marche" fait son chemin dans le provisionnement des noms de domaine alternatifs (SAN) des certificats, je pense qu'il est temps de faire une pause et d'examiner ce qui est exactement en jeu. Ce blog a trois intentions fondamentales :
- Démontrer les risques liés à la saisie incorrecte des noms alternatifs des sujets
- Revoir les meilleures pratiques de MS SAN (elles sont toujours d'actualité)
- Recommander une meilleure approche
Pour diverses raisons, il n'est pas rare que les processus de demande de certificat d'un client évoluent au point que le propriétaire de l'application ou du serveur crée une demande de signature de certificat (CSR) dépouillée et la soumette à une autorité de signature pour qu'elle la complète ou la signe. Le propriétaire du site PKI est chargé de "terminer" cette CSR, en ajoutant à la demande le nom d'hôte, les adresses DNS , l'adresse électronique ou l'adresse IP corrects. Sur un site Microsoft CA, cela est possible en activant la fonction “EDITF_ATTRIBUTESUBJECTALTNAME2” sur l'autorité de certification.
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
L'activation de ce drapeau permet d'inclure des informations SAN en tant qu'"attribut de la demande". En d'autres termes, une fois la RSC créée, les attributs de la RSC peuvent être utilisés pour inclure des informations SAN après coup, ce qui rend possible le flux de travail susmentionné. Ce paramètre "fait tout simplement fonctionner".L'effet de ce paramètre est que les demandes peuvent être modifiées en utilisant une variété de méthodes, y compris AD/CS Web Enrollment, CertReq, et d'autres.
Exemple : certreq -submit -attrib "SAN:DNS=someotherserver.csstest.com" someserver.req someserver.cer
Mais quel est l'impact de cette option de configuration ? Si ce paramètre est activé, la configuration de la politique de l'autorité de certification ressemblera à ce qui suit :
(Certutil –getreg policy)
EditFlags REG_DWORD = 35014e (3473742)
EDITF_REQUESTEXTENSIONLIST -- 2
EDITF_DISABLEEXTENSIONLIST -- 4
EDITF_ADDOLDKEYUSAGE -- 8
EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
EDITF_ENABLEAKIKEYID -- 100 (256)
EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
EDITF_AUDITCERTTEMPLATELOAD -- 200000 (2097152)
La présence de ce paramètre dans les indicateurs de politique d'une autorité de certification signifie que cette dernière ne rejettera plus les informations SAN incluses dans les attributs de demande du certificat. En tant que tel, ce paramètre s'applique à l'ensemble de l'autorité de certification et à tous les autres modèles de certificats émis par cette autorité.
Disons que ce paramètre est activé sur l'autorité de certification parce que l'équipe Web en a besoin dans le cadre du provisionnement des certificats SSL . Cela signifie que l'autorité de certification est configurée pour émettre des certificats à la fois pour l'équipe du serveur Web de l'entreprise, dont le sujet doit être inclus dans la demande, et pour les certificats des utilisateurs de l'entreprise, dont le sujet est configuré pour être automatiquement créé à partir d'Active Directory.
Figure 1 : Configuration du modèle d'autorité de certification.
Les demandes d'inscription personnalisée fonctionnent bien pour les certificats Web SSL et les utilisateurs s'inscrivent automatiquement comme prévu à partir du modèle d'utilisateur. Aucun problème, n'est-ce pas ?
Peut-être. Que se passe-t-il si un utilisateur saboteur mécontent décide d'agir de manière malveillante ? L'utilisation de ce paramètre signifie que rien dans cette configuration n'empêche un utilisateur de devenir qui il veut, en faisant peut-être ce qui suit.
Créer un nouveau CSR :
certreq -new UserCert.inf UserCert.req
Certreq est un utilitaire en ligne command largement disponible qui permet de créer une CSR.
Ce processus utilise le même modèle de certificat que celui auquel l'utilisateur est déjà autorisé à accéder.
(Voici le fichier usercert.inf référencé)
NewRequest]
Exportable=FALSE
KeyLength=2048
KeySpec=1
RequestType=cmc
PrivateKeyArchive=FALSE
[RequestAttributes]
CertificateTemplate=CorporateUserCertificate
Soumettre ce CSR à l'AC.
Certreq -submit -config "CA.csstest.com\CSS Test CA 1" UserCert.req UserCert.cer
Il en résulte un certificat signé par l'autorité de certification, dont l'objet contient CN=Alice User. Le SAN automatiquement ajouté ressemblerait à ceci : [email protected].
Et comme le modèle "CorporateUserCertificate" est configuré pour utiliser l'inscription automatique, les certificats qui en résultent sont automatiquement approuvés. Aucune approbation de l'agent de certification n'est requise.
Figure 2 : Certificat d'utilisateur type pour Alice.
Il s'agit d'un processus assez simple.
Mais qu'en est-il si Alice a agi de manière malveillante ? Que se passerait-il si elle reprenait le même dossier de demande et le soumettait à nouveau ?
Soumettre la RSC à l'autorité de certification, maintenant avec une intention malveillante.
Même fichier de requête que ci-dessus, mais en plus de remplir automatiquement le nom alternatif du sujet du certificat à partir d'AD, disons que nous ajoutons le nôtre, sous la forme d'un attribut de requête CSR. Voici comment procéder.
Certreq -submit -config "CA.csstest.com\CSS Test CA 1" -attrib "SAN:[email protected]&[email protected]" UserCert.req UserCert.cer
Aujourd'hui, en raison de la ”EDITF_ATTRIBUTESUBJECTALTNAME2”et le fait que l'indicateur de politique "CorporateUserCertificate" ne nécessite pas d'approbation, Alice a pu ajouter arbitrairement l'UPN de Bob à son propre certificat. Même si le modèle contient cette information provenant d'AD.
Figure 3 : Alice a ajouté l'UPN de Bob à son certificat.
En fait, Alice est maintenant à la fois Bob et Alice. Ou juste Bob, ou juste Eve, ou le directeur financier, ou n'importe qui d'autre. On peut voir comment ce processus pourrait séduire un logiciel malveillant ou un utilisateur malveillant.
Encore une fois, il s'agit de la Certificat d'utilisateur entreprise qui est destiné à l'enrôlement automatique des utilisateurs de l'entreprise. Toute entrée SAN personnalisée n'est censée être utilisée que pour les autres utilisateurs de l'entreprise. Serveur web de l'entreprise certificats, mais parce que le EDITF_ATTRIBUTESUBJECTALTNAME2 s'applique à l'ensemble de l'autorité de certification, tous de cette autorité de certification sont affectés, et tous les modèles et tous les certificats qui en résultent sont menacés par des attaques d'usurpation d'identité.
C'est pourquoi, entre autres, Microsoft recommande ce qui suit :
"Ne pas activer EDITF_ATTRIBUTESUBJECTALTNAME2 sur une AC d'entreprise".
Je suis d'accord avec cette recommandation et je suggère à chacun de lire et de se familiariser avec l'ensemble des recommandations de Microsoft. Meilleures pratiques de Microsoft en matière de sécurité pour l'autorisation des SAN dans les certificats
En plus de ces bonnes pratiques, les entreprises qui utilisent ou envisagent d'utiliser la EDITF_ATTRIBUTESUBJECTALTNAME2 Le drapeau de l'Union européenne fait ce qui suit :
- Ne faites pas cela
- Veillez plutôt à ce que les propriétaires d'applications disposent de directives actualisées en matière de contenu des certificats
- Veiller à ce qu'il existe des procédures établies pour demander des certificats au contenu correct.
- Toutes les informations relatives à l'objet du certificat (y compris le SAN) doivent être incluses dans la demande de certificat originale.
- Tous les certificats comportant des demandes de SAN personnalisé doivent être évalués et approuvés par un responsable des certificats avant d'être signés par l'AC.
Il est essentiel que les entreprises réévaluent la manière dont les propriétaires d'applications demandent des certificats afin d'atténuer les risques associés aux informations SAN personnalisées... même si cela interfère avec un flux de travail de certificat basé sur le principe "faites-le fonctionner".
