Backdoor de XZ: “No es una omisión de autenticación, sino RCE; tiene gate y no es reproducible”

• Según un análisis preliminar de ingeniería inversa del backdoor de xz, este comportamiento no es una simple omisión de autenticación, sino que se acerca a una ejecución remota de código (RCE)
• El punto central es el flujo en el que RSA_public_decrypt, interceptado por un hook, verifica la firma de la clave de host del servidor con una clave Ed448 fija
• Si la verificación de la firma se supera, el payload puede pasarse a system() para su ejecución
• El análisis es un resultado preliminar compartido con autorización, y la publicación de Bluesky incluye una publicación citada o contenido incrustado
• El backdoor se resume como una forma con gate y no reproducible, por lo que debe verse de manera distinta a un ataque que simplemente reutiliza la misma entrada

---

Flujo de ejecución del backdoor de xz

• El análisis preliminar de ingeniería inversa compartido con autorización se centra en RSA_public_decrypt, interceptado por un hook
  • Verifica la firma de la clave de host del servidor con una clave Ed448 fija
  • Después de la verificación, pasa el payload a system()

Clasificación y restricciones

• Este comportamiento no se clasifica como una omisión de autenticación, sino como ejecución remota de código (RCE)
• El backdoor se resume como con características gated/unreplayable
• La publicación original de Bluesky incluye una publicación citada u otro contenido incrustado

[GN⁺]

Opiniones de Hacker News

• Hay resultados de ingeniería inversa adicional sobre este asunto. Incluyen información de remapeo de símbolos extraída del prefix trie que la puerta trasera usaba para ocultar cadenas, y parece que también intentaba ocultarse de la propia ingeniería inversa/análisis
  https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
  La lista completa de cadenas decodificadas está aquí
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
  Desde la perspectiva de alguien que no conoce bien los internos de OpenSSL, parece que el valor N se toma del campo n de rsa_st
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Este valor es un BIGNUM y parece ser un tipo de longitud variable
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  La puerta trasera extrae este valor del certificado recibido del atacante remoto, intenta descifrarlo con ChaCha20 y, si tiene éxito, lo pasa a system(). system() es casi un simple wrapper que ejecuta una línea de script de shell con los permisos del usuario bajo el cual se está ejecutando el proceso actual
  Si lo entendí bien, esto es peor que un bypass de clave pública. Con un bypass de clave pública, en teoría solo se obtendrían los permisos del usuario que intenta iniciar sesión, y en configuraciones SSH endurecidas es muy probable que el login como root esté bloqueado
  Pero esto es ejecución remota de código en el propio contexto del proceso sshd, así que si sshd se está ejecutando como root, el payload también podría ejecutarse como root. Como ejecución remota de código ampliamente distribuida, en la práctica es casi lo peor posible

  • Con sandboxing adecuado, SELinux y técnicas de mitigación, tal vez se podría impedir que el atacante haga algo con privilegios de root. Pero aplicar un sandbox de forma efectiva al demonio SSH es muy difícil
  • Es enorme. Ni siquiera alcanzo a imaginar cómo se decide qué hacer con los privilegios de mil millones de computadoras

