Recientemente, en el foro de hackers BreachForums, ha aparecido un usuario llamado rose87168 que afirma tener acceso a los servidores en la nube de Oracle y está vendiendo información confidencial, incluyendo credenciales de inicio de sesión único (Single Sign-on, SSO), contraseñas de Lightweight Directory Access Protocol (LDAP), claves de OAuth2 y datos de clientes. Debido a que esta información confidencial podría provocar ataques masivos a la cadena de suministro, ha generado preocupación en todos los sectores. Aunque Oracle ha negado públicamente estas afirmaciones, la empresa de seguridad cibernética CloudSEK de Singapur ha realizado una investigación exhaustiva y ha proporcionado una herramienta gratuita para que el público pueda comprobar si son potenciales víctimas de este incidente.
El informe de investigación de CloudSEK muestra que los hackers lograron atacar con éxito el subdominio “login[.]us2[.]oraclecloud[.]com” y crearon documentos como prueba de su ataque. Según los registros de Wayback Machine en la figura 1, este servidor de dominio es Oracle Fusion Middleware 11G y, según la información obtenida, este servicio tiene una vulnerabilidad conocida como CVE-2021-35587 (CVSS: 9.8), que afecta al componente del agente OpenSSO y las versiones afectadas incluyen 11.1.2.3.0, 12.2.1.3.0 y 12.2.1.4.0. Sin embargo, unas semanas antes del ataque, el servidor objetivo ya había sido cerrado por Oracle.
Figura 1: Registro de Wayback Machine de login[.]us2[.]oraclecloud[.]com. Imagen de CloudSEK
Basado en este incidente, CloudSEK ha presentado tres pruebas clave que demuestran que los datos filtrados son información real de los usuarios y no simplemente datos de prueba:
Prueba 1 – Propósito de “login[.]us2[.]oraclecloud[.]com”
CloudSEK ha encontrado un script de flujo de OAuth2 relacionado con “login[.]us2[.]oraclecloud[.]com” en el repositorio oficial de Github de Oracle. Este script utiliza el método de “concesión de credenciales de cliente” para verificar las solicitudes de API y luego utiliza el client_id y secret_key (codificados en Base64) para generar un token y enviar una solicitud POST a la URL. Este token luego se utiliza como encabezado de autorización para las solicitudes de API posteriores. Esto demuestra que el servidor es un entorno de producción y no un entorno de prueba o temporal.
Figura 2: Prueba 1 – Propósito de login[.]us2[.]oraclecloud[.]com. Imagen de CloudSEK
Prueba 2 – Coincidencia de nombres de dominio reales con la lista de hackers
En las muestras de datos proporcionadas por los hackers, se encontraron algunos dominios pertenecientes a usuarios de la nube de Oracle y no a usuarios virtuales o de prueba. Algunos ejemplos incluyen sbgtv[.]com, nexinfo[.]com, cloudbasesolutions[.]com, nucor-jfe[.]com y rapid4cloud[.]com.
Prueba 3 – Uso de “login[.]us2[.]oraclecloud[.]com” para generar configuraciones de SSO
El proveedor de soluciones de IAM, OneLogin, ha publicado un artículo sobre Oracle Fusion que describe cómo configurar SAML para proporcionar SSO en Oracle Fusion, como se muestra