‘Dieselgate’ versão ferroviária – hacking pesado de hardware
(badcyber.com)- Os trens Impuls 45WE da polonesa Newag, após manutenção independente, não conseguiam partir apesar do diagnóstico normal, e a oficina SPS contratou a Dragon Sector para fazer engenharia reversa do computador de bordo
- Os pesquisadores analisaram o barramento CAN, extraíram dumps de memória baseados em TriCore, aprimoraram o Ghidra e encontraram no software flags de bloqueio e condições de partida, fazendo os trens voltarem a operar
- Em parte do código dos trens havia condições que impediam a partida se eles permanecessem por mais de 10 dias nas coordenadas GPS de determinadas oficinas, além de bloqueios após troca de peças, condição de falha após 1 milhão de km e condição de reporte de falha do compressor baseada em data
- O total analisado foi de 29 trens e, exceto por 5 deles, foram encontradas “surpresas” fora das diretrizes oficiais de operação, com o problema se espalhando por várias regiões como Wrocław, Opole, Krakow, Szczecin e Warsaw
- O caso evoluiu para processos judiciais e investigação por órgãos de aplicação da lei, mas não há confirmação de medidas concretas por parte das autoridades de proteção ao consumidor e à concorrência ou do órgão de transporte ferroviário
Trens Newag Impuls parados após manutenção
- O caso começou na primavera de 2022, quando o primeiro de 11 trens Impuls 45WE fabricados pela Newag e operados pela Lower Silesian Railways não conseguiu partir após concluir a manutenção obrigatória de 1 milhão de km
- A manutenção foi feita pela oficina independente Serwis Pojazdów Szynowych(SPS)
- A Newag também participou da licitação, mas a proposta do fabricante era cerca de 750 mil dólares mais cara
- A SPS venceu com a condição de realizar a manutenção dos 11 trens por cerca de 5,5 milhões de dólares
- A SPS desmontou, inspecionou e remontou os trens conforme o manual de manutenção de cerca de 20 mil páginas fornecido pelo fabricante, mas os trens não se moviam mesmo quando o computador de bordo indicava estado normal
- O inversor não fornecia tensão ao motor, e os técnicos de manutenção não conseguiram encontrar a causa apenas com o manual e as inspeções elétricas e mecânicas
Paradas repetidas e risco contratual crescente
- O segundo trem também parou da mesma forma após a mesma manutenção, e a fabricante Newag se recusou a ajudar
- O terceiro trem perdeu a inspeção por um problema na bateria, e o quarto trem entrou na oficina em seu lugar
- Quando o quarto trem, que operava normalmente, foi acoplado ao trem parado, o trem normal também parou
- A causa disso ainda não foi confirmada
- Em outra oficina em Szczecin também surgiram casos de trens Impuls que não davam partida após manutenção
- Com 6 composições longas da Lower Silesian Railway fora de operação, vieram redução de horários, uso de trens substitutos e lotação em composições mais curtas
- A Newag explicou que os trens tinham sido bloqueados por um “sistema de segurança”, mas não havia menção a esse sistema no manual de 20 mil páginas
- Cada trem parado na oficina gerava multa contratual de mais de 1.000 dólares por dia, aumentando a pressão sobre a SPS
A engenharia reversa da Dragon Sector
- A SPS procurou por “Polish hackers”, encontrou a Dragon Sector, conhecida por CTFs, e as duas partes firmaram contrato
- Participaram do projeto Michał “Redford” Kowalczyk, Sergiusz “q3k” Bazański e Kuba “PanKleszcz” Stępniewicz
- Redford e q3k são conhecidos por hackear notebooks da Toshiba
- Kuba tinha experiência em automação industrial
- No local, os pesquisadores receberam um trem que não se movia, dois computadores sobressalentes e arquivos SDK do fabricante do computador
- A análise inicial começou com tapping do barramento CAN, mas sem documentação do protocolo era difícil interpretar o tráfego
- O SDK só permitia enviar software novo e não tinha função para extrair o software existente
- Quando carregaram uma versão antiga de software que haviam encontrado no primeiro computador sobressalente, esse computador parou de responder
- Os pesquisadores continuaram o trabalho com o único computador sobressalente restante
- No fim, encontraram a interface de depuração e baixaram a memória do dispositivo byte a byte
- O computador de bordo era baseado na arquitetura TriCore, também usada no setor automotivo, e como faltava um bom disassembler, eles aprimoraram parcialmente o Ghidra para analisar o código
As condições de partida encontradas no limite do prazo
- Depois de cerca de um mês e meio, a Lower Silesian Railway decidiu que não podia esperar mais e optou por cooperar com a Newag no reparo e na manutenção dos trens com falha
- A rescisão do contrato com a SPS era esperada para uma semana depois, e os pesquisadores precisavam mostrar resultados no tempo restante
- Os pesquisadores compararam as imagens de memória dos computadores de trens normais e trens com falha
- Como cada trem tinha conjunto de recursos e versão de software diferentes, a comparação simples era difícil
- Eles encontraram diferenças em que certos valores definidos em alguns trens apareciam como 0 em outros
- Mesmo com o computador removido do trem, era possível ligá-lo por um curto tempo e verificar o estado de prontidão do inversor, o que permitia testes em bancada
- Faltando menos de um dia para o prazo final, encontraram uma configuração de flags que poderia fazer o trem voltar a se mover, mas durante os testes o capacitor do último computador de bordo funcional queimou
- Depois de tentar combinar duas unidades danificadas, conseguiram consertar o computador queimado e configurá-lo para dar partida no trem às 2 da manhã
- Um pesquisador levou o computador até a oficina, mas o trem atrasou, e mesmo após conectar o computador no local o trem não partiu de início
- Após mais discussões, encontraram uma flag ausente e conseguiram dar partida no trem às 8h42 da manhã
- Às 9h30, a comitiva da Lower Silesian Railway confirmou que havia possibilidade de recuperar o trem, e o contrato com a SPS não foi rescindido
Condições de bloqueio escondidas no código
- Meses de análise e engenharia reversa revelaram, em vários softwares de trens fornecidos pela Newag, condições que provocavam perda repentina de operabilidade
- Números como
53.13845,17.99011presentes no código eram coordenadas GPS e apontavam para um terreno da PESA perto da estação Bydgoszcz Główny - Depois, também foram encontradas coordenadas de outras oficinas na Polônia capazes de fazer manutenção e reparos
- O código incluía uma condição que desativava a capacidade de partida se o trem permanecesse em uma dessas áreas de oficina específica por pelo menos 10 dias
- Uma das coordenadas era da própria oficina da Newag
- Para as coordenadas da oficina da Newag, havia outra lógica definida, provavelmente para fins de teste
- Em outros trens também foram encontradas condições separadas de bloqueio
- Se determinada peça fosse substituída, o trem era bloqueado por verificação do número de série da peça
- Havia uma opção para desbloquear pressionando uma sequência específica de botões na cabine e na tela do computador de bordo
- Depois que a imprensa noticiou o sucesso na partida do Impuls, os trens receberam uma atualização de software que removia essa opção de “fix”
- Em outros trens foi encontrado código instruindo a “falha” após 1 milhão de km
Falha do compressor reportada por condição de data
- Outro trem se recusou a operar em 21 de novembro de 2022, mesmo não estando em manutenção
- O computador reportou falha do compressor, mas os técnicos avaliaram que não havia problema no compressor
- A análise do código revelou a seguinte condição
- se o dia for 21 ou maior
- e o mês for 11 ou maior
- e o ano for 2021 ou maior
- então reportar falha do compressor
- Esse trem estava originalmente programado para manutenção em novembro de 2021, mas na prática entrou em manutenção mais cedo e só voltou em janeiro de 2022
- Em novembro de 2021 a condição não foi acionada por acaso, e só em 21 de novembro de 2022 a condição planejada de falha foi satisfeita
Dispositivo de conexão GSM encontrado no hardware
- Não só no software, mas também no hardware foram encontrados dispositivos incomuns
- Em um conjunto de trens, os pesquisadores encontraram um dispositivo marcado como “UDP<->CAN converter”
- Parecia ser um dispositivo para permitir comunicação remota com o trem
- Mesmo removendo o dispositivo, nenhuma função essencial deixava de operar
- O computador de bordo enviava informações sobre o estado de bloqueio para esse dispositivo, e o próprio dispositivo estava conectado a um modem GSM
Problema espalhado por várias regiões e escala da análise
- A notícia de que a SPS havia consertado os trens “com falha” da Newag se espalhou para outras empresas, e ficou claro que problemas parecidos eram comuns
- Em Wrocław, foram analisados 13 trens Impuls
- Em outras regiões também foram identificados trens com problemas
- 1 da Kolej Mazowieckie
- 2 de Opole
- 4 de Krakow
- 1 de Zielona Góra
- 4 de Szczecin
- 1 de Warsaw
- A ferramenta criada pelos pesquisadores removia os bloqueios de software do computador de bordo, e cada trem podia ser reparado
- O software de 29 trens foi analisado ao todo, e em todos, exceto 5, foram encontrados elementos fora das diretrizes oficiais de operação
Medidas posteriores e escopo da divulgação
- Há processos judiciais em andamento sobre o caso
- Não se sabe se o Office of Consumer and Competition Protection ou o Railway Transport Office da Polônia tomaram medidas concretas
- Os pesquisadores notificaram a CERT Polska sobre as descobertas
- A CERT Polska informou as “autoridades relevantes”
- O caso está sendo tratado pelas autoridades policiais
- Este conteúdo é um resumo breve da apresentação feita por Jakub Stępniewicz, Sergiusz Bazański e Michał Kowalczyk na conferência Oh My H@ck em 5 de dezembro de 2023
- O texto original omitiu boa parte da análise técnica completa e expressa a expectativa de que os pesquisadores publiquem um documento técnico separado
1 comentários
Opiniões no Hacker News
Há também um post recente relacionado: Polish trains lock up when serviced in third-party workshops - https://news.ycombinator.com/item?id=38530885 - dezembro de 2023, 347 comentários
É inacreditável que sejam tão descarados assim. Código que transforma uma locomotiva em um tijolo se as coordenadas de GPS permanecerem por mais de 10 dias dentro da área de uma oficina concorrente
Isso vai muito além de dificultar reparos com interfaces não documentadas ou firmware assinado criptograficamente; parece mais destruição maliciosa de propriedade. Não conheço o sistema jurídico polonês, mas não consigo imaginar como isso poderia passar batido
Os trens já existem e precisam operar, mas a empresa de manutenção e reparo não pode modificar legalmente o software por causa de direitos autorais. É um impasse total. Espero que essa empresa leve multas enormes e até punição criminal, mas tenho dúvidas se isso realmente vai acontecer
Acho que uma equipe jurídica motivada conseguiria encontrar acusações graves aplicáveis. Especialmente se esses trens ou locomotivas forem considerados infraestrutura crítica, embora isso não seja garantido
Uma coisa é inserir um handshake secreto e escrever documentação de procedimento ruim para fazer a concorrência parecer incompetente; outra, de outro nível, é quebrar intencionalmente o próprio produto porque ele entrou na oficina de um concorrente
O título é um pouco enganoso. O “gate” deste caso não é como o Dieselgate, em que se fraudava a ecologia para passar na certificação em condições artificiais; aqui foi a simulação de uma falha falsa
A empresa hardcodou um algoritmo que, se concluísse com base em dados de localização que outra empresa tinha consertado o trem, reportava uma falha em componentes que funcionavam normalmente, como o compressor, e interrompia a operação do trem
Claro que os dois casos não podem ser exatamente iguais, mas parece claro por que essa comparação foi feita
Uma é fazer o trem parar de funcionar depois de permanecer 10 dias, segundo o GPS, em um local de manutenção concorrente. A outra é hardcodar, em determinado firmware, uma falsa falha do compressor alguns dias depois da próxima manutenção programada
A pior parte é: “É difícil encontrar uma instituição na Polônia que tenha feito mais do que manifestar interesse educado sobre o assunto. Também não sei de nenhuma medida tomada pelo órgão de proteção ao consumidor e concorrência ou pela autoridade de transporte ferroviário”
Os órgãos de defesa do consumidor não têm tanto poder quanto essas instituições
Também vale conferir a discussão do post anterior sobre o artigo relacionado: https://news.ycombinator.com/item?id=38530885
Talvez a solução para problemas estranhos de controle de motor, como manipulação de testes de emissões e bloqueio de reparo por terceiros, seja a padronização das interfaces desses sistemas
Se a saída dos sensores for padronizada, será possível trocar vários componentes e verificar se o sistema não está enganando os reguladores
[1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
Tenho um amigo com um WRX que não tem catalisador, tem um turbo grande e ainda é remapeado, então nunca deveria passar em uma inspeção de emissões. Mas os dados dos sensores são sintetizados e controlam essa parte, então não há códigos de erro e ele passa sem problemas todas as vezes
Seria bom eliminar esse buraco negro chamado firmware e tornar auditorias possíveis
Não é necessária uma padronização completa; abertura já bastaria. Ainda assim, no fundo, essa é a direção certa
Parece que houve sabotagem intencional via software para impedir o uso de serviços de terceiros mais baratos em vez do serviço do fabricante
Estou curioso para ver a decisão do tribunal
É um problema que legisladores, tribunais e o público fiquem perdidos diante de questões técnicas, mas este crime deve se encaixar suficientemente bem nos tipos penais existentes relacionados a sabotagem. O método é “novo”, mas o crime em si é clássico
A impressão é que a qualidade do firmware dos trens, em geral, não é muito boa, e espero que este escândalo leve a uma revisão mais rigorosa
Há 3 anos, a Deutsche Bahn reclamou publicamente dos problemas de software “bizarros” nos trens Bombardier recém-entregues. Por exemplo, quando o maquinista mudava o sentido de marcha, o software do trem travava, e reinicializar levava 1 hora [0]. A Suíça também teve um problema parecido em 2018 [1]
Como cientista da computação, isso é constrangedor. Basta comparar com os trens antigos fabricados na Alemanha Oriental nos anos 1980 [2], que até recentemente puxavam por aqui vagões da Alemanha Ocidental dos anos 1950 [3]. Havia pouca ou nenhuma eletrônica digital, e não havia tempo de boot. Simplesmente funcionavam. Quando não funcionavam, o maquinista geralmente sabia em que parte do motor bater com um martelo para consertar. Não dá para esperar que o maquinista hackeie o firmware do trem e abra o gdb para descobrir por que ele não se move
[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
Empresas que fabricam coisas com software embarcado não estão em um mercado disposto a pagar 2 a 3 vezes mais do que antes pelo pessoal de software. O que sobra são pessoas que aceitam essa diversão como parte da diferença na remuneração total, e pessoas que não conseguiram empregos que pagam mais. A maioria dos sistemas críticos de segurança que usamos é feita por essas pessoas. Compare a remuneração de desenvolvedores na X e na SpaceX e dá para ver como o mercado funciona. Diversão também entra na remuneração total, mas isso também acaba levando pessoas que não são bons desenvolvedores a migrar para projetar novos processos e ferramentas nessa área. Elas podem se agarrar à moda full-stack que já passou e tentar aplicá-la ao firmware de trens. Não seria surpreendente se houvesse 10 vezes mais texto no Jira do que no Git, desenvolvimento scrumfall e REST APIs ou arquitetura orientada a serviços sendo colocadas em sistemas embarcados críticos de segurança
Com exceção de algo como o Tc3 da Beckhoff, ainda nem chegaram à orientação a objetos, e a área inteira está presa nas minas de telas azuis do passado. Gerenciam complexidade com documentos de normas finos, sem nem controle de versão, enquanto as máquinas ficam cada vez mais complexas em termos de sensores e atuadores. Não dá para tratar uma máquina moderna como um pequeno dispositivo embarcado de hobby, mas é o que a indústria faz. Programadores de fora às vezes entram, resolvem problemas de ontem com uma arquitetura de software decente e práticas de desenvolvimento em C, e ganham bom dinheiro. Mas a indústria não aprende com isso. Para eles, produzir software nunca será uma profissão especializada
Muitos trens modernos sofrem com problemas no software básico de operação [0] e atrasos na homologação de software [1]. Mas, para mim, o pior retrocesso é a perda de compatibilidade. Trens elétricos modernos, na prática, só funcionam em conjunto com trens elétricos do mesmo lote. Mesmo sendo o mesmo modelo, se duas empresas fizerem pedidos separados, muitas vezes eles não são compatíveis entre si; e usar em conjunto trens elétricos de empresas diferentes ou encomendados com mais de 10 anos de diferença é algo de que praticamente se deve desistir. Já antes do digital, era comum usar bondes de gerações diferentes em conjunto e adaptar a fiação para compatibilizá-los. Vagões antigos funcionam juntos sem problema, mas não é fácil usar IC2 com Railjet, ou RailJet com ICE-L. Muitas vezes também só determinadas locomotivas e vagões funcionavam juntos
Entre sistemas computadorizados, a alta complexidade e a opacidade tornam muito mais difícil fazê-los funcionar juntos. Placas de circuitos lógicos tradicionais em geral podem ser facilmente submetidas a engenharia reversa, mas engenharia reversa de software é um trabalho altamente especializado. Esse fenômeno também é evidente em outras áreas em que a interoperabilidade piorou muito com a migração para protocolos digitais proprietários
Isso ocorre em parte porque o software é opaco e, por isso, mais difícil de homologar do que tecnologias anteriores, mas a falta real de qualidade também pesa muito. Uma das razões pelas quais a Bombardier entrou em grandes dificuldades foi o software ruim, a ponto de um contrato com mais de 40 unidades encomendadas ter sido cancelado ([2])
Acho que criar software confiável e compreensível é muito mais difícil do que criar circuitos lógicos ou sistemas mecânicos. Não sei qual é a solução, mas é um problema antigo
[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
Estou consumindo apenas conteúdo em inglês. Conteúdos de outros países só chegam a mim quando vazam por grandes veículos de mídia
Fico me perguntando quanto conteúdo bom poderia ser traduzido
Ainda assim, o inglês, ao menos nas áreas mais instruídas do mundo, ironicamente se tornou uma língua franca, e muitas pessoas que se sentem mais confortáveis em sua língua materna traduzem seus melhores trabalhos para o inglês para que sejam lidos mais amplamente. Artigos científicos são o exemplo típico. Talvez o maior presente que a Inglaterra tenha dado ao mundo seja o inglês
Mas só fiquei sabendo de toda essa dependência de fornecedor dos trens pelo HN. Caso contrário, talvez eu nem tivesse sabido, ou só teria descoberto semanas ou meses depois