La brecha en Apify expuso datos de clientes de la plataforma checa de extracción web y automatización. El atacante entró con una credencial comprometida, reunió más credenciales dentro del sistema y llegó hasta cuentas de clientes ligadas a la cuenta inicial.
Fueron dos días de intrusión, el 9 y el 10 de noviembre. Apify la detectó el 11 de noviembre a las 12:13 UTC, cortó el acceso del intruso y abrió una investigación que todavía sigue abierta. SecurityWeek, que publicó la confirmación este 13 de noviembre, cifra en 91.000 los clientes de la empresa en todo el mundo.
Entre esos clientes hay nombres que explican la atención del caso. BleepingComputer recordó que la plataforma sirve a Microsoft, Samsung, T-Mobile, Accenture, Siemens, la Comisión Europea y Roche, y que su crecimiento llegó con el auge de la inteligencia artificial generativa, que disparó la demanda de datos extraídos de la web.
El 12 de noviembre la compañía dio el paso que cambia la lectura del caso: confirmó que a algunos clientes les accedieron información personal o datos guardados en la plataforma. Hasta ese aviso, los primeros mensajes a clientes hablaban de accesos internos sin indicios de datos almacenados tocados.
Una credencial abrió la cadena de accesos
La propia Apify explicó la mecánica en su página de estado, reproducida por BleepingComputer: un tercero sin autorización entró en parte de los sistemas internos y usó una credencial comprometida para obtener credenciales de cuentas y alcanzar cuentas relacionadas. La empresa no ha dicho de quién era esa primera credencial ni cuántas cuentas quedaron comprometidas.
Un cliente compartió en Reddit el aviso que recibió, y SecurityWeek recogió su contenido: nombres, correos electrónicos, datos de facturación, actividad de la cuenta y direcciones IP. La lista duele más en su segunda mitad.
Ese mismo aviso incluía hashes de contraseña con sal, códigos de recuperación de la verificación en dos pasos y números de teléfono. También aparecían tokens de autenticación ligados a los inicios de sesión con Google y con GitHub, las llaves que permiten entrar sin teclear la contraseña.
Los códigos de recuperación merecen renglón propio. Son la llave de repuesto de la verificación en dos pasos: quien los tiene puede saltarse el código temporal del teléfono, y por eso un aviso que los incluye entre lo expuesto obliga a rehacer esa verificación, no solo a cambiar la contraseña.
De las tarjetas de pago solo quedaron expuestos el nombre del titular, la fecha de vencimiento y los últimos cuatro dígitos. Los números completos y los códigos de seguridad quedaron fuera del alcance del atacante, precisó el aviso citado por SecurityWeek.
El patrón recuerda a la brecha de Botpress, que dejó credenciales de bots de 16 cuentas al alcance de un atacante: una plataforma que automatiza tareas guarda, por diseño, llaves de otros servicios, y cada llave guardada multiplica el daño de una sola entrada.
Tokens rotados y verificación en dos pasos nueva
BleepingComputer detalló la respuesta de emergencia: credenciales internas invalidadas, tokens de API rotados y todas las sesiones activas reiniciadas. A los clientes afectados les rotaron también las contraseñas del servicio Apify Proxy, el que enruta las extracciones de datos.
Otra carta pidió a sus destinatarios rehacer la verificación en dos pasos desde la consola de Apify. El motivo es directo: los códigos pudieron quedar expuestos durante la intrusión, y la empresa aseguró a esos clientes que su contraseña seguía a salvo.
Apify sumó vigilancia adicional sobre sus sistemas, cambió secretos internos críticos y revocó conexiones OAuth con servicios de terceros, entre ellas la de GitHub. OAuth es el sistema de permisos que deja a una aplicación entrar en otra cuenta sin pedir la contraseña en cada visita.
La investigación no encontró pruebas de que esas conexiones OAuth sirvieran como puerta de entrada. Quien crea sus Actors, los programas de extracción de la plataforma, desde repositorios privados de GitHub tendrá que reconectar esa integración cuando la empresa avise de que ya es seguro.
Desde el corte del 11 de noviembre, la empresa no ha detectado actividad nueva del atacante en sus sistemas. Ese dato acota la intrusión a los dos días conocidos, aunque la revisión de registros continúa y el conteo de cuentas afectadas sigue sin cifra pública.
Quien trabaja con la plataforma nota la rotación en el bolsillo operativo: tras la brecha en Apify, los datos de clientes quedaron protegidos con llaves nuevas, y cada automatización que llamaba con el token anterior necesita el token nuevo para seguir corriendo.
Para el cliente que no recibió correo, la lectura oficial es estrecha: no ha sido identificado como afectado hasta ahora. La frase deja la puerta abierta a nuevos avisos, porque la empresa sigue contando cuentas y revisando registros con la investigación abierta.
Queda pendiente el dato que ordena todo el caso: cuántas cuentas entregaron datos y de quién era la credencial que abrió la cadena. Apify prometió un informe posterior con la explicación completa, y esa publicación dirá si la rotación masiva de tokens fue precaución o respuesta a un robo mayor.
Fuente: SecurityWeek
Top comments (0)