1 puntos por GN⁺ 2025-03-14 | 1 comentarios | Compartir por WhatsApp
  • En una base de datos pública vinculada a la empresa HealthTech ESHYFT, con sede en Nueva Jersey, quedaron expuestos 86,341 registros y 108.8 GB de datos; la plataforma conecta instalaciones médicas con personal de enfermería en 29 estados
  • El material expuesto incluía perfiles e imágenes faciales, archivos CSV con horarios mensuales de trabajo, certificaciones profesionales, contratos de asignación laboral, CVs y PII adicional
  • Algunos archivos parecen ser documentos médicos subidos a la app como comprobantes de ausencias o licencias por enfermedad, e incluían información de diagnóstico, prescripción y tratamiento que podría estar sujeta a la normativa HIPAA
  • Tras la notificación de divulgación responsable por parte del investigador, el acceso a la base de datos fue restringido más de un mes después, pero no se confirmó quién la administraba, cuánto tiempo estuvo expuesta ni si terceros accedieron a ella
  • Las plataformas de personal médico deben contar con cifrado de datos sensibles, auditorías de seguridad periódicas, retención mínima y anonimización, almacenamiento segregado según sensibilidad, MFA, y planes de respuesta a incidentes y canales de reporte

Exposición detectada en una base de datos pública de ESHYFT

  • El investigador de ciberseguridad Jeremiah Fowler descubrió una base de datos sin protección por contraseña ni cifrado y compartió el hallazgo con Website Planet
  • La base de datos contenía 86,341 registros aparentemente pertenecientes a ESHYFT, con un tamaño total de 108.8 GB
  • El nombre de la base de datos y documentos internos indicaban que los registros pertenecían a ESHYFT, y la mayoría de los documentos estaba dentro de una carpeta llamada “App”
  • ESHYFT es una empresa HealthTech con sede en Nueva Jersey que opera una plataforma móvil para conectar instalaciones médicas con personal sanitario
    • Entre el personal objetivo están los Certified Nursing Assistants (CNAs), Licensed Practical Nurses (LPNs) y Registered Nurses (RNs)
    • La app está disponible en Apple App Store y Google Play Store
    • En Google Play Store supera las 50,000 descargas
    • Apple ya no proporciona estadísticas de usuarios

Archivos expuestos y sensibilidad de la información médica

  • En una revisión de muestra limitada se encontraron varios tipos de archivos
    • Perfiles de usuario o imágenes faciales
    • Archivos .csv con registros mensuales de horarios de trabajo
    • Certificaciones profesionales
    • Contratos de asignación laboral
    • CVs y currículums, además de información de identificación personal (PII) adicional
  • Una sola hoja de cálculo contenía más de 800,000 entradas
    • ID internos de enfermeras
    • Nombre de la instalación
    • Fechas y horas de turnos
    • Horas trabajadas, entre otros datos
  • También se identificaron documentos médicos aparentemente subidos a la app
    • Podrían ser archivos para justificar por qué una enfermera faltó al trabajo o tomó licencia por enfermedad
    • Los reportes médicos incluían información de diagnóstico, prescripción y tratamiento
    • Esa información podría quedar dentro del alcance regulatorio de HIPAA

Medidas tomadas tras la notificación y dudas pendientes

  • El investigador envió de inmediato una notificación de divulgación responsable a ESHYFT
  • El acceso público a la base de datos fue restringido más de un mes después
  • La respuesta de ESHYFT fue: “Thank you! we’re actively looking into this and working on a solution”
  • Aún quedan puntos sin confirmar
    • Si la base de datos era propiedad y estaba gestionada directamente por ESHYFT, o por un contratista externo
    • Cuánto tiempo estuvo expuesta antes de que el investigador la encontrara
    • Si alguien más accedió a ella
  • Cualquier acceso adicional o actividad sospechosa solo podría identificarse mediante una auditoría forense interna

La carga de seguridad crece junto con las plataformas de personal médico

  • ESHYFT afirma que permite a las enfermeras elegir turnos que se ajustan a su horario y ofrece a las instalaciones médicas acceso a personal de enfermería W-2 verificado
  • La plataforma está disponible en 29 estados de EE. UU.
    • AL, AZ, AR, CA, CT, DE, FL, GA, IL, IN, IA, KS, KY, MD, MI, MN, MO, NE, NJ, OH, PA, RI, SC, TN, VT, VA, WA, WI, WV
  • Un reporte de Health Resources & Services Administration (NCHWA) proyecta que para 2027 la escasez de enfermeras registradas en EE. UU. llegará al 10%
  • A medida que crece la demanda de personal sanitario, plataformas como ESHYFT cumplen una función para cubrir la escasez
  • Aun cuando el personal de enfermería realiza trabajo presencial, su integración con tecnología en línea exige salvaguardas de privacidad más sólidas por parte de las empresas HealthTech
  • Cuanto más dependan hospitales y profesionales de la salud de la tecnología para almacenamiento de datos, gestión clínica y contratación, mayor será también la carga de ciberseguridad para toda la industria
  • Los hospitales se consideran infraestructura crítica, y en los últimos años varias redes han sufrido graves ataques de ransomware

