19 de septiembre, 10:45 a. m. (hora del Pacífico)
Si bien nuestra investigación aún está en curso, brindamos una actualización de nuestra respuesta al incidente de seguridad de la semana pasada.
¿Qué sucedió?
Un atacante comprometió la cuenta de un contratista de Uber EXT. Es probable que el atacante haya comprado la contraseña corporativa de Uber del contratista en la web oscura, después de que el dispositivo personal del contratista se infectara con malware, exponiendo esas credenciales. Luego, el atacante intentó repetidamente iniciar sesión en la cuenta de Uber del contratista. Cada vez, el contratista recibió una solicitud de aprobación de inicio de sesión de dos factores, que inicialmente bloqueó el acceso. Eventualmente, sin embargo, el contratista aceptó uno y el atacante inició sesión con éxito.
A partir de ahí, el atacante accedió a varias otras cuentas de empleados que finalmente le dieron al atacante permisos elevados para una serie de herramientas, incluidas G-Suite y Slack. Luego, el atacante publicó un mensaje en un canal de Slack de toda la empresa, que muchos de ustedes vieron, y reconfiguró OpenDNS de Uber para mostrar una imagen gráfica a los empleados en algunos sitios internos.
¿Cómo respondimos?
Nuestros procesos de monitoreo de seguridad existentes permitieron a nuestros equipos identificar rápidamente el problema y actuar para responder. Nuestras principales prioridades eran asegurarnos de que el atacante ya no tuviera acceso a nuestros sistemas; para garantizar que los datos de los usuarios estén seguros y que los servicios de Uber no se vean afectados; y luego investigar el alcance y el impacto del incidente.
Estas son algunas de las acciones clave que tomamos y seguimos tomando:
Identificamos las cuentas de los empleados que se vieron comprometidas o potencialmente comprometidas y bloqueamos su acceso a los sistemas de Uber o requerimos un restablecimiento de contraseña.
Deshabilitamos muchas herramientas internas afectadas o potencialmente afectadas.
Rotamos las claves (restableciendo efectivamente el acceso) a muchos de nuestros servicios internos.
Bloqueamos nuestra base de código, evitando cualquier cambio de código nuevo.
Al restaurar el acceso a las herramientas internas, requerimos que los empleados se vuelvan a autenticar. También estamos reforzando aún más nuestras políticas de autenticación multifactor (MFA).
Agregamos monitoreo adicional de nuestro entorno interno para vigilar aún más de cerca cualquier actividad sospechosa adicional.
¿Cuál fue el impacto?
El atacante accedió a varios sistemas internos y nuestra investigación se ha centrado en determinar si hubo algún impacto material. Si bien la investigación aún está en curso, tenemos algunos detalles de nuestros hallazgos actuales que podemos compartir.
En primer lugar, no hemos visto que el atacante haya accedido a los sistemas de producción (es decir, de cara al público) que alimentan nuestras aplicaciones; cualquier cuenta de usuario; o las bases de datos que usamos para almacenar información confidencial del usuario, como números de tarjetas de crédito, información de la cuenta bancaria del usuario o historial de viajes. También encriptamos la información de la tarjeta de crédito y los datos personales de salud, lo que ofrece una capa adicional de protección.
Revisamos nuestra base de código y no encontramos que el atacante haya realizado ningún cambio. Tampoco hemos encontrado que el atacante haya accedido a ningún dato de cliente o usuario almacenado por nuestros proveedores de la nube (por ejemplo, AWS S3). Parece que el atacante descargó algunos mensajes internos de Slack, así como accedió o descargó información de una herramienta interna que nuestro equipo de finanzas usa para administrar algunas facturas. Actualmente estamos analizando esas descargas.
El atacante pudo acceder a nuestro tablero en HackerOne, donde los investigadores de seguridad informan errores y vulnerabilidades. Sin embargo, todos los informes de errores a los que el atacante pudo acceder se han corregido.
En todo momento, pudimos mantener todos nuestros servicios públicos de Uber, Uber Eats y Uber Freight operativos y funcionando sin problemas. Debido a que eliminamos algunas herramientas internas, las operaciones de atención al cliente se vieron mínimamente afectadas y ahora han vuelto a la normalidad.
¿Quién es responsable?
Creemos que este atacante (o atacantes) están afiliados a un grupo de piratería llamado Lapsus$, que ha estado cada vez más activo durante el último año más o menos. Este grupo generalmente usa técnicas similares para atacar a las empresas de tecnología, y solo en 2022 ha violado a Microsoft, Cisco, Samsung, Nvidia y Okta, entre otros. También hay informes durante el fin de semana de que este mismo actor violó al fabricante de videojuegos Rockstar Games. Estamos en estrecha coordinación con el FBI y el Departamento de Justicia de los EE. UU. en este asunto y continuaremos apoyando sus esfuerzos.
¿A dónde vamos desde aquí?
Estamos trabajando con varias firmas forenses digitales líderes como parte de la investigación. También aprovecharemos esta oportunidad para continuar fortaleciendo nuestras políticas, prácticas y tecnología para proteger aún más a Uber contra futuros ataques.
No hay comentarios:
Publicar un comentario
Te agradezco tus comentarios. Te esperamos de vuelta.