- A través de una vulnerabilidad de seguridad de SharePoint, hackers extranjeros infiltraron una instalación de armas nucleares de Estados Unidos
- Esta intrusión muestra un potencial de impacto en entornos operativos más allá de un simple problema de TI, incluyendo sistemas de aseguramiento de calidad y SCADA
- La descoordinación entre la seguridad de TI y OT se reveló como un problema clave en todo el ámbito federal
- El gobierno federal ha avanzado en una estrategia de confianza cero para redes IT tradicionales, pero la aplicación en entornos OT se está retrasando
- El Departamento de Defensa impulsa el desarrollo de controles de confianza cero para OT, por lo que se prevé la elaboración de una estrategia de seguridad integrada que abarque tanto TI como OT
Vulnerabilidad de SharePoint y la intrusión en una instalación de armas nucleares de EE. UU.
- Ocurrió un incidente en el que hackers extranjeros accedieron a instalaciones de armas nucleares de Estados Unidos aprovechando una falla en SharePoint
- El experto Sovada enfatizó que este acceso podría afectar sistemas como los de control de distribución que administran el aseguramiento de calidad y también los sistemas SCADA responsables del control de energía y del medio ambiente
- Esto sugiere que no se trata de una simple vulnerabilidad de TI
Brecha entre la convergencia IT/OT y la seguridad de confianza cero
- El caso de Kansas City puso en evidencia un problema estructural: la discrepancia entre las prácticas de seguridad de IT y OT en todo el gobierno federal
- El gobierno federal está desarrollando una hoja de ruta de confianza cero para redes IT tradicionales
- Sin embargo, en el entorno operativo (OT), la implementación de un marco de seguridad similar avanza con relativo retraso
- En tiempos recientes, también ha avanzado el desarrollo de un marco de seguridad para tecnología operativa (OT)
Intentos de integrar la seguridad de TI y OT
- Sovada mencionó que existen herramientas de gestión de TI (playbooks) para confianza cero, segmentación de red, autenticación y gestión de identidad
- El Departamento de Defensa de EE. UU. está desarrollando un playbook para aplicar la confianza cero en entornos OT
- En última instancia, busca integrar las directrices de administración de confianza cero de TI y OT, con el objetivo de lograr una seguridad integral en todos los tipos de red
1 comentarios
Comentario de Hacker News
Cuando me llega una propuesta para cambiar de trabajo, una de las primeras cosas que hago es revisar el registro MX del dominio de correo de la empresa; es una forma de saber en un segundo si la compañía es basada en Microsoft sin que la otra parte se dé cuenta. Si es Microsoft, para mí es una señal roja importante. No quiero decir que esto siempre sea válido —solo hablo desde mi experiencia personal—, pero en más de 20 años vi que la mayoría de compañías con un stack de TI basado en MSFT suelen tener una cultura de ingeniería que no me gusta. No se puede decir que una empresa que usa solo Outlook, SharePoint o Teams sea automáticamente una mala empresa, pero sigue siendo un indicador de que puede tener una cultura técnica más precaria que muchas preguntas de entrevista. Puede sonar grosero para ingenieros centrados en Microsoft, y de verdad lo siento. El problema está en mí.
Si te soy franco, esta forma de pensar puede hacerte sonar como un empleado “con problema”. Las compañías que no usan Microsoft suelen usar Google, y por mi experiencia eso suele ser todavía peor. De hecho, en mi experiencia trabajando con quienes odian a Microsoft, este tipo de personas siempre terminaba frenando al equipo por no usar las herramientas elegidas por la empresa. (Además, no entiendo por qué bajó de golpe la calificación de una publicación anterior.)
Que la empresa entregue laptops Mac para mí es una señal positiva, y que entregue laptops con Windows es una señal negativa. La mejor empresa en la que trabajé daba a cada ingeniero de software un Mac y una máquina de escritorio con Linux como equipo base.
Completamente de acuerdo. He trabajado en ambos entornos y, salvo que sea en una escala de siete cifras, ya no quiero volver a trabajar en un entorno de MS.
Personalmente siento que existe relación entre empresas con poco respeto por el trabajo (por ejemplo, abuso de visas H1B) y el uso de un entorno MS. Como vivo en California, en especial casi no se respeta al talento local ni a los trabajadores. Es una atmósfera que también hace caer rápido sindicatos y la regulación del propio estado.
Esos entornos son realmente pésimos. Parece que inculcan una mentalidad de que software y computación no son importantes, y parece que esa cultura también impacta negativamente a quienes construyen software.
Cuando sale un tema como este, la gente siempre dice “Microsoft es mala, jajaja”, pero pienso que no se detienen a considerar los motivos comerciales que la sostienen. ¿Qué tal que no uses Exchange? ¿Cuál sería la alternativa? ¿Algo que soporte de 15 a 150 mil usuarios? Yo operé un clúster de Exchange con 70 mil usuarios. ¿Hay un software de correo que pueda reemplazar un sistema con alta disponibilidad en discos no compartidos y un único endpoint de acceso? ¿Dos RCE más en SharePoint? No es sorpresa; el software en sí no es impresionante. Aun así, este software soporta bien carga pesada. Todo software open source funciona bien en entornos pequeños, pero en escala grande suele colapsar. También entiendo que los desarrolladores de open source no quieran hacer gratis el trabajo tedioso de lidiar con usuarios con baja alfabetización digital. Y Microsoft también da algo de compatibilidad hacia atrás. En las compañías hay un montón de softwares legacy, como CVs sin tocar en décadas o archivos de Excel con macros. Sí, tocando el Registry la seguridad también cae un poco, pero un archivo con macro de Excel de 1997 sigue funcionando. Creo que es difícil encontrar una suite de oficina con la compatibilidad de MS Office. El tema es que Microsoft tiene un problema tipo nudo gordiano, y en la práctica “compatibilidad hacia atrás, ya basta; actualicen todo” es la única salida. Encima, hace unos años desde una compañía nos pidieron actualizar una solución que había sido hecha con Exchange Web Services. Microsoft apagó Exchange Web Services en Office 365 y pidió migrarla a GraphAPI.
Suena como si se hablara de las ventajas de los productos de MS centrados en Exchange, pero el tema ahora es SharePoint. Al igual que con Windows, Microsoft levantó una defensa con Exchange. De verdad me pregunto por qué todas las empresas eligen todo el ecosistema de Microsoft. Especialmente en web, Microsoft lo hace de forma muy mala, y SharePoint es de lo peor de lo peor. Aun así, parece que sí existen varios casos de instalación de sistemas de correo a gran escala con Postfix/Dovecot. Experiencia compartida en Reddit sobre cómo montar un servidor de correo grande
Se dice que SharePoint volvió a tener RCE y por eso es grave. Pero al final, ¿esta funcionalidad no es básicamente un servidor de archivos? (yo no lo he usado). También pienso que Samba o un servidor FTP no tienen problema con grandes volúmenes. En realidad creo que es un problema de UI.
Me intriga cómo trabajaban antes las instalaciones de fabricación de armas sin un sistema así.
Me pregunto cuántas empresas realmente necesitan un servidor Exchange para 150 mil usuarios. En un fabricante estándar de manufactura, ese tamaño casi no debería existir.
Los desarrolladores open source casi nunca se encargan de software hecho para ese nicho, que suele ser aburrido y de usuarios con baja alfabetización computacional. Esto también podría ser un área donde el gobierno contrate a quienes desarrollan open source para aportar al bien público. El gobierno de EE. UU., durante la administración Obama, creó una organización llamada “18F” y realmente construyó software útil para la ciudadanía. En temas siempre problemáticos como programas de impuestos, funcionó muy bien, pero Trump disolvió esa organización justo después de su segundo mandato. (Referencia: History and values de 18F, Lawfare: Lecciones del legado de 18F)
No entiendo con qué lógica se instala SharePoint en infraestructuras críticas nacionales. ¿Cómo puede una empresa usar MS products como SharePoint en un contexto tan ligado a información sensible? Incluyendo MS Office 365, Teams y Edge. Parece que hay que rediseñar la política de seguridad de inmediato.
Hay realmente malas noticias en este escenario.
Entonces me pregunto si existe alguna solución alternativa recomendada.
También hay alguien diciendo que guardó documentos críticos en un baño público de un resort…
Pero así te lo puedes usar todo gratis, ¿no? /broma
He tenido una experiencia previa en la que “puse abajo” un sistema de alertas por Excel. (En realidad no se trata tanto de MSFT, sino de efectos secundarios no intencionados.) Yo operaba un sistema de alertas, construido para buscar la palabra clave 'alert_log' en logs. Hice una hoja de cálculo en Excel para trazabilidad de datos y la llamé 'alert_log'. Como usé la versión en la nube de Excel, el texto ingresado pasó el firewall. En los logs del firewall quedó registrado 'alert_log'. El sistema de alertas interpretó que ese texto estaba en los logs y siguió disparando alertas. En la segunda alerta volvió a incluirse el contenido del log del firewall y empezó un bucle infinito. Los sistemas pueden interactuar entre sí inesperadamente y causar cosas inesperadas. Por eso son importantes enfoques de múltiples capas como auditorías, red team, defense in depth.
SharePoint es, de todo lo que he usado, el software más problemático y con más bugs. Hay un bug de años con Solidworks (herramienta de diseño 3D) donde de repente los archivos no se abren. Microsoft sabe de esto y no veo una razón para no poder resolverlo, pero lo ha dejado sin arreglar durante años. El almacenamiento en la nube de Microsoft es como un laberinto, y no estás seguro ni de dónde está tu archivo ni de si algo funciona. Algunas funciones solo funcionan en navegador y otras solo en app, y ni siquiera hay una lista ordenada de eso. Por eso estoy convencido de que habrá más vulnerabilidades explotables infinitas.
Los productos de Microsoft (especialmente de nube) ahora los uso y siempre termino topándome con etapas de bugs y errores, además de un rendimiento más lento de lo esperado. Recientemente quería enviar correo desde un nuevo subdominio y busqué la configuración DKIM en 365; encontrar dónde estaba ese menú fue una locura. Al final descubrí que el valor de la clave DKIM para email de subdominio debe ir en el dominio raíz. Es francamente ineficiente.
Estamos en un proyecto con contrato del gobierno y hay presión para migrar todo de Slack a MS Teams. Estuve sobreviviendo cerca de 20 años sin usar productos de MS, y me doy cuenta de que en grandes empresas/agencias públicas la tolerancia al dolor de UX es casi infinita.
Sincronizamos archivos con rsync a un SharePoint alojado en MS. En el caso de archivos MS (por ejemplo, Excel), al llegar cambia la metadata interna y cambia el checksum, por lo que rsync interpreta que el archivo cambió otra vez y fuerza una nueva sincronización.
MS Word Online tiene, al menos desde hace dos años, un bug en Firefox Linux (¿también en otros OS?) donde elimina texto. La prioridad número uno de un editor de texto debería ser escribir en el documento, y aquí eso no pasa, y el bug no se corrige. Me funcionó mejor migrar a Overleaf de pago y enseñar LaTeX o su editor integrado a gente no técnica. La salida de documentos también es hermosa, Overleaf no deja de funcionar sin parar y eso me deja muy satisfecho. Aun siendo cliente pagante de Office 365, creo que la priorización de Microsoft es rara. Q&A oficial sobre bug de borrado de texto en la versión web de MS Word
Los servicios de MS como SharePoint parecen hacer un rol interno demasiado crítico y aun así parecen tratarlos como al “niño problema” olvidado.
Si SharePoint es tan malo, me pregunto por qué no hay casos masivos de abuso. Trabajo con muchas compañías Fortune 500, y por percepción propia más del 90% usa SharePoint. Claro, hay mucha diferencia según cómo se implemente, pero si está bien hecho, es bastante utilizable. Aunque exista una mejor alternativa, mantener 5 a 10 productos de proveedores distintos ya es pesado. No termino de entender a quienes no les gusta Teams. Yo uso herramientas de colaboración como Zoom, Slack, Discord y compañía, pero Teams también sirve para todo lo necesario: calendario, reuniones, grabaciones, uso de Copilot. La función de compartir pantalla múltiple en tiempo real y de unirse libremente a canales de Discord me encanta para debugging/pareja de programación, pero Teams cubre las necesidades básicas.
Desde la perspectiva de una compañía que da soporte a sistemas OT, me resulta chocante ver permisos de escritura directa desde Level 5 del modelo Purdue hasta niveles 1/0. (Adicional) Sobre ese modelo Purdue puede revisarse este enlace
Esto me recuerda a la sección de MSSQL de howfuckedismydatabase.com
(Compartiendo enlaces a incidentes de seguridad recientes relacionados con CVE-2025-53770)
Quien expone instalaciones de fisión a internet debería ir a prisión, en mi opinión.