Analytics

jueves, 29 de septiembre de 2022

Auditar código fuente y no morir en el intento

¿Te han asignado una auditoría de código y no sabes por dónde empezar? Estás en el lugar correcto. Pero antes, ¿Sabes qué es una auditoria de código y en qué consiste?

Siguiendo la definición de la Guía de revisión de código de OWASP, "la revisión del código es una forma de ayudar a garantizar que la aplicación se ha desarrollado de manera que se "autodefienda" en su entorno determinado". Es decir, debemos realizar las comprobaciones pertinentes para verificar que están presentes los controles lógicos y de seguridad adecuados, que funcionan como se pretende y que se han invocado en los lugares correctos.

La revisión del código permite a una empresa asegurarse que los desarrolladores de aplicaciones siguen técnicas de desarrollo seguras. Una regla general es que una prueba de intrusión no debería descubrir ninguna vulnerabilidad adicional de la aplicación relacionada con el código desarrollado después de que la aplicación se haya sometido a una revisión de código adecuada, o al menos, sólo deberían descubrirse vulnerabilidades de baja criticidad.

A la hora de efectuar este tipo de tareas podemos diferenciar dos caminos. Por un lado, realizar las auditorias manuales, haciendo búsquedas de palabras clave, o leyendo el código fuente desde el principio hasta el final. Y la otra vertiente, es el uso de las herramientas automáticas.

Ambas opciones tienen ventajas y desventajas. Las herramientas automáticas reducen el tiempo de revisión de código, frente a hacerlo de manera manual, línea a línea. Otro aspecto para tener en cuenta es que las herramientas automáticas se adaptan a cualquier tipo de lenguaje, y se pueden lanzar de manera repetida, mientras que de forma manual depende del nivel de conocimientos que tenga el analista de ese lenguaje. De modo manual, el analista es capaz de examinar trozos de código independiente. Sin embargo, en muchos casos, las herramientas automáticas más fiables requieren de todo el código compilado para realizar sus análisis.

Como contrapartida, estas herramientas automáticas alertan de muchos falsos positivos. Puntos en los que se indica que hay código vulnerable y que finalmente no lo es. Y falsos negativos, puntos vulnerables en el código que no han sido identificados y que generan falsa sensación de seguridad. Estos últimos son los más peligrosos.

Es por ello que a la hora de realizar este tipo de ejercicios hay que combinar ambas estrategias.

¿Cómo empezar?

Un buen punto de partida es conocer la lógica del programa, saber si estamos analizando el desarrollo de un servicio a un banco, a una web de un comercio online o un videojuego nos facilitará el análisis.

El siguiente punto es, sabiendo al lenguaje que nos enfrentamos, conocer las vulnerabilidades existentes para esa tecnología, así como las librerías más utilizadas y sus funciones o métodos potencialmente vulnerables como, por ejemplo, en Java, conocer la versión vulnerable de la librería para logging, Log4j, en la que un atacante que pudiera controlar los mensajes de registro o los parámetros de los mensajes de registro podría ejecutar código arbitrario cargado desde servidores LDAP cuando la sustitución de búsqueda de mensajes estuviera habilitada.

Como recomendación, utiliza herramientas que te ayuden a identificar librerías o dependencias vulnerables. En este caso Dependency Check de OWASP, hace una comprobación de estas de tu proyecto, resumiendo en un HTML cuales son vulnerables, las veces encontradas en tu proyecto, así como nivel de criticidad de las vulnerabilidades asociadas.

¿Qué herramientas podemos usar?

Una de las herramientas más utilizadas para comprobar la seguridad del código es SonarQube, que cuenta con una versión para la comunidad, limitada en reglas semánticas y lenguajes, y otra versión de pago. En este caso, es recomendable su uso para aplicaciones compiladas. No obstante, SonarQube cuenta con un listado de reglas, a modo de documentación, en el que explica lenguaje a lenguaje aspectos a tener en cuenta, posibles bugs y mala implementación de métodos lo que permite usarlos de guía para búsquedas manuales en nuestro código.

Otra de las herramientas más utilizadas es CodeQL, aplicación basada en la búsqueda semántica a través de filtros complejos. Esta herramienta, creada por el equipo de desarrollo de Github, es capaz de automatizar análisis de código durante el desarrollo a través del repositorio en la propia plataforma.

Por último, SemGrep, herramienta que nace en Facebook. También basada en la búsqueda semántica a través de filtros. Es comúnmente usada para auditorías de código ya que entre sus principales ventajas está que no necesita código compilado para hacer el análisis, otra de las ventajas es la cantidad de lenguajes que soporta (Go, phyton, java, JS, TS, Rubi, C, PHP,…) y además dispone de una comunidad muy activa lo que se traduce en más de 1000 reglas predefinidas para tareas concretas. Y un mantenimiento activo cosa que es importante fijarse en herramientas open source.

Cuando accedemos a la página de Semgrep disponemos dos opciones: descargarlo para usarlo en modo local, donde además de la descargar de la app tenemos que bajarnos las reglar básicas con la que analizar código o utilizar la herramienta de manera online.

Referencias:

OWASP Code Review Guide
https://owasp.org/www-project-code-review-guide

Mitre CVE 2021-44228
https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2021-44228

OWASP Dependency check
https://owasp.org/www-project-dependency-check/

SonarSource rules
https://rules.sonarsource.com/

SemGrep
https://semgrep.dev/


Autor: Ismael de Frutos Díaz
Dpto. de Auditoría