El ‘Dieselgate’ de los trenes: hacking pesado de hardware
(badcyber.com)- Los trenes Impuls 45WE de Newag en Polonia, tras mantenimiento independiente, no podían arrancar pese a diagnósticos normales, y el taller SPS encargó a Dragon Sector hacer ingeniería inversa de la computadora a bordo
- Los investigadores analizaron el bus CAN, extrajeron dumps de memoria basados en TriCore y mejoraron Ghidra hasta encontrar en el software flags de bloqueo y condiciones de arranque, con lo que lograron volver a poner en marcha los trenes
- En el código de algunos trenes había condiciones que impedían el arranque si permanecían más de 10 días en las coordenadas GPS de ciertos talleres, bloqueos por reemplazo de piezas, condiciones de falla después de 1 millón de km y reportes de falla del compresor basados en la fecha
- En total se analizaron 29 trenes, y en todos menos 5 se encontraron “sorpresas” fuera de las directrices oficiales de operación; el problema se extendió a varias regiones como Wrocław, Opole, Krakow, Szczecin y Warsaw
- El caso derivó en demandas e investigaciones de las fuerzas del orden, pero no se ha confirmado ninguna acción concreta por parte de las autoridades de protección al consumidor, competencia o transporte ferroviario
Los trenes Newag Impuls se detuvieron tras el mantenimiento
- El caso comenzó en la primavera de 2022, cuando el primero de los 11 trenes Impuls 45WE fabricados por Newag y operados por Lower Silesian Railways no pudo arrancar tras completar el mantenimiento obligatorio de 1 millón de km
- El trabajo quedó a cargo del taller independiente Serwis Pojazdów Szynowych(SPS)
- Newag también participó en la licitación, pero la propuesta del fabricante era aproximadamente 750 mil dólares más cara
- SPS ganó el contrato con una oferta de alrededor de 5.5 millones de dólares por el mantenimiento de los 11 trenes
- SPS desmontó, inspeccionó y volvió a ensamblar los trenes siguiendo el manual de mantenimiento de unas 20 mil páginas proporcionado por el fabricante, pero aunque la computadora a bordo indicaba estado normal, el tren no se movía
- El inversor no suministraba voltaje al motor, y los técnicos de mantenimiento no pudieron encontrar la causa solo con el manual y las revisiones eléctricas y mecánicas
Paros repetidos y riesgo contractual en aumento
- El segundo tren también se detuvo del mismo modo tras el mismo mantenimiento, y el fabricante Newag se negó a ayudar
- El tercer tren no pudo ser inspeccionado por un problema de batería, así que el cuarto entró al taller en su lugar
- Cuando conectaron un tren en operación normal al tren detenido, el tren que sí funcionaba también se paró
- La causa de esto todavía no se ha confirmado
- En otro taller de Szczecin también se dieron casos de trenes Impuls que no arrancaban después del mantenimiento
- Con 6 formaciones largas fuera de servicio en Lower Silesian Railway, hubo recortes de horario, entrada de trenes sustitutos y saturación en formaciones más cortas
- Newag explicó que los trenes habían sido bloqueados por un “sistema de seguridad”, pero en el manual de 20 mil páginas no había ninguna mención de ese sistema
- Por cada tren detenido en el taller, SPS enfrentaba penalizaciones contractuales de más de 1,000 dólares por día, lo que elevó la presión financiera
La ingeniería inversa de Dragon Sector
- SPS buscó “Polish hackers”, encontró a Dragon Sector, conocido por los CTF, y ambas partes firmaron un contrato
- En el proyecto participaron Michał “Redford” Kowalczyk, Sergiusz “q3k” Bazański y Kuba “PanKleszcz” Stępniewicz
- Redford y q3k eran conocidos por hackear laptops Toshiba
- Kuba tenía experiencia en automatización industrial
- En sitio, los investigadores recibieron un tren inmóvil, 2 computadoras de repuesto y archivos SDK del fabricante de la computadora
- El análisis inicial comenzó interviniendo el bus CAN, pero sin documentación del protocolo era difícil interpretar el tráfico
- El SDK solo permitía subir software nuevo y no tenía función para extraer el software existente
- Cuando cargaron una versión antigua del software en la primera computadora de repuesto que encontraron, esa computadora dejó de responder
- Los investigadores continuaron el trabajo con la única computadora de repuesto restante
- Al final encontraron una interfaz de depuración y descargaron la memoria del dispositivo byte por byte
- La computadora a bordo estaba basada en la arquitectura TriCore, también usada en el sector automotriz, y como faltaban buenos desensambladores, mejoraron parcialmente Ghidra para analizar el código
Las condiciones de arranque encontradas justo antes del plazo límite
- Tras aproximadamente un mes y medio, Lower Silesian Railway ya no podía esperar más y decidió colaborar con Newag para reparar y dar mantenimiento a los trenes averiados
- Se esperaba que el contrato con SPS se cancelara una semana después, así que los investigadores tenían que mostrar resultados dentro del tiempo restante
- Compararon las imágenes de memoria de computadoras de trenes sanos y averiados
- Como cada tren tenía distintos conjuntos de funciones y versiones de software, la comparación simple era difícil
- Encontraron diferencias donde valores configurados en algunos trenes aparecían en 0 en otros
- Como era posible encender por un momento la computadora fuera del tren y verificar el estado de preparación del inversor, se podían hacer pruebas sobre escritorio
- Cuando faltaba menos de un día para el plazo, encontraron una configuración de flags que podía permitir mover el tren, pero durante los experimentos se quemó un capacitor de la última computadora a bordo que aún funcionaba
- Después de intentar combinar 2 computadoras dañadas, repararon la que se había quemado y a las 2 de la madrugada la configuraron para arrancar el tren
- Un investigador llevó esa computadora al taller, pero el tren se retrasó y, al conectarla en sitio, al principio el tren tampoco arrancó
- Tras más discusión, encontraron un flag faltante y a las 8:42 a. m. lograron encender el tren
- A las 9:30 a. m., una delegación de Lower Silesian Railway confirmó que el tren podía volver a funcionar y no canceló el contrato con SPS
Condiciones de bloqueo ocultas en el código
- Tras meses de análisis e ingeniería inversa, se encontraron en varios softwares de trenes suministrados por Newag condiciones que provocaban una imposibilidad repentina de operar
- Números como
53.13845,17.99011en el código eran coordenadas GPS y apuntaban a instalaciones de PESA cerca de la estación Bydgoszcz Główny Railway Station - Más tarde también se encontraron coordenadas de otros talleres en Polonia capaces de hacer mantenimiento y reparaciones
- El código incluía una condición que desactivaba la capacidad de arranque si el tren permanecía al menos 10 días dentro de una de ciertas zonas de taller
- Una de esas coordenadas correspondía a un taller de Newag
- Para las coordenadas del taller de Newag se había definido otra lógica, y se presume que era con fines de prueba
- En otros trenes también se encontraron condiciones de bloqueo adicionales
- Si se reemplazaban ciertas piezas, el tren se bloqueaba verificando el número de serie del componente
- Había una opción para desbloquearlo presionando cierta secuencia de botones en la cabina y en la pantalla de la computadora a bordo
- Después de que la prensa informara sobre el arranque exitoso del Impuls, los trenes recibieron una actualización de software que eliminó esta opción de “fix”
- En otros trenes se encontró código que ordenaba “fallar” después de 1 millón de km
Reporte de falla del compresor activado por condición de fecha
- Otro tren se negó a funcionar el 21 de noviembre de 2022, aunque no estaba en mantenimiento
- La computadora reportó una falla del compresor, pero los técnicos consideraron que el compresor no tenía ningún problema
- El análisis del código reveló la siguiente condición
- si el día es 21 o mayor
- y el mes es 11 o mayor
- y el año es 2021 o mayor
- entonces reporta una falla del compresor
- Ese tren originalmente estaba programado para mantenimiento en noviembre de 2021, pero en realidad entró antes al taller y no volvió al servicio hasta enero de 2022
- En noviembre de 2021 la condición no se activó por casualidad, y solo el 21 de noviembre de 2022 se cumplieron finalmente las condiciones de falla previstas
Dispositivo de conexión GSM hallado en el hardware
- No solo en el software: también se encontró un dispositivo inusual en el hardware
- En una composición de tren, los investigadores encontraron un dispositivo marcado como “UDP<->CAN converter”
- Parecía ser un equipo para comunicarse con el tren de forma remota
- Al retirarlo, no se interrumpió ninguna función necesaria para operar
- La computadora a bordo enviaba a ese dispositivo información sobre el estado de bloqueo, y el propio dispositivo estaba conectado a un módem GSM
El problema se extendió a varias regiones y la escala del análisis
- La noticia de que SPS había arreglado los trenes “averiados” de Newag se propagó a otras empresas, y quedó claro que problemas similares eran comunes
- En Wrocław se analizaron 13 trenes Impuls
- También se confirmaron trenes con problemas en otras regiones
- 1 de Kolej Mazowieckie
- 2 en Opole
- 4 en Krakow
- 1 en Zielona Góra
- 4 en Szczecin
- 1 en Warsaw
- La herramienta creada por los investigadores eliminó los bloqueos por software de las computadoras a bordo, y cada tren pudo ser reparado
- Se analizó el software de 29 trenes en total, y en todos menos 5 se encontraron elementos fuera de las directrices oficiales de operación
Medidas posteriores y alcance de la divulgación
- Hay litigios en curso sobre este asunto
- No se sabe si la Office of Consumer and Competition Protection de Polonia o la Railway Transport Office han tomado medidas concretas
- Los investigadores notificaron sus hallazgos a CERT Polska
- CERT Polska informó a las “autoridades pertinentes”
- El caso está siendo tratado por las fuerzas del orden
- Este contenido es un resumen breve de la presentación realizada el 5 de diciembre de 2023 en la conferencia Oh My H@ck por Jakub Stępniewicz, Sergiusz Bazański y Michał Kowalczyk
- El texto original omitió una parte considerable del análisis técnico completo y expresó su expectativa de que los investigadores publiquen un documento técnico por separado
1 comentarios
Comentarios de Hacker News
También hay una publicación reciente relacionada: Polish trains lock up when serviced in third-party workshops - https://news.ycombinator.com/item?id=38530885 - diciembre de 2023, 347 comentarios
Es absurdo que hayan sido así de descarados. Código para dejar una locomotora convertida en un ladrillo si las coordenadas GPS permanecen más de 10 días dentro de las instalaciones de un taller competidor
Esto va muchísimo más allá de interfaces no documentadas o firmware firmado criptográficamente para dificultar las reparaciones; me parece más cercano a la destrucción maliciosa de propiedad. No conozco el sistema legal polaco, pero no puedo imaginar cómo algo así podría quedar impune
Los trenes ya existen y tienen que seguir operando, pero las empresas de mantenimiento y reparación no pueden modificar legalmente el software por temas de copyright. Es un callejón sin salida total. Ojalá esa empresa reciba una multa enorme y hasta sanciones penales, pero dudo que realmente pase
Un equipo legal con iniciativa probablemente podría encontrar cargos graves aplicables. Más aún si esos trenes o locomotoras cuentan como infraestructura crítica, aunque eso no está garantizado
Hay una gran diferencia entre meter un apretón de manos secreto y documentar mal los procedimientos para hacer que la competencia parezca incompetente, y dañar intencionalmente tu propio producto solo porque entró al taller de un competidor
El título puede prestarse un poco a confusión. El “gate” en este caso no es como Dieselgate, donde se engañó sobre lo ecológico para pasar certificaciones bajo condiciones artificiales, sino que aquí se simuló una falla falsa
La empresa hardcodeó un algoritmo que, basándose en la ubicación, si concluía que otra empresa había reparado el tren, reportaba como averiadas piezas que en realidad funcionaban bien, como el compresor, y detenía la operación del tren
Claro, los dos casos no son exactamente iguales, pero se entiende por qué surgió esa comparación
Una fue dejar inoperable el tren después de pasar 10 días en un sitio de mantenimiento de la competencia según el GPS. La otra fue hardcodear, en cierto firmware, que pareciera ocurrir una falla del compresor unos días después del siguiente mantenimiento programado
La peor parte es la de “en Polonia es difícil encontrar una institución que haya hecho algo más que expresar interés cortés por este asunto. Tampoco se sabe qué medidas han tomado la oficina de protección al consumidor y la competencia ni la autoridad de transporte ferroviario”
Las agencias de protección al consumidor no tienen tanto poder como esas instituciones
También vale la pena revisar la discusión de la publicación anterior del artículo relacionado: https://news.ycombinator.com/item?id=38530885
La solución a problemas extraños de control de motor, como manipular pruebas de emisiones o bloquear reparaciones de terceros, quizá sea estandarizar las interfaces de estos sistemas
Si las salidas de los sensores se estandarizan, se pueden intercambiar varios componentes y comprobar si el sistema está engañando a los reguladores
[1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
Tengo un amigo con un WRX que no tiene catalizador, además trae un turbo grande y está tuneado, así que jamás debería pasar una prueba de emisiones. Pero como se sintetizan los datos de los sensores y se controla esa parte, no hay códigos de error y pasa cada vez sin problemas
Sería bueno eliminar ese agujero negro que es el firmware y permitir auditorías
No hace falta una estandarización total; con apertura bastaría. Aun así, en esencia esa es la dirección correcta
Parece que usaron software para obstruir deliberadamente que la gente recurriera a servicios de terceros más baratos en lugar del servicio del fabricante
Me interesa ver qué decide la corte
Es un problema que legisladores, tribunales y el público se pierdan ante cuestiones técnicas, pero este delito encaja bastante bien en los tipos penales ya existentes sobre obstrucción. El método será “nuevo”, pero el crimen en sí es clásico
La calidad del firmware de los trenes en general da la impresión de no ser muy buena, y ojalá este escándalo lleve a revisiones más estrictas
Hace 3 años, Deutsche Bahn se quejó públicamente de problemas de software “extraños” en trenes Bombardier recién entregados. Por ejemplo, cuando el maquinista cambiaba el sentido de marcha, el software del tren se colapsaba, y reiniciarlo tomaba 1 hora [0]. Suiza también tuvo un problema similar en 2018 [1]
Como informático, esto da vergüenza. Basta compararlo con los viejos trenes de Alemania Oriental de los años 1980 [2] que hasta hace poco arrastraban coches de pasajeros de Alemania Occidental de los años 1950 [3] aquí. Tenían muy poca electrónica digital o ninguna, y tampoco había tiempo de arranque. Simplemente funcionaban. Y si no funcionaban, el maquinista normalmente sabía en qué parte del motor había que darle con un martillo para arreglarlo. No se puede esperar que un maquinista hackee el firmware del tren y abra
gdbpara averiguar por qué no se mueve[0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
[1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
[2] https://de.wikipedia.org/wiki/DR-Baureihe_243
[3] https://de.wikipedia.org/wiki/N-Wagen
Las empresas que fabrican cosas con software no están en un mercado dispuesto a pagarle al personal de software 2 o 3 veces lo de antes. Lo que queda son quienes aceptan esa diversión como parte de la compensación total, y quienes no lograron entrar a trabajos que pagan más. La mayoría de los sistemas críticos para la seguridad que usamos los construye gente así. Si comparas la compensación de desarrolladores en X y en SpaceX, se ve cómo funciona el mercado. La diversión también entra en la compensación total, pero eso también produce que personas que no necesariamente son buenos desarrolladores terminen virando a diseñar nuevos procesos y herramientas en este ámbito. Podrían aferrarse a la moda full-stack, que ya pasó su mejor momento, e intentar aplicarla al firmware de trenes. Hay 10 veces más texto en Jira que en Git, hacen desarrollo scrum-cascada, y no sorprendería que estén metiendo REST API o arquitectura orientada a servicios en sistemas embebidos críticos para la seguridad
Salvo algo como Beckhoff Tc3, todavía ni siquiera han llegado a la orientación a objetos, y todo el sector sigue atrapado en las minas de pantallazos azules del pasado. Gestionan la complejidad con documentos de estándares delgados, no tienen control de versiones, y aun así las máquinas se vuelven cada vez más complejas del lado de sensores y actuadores. No se puede tratar una máquina moderna como si fuera un pequeño dispositivo embebido de hobby, pero la industria lo hace. A veces programadores externos entran, ganan buen dinero resolviendo problemas de ayer con una arquitectura de software decente y prácticas de desarrollo en C. Pero la industria no aprende de eso. Para ellos, desarrollar software nunca será una profesión especializada
Muchos trenes modernos sufren problemas de software de conducción básica [0] y demoras en la aprobación del software [1]. Pero creo que el peor retroceso es la pérdida de compatibilidad. Los trenes eléctricos modernos en la práctica solo funcionan juntos con unidades del mismo lote. Incluso si son del mismo modelo, si dos empresas los encargan por separado muchas veces no son compatibles entre sí, y casi hay que rendirse con la idea de usar juntos trenes de empresas distintas o encargados con más de 10 años de diferencia. En cambio, antes de lo digital era común usar juntos tranvías de generaciones distintas y adaptar el cableado para hacerlos compatibles. Los coches antiguos funcionan juntos sin problemas, pero usar en conjunto IC2 y Railjet, o RailJet e ICE-L, no es nada fácil. También había muchos casos en los que solo ciertas locomotoras y ciertos coches funcionaban entre sí
Entre sistemas computarizados, la complejidad y la opacidad son mucho mayores, así que es bastante más difícil hacer que funcionen juntos. Las placas de circuitos lógicos tradicionales por lo general se pueden hacer ingeniería inversa con relativa facilidad, pero la ingeniería inversa de software es un trabajo muy especializado. Este fenómeno también se nota mucho en otros sectores donde el paso a protocolos digitales propietarios ha empeorado bastante la interoperabilidad
Esto se debe en parte a que el software, por su opacidad, es más difícil de aprobar que las tecnologías anteriores, pero también hay una falta real de calidad. Una de las razones por las que Bombardier se metió en un gran problema fue su mal software, al punto de que se canceló un contrato de más de 40 unidades ([2])
Creo que hacer software confiable y comprensible es mucho más difícil que construir circuitos lógicos o sistemas mecánicos. No sé cuál sea la solución, pero es un problema de hace mucho tiempo
[0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn...
[1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf...
[2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB
Solo consumo contenido en inglés. Del contenido de otros países solo termino viendo lo que se filtra a través de los grandes medios.
Me hace preguntarme cuánto buen contenido habrá que podría traducirse
Pero el inglés, al menos en las partes más educadas del mundo, irónicamente ya se ha convertido en una lengua franca, y mucha gente que se siente más cómoda en su lengua materna igual traduce su mejor trabajo al inglés para que lo lea más gente. Los artículos científicos son un ejemplo claro. Quizá el mayor regalo que el Reino Unido le dio al mundo fue el inglés
Pero me enteré de todo este asunto de la dependencia del proveedor de esos trenes por primera vez en HN. Si no, quizá nunca me habría enterado, o lo habría hecho semanas o meses después