0
0
Um incidente recente em que um hacker entediado encontrou uma lista de 1,5 milhão de indivíduos na lista de no-fly da TSA sentados desprotegidos em um servidor exposto à Internet destacou, mais uma vez, a prática arriscada de usar dados de produção e informações confidenciais em ambientes de desenvolvimento.
O hacker suíço “maia arson crimew” descobriu recentemente a lista TSA em um servidor de automação de código aberto Jenkins pertencente à CommuteAir, uma companhia aérea com sede em Ohio que oferece suporte às operações da United Airlines em voos regionais. Em comentários ao Daily Dot – o primeiro a relatar o incidente – ela disse que encontrou a lista de exclusão aérea enquanto procurava por servidores Jenkins expostos à Internet usando o mecanismo de busca Shodan e notificou a empresa sobre o problema.
Acessível Abertamente
A lista – armazenada em um arquivo de texto chamado “NoFly.csv” – continha os nomes de mais de 1,5 milhão de indivíduos que o governo dos EUA proibiu de voar por questões de segurança. A TSA disponibiliza a lista para as companhias aéreas de todo o mundo para que possam rastrear os passageiros que pretendem voar de, para ou sobre os EUA .
O Daily Dot citou maia arson crimew – que se descreve como uma “pesquisadora de segurança” – dizendo que também encontrou credenciais para cerca de 40 baldes Amazon S3 pertencentes ao CommuteAir no mesmo servidor. Uma dessas credenciais a levou a um banco de dados contendo informações confidenciais – como números de passaporte, números de telefone e endereços postais – pertencentes a cerca de 900 funcionários da CommuteAir.
Erik Kane, gerente de comunicações corporativas da CommuteAir, em um comunicado à mídia, descreveu o vazamento como resultado de um servidor de desenvolvimento mal configurado.
“O pesquisador acessou arquivos, incluindo uma versão desatualizada de 2019 da lista federal de exclusão aérea que incluía nome, sobrenome e data de nascimento”, disse Kane. “Além disso, por meio de informações encontradas no servidor, o pesquisador descobriu o acesso a um banco de dados contendo informações pessoais identificáveis dos funcionários da CommuteAir”.
Uma investigação inicial mostrou que nenhum outro dado do cliente foi exposto, acrescentando que a CommuteAir imediatamente colocou o servidor afetado offline depois que o hacker informou a empresa sobre o problema, observou Kane.
“A CommuteAir relatou a exposição de dados à Agência de Segurança Cibernética e Infraestrutura e também notificou seus funcionários”, dizia o comunicado.
Usando dados confidenciais para teste e desenvolvimento
O incidente é um exemplo das coisas que podem dar errado quando as organizações permitem o uso de dados de produção ou informações confidenciais em ambientes de desenvolvimento e teste — neste caso, um servidor Jenkins.
Equipes e desenvolvedores de garantia de qualidade geralmente cortam e colam dados brutos de produção em seus ambientes ao testar, desenvolver ou preparar aplicativos porque oferece uma maneira mais barata, rápida e válida de fazer as coisas em comparação com o uso de dados de teste. No entanto, os especialistas em segurança há muito alertam sobre a prática repleta de riscos, porque os ambientes de desenvolvimento e teste geralmente não possuem os controles de segurança presentes em um ambiente de produção ao vivo.
Os problemas comuns incluem excesso de permissões, falta de segmentação de rede, gerenciamento de patches insatisfatório e uma falta geral de conhecimento dos requisitos de privacidade de dados.
Preocupações com questões de segurança, privacidade e conformidade relacionadas à prática levaram, de fato, muitas organizações a tomar precauções adicionais, como mascarar, ofuscar ou criptografar dados de produção ativos e confidenciais antes de usá-los para teste ou desenvolvimento. Muitos simplesmente usam dados fictícios como um substituto para a coisa real ao testar ou preparar o software. Mesmo assim, a prática de usar dados brutos de produção e informações confidenciais em configurações de desenvolvimento e teste continua bastante comum, de acordo com especialistas em segurança.
“Infelizmente, testar com dados de produção é muito comum”, diz John Bambenek, principal caçador de ameaças da Netenrich. “Simplesmente, criar dados de teste confiáveis e em escala costuma ser complicado, especialmente quando se lida com conjuntos de dados exclusivos.” As equipes de teste geralmente desejam que seus testes representem o mundo real tanto quanto possível, por isso é uma tentação muito natural usar dados de produção, diz ele.
Patrick Tiquet, vice-presidente de segurança e arquitetura da Keeper Security, diz que os servidores DevOps costumam ser os principais alvos dos invasores porque geralmente são menos protegidos do que os servidores de produção ativos. Ele defende que as organizações evitem usar dados de produção em ambientes de não produção, independentemente de quão benignos os dados possam parecer.
“O uso de dados de produção em sistemas de desenvolvimento aumenta o risco de divulgação dessas informações, porque em muitas organizações, os sistemas de desenvolvimento podem não estar tão protegidos quanto seus sistemas de produção”, diz Tiquet.
As organizações que permitem a prática precisam reconhecer o fato de que muitos regulamentos de privacidade de dados exigem que as entidades abrangidas apliquem controles específicos para proteger dados confidenciais, independentemente de onde possam existir no ambiente ou como são usados. O uso de dados de produção em um ambiente de desenvolvimento pode violar esses requisitos, diz Tiquet.
“A exposição de dados confidenciais pode não apenas abrir uma organização para litígios ou problemas relacionados ao governo dependendo dos dados, mas também pode levar a uma erosão da confiança do cliente”, alerta ele. “Embora existam muitos passos que as organizações podem tomar para proteger seus ambientes de teste, como mascaramento e criptografia de dados, o mais importante será incluir as equipes de segurança na configuração e gerenciamento contínuo dos servidores DevOps
FONTE: DARK READING