Herramientas para mejorar tu software y cómo utilizarlas

Todos los días se descubren debilidades en los sistemas y nuevos factores de ataque, que podrían convertirse en una brecha de seguridad explotada por personas malintencionadas. Las pérdidas ocasionadas por un ciberataque pueden ser incalculables e irrecuperables si no se está preparado.

Para garantizar la máxima seguridad de los activos, no sólo es importante mantener los sistemas actualizados. Se debe ser minucioso en el diagnóstico y blindaje de las debilidades de los sistemas. Análisis de vulnerabilidades, pruebas de penetración (pentesting) y búsqueda de sistemas desactualizados, son buenas prácticas que se deben realizar frecuentemente, con las que se consigue mitigar riesgos y fortalecer dispositivos y aplicaciones. 

La auditoría estática de código ayuda a prevenir vulnerabilidades durante el desarrollo antes de su ejecución. En esta oportunidad os dejamos brevemente el uso de algunas de las aplicaciones punteras para visualizar los errores de calidad en el código y el uso de plugins de seguridad para identificar vulnerabilidades.

SonarQube 

Es una herramienta de revisión automática de código para detectar errores y vulnerabilidades potenciales en su código. Se puede integrar con su flujo de trabajo existente para permitir la inspección continua de código en todas las ramas de su proyecto.

Para instalar la aplicación basta con descargarnos el .zip desde aquí.

Requisitos para la instalación:

• Se debe tener instalado Java en su última versión.
• En el caso de que se disponga del JRE en su versión 8, se debe acceder al archivo de wrapper.conf el cual se encuentra en la carpeta \conf y debemos agregar la ruta donde tenemos el JDK en su versión posterior a 11.

Una vez que se cumplan los requisitos accedemos a la carpeta del sonar.

Desde Windows accedemos al símbolo de sistema ingresamos en la ruta \sonarqube-X.X\bin, y luego inicie el servidor ejecutando el comando

C:\sonarqube-X.X\bin\StartSonar.bat

Desde otro sistema operativo descomprímalo, y luego inicie el servidor ejecutando el comando

/opt/sonarqube/bin/[OS]/sonar.sh console

Una vez lanzado el comando se levantará la interfaz la cual accederemos desde http: // localhost: 9000 con credenciales de administrador del sistema (admin / admin), las cuales deben ser cambiadas una vez ingresado al sistema por primera vez, adicional se debe generar un token para aumentar la seguridad de su instalación al no permitir que la contraseña de su usuario de análisis atraviese su red. 

Ahora se debe descargar el sonar-scanner una vez descargado, se copia el código fuente a analizar y se pega dentro de la carpeta \bin de la aplicación sonar-scanner.

Se debe crear un fichero de configuración en la misma carpeta \bin, llamado sonar-project.properties.

#ID del Proyecto
sonar.projectKey=Mi_proyecto
#Nombre del Proyecto
sonar.projectName= Mi_proyecto proyecto
#Versión del Proyecto
sonar.projectVersion=2.0
#Ruta donde copiamos el proyecto
sonar.source=/bin/miproyecto

Se procede a configurar el perfil de seguridad, se establece por defecto en este caso para java.

Una vez configurado, se procede a ejecutar el análisis con el comando sonar-scanner, desde la misma ruta.

Al finalizar el escaneo nos mostrará una URL para visualizar los resultados en html.

Al ingresar a la URL generada http://localhost:9000/dashboard?id=Mi_proyecto

Podemos observar los resultados.

Al acceder a cada ítem, se puede ir verificando las vulnerabilidades potenciales en el código y su respectiva solución.

Podemos seleccionar ver regla, de esta manera nos dice cuál es la mejor forma de solucionar lo detectado, indicando el código que se debería usar.

Para poder descargar el informe del análisis realizado, procedemos a descargar el plugin desde el market de la aplicación al cual se accede desde la pestaña superior de Administración y buscamos el plugin sonar-cnes-report lo instalamos, al reiniciar el servidor ya podemos hacer uso del mismo.

Una vez instalado lo veremos en la barra superior, lo seleccionamos, y al seleccionar el proyecto, nos permite generar su informe.

Descargando un .zip en nuestra máquina donde podremos ver la siguiente información.

Un informe en el cual posee gráficas y lo encontrado durante el análisis, una tabla dinámica con todos los problemas y la configuración de análisis de código.

Para complementar el análisis estático, se usará una herramienta que verifica si las dependencias usadas son vulnerables, comparándolas con la biblioteca de vulnerabilidades del Instituto Nacional de Estándares y Tecnología (NIST)

