Luego de la noticia del ataque cibernético a Uber, queda la incógnita sobre la cadena de sucesos que llevaron al desastre. ¿Qué se sabe hasta el momento?
El día de ayer, varios medios informamos acerca de un ataque informático que sufrió la infraestructura de Uber, la popular compañía de transporte urbano. En dicho reporte se especulaba que el atacante tuvo acceso a una cantidad impresionante de datos de todas las índoles, desde financieros, hasta el código fuente de todo su sistema. Pero ¿Cómo pudo haber pasado todo esto?
Cabe aclarar, eso sí, que todo el desarrollo del ataque sigue bajo investigación, y a ciencia cierta, no se saben con exactitud los pasos que siguió el atacante para lograr el acceso. Sin embargo, es posible recrear una secuencia con los datos actuales para tratar de entender cómo es que pudo ocurrir dicho suceso.
De acuerdo a The New York Times, el atacante podría haber comenzado con la utilización de mensajes de texto fraudulentos, en los que se hacía pasar por personal de sistemas de la empresa con el fin de obtener alguna vía de acceso. En este caso, las credenciales del servicio de mensajería interna de la compañía, Slack.
Una vez obtenidas dichas credenciales, el atacante accedió al canal de Slack, para posteriormente obtener el perfil de conexión al VPN interno de Uber. Dicho perfil estaba pensado para conectarse a la red interna de la empresa —o intranet—, dando acceso a la mayoría de los sistemas no públicos. No se sabe con certeza si se trataba de un usuario de altos privilegios, o de cuentas y recursos mal configurados.
Ya dentro de la red como un usuario cualquiera, el atacante comienza a analizar la infraestructura, para terminar, encontrando un recurso compartido de red que contenía una carpeta con scripts de PowerShell. Estos scripts contenían —presumiblemente en texto plano—, el usuario y contraseña administrativos del sistema de gestión de acceso privilegiado —o Privileged Access Management—, Thycotic.
El PAM, —por sus siglas en inglés—, es un software que tiene como tarea la administración de acceso y asignación de roles a usuarios, permitiendo controlar, supervisar, proteger o auditar todas y cada una de las identidades y actividades dentro del entorno informático de la empresa. Claro está, de nada sirve tenerlo si está comprometido.
Desde este punto, las credenciales y ‘secretos’ de sistemas críticos de uso interno son extraídos por el atacante. Entre ellos, se encuentran los sistemas de autenticación multi-factor DUO y OneLogin, usuarios y contraseñas de Amazon Web Services, el acceso al panel de administración de Google Workspace, Active Directory, al administrador de nombres de dominio, e incluso la plataforma financiera interna de Uber.
A su vez, el atacante tenía control de los sistemas que funcionaban a través de VMWare vSphere vCenter, una de las plataformas de virtualización más utilizadas dentro de infraestructuras en la nube, el acceso a la suite de seguridad empresarial SentinelOne, y al perfil de HackerOne, la plataforma de programas de recompensa —o bug bounty— por cazar vulnerabilidades. Ouch.
Asimismo, el atacante afirma que obtuvo datos confidenciales de Atlassian Confluence, la plataforma de trabajo colaborativo que se usa Uber internamente, así como del sistema de control de versiones STASH, y un repositorio de Phabricator que contiene el código fuente de Uber en si. Más allá de eso, no se sabe a ciencia cierta el impacto de lo robado.
En este diagrama se detalla más o menos la secuencia del ataque, partiendo con el acceso a Slack:
La compañía se encuentra investigando el incidente aún, sin tener claro el alcance —que parece ser total—, ni la cantidad de sistemas afectados, contenido expuesto o si hay datos de usuarios dentro de todo este desastre. Cabe añadir que Uber ya notificó a las autoridades acerca del problema.
Sin embargo, una actualización hasta el momento indica que no hay evidencia suficiente de que haya involucrada información personal sensible (como los historiales de viaje) dentro de las filtraciones. Además, todos los servicios se encuentran funcionando normalmente, y las herramientas de uso interno que fueron desactivadas, poco a poco volvieron a estar activas.
Desde Pisapapeles recomendamos cambiar todas tus contraseñas de acceso, ya que no se sabe a ciencia cierta si hay usuarios afectados entre tantos datos expuestos. Mas vale prevenir que lamentar.
Más allá de los pocos datos revelados, el atacante habría firmado uno de los mensajes enviados mediante HackerOne utilizando un nick de Telegram. The New York Times tuvo contacto con el individuo, quien dice tener 18 años.
Uber se enteró de que estaba sucediendo luego de que el atacante comenzara a burlarse mediante el secuestro del canal de Slack, haciendo énfasis en los datos robados. Por su parte, los demás empleados en el canal lo tomaron a manera de burla, pensando que se trataba precisamente de una broma.
Por su parte, vx-underground también logró contactarlo, confirmando —mediante capturas— varias de las plataformas expuestas anteriormente, validando genuinamente el ataque a Uber.
Es complicado determinar con exactitud desde dónde comenzar. Por un lado, el control de acceso siempre debe ser una política estricta bajo el principio de confianza cero, donde ningún usuario o dispositivo debe tener todo el acceso administrativo de uno o varios sistemas.
Asimismo, todos los archivos confidenciales deben permanecer bajo llave, con acceso limitado o nulo, especialmente si incluyen contraseñas o usuarios en alguna de sus formas. De ser posible, en redes separadas o dentro de almacenamientos en frio, con tal de que no estén completamente expuestas en caso de una filtración o ataque.
En cuanto a contraseñas, lo ideal es implementar una autenticación multi-factor, preferentemente usando llaves físicas en la mezcla, y más importante aún, no utilizar contraseñas débiles y/o recicladas, especialmente en sistemas críticos o aquellos con información sensible.
Si hablamos de suites de seguridad, por más dinero que se invierta en licencias de los mejores softwares, si no se aprovechan al máximo o no se configuran correctamente, es como si no existieran.
Además, contar con un solo proveedor de seguridad hace que dicha dependencia sea problemática en caso de que este proveedor tenga problemas. Lo mejor es tener más de uno, manejando distintas secciones o bajo distintos lineamientos de seguridad.
Y más allá de todas las medidas técnicas, una buena capacitación de ciberseguridad orientada a empleados es algo que seguramente evitará más de un descuido, especialmente cuando de ingeniería social se trata.