• Me pregunto qué tan probable habría sido que esta puerta trasera se descubriera más adelante si no se hubiera detectado por el problema de rendimiento. Entendí el problema de rendimiento como un error/defecto corregible en el código, y también es importante si había herramientas que pudieran detectarlo
  Este tipo de pregunta es muy relevante para entender si esta clase de puerta trasera es la primera, o solo la primera que salió a la luz

  • Habiendo trabajado alrededor de un año en un entorno con muchos actores maliciosos de TI, creo que la probabilidad de descubrimiento siempre es bastante alta. Mantener el secreto requiere una cantidad de energía difícil de imaginar, y lo mismo aplica a mantener la coherencia de la verdad
    Un solo error pequeño puede derrumbarlo todo y, a veces, basta una sola frase para iniciar una reacción en cadena que revele un plan cuidadosamente elaborado
    Las investigaciones criminales funcionan así todos los días. El trabajo policial tiene limitaciones de recursos, pero el software lo revisan todos los días aficionados que lo analizan por hobby, profesionales que lo analizan de manera casi recreativa y profesionales que lo analizan como trabajo
    Al final, lo más probable es que se hubiera descubierto algún día
    El ataque a XZ fue ejecutado muy bien, casi una obra maestra. No me sorprendería que hubiera una agencia estatal involucrada. Pero al mismo tiempo tuvo muchísima suerte. Si se hubiera encontrado aunque fuera uno de los puntos que ahora se señalan como problemáticos, no solo yo sino muchos colegas habríamos iniciado una larga investigación
    Una conclusión que se puede sacar es que, si xz/liblzma no hubiera sido open source, habría sido imposible encontrar estos problemas. Claro que el hecho de que fuera open source también fue parte de lo que lo hizo posible desde el principio, pero basta imaginar que esto hubiera estado dentro de Windows o MacOS
  • Si el exploit no se hubiera usado, la probabilidad de detección habría sido bastante baja. Eligieron muy bien dónde esconderlo. En la práctica estaba fuera de la base de código, en un lugar que los auditores no miran
    Pero si no se usa, no cumple su objetivo. Cuanto más se use, mayor será también la probabilidad de que se detecte después. Es comparable con SolarWinds
  • Creo que durante los próximos meses mucha gente va a pensar muchísimo en esta dirección. La cuestión es si se trata de revisión de código o de algún tipo de análisis de comportamiento
    Personalmente, la llamada a system() me pareció algo descuidada, y creo que un escáner de capacidades binarias potencialmente podría haber encontrado esa ruta
  • Creo que esto habría sido difícil de atrapar. El parche a sshd ocurre en un paso aceptable, el momento de linking, y si este análisis es correcto, tampoco es una puerta trasera de clave maestra, así que no hay rastros típicos en las auditorías de login. Además, que sshd inicie otros procesos puede ser perfectamente permitido
    Una política de SELinux muy estricta tal vez podría detectar que sshd ejecuta algo que no sea una shell, pero un nivel de endurecimiento así sería muy raro
    En cierto modo, el problema de descubrirlo desde fuera del objetivo ya fue probado. Varias personas miraron el payload con valgrind y otras herramientas, pero no lo vieron. También está bastante bien protegido para no ser descubierto en entornos de depuración. Esto se debe a que la infraestructura expuesta debajo del payload no es compatible con herramientas como ASan
    Incluso si se enlaza, el código se ejecuta mucho antes de main(), por lo que, aunque se busque cerca de liblzma con un depurador, normalmente no se observa la escena de ejecución
    Con strace se podrían ver todas las llamadas al sistema y el comportamiento del linker después de que se crea el proceso. Pero por lo que se entiende hasta ahora, el payload no realiza llamadas al sistema en esa etapa para decidir si se activa, sino que parece mirar argv, environ y similares
  • Como derivación interesante, viene a la mente que el ataque de Ken Thompson también fue descubierto en PWB por un bug de rendimiento de memoria
    [0] https://en.wikipedia.org/wiki/PWB/UNIX
    [1] https://news.ycombinator.com/item?id=38020792

• Parece que hay una cadena codificada dentro del payload binario
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
  Esta cadena funciona como un kill switch
  https://piaille.fr/@zeno/112185928685603910
  Si realmente es así, una mitigación podría ser la siguiente

  echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment  
  

  • Es imprescindible incluir -a. De lo contrario, podrías borrar el archivo de entorno. Y, en general, lo correcto es actualizar a una versión sin código malicioso y reiniciar
  • Es demasiado extraño. Huele muchísimo a un actor estatal que quiso dejar una forma de proteger sus propios sistemas

