2 puntos por GN⁺ 2025-12-04 | 1 comentarios | Compartir por WhatsApp
  • En el análisis de la API de la plataforma de IA legal Filevine se descubrió una vulnerabilidad crítica que otorgaba acceso completo de administrador sin autenticación
  • El investigador usó subdomain enumeration para encontrar el subdominio margolis.filevine.com, identificó el endpoint de API de AWS y envió solicitudes de prueba
  • Una solicitud POST simple devolvió una respuesta sin token de autenticación, y dentro de ella había un token de administrador con acceso total al sistema de archivos de Box
  • Con ese token se pudieron recuperar más de 100,000 documentos "confidential", incluyendo información extremadamente sensible de salud, legal y nómina
  • Filevine respondió y corrigió la vulnerabilidad de forma inmediata tras la notificación, y este caso demuestra la importancia de la gestión de seguridad en los servicios legales basados en IA

Cronograma de hallazgo y divulgación de la vulnerabilidad

  • El investigador informó la vulnerabilidad al equipo de seguridad de Filevine por correo electrónico el 27 de octubre de 2025
    • El 4 de noviembre, Filevine reconoció el problema y respondió con un plan de corrección rápida
    • El 20 de noviembre, el investigador verificó si se había aplicado el parche y comunicó su intención de publicarlo en su blog
    • El 21 de noviembre, Filevine confirmó que el parche estaba completo y agradeció el reporte
    • El 3 de diciembre, se publicó la entrada del blog técnico
  • Filevine mostró una respuesta rápida y profesional en todo el proceso y fue considerada un caso ejemplar de divulgación responsable de seguridad

Contexto del mercado de IA legal de Filevine

  • Filevine es una plataforma legal de IA valorada en más de mil millones de dólares y en rápido crecimiento
  • Los despachos de abogados cargan en esta plataforma datos de confidencialidad extremadamente alta para operar
  • El investigador revisó la arquitectura de seguridad de datos de Filevine basándose en su experiencia en proyectos con la Yale Law School

Proceso de ingeniería inversa

  • Debido a las restricciones de acceso de Filevine, el investigador usó la técnica de subdomain enumeration para encontrar un entorno de demostración pública
  • Tras descubrir el subdominio margolis.filevine.com, la página no cargaba, por lo que analizó las solicitudes de red con las herramientas de desarrollador de Chrome
  • En un archivo JS encontró el código POST await fetch(${BOX_SERVICE}/recommend) y confirmó que la variable BOX_SERVICE estaba configurada como un endpoint de API de AWS
  • Al enviar una solicitud en formato {"projectName":"Very sensitive Project"} a /prod/recommend, la respuesta se devolvió sin autenticación

Exposición del token de administrador e impacto

  • La respuesta incluía un token boxToken con permisos administrativos completos de la API de Box
  • Ese token daba acceso al sistema de archivos interno de Box de los bufetes de abogados
    • Permitía acceso total a documentos, registros, información de usuarios y más
  • Al buscar con la palabra clave “confidential” se confirmó un retorno de aproximadamente 100,000 resultados
  • El investigador detuvo inmediatamente las pruebas y reportó la vulnerabilidad a Filevine
  • Si un actor malintencionado hubiera usado ese token, podrían haberse filtrado documentos protegidos por HIPAA, órdenes de corte, información de nómina interna, entre otros

Lecciones de seguridad

  • En la competencia por adoptar IA, las empresas necesitan fortalecer su estructura de protección de datos
  • Especialmente en industrias de alta sensibilidad como legal y salud, los servicios de IA deben mantener estrictos controles de validación de seguridad
  • Este caso deja claro el riesgo que puede provocar el fallo de autenticación y control de permisos en SaaS con IA

