Pocas empresas pueden permitirse el lujo de contar con personal profesional de PKI a tiempo completo. Más típicas son las empresas que asignan este deber como un adjunto a alguien con una función principal separada, como la ingeniería de AD. Como tal, me parece que muchos profesionales de PKI no tienen conocimientos de PKI como un conjunto de habilidades primario. Es fácil entender cómo una mentalidad de "simplemente haz que funcione" puede acabar colándose en los procesos operativos de una PKI. Con demasiada frecuencia, la eficacia operativa se impone fácilmente a los riesgos de seguridad percibidos.
Pero cuando un enfoque de "simplemente haz que funcione" se abre camino en el aprovisionamiento de nombres alternativos de sujetos de certificados (SAN), creo que es hora de hacer una pausa y revisar qué es exactamente lo que está en juego. Este blog tiene tres intenciones básicas:
- Demostrar los riesgos asociados a la introducción incorrecta de los Nombres Alternativos de las Materias.
- Revise las mejores prácticas de MS SAN (siguen siendo relevantes)
- Recomendar un enfoque mejor
Por diversas razones, no es infrecuente que los flujos de trabajo de solicitud de certificados de un cliente evolucionen hasta un punto en el que el propietario de la aplicación o el servidor cree una solicitud de firma de certificado (CSR) básica y la envíe a una autoridad de firma para que la complete o la firme. El propietario de la PKI es responsable de "finalizar" esta CSR, añadiendo el nombre de host correcto, las direcciones DNS , la dirección de correo electrónico o la dirección IP a la solicitud. En Microsoft CA, esto es posible habilitando la función “EDITF_ATTRIBUTESUBJECTALTNAME2” en la CA.
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
La activación de este indicador permite incluir información SAN como "atributo de solicitud". Es decir, una vez creado el CSR, los atributos del CSR pueden utilizarse para incluir información SAN a posteriori, lo que hace posible el flujo de trabajo mencionado. Esta configuración "simplemente hace que funcione".El efecto de esta configuración es que las solicitudes pueden modificarse utilizando diversos métodos, como AD/CS Web Enrollment, CertReq y otros.
Por ejemplo: certreq -submit -attrib "SAN:DNS=someotherserver.csstest.com" someserver.req someserver.cer
Pero, ¿cuál es el impacto de esta opción de configuración? Si esta opción está activada, la configuración de la política de la CA tendrá ahora un aspecto similar al siguiente:
(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)
Ver esto en los indicadores de política de una CA significa que la CA ya no rechazará la información SAN incluida en los atributos de solicitud del certificado. Como tal, esta configuración se aplica a toda la CA y a todas las demás plantillas de certificados emitidas por esa autoridad de certificación.
Digamos que esta configuración está habilitada en la CA porque el "Equipo Web" lo necesita como parte del aprovisionamiento de certificados de SSL . Esto significa que la CA está configurada para emitir certificados tanto para el equipo del servidor web corporativo, cuyo asunto debe incluirse en la solicitud, como para los certificados de usuario corpor ativo, cuyo asunto está configurado para crearse automáticamente a partir de Active Directory.
Figura 1: Configuración de la plantilla CA.
Las solicitudes de inscripción personalizadas funcionan correctamente para los certificados Web SSL y los usuarios se inscriben automáticamente como se espera de la plantilla de usuario. No hay problemas, ¿verdad?
Tal vez. ¿Y si un usuario saboteador descontento decide actuar maliciosamente? Usar esta configuración de bandera significa que no hay nada en esta configuración que impida a un usuario convertirse en quien quiera ser, haciendo quizás lo siguiente.
Crear un nuevo CSR:
certreq -new UserCert.inf UserCert.req
Certreq es una utilidad de línea command ampliamente disponible que creará una CSR.
Este proceso utiliza la misma plantilla de certificado a la que el usuario ya tiene permiso.
(Aquí está el usercert.inf de referencia)
NewRequest]
Exportable=FALSE
KeyLength=2048
KeySpec=1
RequestType=cmc
PrivateKeyArchive=FALSE
[RequestAttributes]
CertificateTemplate=CorporateUserCertificate
Envíe este CSR a la CA.
Certreq -submit -config "CA.csstest.com\CSS Test CA 1" UserCert.req UserCert.cer
Esto produce un certificado firmado por CA, cuyo asunto contiene CN=Usuario Alice. El SAN añadido automáticamente tendría el siguiente aspecto: [email protected].
Y puesto que la plantilla "CorporateUserCertificate" está configurada para utilizar la autoinscripción, los certificados resultantes se aprueban automáticamente. No es necesaria la aprobación del responsable de certificados.
Figura 2: Certificado de usuario típico para Alice.
Se trata de un proceso bastante sencillo.
Pero, ¿y si Alice actuó maliciosamente? ¿Y si cogiera el mismo expediente de solicitud y lo volviera a enviar?
Envíe la CSR a la CA, ahora con malas intenciones.
El mismo archivo de solicitud que el anterior, pero además de rellenar automáticamente el nombre alternativo del asunto del certificado desde AD, digamos que añadimos el nuestro, en forma de atributo de solicitud CSR. He aquí cómo hacerlo.
Certreq -submit -config "CA.csstest.com\CSS Test CA 1" -attrib "SAN:[email protected]&[email protected]" UserCert.req UserCert.cer
Ahora, debido a la CA ”EDITF_ATTRIBUTESUBJECTALTNAME2”y el hecho de que el indicador "CorporateUserCertificate" plantilla no requiere aprobación, Alice ha sido capaz de añadir arbitrariamente UPN de Bob a su propio certificado. A pesar de que la plantilla tiene esta información procedente de AD.
Figura 3: Alice ha añadido el UPN de Bob a su cert.
De hecho, Alice es ahora tanto Bob como Alice. O sólo Bob, o sólo Eve, o el Director Financiero, o quien sea. Uno puede ver cómo este proceso podría atraer al malware, o a un usuario malicioso.
De nuevo, este es el Certificado de usuario corporativo que está pensada para la inscripción automática de usuarios corporativos. Cualquier entrada SAN personalizada se supone que sólo se utiliza en el otro Servidor web corporativo certificados, sino porque el EDITF_ATTRIBUTESUBJECTALTNAME2 se aplica a toda la CA, todos las plantillas de esa CA se ven afectadas, y todas las plantillas y todos los certificados resultantes corren el riesgo de sufrir ataques de suplantación de identidad.
Por eso, entre otras cosas, Microsoft recomienda lo siguiente:
"No habilite EDITF_ATTRIBUTESUBJECTALTNAME2 en una CA de empresa".
Estoy de acuerdo con esta recomendación, y sugiero además que todo el mundo lea y se familiarice con el conjunto completo de recomendaciones de Microsoft. Mejores prácticas de seguridad de Microsoft para permitir SAN en certificados
Me gustaría ofrecer que, además de estas mejores prácticas, las empresas que utilicen o consideren la posibilidad de utilizar el EDITF_ATTRIBUTESUBJECTALTNAME2 bandera haga lo siguiente:
- No lo hagas.
- En su lugar, asegúrese de que existen directrices actualizadas sobre el contenido de los certificados para los propietarios de aplicaciones
- Garantizar que existen procedimientos establecidos para solicitar certificados con el contenido correcto.
- Toda la información sobre el sujeto del certificado (incluido el SAN) debe incluirse en la solicitud de certificado original
- Todos los certificados con solicitudes SAN personalizadas deben ser evaluados y aprobados por un responsable de certificados antes de ser firmados por la CA.
Es fundamental que las empresas reevalúen la forma en que los propietarios de las aplicaciones solicitan los certificados para mitigar los riesgos asociados a la información SAN personalizada... incluso si esto interfiere con un flujo de trabajo de certificados basado en "hacer que funcione".