• ¿Alguien puede explicar brevemente qué hace exactamente el backdoor? ¿Ya se sabe? No parece que el backdoor en sí sea el payload, y me pregunto si se necesita un archivo comprimido malicioso, o si engancha el proceso sshd para escuchar paquetes maliciosos de un atacante remoto
  El texto original suena como si el atacante pudiera enviar un payload malicioso en la etapa previa a la autenticación de una sesión SSH, pero tampoco entiendo por qué dicen que quizá nunca aparezca un exploit. Si se puede hacer ingeniería inversa del código, ¿no se podría escribir también una prueba de concepto?
  En definitiva, ¿cómo controla el atacante una máquina que tiene este backdoor?

  • Piensa en una puerta que se abre si tocas exactamente de la forma correcta. Para quien no conoce el golpe secreto, parece una pared y se comporta como una pared. Sin el golpe secreto, puede que ni siquiera haya forma de demostrar que se abre
    La situación aquí es similar. Antes de hacer algo sospechoso, xz intenta descifrar ciertos datos. Como es un esquema asimétrico, se puede verificar el descifrado sin proporcionar la clave secreta de cifrado, porque se tiene la clave pública correspondiente
    Como encontrar la clave secreta es prácticamente imposible, y si falla el descifrado del payload no hay un comportamiento visiblemente distinto, es posible que el código del exploit nunca se haga público. La única forma de crear código de exploit sería que de algún modo se descubra la clave secreta, y en la práctica eso solo pasaría si el desarrollador del backdoor la filtrara
  • Según lo que he leído, creo que el vector de ataque es este. Al iniciarse, sshd carga libsystemd, y esta carga la biblioteca XZ que contiene el código hackeado
    La biblioteca XZ inyecta su propia versión de las funciones de OpenSSL que verifican firmas RSA
    Cuando alguien inicia sesión por SSH y presenta un certificado SSH firmado para autenticarse, se llaman esas funciones modificadas
    En un certificado pueden incluirse, como parte del proceso normal de inicio de sesión, afirmaciones como el nombre de usuario o el rol, y con esa información se determina si el certificado es válido para iniciar sesión como cierto usuario. Pero si la función modificada detecta un certificado firmado con una clave específica del atacante, extrae algunos subcampos del certificado y los ejecuta como comandos del sistema. El contexto de ejecución es sshd, es decir, el usuario root
    Por desgracia, no conocemos la clave de firma del atacante; solo conocemos la clave pública que usa el código hackeado para la verificación. Básicamente, el atacante puede hacer ejecución arbitraria de comandos como root en un sistema infectado, y como mucho las huellas serían intentos de inicio de sesión fallidos. En sistemas expuestos a Internet, esos intentos ya ocurren en grandes cantidades
  • Parece que todavía no se sabe exactamente qué hace. Pero entiendo la parte de “no reproducible” así: si el payload es incorrecto o no se verifica la firma de la clave del atacante, el backdoor vuelve al comportamiento normal
    Lo clave es que se necesita la firma de la clave del atacante. Mientras esa clave no se filtre o no se rompa el algoritmo RSA, es imposible que otros investigadores o terceros abusen de este backdoor. Si RSA se rompiera, tendríamos problemas mucho más grandes que este
  • Si la criptografía de clave pública se usó correctamente y no hay bugs explotables, no se puede crear una prueba de concepto aunque se haga ingeniería inversa
  • El exploit distribuido no era código fuente sino binario, y estaba hábilmente oculto dentro de datos de prueba. Además, verifica el payload con una clave privada que no se ha publicado
    Por ahora, solo el atacante puede ejecutar el exploit, así que tampoco es posible escanearlo. Salvo efectos secundarios como degradación del rendimiento, es difícil de detectar, y de hecho así fue como se descubrió

• Cuesta entender que un paquete importante que tantos servidores Linux usan a diario deje de poder ser mantenido por su autor original por falta de fondos. Algo tiene que cambiar en el open source
  Una posible solución podría ser una licencia que obligue a empresas o negocios de cierto tamaño a pagar costos de mantenimiento

  • La gente se opone fuertemente a ese tipo de licencias. Empieza una gran reacción de “ya no es libre”, y esa entidad termina cancelada
  • Me pregunto si realmente es falta de fondos o más bien burnout
  • La propuesta de la Cyber Resilience Act de la UE se presenta como una solución. En pocas palabras, el proveedor es responsable de las vulnerabilidades durante la vida útil del producto, ya sea un firewall o una tostadora
    Por lo tanto, los proveedores tienen incentivos para mantener seguro el open source. Ya sea pagándoles a los mantenedores, encargando auditorías de código o contratando empleados de tiempo completo para que contribuyan
  • Importante y necesario no son lo mismo. Este paquete no es tanto importante como necesario
  • Cuesta entender por qué se necesita algo tan complejo como xz. El código de bzip2 es pequeño, y podría mantenerse con una fracción mínima del tiempo de una sola persona