1 comentarios

 
GN⁺ 2025-12-04
Opinión en Hacker News
  • Siempre me sorprende que tarde tanto clasificar y corregir una vulnerabilidad de seguridad tan obvia
    Se divulgó el 27 de octubre y hasta el 4 de noviembre apenas confirmaron por correo, así que durante todo ese tiempo estuvo expuesto todo el sistema de archivos de los clientes
    La corrección real probablemente habría sido un parche de menos de 1 hora; incluso incluyendo pruebas de QA, no debería tomar tanto tiempo
    Me pregunto si nadie revisa el correo de security@, o si estaban de vacaciones, o si reciben tanto spam que no detectan un problema real

    • En mi experiencia, este tipo de retraso se debe a problemas de estructura organizacional y gestión de proyectos
      El equipo de seguridad se encarga del correo de security@, pero el equipo que realmente corrige el bug es otro, así que el proceso de transferencia se complica
      Solo encontrar al equipo dueño del código puede tomar semanas, y como el calendario está saturado es difícil subirle la prioridad
      Si además hace falta aprobación del equipo legal, la respuesta se retrasa aún más
      Las empresas inteligentes le dan al equipo de seguridad autoridad de respuesta de emergencia, pero si eso se abusa también aumenta el desgaste interno
    • En la mayoría de los casos no es tanto que “nadie revisa el buzón de seguridad”, sino que la única persona que conoce esa parte está atendiendo otras 12 cosas al mismo tiempo
      El parche de seguridad es un arreglo de 1 hora, pero entre aprobaciones internas y encontrar al dueño del código termina tomando 2 semanas
      Al final, el verdadero problema es la entropía de la organización
    • Hoy en día llegan demasiados reportes falsos al buzón de security@
      Los LLM incluso pueden generar informes de vulnerabilidades convincentes, y eso hace que un experto pierda horas
      Por eso algunas empresas tienen políticas de revisar ese correo solo durante horario laboral
    • En realidad sí hay mucho spam, pero son solo unos cuantos correos al día, así que no hay motivo para no parchear de inmediato una vulnerabilidad tan grave
      Probablemente, como dijiste, la persona encargada estaba de vacaciones
    • En el centro global de respuesta donde trabajo somos 600 personas, y hay 26,000 incidentes prioritarios
      Cuanto más complejo se vuelve el sistema, los problemas no disminuyen, sino que aumentan
      Al final trabajamos bajo la ilusión de que “podemos con esto”
  • Si esta empresa recibió una valoración de mil millones de dólares, una sola vulnerabilidad básica como esta pudo haberle causado una pérdida de ese tamaño
    Si la hubiera encontrado alguien malintencionado, el daño habría sido irreparable
    Todo el conjunto de datos de clientes pudo haberse filtrado, así que debieron recompensar a quien lo descubrió

    • Exacto. Una vulnerabilidad así podría haberse vendido a un grupo de ransomware por cientos de miles de dólares
      Después habrían venido la filtración de datos, la extorsión, las demandas y las multas
      Por eso algunos hackers terminan yéndose al mercado gris en lugar de actuar como white hats
    • De verdad debieron dar una gran recompensa
  • Trabajo en una empresa financiera, y todos se preguntan por qué sí confían datos de clientes a SaaS X, pero no pueden subir documentos fiscales a AI SaaS Y
    En mi opinión, la industria de la IA ahora mismo parece el Lejano Oeste (Wild West)
    Está avanzando demasiado rápido y se están saltando procesos de seguridad
    Este incidente lo demuestra muy bien

    • FileVine sí es una herramienta legal con IA, pero este problema no tiene relación con la IA en sí
      Parece simplemente un problema de integración con la API de Box
    • Como referencia, la empresa se fundó en 2014 y apenas hace poco añadió funciones con LLM
      Enlace al artículo de Reuters
    • Si SaaS X ofrece funciones de IAM y aplica sus propias políticas de acceso, es relativamente más seguro
      En cambio, si SaaS Y solo dice “déjanos tus datos y estarán seguros”, eso sí da desconfianza
    • Pero primero habría que preguntarse por qué confiaron en SaaS X desde el inicio
    • Lo interesante es que esta vulnerabilidad no tiene nada que ver con la IA y es el tipo de problema que podría ocurrir en cualquier empresa SaaS
  • Este incidente es el choque entre la cultura startup de “conectar APIs rápido” y las industrias legales y médicas, donde una filtración de datos puede arruinarte la vida
    El problema sigue un patrón de bugs propio de la década de 2010, pero viene cubierto con envoltura de marketing de IA en 2025
    Al centralizar documentos para entrenar modelos de IA, el alcance del daño en caso de incidente se vuelve mucho mayor
    En ventas necesitan facilitar el acceso a los datos para cerrar contratos, así que principios como el de mínimo privilegio se dejan para después
    Al final, los abogados creen que están comprando un “asistente de IA”, pero en realidad están otorgando acceso externo a toda la memoria institucional
    La verdadera pregunta es: ¿cuántos de estos sistemas pasarían una prueba seria de red team?

    • Da un poco de risa. La empresa monta todo un show de ciberseguridad y al mismo tiempo crea un agujero de gusano con LLM que se salta todo
      El problema es que los ejecutivos no técnicos no entienden la IA y solo repiten el marketing
      Aun así, me gusta que usé dos veces una metáfora espacial
  • El equipo de Filevine respondió de forma profesional y rápida durante todo el proceso de divulgación
    Reconocieron la gravedad del problema, lo corrigieron y se comunicaron con transparencia
    Por eso creo que en un caso así ni siquiera hacía falta publicar el nombre de la empresa
    Si ya resolvieron el problema, no veo necesidad de exhibirlos

    • Pero en un proceso de divulgación responsable, lo normal es revelar el nombre de la empresa
      Así la industria puede saber qué compañías se toman en serio los reportes
    • La divulgación ética consiste en que ambas partes publiquen juntas los detalles técnicos
      Queda como un buen precedente tanto para hackers como para empresas
    • Si ocultas los errores, pierdes transparencia y confianza
    • En un problema tan grave como este, los clientes tienen que enterarse
      Además, otras empresas de AI SaaS podrían ver esta publicación y evitar cometer el mismo error
  • Los procesos de certificación de seguridad como SOC2 e HIPAA parecen una especie de “teatro de seguridad”
    En la práctica se ignoran las partes importantes, y todo se llena de capturas de pantalla y documentación meramente formal

    • SemiAnalysis calificó estas certificaciones como tan importantes como una licencia de la FAA, pero aun así ellos mismos fueron comprometidos por una simple falta de controles de seguridad
      Enlace al texto relacionado
      Al final esto no es seguridad real, sino casillas de verificación que se compran con dinero
  • El software de seguridad todavía tiene mucho por mejorar en términos de usabilidad y complejidad
    Cuando trabajé en Google y Meta, los sistemas de ACL eran tan complejos que me tomó 4 años entenderlos
    Este tipo de sistemas son imposibles de usar para empresas no técnicas
    Por eso hasta me dan ganas de crear una startup que simplifique la seguridad
    Me parece un problema mucho más difícil que la IA

  • Menos mal que esta empresa permitió publicar la entrada del blog
    Yo también descubrí una gran vulnerabilidad antes, pero la empresa impidió que se hiciera pública

    • “¿De verdad hace falta permiso?” Simplemente haz una divulgación responsable
    • ¿Por qué la empresa tendría control sobre la divulgación? Si seguiste el proceso de reporte, después deberías poder escribir libremente sobre ello
  • Este ataque no fue nada sofisticado
    Filevine dice en su sitio web que hace pruebas de penetración, y no puedo creer que se les haya pasado algo así
    Parece que confundieron un bug bounty con una prueba de penetración
    De verdad no hay excusa

  • Últimamente hay demasiadas startups de healthcare + IA, y me preocupa que en pocos meses ocurra una gran filtración de datos HIPAA
    Se pueden ver casos relacionados también en este hilo