- Andrew Harris, exempleado de Microsoft, afirma que descubrió en 2016 la vulnerabilidad Golden SAML en AD FS y durante años pidió una respuesta, pero la empresa solo mencionó alternativas de largo plazo en vez de corregirla de inmediato
- Esta vulnerabilidad permite, tras el robo de la clave privada de un servidor AD FS, acceder a servicios en la nube como si se fuera un usuario legítimo mediante tokens falsificados; además deja pocos rastros en los logs de auditoría y puede eludir la autenticación multifactor
- La propuesta de Harris de desactivar seamless SSO chocaba con las molestias que esto causaría a clientes del gobierno federal, con el contrato de nube del Pentágono, con la competencia frente a Okta y con preocupaciones sobre la experiencia de usuario
- Tras el ataque de SolarWinds en 2020, hackers rusos aprovecharon esta debilidad para recopilar datos sensibles de organismos como la National Nuclear Security Administration, los NIH y el Treasury Department; después de eso, Microsoft recomendó a los clientes de Microsoft 365 desactivar seamless SSO en AD FS
- Microsoft sostuvo que la protección del cliente es su máxima prioridad y que revisó varias veces el tema de seguridad, pero el testimonio del ex empleado expone un caso de choque entre la cultura de seguridad y las prioridades de negocio
La vulnerabilidad Golden SAML descubierta en AD FS
- Andrew Harris trabajó en Microsoft dentro de Ghostbusters, un grupo secreto que respondía a incidentes de hackeo en clientes sensibles, y en 2016 se enfocó en un problema de AD FS mientras investigaba una intrusión en una gran empresa tecnológica de EE. UU.
- AD FS es un producto que permite que un usuario inicie sesión una sola vez y luego acceda a varios programas de trabajo; lo usan millones de personas
- El riesgo central que identificó Harris era que, en una autenticación basada en SAML, un atacante podía hacerse pasar por un empleado legítimo para entrar a programas basados en la nube
- El atacante primero compromete un servidor on-premises y luego extrae la clave privada del servidor AD FS
- Después puede falsificar tokens para aparentar ser un usuario con altos privilegios
- Como la información de inicio de sesión parece legítima, es difícil detectarlo con logs de auditoría comunes
- Harris consideraba que este problema podía afectar no solo a Microsoft Azure, sino también a organizaciones que usaban otros proveedores de nube como Amazon
La “security boundary” y la decisión de MSRC
- Harris reportó el problema al Microsoft Security Response Center, es decir, MSRC, pero MSRC determinó que no correspondía corregirlo
- MSRC consideró que, como el atacante debía acceder primero al servidor on-premises, ese punto era el límite de seguridad, y que el paso posterior hacia la nube no constituía otro límite de seguridad separado
- Exempleados de MSRC dijeron que en ese momento el centro procesaba muchos reportes de vulnerabilidades con poco personal y que existía una cultura de cerrar casos con “won’t fix”
- También recordaron que la expresión “security boundary” no estaba claramente definida entonces y que Microsoft la usaba con frecuencia como justificación para no hacer correcciones
- En un memorando de 2002, Bill Gates escribió que, entre agregar funciones y resolver problemas de seguridad, debía elegirse la seguridad, pero ex empleados afirman que con el tiempo la influencia de MSRC se debilitó
La solución temporal chocaba con la lógica del negocio
- Harris pensó que una corrección de largo plazo podía tardar y propuso como solución temporal desactivar seamless single sign-on (SSO)
- Esta función de Microsoft permite que el usuario inicie sesión una sola vez y luego acceda tanto a servidores on-premises como a varios servicios en la nube
- Según Harris, el responsable de producto Mark Morowczynski se opuso porque divulgar la vulnerabilidad podía dar pistas a los atacantes y causar grandes inconvenientes a clientes del gobierno federal
- Los empleados federales debían iniciar sesión con smart cards por normativa
- Harris explicó que, si se desactivaba seamless SSO, al acceder a la nube sería necesario un segundo inicio de sesión y en ese proceso ya no podrían usar la smart card obligatoria
- También se mencionaron como razones de oposición el gran contrato de nube del Pentágono y la competencia con Okta
- Microsoft competía con Okta en ese momento y seamless SSO era una de sus ventajas competitivas
- La propuesta de Harris introducía fricción al obligar a los usuarios a autenticarse dos veces y chocaba con la estrategia del producto
- Harris recuerda que Morowczynski dijo que esta no era una decisión técnica sino una decisión de negocio
Advertencias de empresas externas de seguridad
- CyberArk publicó en 2017 una entrada de blog y una prueba de concepto donde llamó a esta técnica Golden SAML
- Más tarde, Brad Smith escribió en respuestas al Senate Intelligence Committee que Microsoft supo de este problema cuando CyberArk lo hizo público en 2017
- Lavi Lazarovitz, de CyberArk, dijo que antes de la publicación compartió el problema en un chat privado de WhatsApp con investigadores de seguridad de varias empresas, incluidos investigadores de Microsoft
- Harris afirma que, después de la publicación de CyberArk, consideró que el problema se había vuelto más urgente y volvió a plantearlo al grupo de producto y a MSRC, pero MSRC mantuvo su postura previa
- En 2019, investigadores de Mandiant demostraron en una conferencia en Alemania cómo comprometer AD FS para acceder a cuentas y aplicaciones en la nube, y también publicaron herramientas
- Mandiant afirmó que notificó a Microsoft antes de la presentación
- Fue el segundo caso en unos 16 meses en que una empresa externa alertó a Microsoft sobre el problema de SAML
La advertencia a clientes de Harris y el caso del NYPD
- En 2019, Harris publicó en LinkedIn una advertencia indirecta diciendo, en esencia, que quien conociera a alguien que no entendiera la relación de autenticación de AD FS podía contactarlo
- Intentó advertir directamente a clientes con los que ya tenía relación, y uno de ellos fue el New York Police Department
- Harris explicó la debilidad de AD FS a Matthew Fraser, responsable de TI del NYPD, y recomendó desactivar seamless SSO
- Fraser confirmó esa reunión y dijo que la debilidad de SAML fue identificada como un área que requería protección y aislamiento
- Harris dejó Microsoft en agosto de 2020 para irse a CrowdStrike y afirma que volvió a plantear la debilidad de SAML en su entrevista de salida
Elusión de autenticación multifactor y el ataque de SolarWinds
- Harris dice que en 2018, conversando con un colega, entendió que un atacante con tokens falsificados también podía eludir la autenticación multifactor
- El problema era que, aunque existieran pasos adicionales de seguridad, con un token falsificado el atacante podía saltárselos todos
- A fines de 2020 se hizo público el ataque de SolarWinds, y el gobierno de EE. UU. dijo que participaron hackers respaldados por el Estado ruso
- Los atacantes insertaron malware en una actualización de software de SolarWinds para obtener acceso trasero a redes y luego aprovecharon vulnerabilidades posteriores a la intrusión como Golden SAML para robar datos de la nube y correos electrónicos
- Los atacantes usaron la debilidad señalada por Harris para recopilar datos sensibles de varias agencias
- National Nuclear Security Administration
- National Institutes of Health
- varias cuentas de correo del Treasury Department
- Brandon Wales, de CISA en ese momento, dijo que casi un tercio de las víctimas ni siquiera usaba el software de SolarWinds
- Microsoft también fue comprometida y, justo después del ataque, recomendó a los clientes de Microsoft 365 desactivar seamless SSO en AD FS y productos similares
La postura pública de Microsoft y las medidas posteriores
- En 2021, el presidente de Microsoft, Brad Smith, dijo ante el Congreso que no hubo vulnerabilidades en productos o servicios de Microsoft explotadas en el ataque de SolarWinds
- Smith explicó que Golden SAML se usó en el 15% de los 60 casos que Microsoft identificó, aunque reconoció que no fueron esos los únicos casos en los que se observaron o extrajeron datos
- Smith afirmó que, si las organizaciones hubieran tomado varias medidas, como comprar productos antivirus como Microsoft Defender y proteger dispositivos con Intune, el daño habría sido mínimo
- Después de SolarWinds, Microsoft adoptó medidas para mitigar el riesgo de SAML, y las funciones para detectar con eficiencia las secuelas del hackeo quedaron incluidas en Sentinel, un producto adicional de pago
- En un blog, Microsoft describió esa falta de detección como un “blind spot”
La respuesta de Microsoft y la polémica sobre su cultura de seguridad
- Microsoft no permitió entrevistas con altos ejecutivos como Brad Smith, pero tampoco negó los hallazgos de la investigación de ProPublica
- En una respuesta por escrito, la empresa dijo que la protección del cliente siempre es la máxima prioridad y que los equipos de respuesta de seguridad tratan todos los temas con seriedad, con evaluaciones manuales y revisiones de socios de ingeniería y seguridad
- Microsoft explicó que, al evaluar amenazas potenciales, considera la posibilidad de interrupciones para el cliente, la probabilidad de explotación y las mitigaciones disponibles
- Un incidente de 2023, en el que hackers vinculados al gobierno chino explotaron una falla de seguridad de Microsoft para acceder a correos de altos funcionarios de EE. UU., también fue objeto de investigación por parte del House Homeland Security Committee
- Al investigar ese caso, el Cyber Safety Review Board concluyó que la cultura de seguridad de Microsoft era inadecuada y necesitaba una reforma total
- Tras el informe presentado al directorio, Satya Nadella dijo a los empleados que, si la seguridad y otras prioridades entraban en conflicto, debían elegir la seguridad
Competencia en el negocio de la nube y consecuencias
- Satya Nadella, quien asumió como CEO en 2014, apostó el futuro de Microsoft al negocio de nube Azure, que en ese momento iba muy detrás de Amazon
- Microsoft propuso a empresas y gobiernos una estrategia de nube híbrida: mantener parte de los servidores on-premises mientras se trasladaba la mayor parte del cómputo a la nube
- La seguridad era un argumento central de venta de la nube, y se presentaba como ventaja el hecho de que personal de seguridad especializado se encargara de parches y actualizaciones
- Harris y otros exempleados dicen que el gran contrato de nube del Pentágono y la presión por hacer crecer Azure influyeron en las decisiones de los equipos de producto
- Microsoft finalmente obtuvo, junto con Amazon, Google y Oracle, una parte del negocio multianual y multimillonario de nube del Department of Defense
- Desde que se hizo público SolarWinds, la acción de Microsoft subió 106%, impulsada principalmente por el éxito de Azure y de productos de IA como ChatGPT
- El producto de reemplazo a largo plazo para AD FS que, según Harris, Morowczynski le mencionó en 2017 empezó a ofrecerse en 2022
1 comentarios
Opiniones de Hacker News
La solución es aplicar zero trust completo dentro de la organización y no confiar en la red. Incluso la red interna debe tratarse como si fuera externa, es decir, como un entorno hostil.
Google fue uno de los primeros casos en adoptar ampliamente zero trust con BeyondCorp, y creo que desde Aurora no ha habido compromisos dentro de la organización interna de Google.
Se necesitan endpoints totalmente administrados, hardening fuerte de endpoints, un inventario completo de todos los recursos de la organización, certificados por dispositivo y un motor de listas de control de acceso que determine el acceso de cada usuario a los recursos.
También se pueden detectar anomalías con heurísticas como el horario laboral, y todas las apps internas de Google están expuestas a Internet y redirigen a un portal SSO, pero en realidad no se puede entrar. Muchos de estos problemas de seguridad ya están resueltos; solo hay que implementarlos.
La mayoría de las organizaciones grandes han acumulado tecnologías internas y externas durante décadas, los sistemas antiguos están prácticamente abandonados, y hay mucha heterogeneidad por fusiones y adquisiciones y por la libertad de cada departamento para elegir herramientas.
Pasar a zero trust requiere una migración a gran escala, “capacitación” para convencer a responsables de IT obstinados y una transición hacia el modelo centralizado al estilo Google.
Aunque los dos primeros puntos consigan presupuesto, el tercero puede ser muy caro. Una de las razones por las que Google desecha tantas cosas es que, en un modelo centralizado, hay que migrar constantemente y hacer upgrades que rompen compatibilidad.
En una startup, me gustaría ofrecer a los clientes esta uniformidad basada en buenas prácticas, pero algún día un cliente podría exigir: “déjennos desactivar zero trust y usar una lista de IP permitidas”. Uno puede terminar preguntándose si aceptarlo para cerrar un contrato grande, y tampoco se puede cancelar una adquisición solo porque se está comprando una empresa que no tiene zero trust.
Más bien, para la mayoría son desafíos extremadamente difíciles, y suena como una respuesta del tipo “solo dibuja el resto del búho”. Por ejemplo, imaginen que Shaw Industries, el mayor fabricante de alfombras y pisos de Estados Unidos, con 22.000 empleados, intenta hacer esto.
Si uno adopta una actitud de estar absolutamente “seguro”, deja de buscar compromisos con dedicación y termina pasando por alto el compromiso que algún día ocurrirá.
Zero trust es una filosofía, y una bastante buena, pero no es una solución por sí misma. Es mejor pensarlo como una filosofía y un conjunto de buenas prácticas que como una solución absoluta.
No creo que esta arquitectura sea adecuada para todas las empresas. La mayoría de las empresas tecnológicas que no son de software sufren daños por ingeniería social simple, correos fraudulentos y problemas de entregar credenciales a terceros, y el espionaje económico también es una gran amenaza.
Google puede tener otras preocupaciones de seguridad, como denunciantes internos o grupos activistas que chocan con la visión de la dirección, y esta estructura podría encajar para esos problemas. Pero eso no significa que todos tengan los mismos vectores de amenaza.
Los problemas de seguridad se pueden resolver, pero la infraestructura necesaria no es trivial, y muchos stacks de software para ingeniería ni siquiera admiten autenticación de terceros.
Los desarrolladores suelen rechazar los “endpoints administrados”, incluso si no son desarrolladores de software. A Google le funciona, pero es más bien un caso especial; en la práctica, una segmentación de red razonable puede ser mucho más efectiva.
La desalineación de incentivos entre seguridad y ganancias es difícil de corregir sin un enorme cambio cultural, especialmente en empresas que cotizan en bolsa. Tampoco sé qué podría detonar ese cambio.
He tenido responsabilidades de ciberseguridad en varios roles, pero la razón por la que no me dediqué a eso de tiempo completo es lo que vi directamente en la industria: un enfoque abrumador en compliance por encima de las buenas prácticas reales de seguridad, y además esos estándares son insuficientes o se aplican débilmente.
Hace falta un cambio cultural, pero creo que debe venir del lado de los clientes. Aunque para los consumidores sea difícil, si los clientes empresariales evaluaran correctamente la seguridad, exigieran garantías vinculantes y tomaran decisiones de compra en función de eso, la industria reaccionaría.
Claro que Microsoft está tan profundamente arraigada en el mercado de escritorio que sería difícil que este enfoque fuera plenamente efectivo.
Dicho eso, también es una reacción directa a la falta de un cambio cultural que se preocupe por la seguridad. Los equipos de seguridad suelen tener solo dos opciones:
afirmar “la seguridad es importante, así que construyamos productos seguros” y que se rían de ellos, o usar el compliance exigido por auditores para empujar a la organización, aunque sea un poco, hacia la seguridad.
Las personas también a veces eligen el dinero por encima de la seguridad. Los gobiernos también parecen haber elegido una fuerza laboral más productiva en lugar de costos más altos y menor productividad.
Cuando una empresa le vende al gobierno, el dinero que puede ganar y el efecto de relaciones públicas son tan grandes que aparece un incentivo para ocultar verdades incómodas. Se me viene a la mente cierto fabricante de aviones.
Puede ir desde ocultar cosas un poco vergonzosas hasta fraudes enormes, sistemáticos y deliberados; con el tiempo puede extenderse a todo el espectro.
Si un líder dice “prioricen la seguridad/calidad”, pero en la práctica no lo recompensa, la mesa ya está servida.
Si todos los días se recompensa o castiga según metas de dinero y, cuando de vez en cuando los atrapan, solo castigan a uno o dos subordinados, entonces lo que la empresa toma en serio es el dinero, no la seguridad/calidad.
Para alcanzar un objetivo hay que dar incentivos. Ventas es muy estresante y te pueden despedir fácilmente, pero si tienes éxito puedes ganar mucho dinero. En seguridad, si tienes éxito solo no te despiden, y si fallas te despiden.
El resultado de un buen trabajo de seguridad es “no pasó nada”: no hay brechas, ni desastres, ni escándalos; por eso también es difícil de medir. El problema es cómo cuantificar una ausencia.
Al final, ventas tiene muchas zanahorias y el mismo garrote que todos, pero seguridad no tiene zanahorias, solo garrotes, y ese garrote podría ser un bate con clavos. La respuesta está en la cultura, y creo que cambiar la cultura es lo más difícil.
No deberíamos esperar que ventas se preocupe por la seguridad; el foco de ventas debe ser el crecimiento. El problema es no darle al otro lado la autoridad y la jurisdicción para decir “no” cuando una corrección de seguridad debe entrar antes que una nueva funcionalidad.
Si un gerente de proyecto que recibe incentivos por crecimiento decide las prioridades, obviamente va a elegir crecimiento por encima de seguridad.
No es que el equipo de seguridad no conozca los problemas, sino que las correcciones no se vuelven prioridad y la cultura y los procesos no logran equilibrar ambos lados.
Del lado del gobierno también hay incentivos considerables para que el contrato se cierre, al menos para la carrera de quienes toman decisiones individualmente.
Ambas partes quieren que la transacción se concrete, y tienen motivos para ocultar defectos mientras el usuario final no se dé cuenta antes de jubilarse.
Creo que el modelo de prioridad de seguridad al estilo Microsoft, cuando Satya Nadella dijo “si hay que elegir entre seguridad y otra prioridad, la respuesta es clara: hagan seguridad”, es así:
meter anuncios en cada rincón de Windows, instalar una grabadora que registre todo lo que hace el usuario, mandarles un correo a los empleados diciendo “hagan seguridad”, y misión cumplida.
Eso me dejó muy claro que gran parte de la capacitación, los correos y los procesos existen para tener una negación plausible.
En Microsoft sí hay personas que se preocupan de verdad por la seguridad. Las he conocido en persona. Pero, en general, estos mecanismos permiten que Satya diga en un tribunal o ante el Congreso: “les dijimos que hicieran mejor la seguridad; fue culpa del equipo de producto o de contribuidores individuales, no de las políticas e incentivos de Microsoft”.
La redacción de un correo no tiene ningún peso. En el momento en que un líder decide intercambiar seguridad por otra cosa, la señal que necesitan los empleados ya fue enviada.
Me vienen a la mente la polémica de que Canonical registraba las búsquedas con la tecla Super y el hecho de que Ubuntu incluía anuncios de Amazon por defecto.
A quien le gustan las computadoras puede instalar Arch, Gentoo o NixOS Minimal y auditar paquetes, pero es poco realista esperar que la mayoría de las personas que no son ingenieras de software hagan eso.
No solo Microsoft, todas las empresas siempre tienen el incentivo de poner tantos anuncios como sea posible y recolectar la mayor cantidad de datos posible. No estoy seguro de apoyar la regulación, pero tampoco conozco otra solución clara.
Como siempre, el cliché de los ejecutivos de “seguridad primero” no importa.
Si recompensas y asciendes a la gente por funcionalidades, pero no recompensas una cultura de seguridad, las personas y las capas gerenciales no son tontas y optimizarán para eso.
No sé cómo habría que diseñar estos incentivos para resolverlo, pero esto seguirá yendo por el mismo camino.
Probablemente no pase nada hasta que los responsables sean castigados y alguien pague el precio.
Normalmente una funcionalidad entra al producto cuando marketing puede mostrar que generará más crecimiento del negocio que su costo. Se podría aplicar la misma idea.
Algo como: “Esta vulnerabilidad afecta al X% de los clientes, el Y% se irá y, junto con el daño reputacional, perderemos una gran suma. En cambio, podemos arreglarla en Z días por una cantidad pequeña. ¿Qué decidimos?”.
Creo que en esta historia se está pasando por alto una pista bastante importante. Desactivar el SSO sin interrupciones tiene un impacto amplio y muy específico en las tarjetas inteligentes físicas que usan los empleados gubernamentales para iniciar sesión en sus dispositivos.
Estas tarjetas, requeridas por normas federales, generan una contraseña aleatoria en cada inicio de sesión, pero debido a la configuración de la tecnología subyacente, quitar el SSO sin interrupciones impide que los usuarios accedan a la nube con su tarjeta inteligente.
El gobierno de EE. UU. es uno de los clientes más grandes de Microsoft, y tanto su base de usuarios como la escala de Active Directory son enormes. Por mi experiencia trabajando en este ámbito, la gestión de usuarios y roles es casi una pesadilla por credenciales robadas, cuentas bloqueadas, etc., y es un blanco constante.
El gobierno de EE. UU. ha intentado mover a todos a la autenticación con tarjetas inteligentes para reducir estos problemas; eliminar las contraseñas y pasar a todos a autenticación de dos factores reduce mucho la superficie de ataque.
Pero, en la práctica, esta persona estaba diciendo que, como parte de la solución, se les dijera a los clientes que simplemente lo apagaran.
No niego el riesgo de la falla original de SAML, pero creo que Harris juzgó de forma injusta el resto de la respuesta de Microsoft. Era como pedirles que desactivaran la autenticación de dos factores en toda la institución.
La mitigación de corto plazo perjudica seriamente la seguridad y puede exponer más a los clientes al mismo tipo de ataques que se buscaba evitar. Esta historia se presentó como otro caso de una empresa a la que no le importó la seguridad, pero parece más bien la reacción de un “denunciante interno” con una visión estrecha de la postura de seguridad general del cliente.
La mayoría de los administradores de sistemas de seguridad de la información de agencias gubernamentales también habrían dicho, por la misma razón, que no era una opción viable.
Al final, ese es también el argumento del artículo. Siguieron vendiéndolo aun sabiendo que no había forma de administrarlo de manera segura.
No es que quiera defender a Microsoft, pero no sé si podría señalar una empresa que priorice claramente la seguridad por encima de las ganancias.
Bill Gates dijo en 2002 que “si hay que elegir entre agregar funciones y resolver problemas de seguridad, hay que elegir la seguridad”, y Satya Nadella dijo algo en la misma línea en 2024: “hagan seguridad”.
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
https://www.theverge.com/24148033/satya-nadella-microsoft-se...
De hecho, hay funciones que yo usaría y por las que pagaría más, pero no las desarrollan porque no serían protocolos completamente seguros o porque tendrían que integrarse con clientes de calendario comunes.
Si los clientes que pagan no valoran la seguridad, entonces, salvo que haya regulación o requisitos legales, el proveedor tampoco la valorará.
Pero considerando que grandes organizaciones y gobiernos son clientes de Microsoft, este caso resulta extraño. Puede haber habido arrogancia del tipo “a nosotros no nos va a pasar” o “nadie se va a enterar”.
Ahora probablemente estén viendo que el daño reputacional también puede perjudicar las ganancias futuras.
Es como imaginar que una constructora hizo un gran puente. Un inspector interno de seguridad advirtió repetidamente a sus superiores sobre una falla estructural que podía llevar al colapso y, con el tiempo, también hubo dos advertencias públicas externas, pero la empresa minimizó su importancia.
Al final el puente se derrumba, y se descubre que la empresa no hizo nada porque no quería perder contratos para vender más puentes defectuosos.
El público estaría, con razón, indignado, y habría consecuencias legales para los involucrados. Pero no entiendo qué es diferente en nuestra industria para que empresas y gerentes puedan salirse con la suya con una mala fe así.
Parece que, si no se pierden suficientes vidas, en general a la gente no le importa demasiado.
https://www.nrk.no/innlandet/statens-vegvesen-legg-fram-rapp...
El software no amenaza vidas de forma inmediata. Por eso, salvo en salud y aeroespacial, casi funciona como el Salvaje Oeste.
Que datos personales se filtren en Internet es terrible, pero comparado con que se desprenda la puerta de un avión, al menos todavía hay tiempo para actuar.
El gobierno podría empezar a cambiar esto exigiendo la firma y aprobación de una persona con licencia en los contratos de productos de software vendidos al gobierno.
El teleférico de Mottarone sí fue claramente similar. Operó durante años con el dispositivo de seguridad desactivado y, cuando se rompió el cable de tracción, la cabina se precipitó hacia abajo y murieron todos los pasajeros.
Golden SAML es más un tipo de ataque que una vulnerabilidad; como vuelve a decir el artículo de CyberArk citado en el texto, solo es posible si primero se toma control total de la máquina.
Si no estoy entendiendo algo mal, no veo una falla específica. Dicho en los términos en que se burlan de Microsoft en el artículo, no se trata de cruzar un límite de seguridad.
En SSO siempre existen estos compromisos. Si la infraestructura de SSO se ve comprometida, todo lo que la usa corre el riesgo de quedar comprometido.
Esta parte se pasa por alto un poco, pero me parece que el “hackeo” real se acerca más a eso.
Mientras se use SSO, tampoco es fácil mitigarlo. Una forma sería hacer que el servicio de destino exija un segundo factor además de un token SAML válido, pero entonces cada usuario tendría que mantener actualizado ese segundo factor para cada servicio de destino.
Eso rápidamente se vuelve inmanejable y, en la práctica, casi no hay aplicaciones SaaS o autohospedadas que soporten SSO y segundo factor al mismo tiempo.
Es parecido a crear un ataque llamado “GOLDEN ADMIN”: si tienes credenciales de administrador, puedes iniciar sesión como administrador y hacer lo que quieras.
Entiendo que es malo que un atacante pueda autenticarse en cualquier parte sin dejar registros, pero aun así estoy de acuerdo con el comentario original.
Creo que hay formas posibles de hacerlo.
No es un problema exclusivo de Microsoft. Como ingeniero de seguridad, si quieres conservar la cordura y tener resultados en esta carrera, tienes que trabajar en un lugar con capacidad técnica y fuertes incentivos regulatorios y presupuesto, o en uno donde culturalmente se preocupen por la seguridad debido a un modelo de amenazas fuertemente ligado a las ganancias.
Los principales ejemplos que cumplen mis criterios son startups pre-IPO que necesitan pasar SOC2 y similares para salir a bolsa, la industria cripto con modelos de amenazas e incentivos de ganancias claros como el robo de claves, y empresas tecnológicas públicas que proveen mucha infraestructura crítica.
Dicho eso, hay lugares como Microsoft que, por ser demasiado grandes para caer, terminan inclinándose hacia ese lado; y también lugares como Google/Project Zero, Verizon/Paranoids y Cloudflare, donde los equipos internos de seguridad parecen fuertes.
Los bancos tienen dinero, una cultura de aversión al riesgo y regulación fuerte, así que podrían ser una opción, pero en salud, aunque la regulación sea fuerte, nunca querría trabajar por el volumen de ataques y la indiferencia.
Por eso, salvo que quieras entrar al equipo DART para ver muchos actores de amenazas reales y respuestas a incidentes variadas, o hacer seguridad de sistemas operativos a muy bajo nivel, no recomendaría ir a Microsoft como ingeniero de seguridad.
No conozco bien el trabajo de los ingenieros de seguridad de Apple. Esta también es la razón por la que la permanencia promedio en una carrera de seguridad ronda más o menos los 10 años: la cordura se desgasta y la paga suele ser lo bastante buena como para que, a los 30 o 40, puedas hacer otra cosa con el dinero ahorrado.