• Si entras ahora al repositorio de xz, está deshabilitado por violar los términos de uso de GitHub. La deshabilitación en sí es comprensible, pero me gustaría que GitHub dejara el código y el historial, mostrara un banner y bloqueara solo las funciones que puedan ser abusadas
  Así los investigadores y otras personas podrían aprender sobre el exploit. En situaciones más triviales, si una biblioteca estaba alojando código malicioso y el repositorio se cae, uno podría simplemente pasarlo por alto como si no fuera gran cosa

  • Probablemente no quieran que herramientas automatizadas lo descarguen
  • Los eventos de GitHub de ese repositorio pueden verse aquí en CSV: https://github.com/emirkmo/xz-backdoor-github
    Si te interesa el código fuente, es fácil de encontrar. Este código y el repositorio Git están vinculados en muchos repositorios Git de todo el mundo, y el código fuente también se incluyó varias veces en releases
  • xz tiene su propio mirror de Git, así que se pueden ver todos los commits

• Como mantenedor de facto de un juego open source poco conocido, he visto desarrolladores ir y venir. Simplemente fusiono todas las contribuciones valiosas
  Algunos colaboradores se meten bastante a fondo en funcionalidades, con C y C++ mezclados en distintos estilos de código. No siempre entiendo todos los detalles de implementación, pero en algún rincón de mi mente pienso que, si alguien metiera un backdoor realmente malo, el proyecto se iría al demonio
  Por suerte, el juego es muy obscure y la superficie de ataque es muy pequeña. Aun así, se me quitaron las ganas de intentar firmar binarios de Windows de buena fe
  Este backdoor de xz es una pesadilla enorme, y siento pena por los desarrolladores originales y por todos los que quedaron metidos en esto

  • Claro, eso es cierto, pero no es un problema exclusivo del software. De hecho, ni siquiera estoy seguro de que pueda llamarse “problema” en un sentido significativo
    Cuando vas caminando por un sendero en el bosque, un auto que pasa podría simplemente atropellarte. Es muy probable que el conductor no sea atrapado, no hay forma de impedirlo y no hay policía al lado. Este escenario, mucho más aterrador que un backdoor de software, en realidad es el riesgo mínimo que uno tiene que aceptar para poder vivir haciendo cosas. Y de hecho cosas así ocurren
    Pero, al final, la gran mayoría de la gente no intenta hacer daño activamente a los demás. Todo lo que hacen los humanos siempre se ha basado en esa suposición, y sigue siendo así
    La ilusión de que esto se evitaría haciendo revisiones de código un poco más estrictas, usando más linters, CI y pattern matching, popularizando más la firma de código y verificando la identidad de las personas es, en realidad, el verdadero problema. Es un síntoma del delirio estilo Silicon Valley de que el mundo puede y debe administrarse y controlarse a todo nivel de detalle. Esa “cura” puede ser mucho peor que cualquiera de las enfermedades que intenta prevenir
  • El difunto Pieter Hintjens, de ZeroMQ, defendía una práctica llamada Optimistic Merging. Consiste en fusionar contribuciones de inmediato, sin esperar revisión de código ni resultados de CI. Un enfoque con criterios de merge laxos no es algo completamente descabellado
    [1]: http://hintjens.com/blog:106
    Entiendo la ventaja de crear una comunidad donde los colaboradores participen con gusto en el proyecto. Pero me daba la impresión de que era una forma de hacer crecer un proyecto sin una visión o dirección claras, y que al final imponía una carga excesiva a los mantenedores para ajustar las contribuciones de otros a un estándar común
    La revisión real del código se desplaza a algún momento desconocido del futuro, y no queda claro si entonces la revisión será rigurosa, ni quién se hará responsable de realizarla o de corregir los problemas. Al final suena como una receta para el caos, sin control sobre lo que se distribuye a los usuarios
    También está el problema de distribuir código malicioso. Este tema aparece incluso en los comentarios de esa entrada del blog, y Pieter describe exactamente el mismo escenario que el caso de xz
    “Supongamos que Mallory es paciente y engañoso, y que durante el tiempo suficiente actúa como un colaborador válido hasta obtener el control del proyecto; luego empieza a introducir lentamente un backdoor. En ese caso, ni una revisión de código cuidadosa ayuda. Mallory solo necesita ganarse la confianza suficiente para convertirse en mantenedor, y eso no es una cuestión de si se puede, sino de cómo hacerlo.”
    Él concluye que “la mejor defensa es el tamaño y la diversidad de la comunidad”
    Pero creo que una revisión de código cuidadosa sí puede reducir la probabilidad de que esto ocurra. Si se revisan rigurosamente todas las contribuciones, ya sean de colaboradores de confianza o externos, aumentan las posibilidades de detectar antes comportamientos extraños o commits que dicen “hacer A” pero en realidad hacen B
    También es debatible que Optimistic Merging lleve a una comunidad más grande y diversa. Hay muchos proyectos con comunidades activas aun teniendo guías de contribución estrictas. Y no responde cuándo ni cómo se detectaría un parche malicioso
    El problema de xz no fue una comunidad pequeña, sino que no había comunidad. Un único actor malicioso obtuvo el control del proyecto, con casi ninguna supervisión de nadie más. Las guías de contribución no fueron un factor del tamaño de la comunidad, y esto habría ocurrido se usara Optimistic Merging o no
    [2]: http://hintjens.com/blog:106/comments/show#post-2409627
  • Siempre me sorprende ver que las empresas ponen esfuerzos enormes en la seguridad del perímetro de red, mientras que en las organizaciones de desarrollo se instala cotidianamente brew install cask o extensiones de vi/emacs/vscode
    Rust podría considerarse el lenguaje/comunidad de programación con los valores predeterminados más seguros, con un diseño priorizando tanto la seguridad que casi no permite juegos con punteros. Pero la ruta de instalación más común y recomendada es esta, y yo también soy un hipócrita total y la uso seguido
    https://www.rust-lang.org/tools/install
    Esto es solo un ejemplo. A demasiadas personas se les volvió memoria muscular abrir por su cuenta ejecución remota de código con cosas como “haz curl de esto y pásalo por pipe a sh”, mientras al mismo tiempo discuten por el bloque unsafe de alguien
  • Sinceramente, era cuestión de tiempo que nos diéramos cuenta de que nuestra buena fe sería explotada. Conductas como “rompamos rápido y arreglemos rápido” o “¿quién quiere quedarse con la propiedad de mi proyecto?” son una invitación a los problemas, pero mientras el open source sea trabajo afectivo no remunerado por amor a programar, es difícil imaginar vivir sin ellas
    Es lamentable que esto haya ocurrido, pero no sorprendente. Ojalá aparezcan mejores herramientas para enfrentar a estos actores maliciosos, y que además sean open source

