Mitigando el riesgo de deshabilitar EPA en ADFS

2

Actualmente estoy investigando la implementación de un servidor de Servicios de federación de Active Directory (ADFS) para proporcionar el inicio de sesión único para diversos servicios. De forma predeterminada, ADFS habilita la compatibilidad con Protección ampliada para la autenticación ( EPA) para protegerse contra los ataques de intermediarios contra la autenticación de Windows integrada (IWA). Todo esto está muy bien, pero actualmente ningún navegador web es compatible con EPA con la excepción de Internet Explorer (lo cual es bastante lamentable dado el tiempo que EPA ha estado disponible para protegerse contra esta vulnerabilidad). Estandarizar en Internet Explorer no es una opción viable para nosotros y, por lo tanto, esto deja la inhabilitación de EPA como la única otra opción si queremos habilitar la autenticación transparente para los servicios admitidos desde los clientes de la red interna. Sin embargo, tengo curiosidad por otros métodos de endurecimiento que podrían usarse para ayudar a mitigar el riesgo de deshabilitar el EPA, con el entendimiento de que ninguno de ellos eliminará de manera absoluta la vulnerabilidad subyacente que el EPA trata de abordar (al menos, ninguno que yo sepa). consciente de).

Mi idea era que, aparte de la lista blanca que requieren todos los navegadores principales en la configuración predeterminada para las URL en las que se permite el uso de IWA, era realizar algún tipo de anclaje de certificado en el certificado (s) utilizado en el servidor SSO (s). En este sentido, un atacante teórico tendría que suplantar a una de las URL incluidas en la lista blanca y también tener acceso a la clave privada para uno de los certificados contra los que se encuentra el navegador para la URL. Esto, por supuesto, no evita totalmente el ataque que la EPA busca prevenir como lo entiendo, pero presumiblemente haría que realizar el MitM para llevar a cabo el ataque sea mucho más difícil, dado que lo necesitaría:

  • Conocimiento de una de las URL incluidas en la lista blanca que debe ser MitM'd ( no demasiado difícil )
  • Acceso a la clave privada de uno de los certificados anclados ( supone muy difícil )
  • Capacidad para romper la criptografía del certificado existente ( actualmente imposible )

Así que mis preguntas son:

  • ¿El pensamiento detrás de lo anterior generalmente suena o hay brechas importantes?
  • Si no, ¿cuáles son los otros pasos alternativos que podrían tomarse para ayudar a reducir el riesgo de deshabilitar el EPA?
pregunta ralish 24.03.2015 - 07:44
fuente

0 respuestas

Lea otras preguntas en las etiquetas