Si se trata de un sistema que está en una ruta crítica a este nivel, no debería haber pasado por un pipeline de CI como corresponde
No soy extremadamente estricto con las pruebas automatizadas, pero para un sistema de esta importancia la gestión de estado debería ser excepcionalmente buena
No se debería hacer un despliegue a producción sin pruebas de integración para todos los entornos que afirman soportar, y no tiene sentido que una empresa de este tamaño e importancia ni siquiera tenga servidores de staging o de pruebas de desarrollo que validen todo el conjunto de imágenes soportadas
Hay demasiadas suposiciones con tan poca información. Por ejemplo, podría haber habido un archivo correcto en realidad, y el punto de falla podría haber sido el código que sube el artefacto validado al CDN
En ese caso, el problema podría aparecer recién después de pasar muchas verificaciones antes del despliegue. No quisiera apresurarme a concluir que no prueban en absoluto lo que envían a Windows
¿Quién dijo que no tienen ese entorno? ¿Quién dijo que no pasó todas esas pruebas? Por ahora hay demasiadas suposiciones
Recuerdo que, cuando entrevisté hace unos años con un equipo encargado de un lenguaje que corre en el kernel, dijeron que su CI ejecutaba entre 20 mil y 40 mil combinaciones y configuraciones de máquinas/OS
Entre ellas seguramente habría Windows básico
Si el criterio de aceptación era “si hay una firma de datos incorrecta, impedir que la máquina arranque”, entonces, como eso podría significar una distribución dañada o una red comprometida, quizá no arrancar era, visto en retrospectiva, el comportamiento correcto
También es posible que el diseño fuera que la máquina no debía arrancar por completo hasta que se descargara un archivo con una firma válida
Es difícil creer que un archivo lleno por completo de caracteres nulos haya sido un artefacto del pipeline de build automático
Apostaría a que algo se compiló y pasó las pruebas de CI, y luego el sistema se rompió en una etapa posterior que copiaba el archivo para prepararlo para el despliegue. Aunque por ahora todo esto es mera especulación
Relacionado con esto, no parece casualidad que dos de los mayores desastres tecnológicos de la historia (CrowdStrike y el hackeo de SolarWinds de hace unos años) hayan salido de software de seguridad que se descontroló
Creo que es muy probable que las personas con mentalidad hacker que quieren fundar empresas de software de seguridad sean las menos interesadas en implementar las partes aburridas de una cultura centrada en procesos. En el caso de SolarWinds se reveló que la cultura de seguridad interna de la empresa era terrible, y en este caso, cuando se conozca la causa raíz, parece probable que haya sido un proceso de despliegue rápido y laxo
No estoy de acuerdo. Las empresas de seguridad sufren el síndrome de “demasiado grandes para quebrar”, y como los clientes quieren marcar casillas, el dinero entra fácilmente La seguridad no es un producto que se compra, sino una cultura, y debe inculcarse desde el primer día con esfuerzo activo y trabajo duro. No hay ningún producto en el mercado que te proporcione seguridad; solo hay productos a los que culpar cuando surge un problema
CrowdStrike fue fundada originalmente y tenía su sede en Irvine, California
La mayor parte de la organización de ingeniería inicial era remota/trabajaba desde casa o estaba en Irvine, y a medida que creció agregaron una oficina en Sunnyvale; después trasladaron oficialmente la sede a Austin, TX
En los últimos años también han ampliado sus operaciones de ingeniería en el extranjero, lo que posiblemente incluya offshoring
Es una hipótesis distinta, pero compatible. El software de seguridad por lo general necesita permisos de acceso amplios y potentes
Por eso, cuando ocurre un error o una intrusión, el impacto tiende a ser mucho mayor
El historial de la industria es bastante peculiar. Solo de lo que me viene a la mente de inmediato están CrowdStrike, SolarWinds, Kaspersky y https://en.wikipedia.org/wiki/John_McAfee
Seguro que me estoy olvidando de más. Quizá tenga una estructura similar al problema de autoselección que afecta a la industria legal del cannabis
El software de seguridad necesita acceso a nivel de kernel. Si algo se rompe, termina en bucles de arranque y cuelgues
La mayoría del resto del software no necesita acceso a un nivel tan bajo, y si falla no se lleva consigo a todo el sistema; además, puede actualizarse automáticamente con rapidez
Si hubiera que buscarle un lado positivo a este desastre, hay una pequeñísima esperanza de que las organizaciones reconsideren el acceso a nivel de kernel
No se puede asumir que cualquier empresa de videojuegos tenga la capacidad suficiente para usar software anticheat a nivel de kernel
A menos que Microsoft tome medidas muy fuertes, no creo que el software de juegos se vea afectado
Aun así, como Microsoft tiene empresas de videojuegos bajo su ala, es muy probable que siga dando hooks para juegos. Las organizaciones empresariales ni se inmutarían ante las prácticas anticheat de Riot, porque no instalan LoL en las máquinas de trabajo
Los rivales a los que hay que enfrentar son los compradores de cheats que dicen “¿un driver a nivel de kernel cualquiera? ¡sin problema!”
Creo que el anticheat debería ser en su mayor parte del lado del servidor y basado en comportamiento
En macOS, por lo que sé, al menos no es posible el acceso al kernel, lo cual es un alivio
Esto parece un archivo de prueba que alguien de QA habría probado en segundo o tercer lugar, después de un archivo vacío y un archivo mínimo válido. Es impactante el nivel de incompetencia generalizada que queda expuesto aquí
En un mercado competitivo donde se impresiona a ejecutivos no técnicos con presentaciones, tampoco sorprende que una empresa técnicamente competente no tenga ventaja sobre una incompetente
Hace poco leí el fallo sobre Craig Wright https://www.judiciary.uk/judgments/copa-v-wright/, y él, que afirmó falsamente ser Satoshi Nakamoto, ni siquiera tenía competencias técnicas básicas en áreas en las que decía ser un experto mundial. En el estrado ni siquiera sabía qué significaba “unsigned”, y parece que desde los 90 venía engañando a la gente con jerga técnica, demos manipuladas y documentos falsificados mientras trabajaba en seguridad para grandes empresas
George Kurtz, fundador y CEO de CrowdStrike, era CTO de McAfee hace 14 años, cuando McAfee hizo casi lo mismo: https://old.reddit.com/r/sysadmin/comments/1e78l0g/can_crowd...https://en.wikipedia.org/wiki/George_Kurtz
La propia CrowdStrike también causó el mismo problema hace 3 meses en Debian stable: https://old.reddit.com/r/debian/comments/1c8db7l/linuximage6...
Es terrible que las normas de cumplimiento PCI hayan metido CrowdStrike y antivirus en casi todas partes de la infraestructura de TI actual
También es irónico que el cumplimiento haya creado la mayor vulnerabilidad como un enorme punto único de falla
Pero así suelen ser las regulaciones gubernamentales
Lo peor de este incidente es que los actores estatales ahora tienen un plano claro para un ataque a infraestructura a gran escala
Me da gracia que la gente en los enlaces se enoje porque lo llamen una “falla de Microsoft” y digan que “es culpa de CrowdStrike”
Pero esto también es una falla de Microsoft. En términos más amplios, es otra falla de la industria
¿Cuántas veces más tiene que repetirse algo así para que haya reformas en la industria que nos permitan construir sistemas seguros y confiables, algo que venimos investigando desde hace 70 años? Se siente como 1988 repitiéndose otra vez
Es bastante irónico que Craig Wright haya propuesto no hacer que los certificados digitales sean emitidos por una sola computadora o clúster, sino subirlos a una blockchain
Si está en un solo lugar se convierte en objetivo, pero una red peer-to-peer es mucho más resiliente a ataques
Si este problema hubiera tenido que ver con que el certificado raíz de todas las computadoras se hubiera reemplazado por CrowdStrike, los certificados registrados en una blockchain quizá podrían ser la solución. No soy experto en criptografía, pero suena plausible
Además, recién cuando escuché la explicación de Craig Wright sobre blockchain empecé a entender bastante el whitepaper de Bitcoin. Puede que no sea el mejor coder, pero ¿acaso un matemático no puede ser útil en seguridad?
No quiero sonar conspiranoico, pero parece demasiado pronto para descartar mala intención solo con la navaja de Hanlon
La mayoría de los errores no son tan absurdamente globales. Parece el error más grande hasta ahora, como el Y2K que no ocurrió
CrowdStrike tiene un comportamiento por el cual, si un archivo que se transmite por un socket de red coincide con una firma de malware, lo reemplaza por ceros
Si esos archivos son los propios archivos de firmas de malware, no sería sorprendente que haya coincidencias
Esto encaja con lo que escuché de un amigo que conoce a alguien que trabaja en CrowdStrike sobre este bug
El bug estuvo latente durante años dentro de un driver del kernel, y se activó al entrar datos defectuosos. Esos datos se agregaron en una etapa de posprocesamiento de una actualización de configuración, después de las pruebas pero antes de copiarla a los servidores de actualización desde donde la tomarían los clientes
Parece que la configuración de pruebas de CrowdStrike estaba bien para los datos de configuración en sí, pero no lo detectó antes de salir a producción porque estaban probando lo equivocado
Si publican un análisis post mortem, espero que reconozcan este problema y expliquen qué harán para evitar otra falla de proceso con impacto mundial
Por fin una explicación que tiene cierto sentido
Creo que cualquier administrador de sistemas competente, a estas alturas, ya habrá desactivado las actualizaciones automáticas desde Greenland hasta New Zealand, las habrá bloqueado con firewall y estará armando un plan para sacar este producto de sus activos de servidores lo antes posible
El presupuesto de marketing de los productos competidores probablemente aumente este trimestre
CrowdStrike debería pasar por algo mucho mayor que simplemente “reconocerlo”
Aunque los contratos tengan “limitación de responsabilidad”, espero que haya investigaciones serias, multas y cuestionamientos legales
El daño causado por este incidente es difícil incluso de calcular, y es mayor si se incluye el tiempo perdido por empresas y personas comunes. Por ejemplo, también quienes intentaban tomar vuelos
Este tipo de negligencia debe tener un costo
Yo pensaba que Windows exigía la firma de todos los módulos del kernel
Si no se trata de una simple filtración de prueba sino de varias copias dañadas, queda la duda de cómo pudieron pasar la verificación de firma y ser cargadas por el kernel
Puede que este no fuera el contenido original del archivo, sino el resultado de una respuesta manual para detener el daño
Alguien pudo haber esperado que sobrescribir el archivo incorrecto con un archivo del mismo tamaño lleno de ceros volviera inofensiva la actualización
O bien, si seguimos la hipótesis de que “se saltaron QA por una vulnerabilidad crítica”, detener la distribución del parche real pudo haber sido un intento de reducir el acceso a los datos reales y retrasar la ingeniería inversa de la vulnerabilidad
Según una explicación publicada en el foro de tecnología de 4chan, el problema tuvo dos etapas
Un driver de kernel firmado llamado CSAgent.sys parseaba los archivos de definiciones de virus de CrowdStrike, y no manejaba correctamente los casos en que un archivo de definiciones malformado provocaba un acceso inválido a memoria
Había un driver de kernel con bomba de tiempo que llevaba meses funcionando sin problemas con archivos de definiciones normales, y en algún momento el servidor web o CDN que entregaba las definiciones empezó a servir contenido incorrecto, como archivos vacíos, bytes aleatorios u otros archivos de software
La explicación dice que el cliente de actualización descargaba eso bajo C:\Windows\System32\drivers, y que CSAgent.sys lo leía y parseaba de nuevo, provocando una pantalla azul con PAGE_FAULT_IN_NONPAGED_AREA y un ciclo de reinicios
Al comparar CSAgent.sys_18511.sys y CSAgent.sys_18513.sys, dicen que se ven indicios de cambios en la comprobación de tamaño y en el tamaño del búfer, para que futuros archivos de definiciones incorrectos no causen un fallo
Suena como si alguna función de protección antivirus en el servidor que entrega los archivos de definiciones hubiera bloqueado la lectura del disco y, en vez de devolver un error, hubiera entregado datos de salida en ceros
Si realmente algún paquete antivirus fue la causa, sería bastante irónico
Si esto ocurrió varias veces, podría haber sido un ataque de hackers dirigido a un driver de kernel pésimamente escrito
Especialmente en el contexto del momento electoral actual y de que es una empresa que le gusta a Trump, también podría haber sido una demostración de fuerza
Antes ya me había pasado que un software de seguridad convertía archivos enteros en ceros y rompía la compilación de software
No digo que este sea el caso ahora, pero tampoco me sorprendería
Básicamente, en Windows el enlazador no podía abrir el archivo porque otro proceso lo tenía bloqueado mientras lo escaneaba. Pero en vez de arrojar un error, reemplazó con ceros el código objeto que debía enlazarse
La gente no encontraba la causa hasta que abrió el depurador y recién ahí confirmó que grandes bloques del código objeto habían sido reemplazados por ceros
He tenido demasiadas veces el problema de que Visual Studio no puede escribir en un archivo que acaba de compilar
El antivirus agarra el binario recién generado justo en el momento en que mt.exe necesita escribirlo, así que incluso tengo hecho un wrapper para mt.exe que agrega reintentos. Las builds de CI también solían fallar aleatoriamente por esto
1 comentarios
Opiniones de Hacker News
Si se trata de un sistema que está en una ruta crítica a este nivel, no debería haber pasado por un pipeline de CI como corresponde
No soy extremadamente estricto con las pruebas automatizadas, pero para un sistema de esta importancia la gestión de estado debería ser excepcionalmente buena
No se debería hacer un despliegue a producción sin pruebas de integración para todos los entornos que afirman soportar, y no tiene sentido que una empresa de este tamaño e importancia ni siquiera tenga servidores de staging o de pruebas de desarrollo que validen todo el conjunto de imágenes soportadas
En ese caso, el problema podría aparecer recién después de pasar muchas verificaciones antes del despliegue. No quisiera apresurarme a concluir que no prueban en absoluto lo que envían a Windows
Entre ellas seguramente habría Windows básico
También es posible que el diseño fuera que la máquina no debía arrancar por completo hasta que se descargara un archivo con una firma válida
Apostaría a que algo se compiló y pasó las pruebas de CI, y luego el sistema se rompió en una etapa posterior que copiaba el archivo para prepararlo para el despliegue. Aunque por ahora todo esto es mera especulación
Relacionado con esto, no parece casualidad que dos de los mayores desastres tecnológicos de la historia (CrowdStrike y el hackeo de SolarWinds de hace unos años) hayan salido de software de seguridad que se descontroló
Creo que es muy probable que las personas con mentalidad hacker que quieren fundar empresas de software de seguridad sean las menos interesadas en implementar las partes aburridas de una cultura centrada en procesos. En el caso de SolarWinds se reveló que la cultura de seguridad interna de la empresa era terrible, y en este caso, cuando se conozca la causa raíz, parece probable que haya sido un proceso de despliegue rápido y laxo
La seguridad no es un producto que se compra, sino una cultura, y debe inculcarse desde el primer día con esfuerzo activo y trabajo duro. No hay ningún producto en el mercado que te proporcione seguridad; solo hay productos a los que culpar cuando surge un problema
La mayor parte de la organización de ingeniería inicial era remota/trabajaba desde casa o estaba en Irvine, y a medida que creció agregaron una oficina en Sunnyvale; después trasladaron oficialmente la sede a Austin, TX
En los últimos años también han ampliado sus operaciones de ingeniería en el extranjero, lo que posiblemente incluya offshoring
Por eso, cuando ocurre un error o una intrusión, el impacto tiende a ser mucho mayor
Seguro que me estoy olvidando de más. Quizá tenga una estructura similar al problema de autoselección que afecta a la industria legal del cannabis
La mayoría del resto del software no necesita acceso a un nivel tan bajo, y si falla no se lleva consigo a todo el sistema; además, puede actualizarse automáticamente con rapidez
Si hubiera que buscarle un lado positivo a este desastre, hay una pequeñísima esperanza de que las organizaciones reconsideren el acceso a nivel de kernel
No se puede asumir que cualquier empresa de videojuegos tenga la capacidad suficiente para usar software anticheat a nivel de kernel
Aun así, como Microsoft tiene empresas de videojuegos bajo su ala, es muy probable que siga dando hooks para juegos. Las organizaciones empresariales ni se inmutarían ante las prácticas anticheat de Riot, porque no instalan LoL en las máquinas de trabajo
Esto parece un archivo de prueba que alguien de QA habría probado en segundo o tercer lugar, después de un archivo vacío y un archivo mínimo válido. Es impactante el nivel de incompetencia generalizada que queda expuesto aquí
En un mercado competitivo donde se impresiona a ejecutivos no técnicos con presentaciones, tampoco sorprende que una empresa técnicamente competente no tenga ventaja sobre una incompetente
Hace poco leí el fallo sobre Craig Wright https://www.judiciary.uk/judgments/copa-v-wright/, y él, que afirmó falsamente ser Satoshi Nakamoto, ni siquiera tenía competencias técnicas básicas en áreas en las que decía ser un experto mundial. En el estrado ni siquiera sabía qué significaba “unsigned”, y parece que desde los 90 venía engañando a la gente con jerga técnica, demos manipuladas y documentos falsificados mientras trabajaba en seguridad para grandes empresas
George Kurtz, fundador y CEO de CrowdStrike, era CTO de McAfee hace 14 años, cuando McAfee hizo casi lo mismo: https://old.reddit.com/r/sysadmin/comments/1e78l0g/can_crowd... https://en.wikipedia.org/wiki/George_Kurtz
La propia CrowdStrike también causó el mismo problema hace 3 meses en Debian stable: https://old.reddit.com/r/debian/comments/1c8db7l/linuximage6...
Es terrible que las normas de cumplimiento PCI hayan metido CrowdStrike y antivirus en casi todas partes de la infraestructura de TI actual
Pero así suelen ser las regulaciones gubernamentales
Pero esto también es una falla de Microsoft. En términos más amplios, es otra falla de la industria
¿Cuántas veces más tiene que repetirse algo así para que haya reformas en la industria que nos permitan construir sistemas seguros y confiables, algo que venimos investigando desde hace 70 años? Se siente como 1988 repitiéndose otra vez
Si está en un solo lugar se convierte en objetivo, pero una red peer-to-peer es mucho más resiliente a ataques
Si este problema hubiera tenido que ver con que el certificado raíz de todas las computadoras se hubiera reemplazado por CrowdStrike, los certificados registrados en una blockchain quizá podrían ser la solución. No soy experto en criptografía, pero suena plausible
Además, recién cuando escuché la explicación de Craig Wright sobre blockchain empecé a entender bastante el whitepaper de Bitcoin. Puede que no sea el mejor coder, pero ¿acaso un matemático no puede ser útil en seguridad?
La mayoría de los errores no son tan absurdamente globales. Parece el error más grande hasta ahora, como el Y2K que no ocurrió
Este artículo está equivocado y, como no hay otra forma de bajarlo de la portada, lo marqué con flag
Que se haya encontrado un archivo lleno de ceros en una computadora averiada no significa que ese archivo se haya distribuido lleno de ceros desde el principio
https://x.com/craiu/status/1814339965347610863
https://x.com/cyb3rops/status/1814329155833516492
Si esos archivos son los propios archivos de firmas de malware, no sería sorprendente que haya coincidencias
Esto encaja con lo que escuché de un amigo que conoce a alguien que trabaja en CrowdStrike sobre este bug
El bug estuvo latente durante años dentro de un driver del kernel, y se activó al entrar datos defectuosos. Esos datos se agregaron en una etapa de posprocesamiento de una actualización de configuración, después de las pruebas pero antes de copiarla a los servidores de actualización desde donde la tomarían los clientes
Parece que la configuración de pruebas de CrowdStrike estaba bien para los datos de configuración en sí, pero no lo detectó antes de salir a producción porque estaban probando lo equivocado
Si publican un análisis post mortem, espero que reconozcan este problema y expliquen qué harán para evitar otra falla de proceso con impacto mundial
Creo que cualquier administrador de sistemas competente, a estas alturas, ya habrá desactivado las actualizaciones automáticas desde Greenland hasta New Zealand, las habrá bloqueado con firewall y estará armando un plan para sacar este producto de sus activos de servidores lo antes posible
El presupuesto de marketing de los productos competidores probablemente aumente este trimestre
Aunque los contratos tengan “limitación de responsabilidad”, espero que haya investigaciones serias, multas y cuestionamientos legales
El daño causado por este incidente es difícil incluso de calcular, y es mayor si se incluye el tiempo perdido por empresas y personas comunes. Por ejemplo, también quienes intentaban tomar vuelos
Este tipo de negligencia debe tener un costo
En Mastodon, Kevin Beaumont afirma que el archivo que recibió varía según el cliente
https://cyberplace.social/@GossiTheDog/112812454405913406
Basta con bajar un poco
Si no se trata de una simple filtración de prueba sino de varias copias dañadas, queda la duda de cómo pudieron pasar la verificación de firma y ser cargadas por el kernel
Puede que este no fuera el contenido original del archivo, sino el resultado de una respuesta manual para detener el daño
Alguien pudo haber esperado que sobrescribir el archivo incorrecto con un archivo del mismo tamaño lleno de ceros volviera inofensiva la actualización
O bien, si seguimos la hipótesis de que “se saltaron QA por una vulnerabilidad crítica”, detener la distribución del parche real pudo haber sido un intento de reducir el acceso a los datos reales y retrasar la ingeniería inversa de la vulnerabilidad
Según una explicación publicada en el foro de tecnología de 4chan, el problema tuvo dos etapas
Un driver de kernel firmado llamado CSAgent.sys parseaba los archivos de definiciones de virus de CrowdStrike, y no manejaba correctamente los casos en que un archivo de definiciones malformado provocaba un acceso inválido a memoria
Había un driver de kernel con bomba de tiempo que llevaba meses funcionando sin problemas con archivos de definiciones normales, y en algún momento el servidor web o CDN que entregaba las definiciones empezó a servir contenido incorrecto, como archivos vacíos, bytes aleatorios u otros archivos de software
La explicación dice que el cliente de actualización descargaba eso bajo C:\Windows\System32\drivers, y que CSAgent.sys lo leía y parseaba de nuevo, provocando una pantalla azul con PAGE_FAULT_IN_NONPAGED_AREA y un ciclo de reinicios
Al comparar CSAgent.sys_18511.sys y CSAgent.sys_18513.sys, dicen que se ven indicios de cambios en la comprobación de tamaño y en el tamaño del búfer, para que futuros archivos de definiciones incorrectos no causen un fallo
Si realmente algún paquete antivirus fue la causa, sería bastante irónico
Especialmente en el contexto del momento electoral actual y de que es una empresa que le gusta a Trump, también podría haber sido una demostración de fuerza
Antes ya me había pasado que un software de seguridad convertía archivos enteros en ceros y rompía la compilación de software
No digo que este sea el caso ahora, pero tampoco me sorprendería
Básicamente, en Windows el enlazador no podía abrir el archivo porque otro proceso lo tenía bloqueado mientras lo escaneaba. Pero en vez de arrojar un error, reemplazó con ceros el código objeto que debía enlazarse
La gente no encontraba la causa hasta que abrió el depurador y recién ahí confirmó que grandes bloques del código objeto habían sido reemplazados por ceros
El antivirus agarra el binario recién generado justo en el momento en que mt.exe necesita escribirlo, así que incluso tengo hecho un wrapper para mt.exe que agrega reintentos. Las builds de CI también solían fallar aleatoriamente por esto