• Este backdoor plantea varias preguntas. ¿Qué otros backdoors habrán implantado el mismo equipo o equipos similares? ¿Cuántos equipos de este tipo están activos? ¿Cuántas dependencias son vulnerables a este tipo de ataques de infiltración? ¿Qué tan grande es la superficie de ataque de nuestra industria para estas operaciones encubiertas dirigidas?
  Crear un grafo de los principales servicios de red como apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix, junto con todas sus dependencias y todos los grafos de committers de esas dependencias, podría ser un primer paso para identificar dónde hay más valor y menos vigilancia.
  Es imposible que esta sea la primera vez que alguien intenta algo así. Solo es el primer caso que quedó expuesto porque falló. Sabemos de backdoors que se intentaron introducir en el kernel de Linux y fueron descubiertos, pero esto es un ataque remoto y de una naturaleza completamente distinta.

  • ¿Por qué decidieron crear un backdoor en vez de usar un zero-day, como hace todo el mundo?
    ¿Por qué no distribuir algo de apariencia inocua que, si se detectaba, pudiera parecer un bug, en lugar de implementar un backdoor con todas las funciones y además ocultar la forma de distribución?
    Esto debió haber sido una decisión deliberada. El motivo podría dar pistas sobre cuál era el objetivo.
  • Debian también debería preguntarse por qué parcheó un servicio que se ejecuta como root y acepta conexiones desde Internet para que cargara una biblioteca innecesaria.

