Una contraseña publicada por error expuso el código fuente de Mercedes-Benz
Un token de autenticación filtrado en un repositorio público de GitHub habría dado acceso a un amplio código fuente y secretos internos de Mercedes-Benz, lo que encendió las alarmas sobre la higiene básica de seguridad en un gran fabricante de automóviles. Los comentaristas debaten la ética y los riesgos de informar estas vulnerabilidades directamente o a través de periodistas, especialmente bajo las restrictivas leyes alemanas contra el hackeo. El incidente también alimenta preocupaciones más amplias sobre cómo se desarrolla el software automotriz crítico para la seguridad, si debería ser de código abierto o estar más estrictamente regulado, y por qué los grandes fabricantes siguen teniendo dificultades para gestionar credenciales y prácticas de desarrollo seguras.
Divulgación responsable y riesgo legal
- Debate sobre por qué el investigador acudió a TechCrunch en lugar del contacto de seguridad publicado por Mercedes.
- Algunos ven la implicación de los medios como una búsqueda de notoriedad y un aumento innecesario del riesgo para Mercedes.
- Otros sostienen que, incluso con programas de bug bounty o de divulgación de vulnerabilidades, las empresas aún pueden reaccionar con amenazas legales, especialmente en jurisdicciones como Alemania, donde informar sobre vulnerabilidades ha llevado a multas y exposición penal.
- Los periodistas son vistos tanto como una posible protección para las fuentes como como una responsabilidad, ya que implicar a la prensa ha sido citado en sí mismo como “daño” en casos alemanes.
Código abierto / Transparencia para el software automotriz
- Un sector importante sostiene que el software automotriz (y otro software crítico para la seguridad) debería ser de código abierto o al menos con el código fuente disponible, para auditoría pública o profesional y para evitar la “seguridad por oscuridad”.
- Otros responden que el código abierto por sí solo no garantiza revisión; una auditoría seria requiere incentivos, habilidades y a menudo firmas profesionales.
- Preocupa que permitir por completo modificaciones al software de control del coche pueda crear pesadillas de seguridad y responsabilidad; la comparación con las “modificaciones inseguras” físicas existentes muestra que ya toleramos cierto riesgo y lo regulamos mediante inspecciones.
- El derecho a reparar y el control del propietario sobre los vehículos son temas recurrentes; algunos proponen empezar con modelos opcionales “trasteables” en lugar de mandatos universales.
Gestión de secretos y cultura de software de Mercedes
- Muchos se alarman de que los repositorios contuvieran contraseñas, claves de API, tokens SSO y documentos de diseño, calificándolo por debajo incluso de la higiene de un desarrollador junior.
- Explicaciones ofrecidas: cultura heredada de la ingeniería mecánica, falta de prácticas modernas de software/seguridad, dependencia excesiva de repos privados y de la seguridad del endpoint.
- Los comentaristas señalan que esto es común en muchos sectores; los secretos en texto plano aparecen en la mayoría de las consultorías.
- Múltiples menciones a gestores de secretos y al escaneo de secretos de GitHub, y especulación de que esos controles no se adoptaron o no se aplicaron.
- Algunos culpan más a la falta de responsabilidad y de cultura de seguridad que a los desarrolladores individuales.
Piezas de repuesto, claves de firma y control del mercado
- Especulación sobre si se filtró alguna clave criptográfica usada para autenticar piezas genuinas, lo que podría debilitar el control de los fabricantes sobre el mercado posventa.
- Debate sobre los elevados márgenes de los OEM en componentes genéricos y nostalgia por los modelos antiguos de Mercedes con mejor soporte de piezas e ingeniería.
Experiencias de usuarios con el software del coche y la seguridad
- Frustración con la UX moderna de Mercedes y la fiabilidad del software, descrito como “poco fiable y a veces peligroso”.
- Anécdotas de sistemas de asistencia al conductor tanto de Mercedes como de Tesla comportándose de forma impredecible o peligrosa, lo que sugiere desafíos en toda la industria.
Observaciones generales de seguridad
- Varios señalan que la exposición de claves, credenciales y documentos internos es mucho más grave que la filtración del código fuente por sí sola.
- Se enfatiza que las contraseñas y los tokens acabarán filtrándose tarde o temprano, por lo que las arquitecturas deben asumir la компромiso y evitar “puertas” de una sola cadena para activos críticos.