Assistimos a uma mudança de paradigma no que toca ao mundo automóvel. Os elétricos estão a tomar conta das estradas e o conceito mecânica automóvel é cada vez mais veículo elétrico e eletrónico. Resumindo, são cada vez mais computadores sobre rodas. Assim, tal como aconteceu em vários outros segmentos, a questão que se pode e deve colocar é se estes grandes centros informáticos geradores de dados poderão ou não ser “hackeados” e os proprietários vítimas de ransomware.
Já pensou um dia chegar ao seu carro e ele estar “sequestrado” e a pedir um resgate para circular?
E se um dia o seu carro fosse “hackeado”?
Os carros têm dezenas de unidades de controlo eletrónico baseadas em microprocessadores (ECUs), que executam coletivamente milhões de linhas de código. Depois há a telemática, o software de assistência ao condutor e o sistema de info-entretenimento, entre vários outros sistemas e componentes que atualmente fazem parte de um veículo moderno.
Ora, não é de estranhar que à medida que as capacidades digitais e autónomas dos automóveis aumentem, a integridade desse código será ainda mais importante – especialmente a sua segurança.
Se pensarmos bem, cada carro vem com muitos componentes, e cada um destes pode ter uma base de código diferente, que, se mal testada ou protegida, é vulnerável a bugs, erros, ou código malicioso. Mas e se pudéssemos vedar os sistemas tonando-os totalmente seguros antes de saírem das fábricas?
Há uma declaração muito interessante de Matt Wyckhouse, fundador e CEO da Finite State. Esta é uma empresa de análise de risco. Contudo, o interessante foram mesmo as ações desenvolvidas por Matt para o seu carro, um Tesla. Ele investiu pessoalmente na segurança do seu carro.
Quais são algumas das falhas de segurança mais comuns?
Como especialistas em segurança e análise de risco, Matt referiu algumas particularidades que não estão de todo acessíveis ao consumidor comum que comprou o carro.
Segundo ele, uma das falhas mais comuns é o código mal escrito e vulnerável a riscos de segurança ou atividades maliciosas. Estes milhões de linhas de código dentro dos microprocessadores de um carro têm a sua própria origem. Por exemplo, o firmware do sistema incorporado, incluindo o firmware usado em veículos conectados, é composto por 80 a 95% de componentes de terceiros e de código aberto.
E, quando se começa a utilizar software de outras partes que podem não partilhar a sua vigilância de segurança, o risco aumenta.
Alguns dos exemplos deixados pelo especialistas em segurança são até bem conhecidos e já fizeram vítimas recentemente.
Vulnerabilidade do Log4J
Um exemplo da recente vulnerabilidade do Log4j – uma vulnerabilidade zero-day na biblioteca de registo baseado em Java do Apache Log4j. O programador principal pode ter puxado o software Log4j como parte da sua prática de desenvolvimento. Ou pode estar envolvido num terceiro, quarto, ou quinto componente construído em Java que chega ao software final.
Isto põe em risco a segurança de qualquer servidor automático que utilize a biblioteca. Os dados são recolhidos e armazenados em locais diferentes ao longo do tempo. Isto aumenta o risco de impacto sobre o software do veículo.
Conforme reportamos, em janeiro, o investigador de cibersegurança David Columbo conseguiu entrar remotamente em mais de 25 Teslas devido a uma falha de segurança descoberta em software de terceiros utilizado pelos condutores da Tesla.
Isto não lhe permitiu ‘conduzir’ os carros. No entanto, disse que foi possível trancar e destrancar janelas e portas, desativar os sistemas de segurança dos carros, buzinar e ligar e desligar os rádios dos carros.
So, I now have full remote control of over 20 Tesla’s in 10 countries and there seems to be no way to find the owners and report it to them…
— David Colombo (@david_colombo_) January 10, 2022
O problema de segurança das credenciais codificadas
Outro exemplo deixado por Matt são as credenciais hardcoded (palavras-passe codificadas/incorporadas). É aqui que as palavras-passe de texto simples e os dados secretos são colocados no código-fonte. Fornece uma porta traseira para testes e depuração de produtos.
Deixado no código final, um atacante pode ler e modificar ficheiros de configuração e alterar o acesso do utilizador. Se a mesma palavra-passe estiver a ser utilizada como padrão em vários dispositivos, então tem um problema ainda maior.
Em 2019, as credenciais hardcoded deixadas na aplicação móvel MyCar tornaram possível aos atacantes aceder aos dados do consumidor e obter acesso físico não autorizado ao veículo do alvo.
OK… então, como é que se protege o software contra vulnerabilidades e ataques?
O CEO da Finite State diz que é neste ponto que começa o seu trabalho. O ponto de vista é interessante de facto. Então ele refere que o seu trabalho começa na fase de teste, concentrando-se na cópia binária final e nas versões. Basicamente ele refere que faz o trabalho de trás para a frente.
Primeiro automatiza a engenharia inversa do código. Desmonta-o, descompila-o e testa as fraquezas e vulnerabilidades. De seguida, o resultado é partilhado com a equipa de segurança do cliente.
Matt Wyckhouse explicou que os testes finais permitem-lhes ver como um artefacto de software mudou ao longo do tempo:
E se houver uma mudança não intencional que não seja rastreável até uma ação da equipa de desenvolvimento, isso é motivo para investigar mais a fundo.
Analisando a evolução da segurança noutros setores e transpondo essa evolução para o mundo automóvel, damos conta que os conceitos de segurança cibernética e mobilidade ainda têm muito caminho a percorrer.
Contudo, segundo Wyckhouse, os fabricantes de automóveis estão continuamente a investir em segurança, não só para cumprir as normas da indústria, mas também para obter vantagens de reputação e competitivas sobre os seus rivais que repetidamente sofrem violações de segurança.
Ainda assim, refere o especialista, não há uma semana sem que não haja mais um relatório de um ataque ou de uma vulnerabilidade encontrada por investigadores “white-hat”… os bons da fita! E à medida que a automatização automóvel aumenta, os riscos só se tornam maiores.