• Esto parece significar que, para escanear remotamente el exploit, necesitaríamos la clave privada del atacante, que no tenemos. La única otra opción es ejecutar scripts de detección localmente.

  • Una forma absolutamente terrible que algunos escáneres podrían elegir sería marcar como “potencialmente vulnerable” cualquier servidor que ofrezca autenticación RSA. La mayoría de los servidores SSH ofrecen autenticación RSA y, de hecho, el RFC de SecSH también dice que implementarla es obligatorio. Eso podría empujar a la gente a volver a la autenticación por contraseña.
    A menos que se demuestre que este problema se propagó ampliamente en sistemas reales, ese enfoque parece peor que cuando “expertos” similares exigían cambiar las contraseñas cada año, reduciendo la seguridad real mientras la seguridad en el papel se veía mejor.
  • Como parece que el código de verificación de firma solo se ejecuta cuando la clave pública del cliente coincide con una huella específica, quizá pueda detectarse mediante información de timing.
    La verificación de firma del backdoor debería tardar alrededor de 100 µs, así que una clave cuya huella coincida debería demorar ese tiempo adicional frente a una que no coincida. Esa diferencia de tiempo es realísticamente detectable al menos en una LAN, y quizá también a través de Internet si el escáner se ejecuta desde una ubicación cercana al objetivo.
    Los sistemas que bloquean la IP del cliente después de varios intentos fallidos de autenticación dificultarán más el escaneo.
    (https://bench.cr.yp.to/results-sign.html muestra que la verificación Ed448 toma unos 400 mil ciclos, lo que equivale a 100 µs a 4 GHz)
  • El tuit dice que “no se puede reproducir”. Me pregunto por qué no puede reproducirse. ¿Será que el sshd con backdoor emite algún desafío y el atacante tiene que firmarlo?

• Puede que sea una opinión impopular, pero no puedo evitar admirar toda la operación. Por supuesto la condeno, pero aun así me impresiona. Desde la concepción hasta la ejecución fue realmente una obra de arte, y que la hayan detectado tan temprano fue una suerte enorme.

  • Si el payload no hubiera causado pausas aleatorias de 0.5 segundos durante el inicio de sesión SSH, probablemente no se habría descubierto durante mucho tiempo.
    La próxima vez, es probable que los atacantes creen un payload que no genere picos extraños de latencia en una operación donde hay una persona esperando.
    Por alguna razón me recuerda a cómo Kim Dotcom descubrió que era objeto de escuchas ilegales. Fue porque de pronto su ping subió muchísimo en MW3. Al investigar, resultó que solo sus paquetes estaban siendo ruteados físicamente a través de una oficina del GCSB ubicada muy lejos. El GCSB no tiene autoridad para espiar a residentes permanentes de Nueva Zelanda. Al final recibió una disculpa personal del primer ministro neozelandés.
  • “Después de todo, ese tipo que nunca debió haber sido mergeado hizo cosas grandiosas. Terribles, sí, pero grandiosas.”
    Creo que la parte más ingeniosa fue la elección del proyecto a infiltrar. Leer a posteriori la discusión del pull request de IFUNC de “Hans” duele, pero muestra muy bien por qué eligieron este proyecto.
    Me gustaría saber cuántas personas había detrás de “Jia” y “Hans”, y cómo analizaron y diseñaron su estrategia de comunicación y contribuciones de código. Algunos aspectos, como esas terceras identidades que parecían presionar en la lista de correo, se ven algo burdamente construidos.
    Por eso todavía es posible que haya sido un equipo pequeño y sofisticado, o incluso una sola persona. Si fuera un actor estatal, pensaría que tendrían gente dedicada todo el día a crear y mantener identidades falsas para una operación así.
    Si alguien hubiera pensado “estos tres usuarios están presionando de forma un poco grosera, qué raro, ¿quiénes son? Las cuentas fueron creadas todas más o menos al mismo tiempo. Sospechoso. ¿Por qué alguien insistiría tanto con esto usando cuentas falsas? Debería investigarlo”, habrían estado en problemas. Comparado con todo el esfuerzo invertido, esa parte fue descuidada, mal planificada o con poco presupuesto.
  • Estoy de acuerdo, pero la parte de ingeniería social se siente especialmente cruel.
  • No creo que sea una opinión tan impopular. En muchos sentidos fue un ataque muy impresionante. Fue sutil, se construyó durante varios años y probablemente no nos habríamos enterado si el atacante no hubiera cometido el error de provocar esa extraña degradación de rendimiento que motivó la investigación.
    Si agregamos una hipótesis dramática, quizá el atacante se asustó de la bomba nuclear informativa que estaba a punto de detonar y lo saboteó a propósito.
    Se puede odiar el resultado final y, al mismo tiempo, reconocer la complejidad del ataque.
  • No sé si “admirar” sea la palabra correcta, pero sí fue una operación bastante impresionante.