Riesgos potenciales y medidas de seguridad necesarias

  • Si se exponen la información de identificación personal, los datos salariales y el historial laboral del personal de enfermería, pueden generarse riesgos tanto para las personas como para las instalaciones médicas empleadoras
  • Si escaneos de identificaciones como licencias de conducir o tarjetas de Social Security se combinan con dirección e información de contacto, podrían usarse para robo de identidad o fraude financiero
  • La exposición de información personal y profesional puede derivar en phishing dirigido usando datos reales
    • Esto podría utilizarse para engañar a las víctimas con fraudes laborales o hacer que revelen más información personal o financiera
    • Sin embargo, esto no significa que los datos de ESHYFT o de sus usuarios hayan sido realmente usados en fraude o actividades indebidas
  • Las empresas HealthTech y los proveedores de software médico deberían considerar las siguientes medidas
    • Protocolos obligatorios de cifrado para datos sensibles
    • Auditorías de seguridad periódicas para identificar vulnerabilidades en la infraestructura interna
    • Limitación del almacenamiento de datos sensibles y anonimización cuando sea posible
    • Fechas de expiración para datos que ya no estén en uso
    • Almacenamiento segregado según la sensibilidad de los documentos
  • En este caso, parece que los archivos de usuarios se subieron a una sola carpeta sin separación por nivel de sensibilidad
    • Las imágenes de perfil de usuario pueden tener baja sensibilidad
    • Los comprobantes de exámenes médicos pueden tener alta sensibilidad
    • En teoría, ambos tipos de documentos no deberían almacenarse en la misma carpeta
  • La segregación y el cifrado de datos sensibles agregan una capa adicional de protección ante exposiciones accidentales o ataques maliciosos
  • Las aplicaciones que permiten acceder a datos o documentos sensibles deben requerir MFA
    • Incluso si se filtran credenciales como nombre de usuario y contraseña, esto dificulta el acceso inmediato a la aplicación o al panel del usuario
  • Las empresas HealthTech deben contar con planes de respuesta ante filtraciones de datos y canales de comunicación dedicados para reportar posibles incidentes de seguridad
    • Si solo existen contactos de soporte o ventas, puede retrasarse la llegada del reporte a los responsables clave que deben actuar ante una filtración
    • Cuando datos sensibles quedan expuestos públicamente, cualquier retraso en mitigación y recuperación puede ser crítico
  • Tras un incidente de datos, debe proporcionarse una notificación de divulgación responsable y oportuna a los usuarios que puedan verse directamente afectados
  • También se debe orientar a los usuarios sobre cómo reconocer intentos de phishing relacionados con la aplicación o el servicio en cuestión
  • Esto no implica que Shiftster LLC dba ESHYFT, sus contratistas o afiliadas hayan cometido actos ilícitos, ni constituye una afirmación de que los datos internos o de usuarios estuvieran en riesgo inminente

