Afortunadamente, Uber informó sobre esta infracción y actuó rápidamente.
La semana pasada, un hacker de 18 años usó técnicas de ingeniería social para comprometer la red de Uber. Comprometió el inicio de sesión de Slack de un empleado y luego lo usó para enviar un mensaje a los empleados de Uber anunciando que había sufrido una violación de datos. Uber confirmó el ataque en Twitter a las pocas horas, emitiendo más detalles en esta página (sitio en inglés). La compañía afirma que ningún dato de usuario estaba en riesgo, notificó a las fuerzas del orden y todos sus servicios se restauraron al estado operativo. (Hubo algunas interrupciones breves de varias herramientas de software, pero también están nuevamente en línea). Uber ahora cree que el hacker es parte de un grupo de hackers llamado Lapsus$.
Lo interesante de este incidente fue la velocidad a la que varias publicaciones y analistas de seguridad brindaron cobertura, la rapidez con la que Uber notificó al mundo y la cantidad de detalles que ya tenemos sobre lo sucedido. Comparé esto con otro hack de Uber en 2016, cuando se robó la información personal de unos 57 millones de clientes y conductores. Esa violación no se hizo pública durante más de un año (sitio en inglés) y dio como resultado que Uber despidiera a su director de seguridad, Joseph Sullivan. Actualmente está siendo juzgado por presuntamente arreglar el pago de $100,000 a los piratas informáticos para encubrir las cosas y por la demora en revelar la violación. Supuestamente, los piratas informáticos se vieron obligados a firmar acuerdos de confidencialidad, una forma extraña de lidiar con la violación, sin duda.
¿Cómo sucedió la brecha?
La brecha de la semana pasada se explica en este hilo de Twitter, lo cual es inusual debido a este nivel de detalle compartido por el atacante, quien supuestamente compartió las capturas de pantalla que se muestran en el hilo. Incluyen consolas que controlan los servicios web de Amazon de Uber y las cuentas de Google Workspace, junto con otros sistemas críticos. Un analista de seguridad, que reaccionó a la brecha en su propio hilo de Twitter, dijo que el pirata informático tiene un control administrativo casi total sobre los sistemas informáticos de la empresa, incluido el código fuente del software y los sistemas de mensajería interna.
El pirata informático, que Uber ahora cree que es miembro del grupo de piratería Lapsus$ (sitio en inglés) que ha estado detrás de muchas otras infracciones de alto perfil, habló posteriormente con varios reporteros y admitió que obtuvo acceso mediante el uso de técnicas de ingeniería social con un contratista de la empresa. Establecieron un portal MFA de intermediario que engañó a esta persona para que revelara sus credenciales de autenticación, afirmando ser del departamento de TI de Uber.
Luego, el pirata informático inició sesión en la VPN corporativa y recorrió la red en busca de objetivos, incluido un script de PowerShell que contenía acceso de administrador a una plataforma de administración de acceso privilegiado. Un destino fueron los informes de recompensas por errores HackerOne de Uber, que podrían ser muy dañinos, ya que conocerían las vulnerabilidades que aún no se han remediado y podrían obtener un pago premium si se comparten en la web oscura .
Lecciones aprendidas
Aquí hay algunos puntos clave a tener en cuenta después de esta infracción:
1. No todos los métodos MFA se crean por igual
Uber no estaba usando claves de acceso FIDO2 (sitio en inglés) ni tokens de hardware para asegurar sus cuentas internas más críticas. Estos son más resistentes a los ataques de phishing como el que sucedió aquí. Los atacantes pueden crear fácilmente páginas de inicio de sesión falsas que pueden recopilar la información de un usuario para los empleados desprevenidos.
2. La ingeniería social sigue siendo una gran amenaza
Puedes tener todo tipo de sistemas de seguridad, pero luchar contra la naturaleza humana básica sigue siendo difícil. Era fácil ver cómo el hacker se ganó la confianza y comprometió al empleado de Uber. Ars Technica señala (sitio en inglés): “Muchas organizaciones y culturas continúan creyendo que sus miembros son demasiado inteligentes para caer en los ataques de phishing. Les gusta la comodidad de las aplicaciones de autenticación en comparación con las formas FIDO2 de MFA, que requieren la posesión de un teléfono o una clave física. Este tipo de infracciones seguirán siendo un hecho de la vida hasta que cambie esta mentalidad”.
3. Las credenciales de inicio de sesión del administrador no deben estar codificadas en ninguna parte
Especialmente no en guiones. Básicamente, esto significa que tiene autenticación de factor cero, ya que cualquier persona que lea el script puede averiguar las credenciales.
4. Es fundamental contar con un canal de comunicación alternativo
Este canal debe estar fuera de la banda de tu red para comunicarse entre tu equipo de respuesta a infracciones. Después de que el hacker comprometiera a Slack, enviaron varios mensajes reclamando la hazaña que no fueron tomadas en serio por el personal de seguridad de Uber, quienes pensaron que se trataba de una broma (no lo era).
Afortunadamente, Uber informó sobre esta infracción y actuó rápidamente. La empresa tomó varias medidas para bloquear su repositorio de códigos, cambiar las credenciales e identificar otras cuentas comprometidas. Continúan agregando contenido a su página web (sitio en inglés).
