Joven hacker sonriendo

Hackeamos su software

cero falsos positivos

Inteligencia experta + tecnología especializada

Asserts

1. Descripción

Asserts es un motor de automatización de cierre de hallazgos de seguridad sobre ambientes en ejecución (DAST).

Asserts
Figura 1. Caso de uso

2. Instalación

Asserts está alojado PyPI, de modo que puedes instalarlo fácilmente utiizando pip3 en un sistema con Python3:

asserts installation
1
$ pip3 install -U fluidasserts

Para uso normal o interactivo se debe configurar la variable FA_STRICT a false en sistemas operativos similares a UNIX (como se muestra a continuación):

1
$ export FA_STRICT="false"

En Windows:

1
> set FA_STRICT="false"

Ahora, estás listo para empezar con las pruebas de cierre de vulnerabilidades.

Instalación en un contenedor de Docker

Si tienes Docker puedes descargar y ejecutar Asserts dentro de un contenedor, para ello ejecuta el siguiente comando:

1
$ docker pull fluidattacks/asserts

Y luego entra al contenedor:

1
2
$ docker run -it fluidattacks/asserts sh
/ # asserts
1
2
3
4
5
#  ___
# | >>|> fluid
# |___|  attacks, we hack your software
#
# Loading attack modules ...

Es necesario asegurarse de realizar el docker pull antes de cada ejecución del contenedor para asegurar que se está utilizando la versión más reciente de Asserts.

Una vez dentro del contenedor es posible ejecutar Asserts desde el shell interactivo de Python o contruir rápidamente un script utilizando vi. Pero sería mucho más útil montar el directorio donde se localiza el exploit en el contenedor.

1
2
$ docker run -v /home/me/myexploits/:/exploits/ -it fluidattacks/asserts sh
/ # asserts /exploits/open-sqli.py
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#  ___
# | >>|> fluid
# |___|  attacks, we hack your software
#
# Loading attack modules ...

check: fluidasserts.proto.http.has_sqli
status: OPEN
message: A bad text was present
details:
  bad_text: Warning.*mysql_.*
  fingerprint:
    banner: "Server: nginx/1.4.1\r\nContent-Type: text/xml\r\nTransfer-Encoding: chunked\r\
      \nConnection: keep-alive\r\nX-Powered-By: PHP/5.3.10-1~lucid+2uwsgi2"
    sha256: 588702eb0b53294654f934d86664956e9739db47c34ffd8d703550cd5fd670a0
  url: http://testphp.vulnweb.com/AJAX/infoartist.php?id=3%27
when: 2018-09-06 08:33:08.781518

Uso en un pipeline de integración continua (CI)

Si tienes una aplicación suscrita a nuestro servicio de hacking continuo el cual incluye el uso de Asserts, es posible integrarlo en tu pipeline de CI para garantizar que tu software se construya y entregue sin vulnerabilidades abiertas. Entregaremos un contenedor Docker personalizado con las pruebas específicas necesarias para mantener la ruptura de builds con el exploit.

Para lograr esto, sigue los siguientes pasos:

  1. Agrega las variables de entorno requeridas: USER, PASS, ORG y APP. No te preocupes, los valores serán entregados por nosotros!:

    • USER: Nombre del usuario del registro de nuestro contenedor.

    • PASS: La contraseña del usuario.

    • ORG: El nombre de la organización.

    • APP: El nombre de la aplicación.

      Por ejemplo, en Gitlab, tu entorno podría verse así:

      Variables de entorno de Gitlab
  2. Agregar un job para ejecutar Asserts. Por ejemplo en Gitlab, agregarías una de estas tres líneas a tu archivo .gitlab-ci.yml:

    asserts in gitlab
    1
    2
    3
    4
    5
    6
    7
    8
    fluidasserts:
      script:
        - docker login fluid-docker.jfrog.io -u "$USER" -p "$PASS"
        - docker pull fluid-docker.jfrog.io/"$ORG":"$APP"
        - docker run -e ORG="$ORG" -e APP="$APP" -e USER="$USER"
                     -e PASS="$PASS" -e FA_STRICT="true" --rm
                     fluid-docker.jfrog.io/"$ORG":"$APP"
        - docker logout fluid-docker.jfrog.io
    
  3. A partir de ahora, tu pipeline fallará si se encuentra alguna vulnerabilidades abierta. Para evitar romper el build pero aún así correr las pruebas, cambia el valor de la variable FA_STRICT a false.

