Você com certeza já passou por algum exame médico ou passará. A Medicina usa de diversos recursos tecnológicos tanto para a realização de exames laboratoriais, para o monitoramento de sinais vitais e muitas vezes, estes recursos auxiliam na própria manutenção da vida do paciente.
Estes dispositivos estão presentes na vida da maioria das pessoas desde a vida intrauterina, durante o acompanhamento pré-natal, até a idade avançada. Estes equipamentos podem inclusive estar inseridos no corpo do paciente, seja temporariamente ou permanente. Podendo atuar como substitutos de membros ou outros órgãos do corpo; liberação controlada de fármacos, como terapia hormonal, bombas de insulina ou analgesia, tratamento de doenças, lesões ou deficiências. Considere agora imaginar que algum destes dispositivos possa ser alvo de um ataque cibernético.
Acha improvável? Em julho de 2007 a Baxter Healthcare Corporation declarou, por duas vezes, ter identificado um comportamento anômalo em diversas de suas bombas de insulina inclusive utilizando o termo “buffer overflow” para descrever o ocorrido (FDA, 2007). Já em 2016 cerca de 10 Milhões de registros de saúde foram colocados à venda por cibercriminosos (Healthcare IT News, 2016), e semelhante vazamento teria ocorrido em terreno nacional em princípios de 2019, o vazamento de dados pessoais de 2,4 milhões de usuários do SUS – Sistema Único de Saúde (UOL, 2019).
Para demonstrar o quanto um único destes dispositivos pode colocar em risco cabe destacar que em 2017 foi anunciado um recall de quase 500.000 marca-passos devido a falhas desta natureza. Uma atualização de Firmware foi descrita em um comunicado oficial do FDA (THE GUARDIAN, 2017).
Os serviços financeiros apresentaram 352.771 arquivos confidenciais expostos em média, enquanto empresas do setor da saúde como Healthcare, Pharma e Biotech têm 113.491 arquivos em média – o mais alto quando comparados os setores. (Varonis) https://www.varonis.com/blog/data-risk-report-highlights-2019/
Segundo um relatório da Verizon o número de violações envolvendo organizações de saúde (15%) podem ser mais elevados que no setor financeiro (10%). https://enterprise.verizon.com/en-gb/resources/reports/dbir/
Por fim consideramos que até 83% dos dispositivos de imagens médicas conectados à Internet – de máquinas de mamografia a máquinas de ressonância magnética – são vulneráveis, de acordo com o Relatório de Ameaças à IoT 2020 da equipe de segurança de ameaças da Unidade 42 da Palo Alto Networks. https://fortune.com/2020/03/13/hospital-hacked-ransomware-medical-imaging-machine/
Após essa longa introdução que tal testarmos o quando isto de fato é fácil para os atacantes?
No ultimo dia 21 de Maio (2020) após escolhermos um dispositivo hospitalar aleatório em um conhecido mecanismo de busca, identificamos que o mesmo se tratava de um equipamento de imagens de radiologia, em trinta minutos (a gente conversa pra caramba, senão haveria mais foco xD) identificamos uma vulnerabilidade bastante básica. Após relatarmos a falha sob a CVE identificada por 2020-13363, podemos dizer que o mesmo dispositivo contavas com mais dezenas de falhas. O que de fato encontramos?
Em primeiro lugar fica clara uma questão não apenas ética, mas moral, envolvida no estudo da segurança deste tipo de dispositivo: identificar uma vulnerabilidade é diferente de explora-la. Sem saber o que tem lá do outro lado não é seguro mexer em algo que pode não ser reconfigurado adequadamente, sem falar nos riscos diversos a todos os indivíduos em contato com aquele dispositivo. Como citado acima, neste caso um DDoS pode afetar uma vida… ou várias.
A vulnerabilidade identificada permitia um XSS refletido na tela de login do equipamento, explorando uma entrada de dados após um erro de login. Por motivos de confidencialidade, o passo a passo não será divulgado até a correção pela fabricante. Mas vamos explicar de maneira bem simples a vulnerabilidade de XSS.
Antes de tudo, vale ressaltar que a vulnerabilidade de XSS possui 3 tipos (Refletido, Armazenado e baseado em DOM) Refletido: É quando a uma entrada de dados que não faz a validação do payload (Os dados que você está transmitindo) corretamente e por conta disso, ele retorna os dados que você inseriu na sua forma original.
Exemplo:
Aqui temos um campo de entrada de dados onde eu inserir um “ola” e ele me retornou na tela um “Hello Ola”, agora vou inserir um “ola” para ver o que ele nos retorna.
Bingo! Ele nos retornou um “Hello Ola” e se vocês verificarem a URL, ele retorna isso em GET e mostra o campo de entrada de dados “?name=”
Se você olhar o código fonte, verá que ele pega tudo que vem dentro no “?name=” via GET e não faz nenhuma validação desse dado, assim ele armazena no ‘name’ e retorna para você na tela aquele tipo de dado.
E o que aconteceria se injeta-se-mos um payload em javascript?
Injetamos para podermos ver como a aplicação se comporta.
Bingo! Ele não fez a validação de entrada e me resultou em um XSS refletido. E olhando o código fonte, podemos ver que ele tratou como um elemento de javascript e não como uma string ou um texto no caso.
Armazenado: Ele já é diferente do refletido, pois para que o usuário seja impactado, é necessário enviar para a vítima aquela URL com o inserido. Mas no caso do armazenado, o servidor ele já injeta esse código no seu banco de dados e se não for validado de maneira correta, ele pode acabar armazenando e toda vez que a vítima for acessar aquela página, ele será executado, sem a necessidade de enviar uma URL maliciosa. Geralmente um XSS armazenado parte de formulários de contato mal desenvolvidos ou até mesmo campos de entrada que acabam salvando esses dados no servidor da aplicação.
Exemplo:
Esse é um campo de formulário, no caso se nos inserirmos alguns dados como meu Nome e uma mensagem, veja o que ele retorna.
Ela armazena no servidor e nos retorna na tela os dados quaisquer que decidirmos inserir.
Observando mais de perto o código fonte, notamos que ele armazena tudo que vem do campo nome e mensagem em um banco de dados mysql, porém a aplicação não valida a entrada de dados, assim armazenando qualquer tipo de informação inserida. Então se por acaso optarmos por inserir dados a aplicação não os validará ao entrarem por esse campo e assim armazenará esse alert no servidor.
Agora se inserirmos um payload no campo mensagem e ela armazenou no servidor.
E com isso, bastará apenas clicarmos no F5 para recarregar a página e o servidor executa, assim nos retornando a seguinte tela.
Optamos por mudar o payload, apenas trocando o “hello world” por um dado do tipo inteiro, pois a aplicação não estava executando uma string. Você poderia inserir um para ele retornar o nome do servidor e o local que está hospedado essa aplicação vulnerável.
Isso é uma forma simples de XSS armazenado.
Baseado em DOM: Para muitos a sua definição é meio complexa, mas em resumo, o XSS baseado em DOM ele trabalha com a modificação do ambiente do navegador e não do servidor, ou seja, com a modificação do lado cliente e não do lado servidor. Diferente do Refletido e Armazenado que trabalha com uma entrada de dados mal validada.
Infelizmente não temos um laboratório pronto para exemplificar o XSS baseado em DOM, mas um de nós produzirá um artigo separado para isso.
Se quiser saber um pouco sobre XSS baseado em DOM, veja esse artigo:
https://portswigger.net/web-security/cross-site-scripting/dom-based
Mas e quanto a vulnerabilidade no dispositivo médico? Infelizmente o dispositivos possuía esse mesmo problema, a entrada de dados quando ocasionava em um erro de login, não era validada corretamente, exemplo:
Login.php?=MessageError, que mudamos para MessageError e poderíamos inserir um payload, assim ocasionando um XSS refletido. O impacto maior seria um Defacement ou até mesmo ocasionar em problemas pro dispositivo. De que natureza seriam estes problemas? mal funcionamento em um dispositivo hospitalar pode ocasionar gastos, espera demasiada, problemas de diagnóstico… quiçá algo pior se tratando de outros dispositivos, ou problemas preexistentes combinados com o ataque.
Por último gostaríamos de ressaltar que o objetivo deste artigo não é se gabar por ter encontrado uma vulnerabilidade, esperamos que este exemplo pratico estimule pesquisadores, médicos, advogados, e principalmente pacientes, a se interessar pelo assunto. Somente assim vamos poder proteger melhor aqueles que dependem destes equipamentos, ou seja, a sociedade como um todo.
Este artigo foi escrito a quatro mãos por Joas Antonio e Raul Cândido. E teve como inspiração uma pesquisa sobre Segurança da Informação para Dispositivos Implantáveis, desenvolvida pelo mesmo Raul Cândido, Henrique Braz e Paulo Klerk.
Autor
Views: 591
