Big Data Security Tales: WSO2 Carbon y la ayuda del Login #BigData

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.

Figura 1: WOS2 Carbon y la ayuda del Login

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.

Figura 2: Familia de productos de WS2 Carbon

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í.

Figura 3: Ayuda en la página de Login de los productos WS2 Carbon

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.

Figura 4: Sesión de Hacking con Buscadores usando dorks con Google, Bing y Shodan

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.

Figura 5: Búsqueda del HTTP Header "Server: WSO2 Carbon Server"

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.

Figura 6: Un panel de identidad de WSO2 Identity Server

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.

Figura 7: Un entorno de Active Directory gestionado en una solución de Single Sign-On

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.

Figura 8: WSO2 Application Server

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.

Figura 9: WSO2 Enterprise Mobile Manager para gestionar apps, certificados y dispositivos

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.

- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)
- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
- Big Data Security Tales: Kibana & ElasticSearch objetivos del ransomware
- Big Data Security Tales: Apache CouchDB Relax... o no
- Big Data Security Tales: Riak NoSQL Database

Saludos Malignos!