¿Qué es el Anclaje de Clave Pública?
Normalmente, el tráfico entre una aplicación cliente y su lado del servidor depende de la Infraestructura de Clave Pública (PKI). Si bien este mecanismo es suficiente para la mayor parte del tráfico de Internet, el Okta Secure Identity Commitment requiere que consideremos a los atacantes avanzados, persistentes y dirigidos, incluso incluyendo a los actores a nivel de estado-nación.
Okta utiliza PKI y TLS como base para toda la comunicación entre servicios, incluido Okta Verify. Sin embargo, en escenarios de ataque avanzados, un certificado público fuera del control de Okta podría verse comprometido y ser aceptado por el sistema operativo de un dispositivo o explícitamente confiado por el usuario de ese dispositivo. En tales casos, un agente de amenazas puede inspeccionar y manipular el tráfico entre Okta Verify y los puntos de conexión del lado del servidor de Okta a través de un ataque de intermediario (AITM), lo que causa una serie de problemas que explicaremos más adelante.
Public Key Pinning es una forma de permitir solo los certificados esperados por la aplicación cliente, bloqueando todos los demás. Esto significa que, incluso en el caso de que una autoridad de certificación pública se vea comprometida (por ejemplo, Digicert), nuestras aplicaciones cliente no aceptarán esos certificados. En cambio, un atacante tendría que haber robado las claves privadas internas de Okta para hacerse pasar por nuestros servidores.
Ejemplo de ataque: WiFi o VPN falsos
Imagina que un usuario est trabajando desde una cafeter a. Otro cliente en la cafeter a tiene una pi a en su mochila. Este dispositivo puede hacerse pasar por la red WiFi de la tienda y tomar el control de las conexiones de forma agresiva, fingiendo una alta intensidad de se al, entre otras t cticas inteligentes.
Cuando un dispositivo se conecta a una red WiFi, recoge la configuración de red, como la configuración de DNS y proxy, lo que le permite enrutar todo el tráfico hacia sí mismo antes de enviarlo al destino adecuado. Con un certificado SSL robado de un tercero (o un perfil aceptado), incluso el tráfico HTTPS se puede descifrar sin levantar una alarma.
Una vez que esto está en su lugar, los flujos como OpenID Connect se vuelven vulnerables al redireccionamiento del tráfico, lo que puede provocar el robo de tokens de acceso o su configuración en otra URL.
En el flujo anterior, ocurre la siguiente secuencia:
- Okta Verify intenta conectarse a la configuración openid-configuration de la organización, que es requerida por la especificación del protocolo.
- El tráfico se redirige a la infraestructura del atacante.
- Los valores devueltos por la infraestructura del atacante cambiarán los parámetros clave:
- Cambie keys_uri al endpoint de claves del atacante. Esto permite al atacante enviar JWTs, que pasarán la verificación a pesar de carecer de claves privadas legítimas.
- Cambie los endpoints como token_endpoint que podrían causar que los flujos de intercambio de tokens definidos por el estándar se dirijan a la infraestructura del atacante (que luego puede ser interceptada).
- En este punto, el atacante ha ampliado significativamente la superficie de ataque, lo que podría llevar a la apropiación de cuentas si se combina con algún tipo de phishing.
Cómo te protege el anclaje
Hay tres objetivos principales al fijar nuestras conexiones TLS: autenticidad, integridad y privacidad.
Autenticidad
Las aplicaciones cliente de Okta se implementan con protección contra alteraciones y claves públicas grabadas. La infraestructura de Okta contiene las claves privadas, por lo que las usamos para confirmar la identidad del servidor usando esas claves grabadas. Esto significa que Okta Verify no puede ser engañado para conectarse a un sitio de phishing u otra infraestructura controlada por el atacante.
Integridad
Aunque la mayor parte de los datos transferidos entre el cliente y el servidor ya están encapsulados en estructuras verificables como los JSON Web Tokens, es posible que los endpoints necesarios para verificar estas estructuras no lo estén (por ejemplo, `/oauth2/v1/keys`). El *key pinning* evita que el cliente acepte un conjunto de claves manipuladas, lo que podría dar lugar a una gran superficie de ataque que incluya errores de configuración y ataques de *phishing*.
Privacidad
Aunque Okta trabaja para minimizar el uso de información de identificación personal (PII), la naturaleza de Okta Verify Device Assurance incluye la identificación exitosa del dispositivo y las señales detalladas asociadas con él para aumentar la seguridad de tu organización. Si terceros leyeran estos datos, podrían recopilar información sobre los usuarios y sus dispositivos para usarla en ataques o recopilación de datos.
Ejemplo de ataque cuando el pinning está activo
Cuando el anclaje está activo, Okta Verify examina la conexión TLS durante el protocolo de enlace TLS antes de enviar o recibir cualquier dato. El cliente entonces abandona la conexión, cerrando inmediatamente cualquier posibilidad de que una infraestructura que no sea de Okta lea o modifique los datos en tránsito.
Esta protección representa un control mitigante para Okta FastPass que no se puede lograr con otros autenticadores resistentes al *phishing* como las llaves de *hardware* / WebAuthN, ya que estos dependen de la implementación (no anclada) de PKI + TLS del navegador para enviar afirmaciones firmadas a través de Internet.
Las desventajas
La principal desventaja del anclaje para Okta es la complejidad operativa. Como siempre, estamos dispuestos a aceptar ese trabajo extra para mantener a nuestros clientes más seguros.
Algunas organizaciones tienen políticas que inspeccionan todo el tráfico dentro de su perímetro de red. Si el tráfico de Okta Verify se incluye en las reglas de inspección, bloqueará sus propias conexiones de red, tal como lo haría si un atacante realizara una inspección o modificación del tráfico.
Por las razones mencionadas anteriormente, no podemos permitir la inspección del tráfico entre Okta Verify y su infraestructura sin exponer a los clientes a los escenarios de ataque mencionados anteriormente. Si necesita inspeccionar el tráfico en su red, puede allow-list Okta’s infrastructure from inspection rules. Las organizaciones que necesitan inspeccionar el tráfico de inicio de sesión entre los navegadores y la infraestructura de Okta pueden usar un custom domain e inspeccionar el tráfico a ese dominio sin afectar a Okta Verify.
Estamos observando este espacio y estaríamos abiertos a explorar alternativas que representen mejoras de seguridad y operativas. Puedes estar seguro de que si eso sucede, la barra de seguridad del reemplazo estará al mismo nivel o por encima del nivel actual.
Okta ha asumido un compromiso de priorizar la seguridad. Nos esforzamos cada día para hacer de Okta Verify el autenticador más seguro del mundo, protegiendo a Okta y a nuestros clientes. El anclaje de claves es una pieza fundamental de la seguridad general de Okta Verify, y continuaremos haciendo todo lo posible para mantenerte seguro.
¿Tiene preguntas sobre esta publicación de blog? Contáctenos en eng_blogs@okta.com.
Explora más Blogs de Ingeniería de Okta para ampliar tus conocimientos.
¿Listo para unirte a nuestro apasionado equipo de ingenieros excepcionales? Visita nuestra página de empleo.
Desbloquee el potencial de la gestión de identidades moderna y sofisticada para su organización. Contact Sales para obtener más información.
