A los productos de WSO2 Carbon voy a dedicarle varias entradas, porque hemos visto bastantes cosas en ellas, pero antes de nada quería avisaros a todos los que tenéis alguno de estos productos de algo igual de básico a lo que sucedía con Apache Ambari: Su usuario por defecto. Lo que sucede aquí es que este usuario por defecto está en todos, absolutamente todos los productos, de WSO2 Carbon, que no son pocos.

Si vamos a su web podemos ver que los productos son 100% Open Source, y que tienen soluciones casi para todas las necesidades en entornos de BigData, además de algunos productos de gestión de Cloud, Identidad o entornos móviles, con soluciones para Single Sign-On o para Mobile Device Management.

Tienen soluciones para gestión de almacenamiento, para API Management, para gestión de colas, etcétera, y en todas ellas, en el panel de Login hay un enlace a Sign-in Help, que te lleva al siguiente cuadro de diálogo en el que se explica que el usuario por defecto es admin/admin y que no se puede eliminar, así que hay que cambiarle la contraseña sí o sí.

Esto es algo que hay que evitar en el software, y cuando un nuevo sistema se instala, durante el proceso de instalación debe exigirse cambiar la contraseña. Tener este tipo de usuarios es un error que al final alguno de tus usuarios va a cometer. En este caso, además, el problema del dorking se agrava con el uso de una firma en el HTTP Header de Server, algo que también hay que evitar. En este vídeo tenéis una pequeña sesión de hacking con buscadores y el uso de los dorks.

Para hacer un dork en este caso solo hay que fijarse en que todos los productos de esta familia usan el HTTP Header Server: WSO2 Carbon Server por lo que localizar todas las instalaciones públicas en Internet haciendo un poco de hacking con buscadores con Shodan o Censys es tan sencillo como buscar esta firma en las respuestas de las peticiones HTTP, y como veis salen más de mil instalaciones públicas.

Sacar todas las URLs de Login de Shodan y hacer una prueba con admin/admin es sencillo, y esto le puede abrir decenas de sitios a un atacante para acceder a paneles de administración de todo tipo, desde sistemas de gestión de identidad, hasta almacenamiento o publicación de apps.

En algunos entornos de Single Sign-ON se gestionan, como es habitual, credenciales de los usuarios en muchos entornos, incluso los entornos de Active Directory de la compañía que pueden estar en la Cloud de Microsoft Azure o de Amazon Web Services, por lo que el riesgo puede ser mayor.

Pero el riesgo puede convertirse en un gran problema si un atacante llega a las herramientas de publicación de apps y las troyaniza, haciendo que la distribución del software de la empresa salga con malware por defecto, tal y como hemos visto en el pasado en otros ataques.

O incluso si tienes tu panel de Mobile Device Management expuesto para que cualquiera configure a su gusto las apps y los perfiles de los terminales de su empresa.

Yo contacté con ellos y he alertado a algunos de nuestros clientes que se veían afectados, pero mientras que este software siga teniendo este usuario y contraseña por defecto, día a día irán apareciendo nuevas instalaciones que vuelven a cometer el mismo error de dejar - tal vez temporalmente - la contraseña por defecto "mientras configuran todo". Si tienes este software en alguna parte de tu infraestructura asegúrate de cambiar esto. Además, como son proyectos Open Source, estoy mirando a ver si podemos hacer un commit con un plugin de Latch para poder poner un 2FA al menos al login en los proyectos más importantes - que son muchos -. Si te animas a colaborar, contacta conmigo.

Saludos Malignos!