1 comentarios

 
GN⁺ 2025-03-14
Opiniones en Hacker News
  • Hace poco escuché que esta empresa, antes de ofrecer trabajos, usa un informe crediticio para determinar cuánta deuda tienes, es decir, qué tan desesperado estás, y luego usa esa información para ajustar a la baja la tarifa por hora que te ofrece.
    Si esta filtración les trae consecuencias, parece que se merecen eso y más.

    • No recuerdo la fuente, pero alguna vez escuché un podcast sobre servicios tipo “Uber para enfermeras”, y decía que hacían todo tipo de cosas en contra de las enfermeras.
      Cuando recibían una llamada, tenían que activar una app de seguimiento de ubicación, y aunque quedaran atrapadas en el tráfico o se cortara la señal del teléfono, acumulaban penalizaciones; esas penalizaciones luego se traducían en una baja de salario.
      En la práctica, están armando como arma las pésimas condiciones de enfermería, donde ya hay demasiados pacientes, falta personal de apoyo y todavía hay que hacer registros después de turnos de 12 horas. Mi esposa es enfermera, así que esto se siente todavía más real.
    • La presentación sobre la contención de salarios de enfermeras está aquí: https://pluralistic.net/2025/02/26/ursula-franklin/
    • Me pregunto por qué las enfermeras usan servicios así si la escasez de enfermeras es tan grave.
      Especialmente si son enfermeras con experiencia, no deberían tener motivo para usar una app pésima que les recorta el sueldo; cualquier institución de salud debería poder contratarlas casi de inmediato, y si son RN, también parecen tener muchas opciones de telemedicina.
    • Parece una forma terrible de estimar el salario de una enfermera.
      Podrían tener cónyuge, sus padres podrían pagarles la tarjeta de crédito, alguien con mal crédito podría no preocuparse mucho, o podrían tener dinero familiar.
      También se puede estar desesperado por trabajo aunque se tenga poca deuda, así que me pregunto si esto realmente funciona.
  • La sección Data Security de la política de privacidad dice que usan salvaguardas físicas, administrativas y técnicas para mejorar la integridad y seguridad de la información que recopilan y almacenan, pero que ninguna seguridad es perfecta o impenetrable, y que no garantizan que no haya filtraciones, acceso, divulgación, alteración o destrucción.
    En particular, este servicio declara que no está diseñado para almacenar ni proteger información de salud protegida bajo HIPAA, pero no sé si decir “perdón, no lo hicimos como un sistema compatible con HIPAA” puede hacer que desaparezca la responsabilidad.
    0: https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...

    • HIPAA se aplica a datos de pacientes, no a datos de proveedores de atención médica.
      El artículo dice que, al parecer, las enfermeras subieron a la app documentos médicos con diagnósticos, recetas e información de tratamientos para justificar ausencias o licencias por enfermedad, y que eso podría calificar como información de salud protegida.
      Si esta empresa está sujeta a HIPAA depende de si es una covered entity o un business associate, y por la política de privacidad parece poco probable que hayan firmado un Business Associate Agreement.
      Además, HIPAA en sí tampoco es ideal como estándar de seguridad; grandes empresas llegan a intercambiar grandes volúmenes de información de salud protegida por Gmail con el argumento de que Gmail cumple con HIPAA.
      0: https://www.hhs.gov/hipaa/for-professionals/covered-entities...
    • HIPAA solo se aplica a ciertos sujetos llamados covered entities.
      A grandes rasgos, entran los proveedores de salud que aceptan seguros o las aseguradoras, y los proveedores de salud que no aceptan seguros no tienen que cumplir HIPAA.
      En este caso, ESHYFT parece ser solo una empresa que provee mano de obra, así que no parece estar directamente relacionada con HIPAA, y no es muy distinta de una gran consultora que ofrece servicios de refuerzo de personal.
    • HIPAA no depende de unos términos y condiciones mal hechos: o aplica, o no aplica.
      Eso sí, su alcance es más limitado de lo que uno esperaría y las sanciones también son débiles. Si Facebook hace que instalen algo como píxeles de seguimiento y se lleva datos médicos personales, es muy probable que no sea una violación de la ley, y quizás solo se le pueda reclamar a quien provocó la filtración.
      En este caso tampoco parece fácil limitar los daños mediante HIPAA. Se parece más al caso de un médico que sube datos de pacientes a Google Drive y luego se filtran por un contratista de Google o por un hackeo.
      El servicio de ESHYFT no necesita ni se beneficia de datos protegidos por HIPAA, así que no parece fácil ganar por una infracción de HIPAA, aunque otras responsabilidades por daños todavía son posibles.
    • Si no son proveedores médicos directos, ese argumento de exención quizá podría funcionar. No digo que lo apoye.
  • Es fácil confundirse por la autoridad que tienen los profesionales de la salud, pero es mejor no darle nunca tu número de Seguro Social a un médico o a un hospital.
    No lo necesitan. Verificar una identificación tampoco significa escanearla ni fotografiarla.
    Médicos, hospitales y clínicas están entre los peores en seguridad de la información, casi no tienen capacitación, las sanciones por equivocarse son leves, y esa información al final se usa más que nada para rastrearte si no pagas la factura.

    • En Estados Unidos, HIPAA es en la práctica el marco legal de privacidad más fuerte, así que parece que hay pocos grupos que reciban sanciones tan grandes como los proveedores de salud cuando filtran información.
    • Me pregunto qué habría que hacer si te dicen que no te darán una cita sin el número de Seguro Social.
  • Me pregunto qué tan antiguo es ese bucket de S3. Desde cierto momento, AWS empezó a hacer que los nuevos buckets de S3 fueran privados por defecto.
    Si es así, lo más probable es que sea un bucket antiguo, o que hayan abierto todo imprudentemente al público porque las cargas/descargas de archivos no funcionaban en la app móvil o el servicio.

    • Tal vez un desarrollador web lo dejó abierto para usar assets en el sitio web y no pensó en otros datos sensibles dentro del mismo bucket.
  • Me pregunto por qué en el título usaron “Uber para enfermeras” en vez del nombre real de la empresa.

    • Según el artículo, el nombre es ESHYFT. Suena como una marca de electrónicos que verías en AliExpress, pero parece de todavía menor calidad.
    • Comunica de inmediato que la empresa es una porquería, de una forma que el nombre por sí solo no lograría.
  • La semana pasada le echaban la culpa a Firebase; esta vez supongo que se la van a echar a AWS.
    Los procedimientos de seguridad de cuando armas algo a la carrera a las 3 de la mañana para mostrárselo a tus amigos no deberían aplicarse tal cual a un producto que aloja información de identificación personal. La seguridad básica de los datos tiene que implementarla el propio operador.

    • Es cierto que hay que implementar seguridad básica de datos, pero la plataforma también debería ayudar tanto como sea posible.
      Hay que hacer que, incluso si los desarrolladores solo siguen los valores predeterminados, caigan en el pit of success seguro.
      En este caso, los buckets de S3 deberían ser privados y cifrados de forma predeterminada, y el desarrollador debería tener que desactivarlo explícitamente. Hoy puede que sea así, pero antes no lo era.
  • La industria de la salud está rota de principio a fin, y hasta las empresas tecnológicas a su alrededor parecen incompetentes.
    Como los hospitales baratos propiedad de corporaciones no quieren contratar enfermeras como empleadas W2, el trabajo de enfermería se está uberizando, y es muy probable que la tacañería de los hospitales haya llevado a elegir una app tan deficiente como esta.
    Quizá incluso hubo sobornos para el administrador que la aprobó, y ESHYFT debería ir a la quiebra por esto, pero parece más probable que en realidad no pase nada.

    • La quiebra no basta; también debería haber cargos por negligencia penal.
      Mientras ningún ejecutivo vaya a la cárcel, estas cosas van a seguir pasando. Es muy probable que alguien haya ganado mucho dinero con este negocio sin invertir en seguridad de la información.
      El costo de esos ahorros lo pagaron personas ajenas a las ganancias, y quizás dentro de unos años esos ejecutivos anden dando charlas sobre cómo construir una empresa exitosa.
      Si este tipo de conducta no tiene consecuencias, el público seguirá pagando el precio de las ganancias privadas.
    • Apps como esta permiten, hasta cierto punto, que hospitales y proveedores de salud independientes puedan resistir.
      Los grandes sistemas de salud tienen sus propios pools de enfermeras flotantes o sistemas internos de ofertas.
      Tener acceso a un sistema para cubrir vacaciones y vacantes también es un argumento de venta cuando los compran los grandes sistemas.
    • Lo de los sobornos me intriga especialmente. Estoy de acuerdo en que es posible, pero no sé cómo se podría erradicar en la práctica.
      Las personas que saben que está mal son justamente quienes reciben esos beneficios, así que casi no tienen incentivos para arreglarlo.
  • Me pregunto si todavía estamos fingiendo que existen organismos reguladores funcionales que puedan tomar medidas ante cosas así.

    • Si despiden de inmediato a la persona que trabajaba con más empeño para encontrar estas cosas, el gobierno sí se vuelve más eficiente.
  • No entiendo por qué esto sigue repitiéndose. Se siente como si cada mes apareciera una nueva filtración desde un bucket de S3 abierto.

    • Las causas pueden ser empresas nuevas con sistemas inmaduros, trabajos secundarios que un desarrollador joven hace por su cuenta dentro de una empresa antigua, malas configuraciones predeterminadas, etc.
      Pero lo más importante es que hay muchas personas con fuertes incentivos para seguir explorando a gran escala. Hoy es muy fácil rastrear internet —GitHub, IP, dominios y demás—, y detectar “configuraciones incorrectas de S3” está al nivel de scripts que cualquiera puede usar, sin requerir habilidades avanzadas de programación.
    • S3 y la mayor parte de AWS tienen un diseño terrible, así que al iniciar un proyecto nuevo uno termina buscando y copiando una política de acceso que parezca funcionar.
      Esa política puede no ser adecuada más adelante para el entorno de producción. No digo que esté bien, sino que así es como ocurren estas cosas en la práctica.
  • Si la persona que armó la infraestructura la construyó estando demasiado agotada y se despertó por la mañana viendo esto, de verdad es una pena.