Un segundo proveedor polaco de software médico ha sido atacado en cuestión de semanas. Los atacantes utilizaron una vulnerabilidad de inyección SQL para robar datos de pacientes de Medyc, una plataforma vendida por QBUSoft a consultorios médicos y clínicas. La brecha de datos de Medyc en Polonia con exposición de PESEL sigue a un incidente mucho mayor en agosto, y juntos muestran cuánto riesgo recae sobre los proveedores detrás del software de las clínicas, no sobre los pacientes cuyos registros custodian.

Los detalles a continuación provienen de la cobertura de Help Net Security. Algunas partes del resumen original estaban truncadas, por lo que esta publicación se limita a lo que ha sido confirmado.

Qué fue robado de Medyc

Medyc es una plataforma que los consultorios médicos y las clínicas utilizan para gestionar el registro de pacientes, los historiales y las recetas. Según el informe, los hackers robaron datos de pacientes del proveedor explotando una vulnerabilidad de inyección SQL.

El informe indica que la información robada incluye datos de contacto y números PESEL, los números de identificación nacional utilizados en Polonia. El alcance completo del robo de Medyc, incluido cuántos pacientes están afectados, no estaba disponible en el extracto proporcionado, por lo que no vamos a aventurar una cifra.

Los números PESEL importan porque son un identificador de larga duración. A diferencia de una contraseña, una persona no puede cambiarlo fácilmente. Cuando se combina con un nombre y datos de contacto, puede utilizarse para hacer que los intentos de suplantación de identidad parezcan más convincentes.

Cómo la brecha de MyDr preparó el terreno

El incidente de Medyc no ocurrió de forma aislada. En agosto, los atacantes robaron datos de casi 19 millones de personas de MyDr, una empresa con sede en Varsovia cuyo software utilizan alrededor de 12.000 centros sanitarios. La base de datos filtrada también contenía números PESEL.

Esa escala es la parte importante. Un único proveedor que atiende a miles de centros posee los registros de una gran parte de la población de un país en un solo lugar. Cuando ese proveedor es comprometido, todas las clínicas que dependen de él se ven afectadas a la vez, y los pacientes a menudo no tienen idea de qué software utiliza el consultorio de su médico.

El caso de Medyc añade un segundo punto de datos. Dos proveedores diferentes, dos brechas, y ambas involucran el mismo tipo de identificadores sensibles. Ese patrón sugiere que los atacantes ven a los proveedores de software médico como objetivos eficientes, ya que una sola intrusión exitosa puede producir registros de muchas clínicas.

Por qué la inyección SQL sigue afectando a los proveedores de atención médica

La inyección SQL es una de las vulnerabilidades web más antiguas y mejor comprendidas. Ocurre cuando una aplicación pasa datos proporcionados por el usuario a una consulta de base de datos sin separar adecuadamente los datos de los comandos. Un atacante puede entonces elaborar datos de entrada que modifiquen la consulta y hagan que la base de datos devuelva información que no debería.

La solución es bien conocida: consultas parametrizadas, validación de datos de entrada, cuentas de base de datos con privilegios mínimos y pruebas periódicas. Sin embargo, el fallo sigue apareciendo, especialmente en software que ha crecido durante muchos años o que gestiona muchas integraciones. Las plataformas de atención médica a menudo encajan en esa descripción, ya que procesan formularios de registro, recetas y consultas de historiales a través de componentes accesibles desde la web.

La misma clase de vulnerabilidad aparece mucho más allá de la medicina. Nuestra cobertura de atacantes que explotan un zero-day de inyección SQL en GeoServer sin parchear muestra cómo un tipo de fallo puede utilizarse contra plataformas muy diferentes. La lección es consistente: cuando una aplicación accesible desde internet se comunica con una base de datos, las consultas inseguras son un riesgo grave.

Qué significa esto para ti

Si eres un paciente en Polonia, probablemente no puedas saber si tu clínica utiliza Medyc, MyDr u otro sistema. Ese es el problema central. Tus datos están en manos de un tercero que no elegiste, y tus propios hábitos de seguridad tienen poca influencia sobre cómo ese tercero escribe su código.

Una VPN cifra el tráfico entre tu dispositivo y un servidor. No protege una base de datos que un proveedor almacena y a la que un atacante accede a través de un fallo en la propia aplicación del proveedor. Lo mismo ocurre con el cifrado del dispositivo y las contraseñas seguras: son útiles, pero no detienen una brecha del lado del proveedor.

Lo que puedes hacer es reducir el daño si tus datos son utilizados indebidamente:

  • Trata con escepticismo las llamadas, mensajes de texto o correos electrónicos inesperados que mencionen tu salud, recetas o PESEL, incluso si parecen conocer datos personales.
  • No compartas tu PESEL ni tu información médica ante un contacto no solicitado. Contacta a la clínica a través de un número que busques tú mismo.
  • Estate atento a avisos oficiales de tu clínica o de los reguladores sobre si tus datos se vieron involucrados.
  • Utiliza contraseñas seguras y únicas y autenticación de dos factores en el correo electrónico y las cuentas financieras, ya que son objetivos comunes tras las filtraciones de datos de identidad.
  • Revisa tus registros financieros y crediticios en busca de actividad que no reconozcas.

Conclusiones clave

La brecha de datos de Medyc en Polonia con exposición de PESEL, que llega después de la filtración de MyDr que afectó a casi 19 millones de personas, muestra que los proveedores concentrados de software sanitario son puntos únicos de fallo. Herramientas personales como una VPN vale la pena usarlas para la navegación privada, pero no pueden arreglar un fallo dentro de la base de datos de un proveedor. La responsabilidad de eso recae en los proveedores, que necesitan corregir problemas básicos como la inyección SQL, y en los reguladores que los supervisan.

Para los lectores, el paso práctico es la vigilancia ante la suplantación de identidad y el phishing que utiliza identificadores filtrados. Para ver cómo se explota el mismo tipo de fallo en otros lugares, lee nuestro informe sobre el zero-day de inyección SQL en GeoServer.