Dependency-Check 

Es una herramienta de análisis estático de software (SCA) que intenta detectar vulnerabilidades divulgadas públicamente contenidas dentro de las dependencias de un proyecto. Lo hace determinando si hay un identificador de enumeración de plataforma común (CPE) para una dependencia determinada. Si se encuentra, generará un informe que vincula a las entradas (CVE) asociadas.

Descarga directa desde aquí.

Es necesario conexión a internet para el uso de esta herramienta, si el servidor donde se va a ejecutar no posee salida a internet, es necesario descargarse directamente la biblioteca donde se encuentran todas las vulnerabilidades para que la aplicación pueda realizar el chequeo correspondiente, se debe descargar el siguiente .jar desde aquí.

Luego ejecutarlo:

java -jar nist-data-mirror.jar < directorio-espejo > [xml | json]

La verificación de dependencia se puede usar actualmente para escanear aplicaciones Java y .NET para identificar el uso de componentes vulnerables conocidos. Analizadores experimentales para aplicaciones Python, Ruby, PHP y Node.js; estos son experimentales debido a las posibles tasas de falsos positivos y falsos negativos. 

¿Cómo funciona el control de dependencia?

La verificación de dependencia funciona mediante la recopilación de información sobre los archivos que escanea utilizando analizadores. La información recopilada se llama Evidencia; Hay tres tipos de evidencia recopilada: proveedor, producto y versión. Por ejemplo, JarAnalyzer recopilará información del manifiesto, pom.xml, y los nombres de los paquetes dentro de los archivos JAR escaneados y tiene heurística para colocar la información de las diversas fuentes de evidencia.

Ejemplo:

 <entry id = "CVE-2012-5055">
  ...
    <vuln: lista de software vulnerable>
      <vuln: product> cpe: / a: vmware: springsource_spring_security: 3.1.2 </ vuln: product>
      <vuln: product> cpe: / a: vmware: springsource_spring_security: 2.0.4 </ vuln: product>
      <vuln: product> cpe: / a: vmware: springsource_spring_security: 3.0.1 </ vuln: product>
    </ vuln: lista de software vulnerable>
  ...
  </entry>

Estas entradas de CPE se leen "cpe: / [Tipo de entrada]: [Proveedor]: [Producto]: [Versión]: [Revisión]: ...". Los datos de CPE se recopilan y almacenan en un índice de Lucene. Dependency-Check usa la evidencia recopilada e intenta hacer coincidir una entrada del Índice Lucene CPE. Si se encuentra, el CPEAnalyzer agregará un identificador a la dependencia y posteriormente al informe. Una vez que se ha identificado un CPE, las entradas CVE asociadas se agregan al informe.

Un punto importante sobre la evidencia es que se califica utilizando diferentes niveles de confianza: bajo, medio, alto y crítico. Estos niveles de confianza se aplican a cada elemento de evidencia. Cuando se determina el CPE, se le da un nivel de confianza que es igual al nivel de evidencia de nivel más bajo, utilizado durante la identificación. Si solo se usó evidencia de mayor confianza para determinar el CPE, entonces el CPE tendría un nivel de confianza más alto.

Debido a la forma en que funciona la verificación de dependencia, pueden existir falsos positivos y falsos negativos. 

Dependency-check no utiliza actualmente hashes de archivos para la identificación. Si la dependencia se creó desde el origen, el hash probablemente no coincidirá con el hash "publicado". Si bien el mecanismo basado en la evidencia utilizado actualmente también puede ser poco confiable, la decisión de diseño fue evitar mantener una base de datos hash de bibliotecas vulnerables conocidas. 
 
Cómo leer los informes

Una vez finalizado el análisis, creara un informe en html, en la parte superior del informe contiene una lista de los componentes vulnerables identificados. Al hacer clic en el enlace 'Mostrar dependencias vulnerables', la lista se ampliará para incluir todas las dependencias analizadas:

• Dependencia: El nombre de archivo de la dependencia analizada.
• CPE: Cualquier identificador de enumeración de plataforma común encontrado.
• GAV: El grupo Maven, artefacto, versión (GAV).
• Gravedad más alta: La gravedad más alta de cualquier CVE asociada.
• Recuento de CVE: El número de CVE asociadas.
• Confianza CPE: Una clasificación de qué tan confiable es la verificación de dependencia de que el CPE se identificó correctamente.
• Recuento de pruebas: La cantidad de datos extraídos de la dependencia que se utilizó para identificar el CPE.