Unas 35.000 aplicaciones de Grok Build quedaron expuestas
Una investigación de seguridad localizó unas 35.000 aplicaciones creadas con Grok Build que eran accesibles públicamente. Algunas contenían información confidencial de empresas y trabajadores, desde listados de personal hasta datos médicos, comerciales y relacionados con instalaciones de defensa. El hallazgo apunta a un problema en el diseño de los enlaces para compartir aplicaciones: sus direcciones podían localizarse mediante servicios de DNS pasivo.
La investigación, atribuida a Claroc y recogida por Ars Technica, no implica que todas las aplicaciones expuestas incluyeran información sensible. Sí muestra que el mecanismo de acceso podía dejar visibles contenidos que sus responsables quizá consideraban limitados a usuarios con el enlace.
Qué tipo de información apareció en las aplicaciones
Entre los ejemplos descritos figura un panel de salud laboral de una constructora peruana con 3.784 exámenes médicos de trabajadores. También se encontró una aplicación de un centro de servicio de Tesla con una clasificación de 22 técnicos y datos sobre productividad y bonificaciones. La investigación no detalla en ese caso si los datos se utilizaron para tomar decisiones laborales ni quién pudo consultarlos.
Otros hallazgos abarcan una plantilla de 108 personas vinculadas a un contrato de apoyo logístico de la Marina estadounidense y una aplicación hospitalaria con unos 3.565 empleados identificados por nombre y número de identificación. En el sector de cruceros, una lista de cocina incluía nombres completos e identificadores de empleados.
La exposición no se limitaba a datos personales. Claroc encontró una propuesta confidencial de servicios informáticos con la lista de componentes de hardware, una propuesta de tránsito IP dirigida a un operador europeo y una hoja de seguimiento de 37 proyectos inmobiliarios con cifras de ventas y beneficios. También aparecieron unas 4.000 órdenes de transporte de vehículos con precios y márgenes, además de una hoja de llamadas con unos 583 posibles compradores de viviendas, sus presupuestos y notas de financiación.
Uno de los ejemplos más delicados correspondía a un grupo aeroespacial y de defensa noruego-finlandés: una planificación de cargas y un procedimiento de carga para un edificio de explosivos en una planta estadounidense, junto con una matriz de formación sobre salud, seguridad y medioambiente. La presencia de estos datos en una aplicación accesible plantea una exposición de información operativa, aunque la investigación citada no afirma que se produjera un incidente físico o que alguien la utilizara con ese fin.
Por qué los enlaces podían descubrirse
Grok Build permite generar aplicaciones para pruebas internas y compartirlas mediante una URL. El modelo se apoya en que quien conoce el enlace puede acceder al recurso: la dirección funciona, en la práctica, como una credencial. Este sistema, conocido como control de acceso basado en capacidades, facilita compartir sin crear necesariamente una cuenta para cada persona, pero hace que la confidencialidad dependa de que el enlace no se divulgue y no sea fácil de encontrar.
Según la descripción de la investigación, las direcciones de Grok Build incluían varias palabras aleatorias antes del dominio grok.me. Una combinación de tres palabras podía aportar alrededor de 38 bits de entropía, es decir, un número muy alto de posibilidades y una protección frente a intentos de adivinación directa. Sin embargo, el problema señalado no consistía en probar combinaciones al azar.
Los servicios de DNS pasivo conservan registros de consultas realizadas para resolver nombres de dominio y permiten buscar algunos de esos registros. Cuando alguien consulta por primera vez una dirección, esta puede quedar recogida en esas bases de datos. Como las palabras aleatorias estaban a la izquierda del dominio, los investigadores pudieron buscar nombres que seguían ese patrón y localizar enlaces existentes. La aleatoriedad dificultaba adivinar una URL, pero no impedía que una dirección ya consultada apareciera en registros accesibles.
La investigación contrasta este diseño con enlaces en los que el identificador aleatorio aparece después del dominio, como en los documentos compartidos de Google. El argumento técnico es que esa estructura habría dificultado encontrar los enlaces de Grok Build mediante búsquedas en DNS pasivo. La comparación se refiere a la ubicación de la parte aleatoria, no demuestra que cualquier enlace de ese otro tipo sea seguro por sí solo.
Qué deberían revisar las organizaciones
El cofundador y director técnico de Claroc, Asaf Aprozper, indicó que estaba notificando a las empresas afectadas. En el caso de la compañía de cruceros de lujo, señaló que, tras hablar con su responsable de seguridad de la información, el equipo de seguridad ya trabajaba para contener la exposición. La investigación también menciona organizaciones de distintos sectores, entre ellas empresas que trabajan para grandes compañías y un contratista de defensa.
Para las organizaciones que hayan usado Grok Build, el primer paso práctico es identificar las aplicaciones compartidas y comprobar qué información contienen y quién puede acceder a ellas. Si un enlace da acceso a datos personales, comerciales o de operaciones, retirarlo o restringirlo es más importante que limitarse a cambiar su nombre: una URL expuesta podría seguir circulando. También resulta prudente revisar si los datos publicados requieren medidas adicionales, como avisar a las personas afectadas o gestionar el incidente conforme a las obligaciones aplicables.
El caso recuerda una distinción clave para los equipos de desarrollo y seguridad: que una URL sea difícil de adivinar no equivale a una política de acceso robusta. Para aplicaciones internas con información sensible, el acceso debería vincularse a identidades verificadas y permisos explícitos, en lugar de depender únicamente de que el usuario posea un enlace. Compartir por URL puede ser útil para pruebas, pero exige controlar qué se publica, durante cuánto tiempo y con qué nivel de acceso.
