SonarQube – Auditando al Auditor – Parte II

• Parte I
• A estos hallazgos se le asignó un código CVE-2020-28002

Continuando con esta serie de publicaciones, vamos a analizar un “comportamiento” algo peculiar/extraño y evidentemente inseguro por parte del producto SonarQube Community, así que esperamos ser lo más claros y concisos posibles. 

¿Por qué es importante revisar herramientas como SonarQube?

Desde la perspectiva de un atacante la respuesta es simple, los productos como SonarQube se vuelven atractivos porque almacenan o tienen acceso a todo el código fuente de los aplicativos de una organización, de esta manera es más rentable atacar un eslabón del proceso DevSecOps que la aplicación objetivo en sí misma, pues recordemos que al tener el código fuente el ataque al aplicativo será dirigido, eso sin mencionar que en muchas ocasiones nos encontramos con archivos de configuración, cadenas de conexión en texto claro y configuraciones de seguridad basadas en oscuridad, etc. 

Entremos en materia y partamos con las siguientes características de producto:

SonarQube ID information

• Server ID: 32FADB56-AXRx4wuyUe_xmLIBDkFu
• Version: 8.4.2.36762
• Date: 2020-10-22

A groso modo y de forma muy general, SonarQube tiene 2 estados para la publicación de proyectos; el público y el privado, esto en complemento a la respuesta anterior, pues ¿De qué sirve un sistema robusto de seguridad en la organización, si mi servidor local de SonarQube expone todos los códigos fuente?, o peor aún si no fuese un servidor local…

Cuando se monta por primera vez el sistema SonarQube, sin previa autenticación no podrán encontrar ningún acceso a crear un proyecto o analizarlo, únicamente se tiene visibilidad sobre aquellos que se han dejado expuestos públicamente (hasta aquí, bien), sin embargo, este comportamiento no se cumple al pie de la letra, ya que un externo puede crear proyectos anónimos y adicionalmente sobrescribir proyectos ya existentes, sean públicos o privados, y lo mejor, sin autenticación.

Iniciamos con un sistema por defecto, sin privilegios ni proyectos:

Para realizar el análisis del código es necesario descargar el SonarScanner en alguna de sus presentaciones según sea el caso (https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/#)

• Grandle
• MSBuild
• Maven
• Azure DevOps
• Jenkins
• Ant

En local o con alguna de las posibles integraciones, se nos pide que le indiquemos como mínimo los siguientes parámetros al SonarScanner:

• sonar.projectKey=
  • Nombre del proyecto a analizar
• sonar.sources=
  • Path donde se encuentra el código
• sonar.host.url=
  • URL del server SonarQube o por defecto llama a SonarCloud.io
• sonar.login=
  • Nombre de usuario o token de conexión
• sonar.password=
  • Requerida si se usa en conjunto con sonar.login

En lo anterior se contempla la autenticación básica o por token, y es razonable pensar que sin proporcionar un token correcto o un login y password adecuados, no es posible realizar un análisis ni subir información al server:

• sonar-scanner.bat -D”sonar.projectKey=proyecto_anonimo” -D”sonar.sources=.” -D”sonar.host.url=http://192.168.0.56” -D”sonar.login=test” -D”sonar.password=test“

Efectivamente la respuesta nos indica que NO tenemos autorización para las acciones de análisis ni creación de proyectos, pero qué sucede si enviamos un login vacío sin el parámetro password, o lo que sería igual a la autenticación por token vacío:

• sonar-scanner.bat -D”sonar.projectKey=proyecto_anonimo” -D”sonar.sources=.” -D”sonar.host.url=http://192.168.0.56” -D”sonar.login=“

En este caso la respuesta es exitosa, por lo que sin autenticación es posible crear proyectos y realizar analisis de código. En el dashboad inicial podemos evidenciar que el proyecto y análisis se creó sin requerir ningún tipo de autenticación o privilegios:

Validando los logs y las tareas internas en el SonarQube, se puede observar que el proyecto anteriormente creado sin autenticación fue asignado por el usuario anonymous:

El siguiente paso consiste en comprobar si es posible tener el mismo comportamiento pero con un proyecto privado, el cual al ser privado no se encuentra listado ni accesible por defecto, requiere de privilegios y un usuario autenticado:

• Nombre: proyecto_privado
• Visibilidad: privada
• Creador: admin

Nota: los privilegios de los grupos “sonar-administrators” y “sonar-users” son los asignados por defecto al seleccionar la visibilidad “private” del proyecto. En futuras publicaciones veremos el manejo de los permisos y estas asignaciones de privilegios bastante abiertas a nivel de seguridad.

Ahora intentamos nuevamente el análisis con el Sonar-Scanner, pero indicando como projectKey “proyecto_privado” y veremos que sí es posible sobrescribir el proyecto y afectar el proceso ágil que se tenga implementado:

• sonar-scanner.bat -D”sonar.projectKey=proyecto_privado” -D”sonar.sources=.” -D”sonar.host.url=http://192.168.0.56” -D”sonar.login=“

La respuesta exitosa por parte del Sonar-Scanner nos indica que ha sido posible analizar, subir y reemplazar el proyecto privado existente sin contar con credenciales o permisos. Ya que el proyecto es privado y no se expone, es necesario validarlo con un usuario del aplicativo y ver que efectivamente el análisis y la sobreescritura del proyecto se llevó acabo.

Verificando nuevamente los logs y los task creados para este proyecto, se observa nuevamente que la acción realizada se le asigno al usuario anonymous:

En este punto de la revisión queda en evidencia que es posible saltarse los mecanimos de autentición para la creación y el analisis de proyectos tanto públicos como privados, aún si se cuentan con permisos restrictivos sobre estos.

Consideraciones generales de seguridad:

• Un atacante puede sobrescribir proyectos públicos y privados, lo que se traduce en la posible inyección de código en este paso del proceso ágil.
• En un proceso Dev¿Sec?Ops, donde todas las plataformas de desarrollo continuo y despliegue continuo están integradas y conectadas entre sí para permitir que un pequeño cambio a nivel de código pueda verse reflejado en producción en cuestión de minutos, alterar la confianza, la seguridad y el código en un paso del proceso tendría repercusiones a nivel de todo el esquema.
• SonarQube soporta los WebHooks, por lo que el re analisis puede utilizarse para aprovechar los disparadores a otras plataformas integradas.

Estos comportamientos listados en esta publicación son debido a una configuración insegura establececida en los endpoints /api/CE/submit del api del producto SonarQube, la descripción son indica lo siguiente:

• http://[server]/web_api/api/ce?deprecated=true&internal=true

Aunque indica que requiere ciertos privilegios, ya hemos visto que básicamente se puede realizar de forma anonima. Al final, cuando el Sonar-Scanner termina localmente el analisis del código, envia un reporte utilizando este endpoint y subiendo un archivo ZIP con la información.

Aún quedan varios temas para poder tocar con SonarQube, por lo que esperamos seguir profundizando en esta serie de publicaciones.

La respuesta por parte de SonarQube, indica que ya eran consientes de esta vulnerabilidad, no obstante es un tema atribuido a la configuración por defecto, en un claro ejemplo donde la usabilidad se convierte en problemas de seguridad.

https://jira.sonarsource.com/browse/MMF-2146

Agradecemos la pronta gestión por parte de SonarQube, y su disposición para darle solución a estos hallazgos reportados.

Saludos.