Por Canuto  

Una semana de pruebas sobre una Prusa MK4S llevó al ingeniero Yannick Dixken a identificar cerca de 23 defectos en el firmware Buddy y a demostrar una ejecución remota de código con un Rickroll. Prusa coordinó con él la divulgación y, según el reporte, las vulnerabilidades ya están corregidas en versiones del firmware posteriores a la 7.0.0.
***

  • Yannick Dixken reportó 14 hallazgos que sumaban aproximadamente 23 defectos tras una semana de análisis con Opus 4.8 y un fuzzer.
  • La falla más grave permitía que el controlador principal de la impresora ejecutara código enviado por red mediante Prusa Connect.
  • El fabricante coordinó la respuesta tras recibir la divulgación, y las vulnerabilidades están parcheadas en firmware Buddy posterior a la versión 7.0.0.

Una semana de pruebas y un hallazgo remoto

Una impresora 3D Prusa MK4S terminó protagonizando un Rickroll después de que un ingeniero de software demostrara que podía ejecutar código a distancia en el equipo. Yannick Dixken dedicó una semana a probar la seguridad del dispositivo y reportó 14 hallazgos, que en conjunto correspondían a aproximadamente 23 defectos individuales. El resultado no fue solo una demostración llamativa: la cadena de fallas culminó con el controlador principal de la impresora ejecutando código que Dixken le envió por la red.

El investigador publicó el video de prueba y sus resultados en coordinación con Prusa, según informó Tom’s Hardware. En su blog, titulado “Never gonna print you up!”, Dixken describió la demostración como una ejecución remota de código, conocida por las siglas RCE, y explicó que el efecto visible fue hacer que la impresora reprodujera el conocido Rickroll. El video sirvió para mostrar una consecuencia concreta de la vulnerabilidad, aunque el hallazgo principal era la capacidad de enviar instrucciones al controlador.

Dixken indicó que trabajó con Opus 4.8 y un fuzzer, además de recurrir a depuración e ingeniería inversa. La combinación le permitió examinar el comportamiento del firmware y localizar fallas en un periodo relativamente breve, pero el reporte no atribuye el descubrimiento exclusivamente a la inteligencia artificial: el análisis también incluyó técnicas de investigación de seguridad aplicadas por el propio ingeniero. El uso de estas herramientas aparece como parte de su metodología, no como sustituto de la verificación técnica.

El hallazgo más grave recibió una puntuación de 8,1 y fue clasificado oficialmente como de severidad alta. La noticia no precisa el sistema de puntuación utilizado ni aporta un identificador de vulnerabilidad, por lo que la cifra debe leerse tal como fue reportada, sin equipararla automáticamente a una escala específica. Sí señala dónde estaba la falla: en Prusa Connect, la plataforma de gestión que puede utilizarse en la nube o instalarse en modalidad autohospedada.

La cadena de fallas y sus posibles efectos

La ejecución remota de código ocurre cuando una vulnerabilidad permite que un atacante haga ejecutar instrucciones en un sistema desde otro dispositivo, en este caso a través de la red. El reporte describe una cadena que terminó en el controlador principal de la MK4S, pero no detalla las condiciones necesarias para explotarla ni afirma que se haya utilizado contra impresoras de otros usuarios. Por eso, la demostración confirma el riesgo técnico sin establecer que hubiera ocurrido un ataque real contra clientes.

Además de la RCE, la revisión encontró problemas en varias áreas del firmware Buddy. Entre ellos figuran un ataque relacionado con nombres de archivos en unidades USB, desbordamientos de heap provocados por archivos de impresión cifrados mal formados y fallas de denegación de servicio en la red. Son categorías distintas: una afecta el manejo de nombres, otra puede alterar la memoria durante el procesamiento y la tercera puede interrumpir la disponibilidad de funciones de red.

La variedad de defectos importa porque una impresora conectada no es únicamente un mecanismo que mueve piezas y deposita material. También procesa archivos, interactúa con almacenamiento extraíble y recibe comunicaciones mediante servicios de red, de modo que errores en esas rutas pueden tener consecuencias diferentes. En este caso, el material disponible no afirma que todas las fallas permitieran tomar control del equipo; la posibilidad de ejecutar código a distancia corresponde al hallazgo destacado, mientras que las otras se describen como vulnerabilidades independientes.

Dixken observó que varios errores podían estar asociados al uso de sentencias assert, empleadas por desarrolladores para imponer ciertas suposiciones sobre el comportamiento del programa. Si una condición asumida no se cumple, el software puede reaccionar de forma inesperada, aunque el reporte no atribuye cada uno de los defectos a ese patrón. La observación apunta a una posible fuente común de problemas, no a una explicación confirmada para todos los hallazgos identificados durante la semana de pruebas.

Divulgación coordinada y correcciones

La respuesta de Prusa fue parte central de la divulgación. Dixken dijo que, dentro de las 24 horas posteriores a compartir el video del Rickroll en redes sociales, el equipo de la empresa coordinó con él de forma profesional, eficiente y amable. Esa rapidez describe la experiencia que relató el investigador y no permite inferir por sí sola cómo se gestionan todos los reportes de seguridad de la compañía, pero sí da cuenta de la colaboración en este caso.

Según el reporte, todas las vulnerabilidades ya están corregidas en las versiones del firmware Buddy posteriores a la 7.0.0. La recomendación práctica para quienes usan una impresora Prusa es comprobar que el equipo tenga una versión dentro de ese rango corregido y mantener el firmware actualizado. La información publicada no identifica versiones concretas posteriores ni detalla el procedimiento de actualización, por lo que no conviene deducir números de compilación que no aparecen en el reporte.

El caso también ilustra por qué la divulgación coordinada puede reducir el tiempo entre el hallazgo y la corrección. El investigador comunicó sus resultados al fabricante y publicó la demostración en coordinación con la empresa, lo que permitió presentar el problema junto con el estado de los parches. Sin embargo, una respuesta rápida en una investigación no elimina la necesidad de revisar y actualizar los dispositivos: las correcciones solo protegen a los usuarios que instalan firmware que ya las incluye.

Dixken se describió como arquitecto cloud freelance e ingeniero de DevOps y plataformas, y señaló que la investigación de seguridad es una afición. En una semana de trabajo, su examen de una impresora propia pasó de la depuración y el fuzzing a una demostración de ejecución de código por red, además de descubrir otros defectos relacionados con archivos, USB y conectividad. El episodio combina una presentación humorística con un asunto serio: los equipos conectados también necesitan auditorías y procesos de actualización eficaces.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados