Olá novamente! Mais uma vez encontrei um banco de dados aberto para você com dados médicos. Recorde-me que, recentemente, havia três dos meus artigos sobre esse tópico: vazamento de dados pessoais de pacientes e médicos do serviço médico on-line DOC + , vulnerabilidade do serviço Doctor Near e vazamento de dados de postos médicos de emergência .
Dessa vez, o servidor Elasticsearch, com registros do sistema médico de TI da rede de laboratórios do Centro de Diagnóstico Molecular (CMD, www.cmd-online.ru), acabou por estar em acesso aberto.
: . . , .
O servidor foi descoberto na manhã de 1º de abril e isso não me pareceu ridículo. A notificação do problema foi enviada ao CMD por volta das 10h (GMT) e por volta das 15h, a base ficou inacessível.
De acordo com o mecanismo de busca Shodan, esse servidor chegou ao acesso aberto em 09/03/2019. Sobre como os bancos de dados abertos do Elasticsearch são descobertos , escrevi um artigo separado.
A partir dos registros, foi possível obter informações muito confidenciais, incluindo nome, sexo, datas de nascimento do paciente, nome dos médicos, custo dos estudos, dados da pesquisa, arquivos de resultados da triagem e muito mais.
Um exemplo de um log com os resultados dos testes do paciente:
"<Message FromSystem=\"CMDLis\" ToSystem=\"Any\" Date=\"2019-02-26T14:40:23.773\"><Patient ID=\"9663150\" Code=\"A18196930\" Family=\"XXX\" Name=\"XXX\" Patronymic=\"XXX\" BornDate=\"XXX-03-29\" SexType=\"F\"><Document></Document><Order ID=\"11616539\" Number=\"DWW9867570\" State=\"normal\" Date=\"2017-11-29T12:58:26.933\" Department=\"1513\" DepartmentAltey=\"13232\" DepartmentName=\" \" FullPrice=\"1404.0000\" Price=\"1404.0000\" Debt=\"1404.0000\" NaprOrdered=\"2\" NaprCompleted=\"2\" ReadyDate=\"2017-12-01T07:30:01\" FinishDate=\"2017-11-29T20:39:52.870\" Registrator=\"A759\" Doctor=\"A75619\" DoctorFamily=\"XXX\" DoctorName=\"XXX\" DoctorPatronymic=\"XXX\"><OrderInfo Name=\"TEMP_CODE\">0423BF97FA5E</OrderInfo><OrderInfo Name=\"\">-1</OrderInfo><OrderInfo Name=\"\">DWW98675708386841791</OrderInfo><OrderInfo Name=\"\">0</OrderInfo><OrderInfo Name=\"\">18.03.2019</OrderInfo><OrderInfo Name=\"\"> RU.1303.00601</OrderInfo><Serv Link=\"1\" PathologyServ=\"1\" Code=\"110101\" Name=\" (Urine test) \" Priority=\"NORMAL\" FullPrice=\"98.0000\" Price=\"98.0000\" ReadyDate=\"2017-11-30T07:30:01\" FinishDate=\"2017-11-29T20:14:22.160\" State=\"normal\"/><Serv Link=\"2\" Code=\"300024\" Name=\" II , , LifeCycle (DELFIA)\" Priority=\"NORMAL\" FullPrice=\"1306.0000\" Price=\"1306.0000\" ReadyDate=\"2017-12-01T07:30:01\" FinishDate=\"2017-11-29T20:39:52.870\" State=\"normal\"/><Probe ID=\"64213791\" Number=\"3716965325\" Date=\"2017-11-29T00:00:00\" OuterNumber=\"66477805\" Barcode=\"3716965325\" Biomater=\"66\" BiomaterName=\" ()\" Type=\"physical\"><Probe ID=\"64213796\" Number=\"P80V0018\" Date=\"2017-11-29T12:58:26.933\" Biomater=\"66\" BiomaterName=\" ()\" WorkList=\"80\" WorkListName=\" \" Type=\"virtual\"><Param State=\"Valid\" User=\"A872\" UserFIO=\"XXX\" UserStaff=\" \" Code=\"3005\" guid=\"7BA0745FD502A80C73C2CAD341610598\" Name=\" II , , LifeCycle (DELFIA)\" Group=\" \" GroupCode=\"80\" GroupSort=\"0\" Page=\"1\" Sort=\"2\"><LinkServ IsOptional=\"0\">2</LinkServ><Result Name=\" II , , LifeCycle (DELFIA)\" Value=\" (.)\" User=\"A872\" UserFIO=\"XXX\" Date=\"2017-11-29T20:39:03.370\" isVisible=\"1\" HidePathology=\"0\" IsNew=\"0\"><File Name=\" 2 _page1.png\" Type=\"image\" Format=\"png\" Title=\"3716965325_prenetal2_page1\" Description=\" 2 _page1\" Sort=\"1\">iVBORw0KGgoAAAANSUhEUgAABfoAAAfuCAIAAAArOR8rAAD//0lEQVR4Xuy9P7BtQ7u+/e3oECF6iRAhQoQI0SZCtIkQIdpEiBCxI0SIECFiV50qRKg6VYgQIUKEiDfiRL7rnPtXz+nqHnPMsfb6s+cc61rBqjl79Oh++uoe/eceT/c8888///
Marquei todos os dados sensíveis com o símbolo "X". Na realidade, tudo foi armazenado em forma aberta.
A partir desses registros, era fácil (recodificando a partir do Base64) obter arquivos PNG com os resultados da triagem, já em um formato fácil de ler:
O tamanho total dos logs excedeu 400 MB e no total eles continham mais de um milhão de entradas. É claro que nem todos os registros eram dados exclusivos do paciente.
Resposta oficial do CMD:
Queremos agradecer pelas informações sobre a disponibilidade de vulnerabilidades no banco de dados de log e armazenamento de erros do Elasticsearch que foram prontamente transmitidas em 01/04/2019.
Com base nessas informações, nossos funcionários, juntamente com especialistas relevantes, limitaram o acesso a esse banco de dados. O erro na transferência de informações confidenciais para a base técnica foi corrigido.
Durante a análise do incidente, foi possível descobrir que a aparência do banco de dados especificado com logs de erros em domínio público ocorreu devido a um motivo relacionado ao fator humano. O acesso aos dados foi prontamente fechado em 01/01/2019.
No momento, medidas estão sendo tomadas por especialistas internos e externos para auditar adicionalmente a infraestrutura de TI para proteção de dados.
Nossa organização desenvolveu regulamentos especiais para trabalhar com dados pessoais e um sistema de nível de responsabilidade do pessoal.
A infraestrutura de software atual envolve o uso do banco de dados Elasticsearch para armazenar erros. Para aumentar a confiabilidade de alguns sistemas, os servidores correspondentes serão migrados para o data center de nosso parceiro, para um ambiente de software e hardware certificado.
Obrigado por suas informações oportunas.
Sempre são encontradas notícias sobre vazamentos de informações e informações privilegiadas no meu canal do Telegram, “ Vazamentos de informações ”.