Etapas CI

De acuerdo, estoy dentro. Pero en qué etapa debería probar mi aplicación con Asserts ? Existen al menos 3 buenos momentos para ejecutar una prueba de cierre:

  1. Luego de desplegar a un ambiente efímero o real.

  2. Luego de desplegar al ambiente de producción.

  3. Luego de cada commit !

Post-producción

Al igual que antes, iniciamos sesión en el repositorio de artefactos, actualizamos la imagen personalizada, y la ejecutamos con Docker. Esta vez, sin embargo, montamos el volumen correspondiente al commit actual al directorio /code en el contenedor, debido a que el contenedor ya está configurado para probar el código allí almacenado. Este job sólo se ejecuta en la rama master y en una de las últimas etapas, llamada post-deploy

post-deploy
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
asserts-prod:
  stage: post-deploy
  script:
    - docker login fluid-docker.jfrog.io -u "$USER" -p "$PASS"
    - docker pull fluid-docker.jfrog.io/"$ORG":"$APP"
    - docker run -e ORG="$ORG" -e APP="$APP" -e USER="$USER" -e PASS="$PASS"
                 -e FA_STRICT="true" --rm -e STAGE=post-deploy
                 -v /tmp${CI_PROJECT_DIR}/${CI_COMMIT_REF_NAME}:/code
                 fluid-docker.jfrog.io/"$ORG":"$APP"
    - docker logout fluid-docker.jfrog.io
  retry: 2
  only:
    - master

Post-efímero

Pero espera! podemos evitar algunos bugs antes de realizar el despliegue a producción. Si utilizas ambientes efímeros, también puedes ejecutar pruebas de cierre en éstos:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
Asserts-Review:
  stage: test
  script:
    - docker login fluid-docker.jfrog.io -u "$USER" -p "$PASS"
    - docker pull fluid-docker.jfrog.io/"$ORG":"$APP"
    - docker run -e ORG="$ORG" -e APP="$APP" -e USER="$USER" -e PASS="$PASS"
                 -e FA_STRICT="true" --rm -e STAGE=test
                 -e BRANCH="$CI_COMMIT_REF_SLUG"
                 -v /tmp${CI_PROJECT_DIR}/${CI_COMMIT_SHA}:/code
                 fluid-docker.jfrog.io/"$ORG":"$APP"
    - docker logout fluid-docker.jfrog.io
  retry: 2
  except:
    - master
    - triggers

En contraste con el job anterior de post-despliegue, este corre en las ramas de desarrollo, durante la etapa de pruebas (test). Aparte de esto, todo lo demás sigue siendo igual, justo como iniciar un ambiente de producción espejo.

Pre-commit

Como desarrollador, puede que te estés preguntando: "¿Por qué debo esperar a que todas las etapas de CI terminen si solo quiero probar si mi ultimo commit reparó la brecha de seguridad?" Puedes correr Asserts localmente en tu máquina, pero a veces algunos pequeños detalles (como las versiones de las dependencias) pueden causar que la prueba pase exitosamente de forma local pero falle en la integración continua.

En ese caso, puedes utilizar la versión Dockerizada de Asserts como un hook del pre-commit:

pre-commit
1
2
3
4
5
- id: asserts-docker
  name: Running Asserts on the code
  description: Run Asserts to perform SAST
  entry: -v /path/to/your/code/:/code fluidattacks/asserts:latest /code/asserts.sh
  language: docker_image

Esta configuración en particular funciona para la herramienta pre-commit pero puede ser adaptada a herramientas similares como overcommit. El uso de dichas herramientas es conveniente para el desarrollador, ya que las pruebas pueden ser ejecutadas rápidamente en sus máquinas con cada commit:

Pre-commit test passed
Pre-commit test failed

Las mismas pruebas pueden ser ejecutadas en tiempo de CI (por ejemplo, en una entapa de lint) para garantizar que nada se ha "roto" incluso si el desarrollador olvida ejecutarlo. Para ello sólo coloca la siguiente línea:

1
pre-commit run --all-files

En algún lugar de tu script de CI.


Estado de los servicios - Términos de Uso