Joven hacker sonriendo

Hackeamos su software

cero falsos positivos

Inteligencia experta + Tecnología especializada
DXST - SAST - IAST - SCA - DevSecOps
Caja blanca - Caja gris - Caja negra
Atacando Aplicaciones Web, APIs, Apps Móviles,
Cliente Servidor, Servidores, Redes, Dispositivos IoT
IoT SCI: Sistemas de Control Industrial

Retos Técnicos

Esta etapa es paralela a las demás etapas del proceso y por ende, entre más avances desde ahora en ella, mayor es la probabilidad que cuando finalicen las demás etapas, puedas ser evaluado antes que los demás participantes.

También puede considerarse como una especie de salvavidas en el proceso, pues puedes no estar graduado, no tener experiencia, o que el resultado de tu examen de conocimiento sea bajo, pero si fuiste capaz de finalizar esta etapa, habrás evidenciado que tienes la competencia más valiosa: aprender de cosas nuevas sobre la marcha y aplicarlas para resolver problemas reales. Esto, con la calidad humana, y fuertes valores tienen mayor peso que todo lo demás.

1. Filosofía

En esta etapa se busca que evidencies, mediante ejercicios prácticos, tus competencias técnicas en problemas parecidos a los que enfrentarás en Fluid Attacks, y con las cuales podrás solucionar de forma efectiva problemas de nuestros clientes en el ámbito de la seguridad. También demuestra que serás un compañero valioso para enriquecer a los miembros actuales del equipo de trabajo.

Los retos técnicos se dividen en retos de hacking y retos de programación. Con los primeros demuestras tu habilidad y astucia para sobrepasar controles de seguridad. Con los segundos demuestras que estás en capacidad de rápidamente entender un programa, comprender un lenguaje y por ende, te será más fácil auditar código fuente y encontrar vulnerabilidades.

La filosofía es fomentar el aprendizaje a partir de la solución activa de problemas y desestimular el aprendizaje pasivo.

El repositorio contiene las soluciones a retos computacionales públicos construidos en el contexto anterior. Al hacer los retos públicos buscamos:

  1. Fomentar la solución de retos no resueltos.

  2. Si el reto está resuelto, fomentar la solución del reto de otra forma.

  3. Si el reto está resuelto, hacer evidente la similitud de la nueva solución.

  4. Darles vida a las soluciones financiadas por Fluid Attacks.

  5. Permitir a terceros visualizar los entregables de nuestro equipo.

Los efectos colaterales de esta decisión permiten a Fluid Attacks:

  1. Utilizar la infraestructura de GitLab para analizar la calidad y velocidad del desarrollo de las personas en formación,

  2. Desde etapas tempranas familiarizar a potenciales talentos con las herramientas (Git, AsciiDoc, Python, Gherkin, etc) y conceptos (automatización, pruebas de unidad, integración continua, linting, etc.) que utilizarán en su labor diaria en Fluid Attacks,

  3. Hacer visible a la comunidad y al equipo los resultados propios (presión de pares).

2. Objetivos

  1. Resolver 10 retos de programación.

  2. Resolver 10 retos de hacking.

3. Condiciones

  1. El entrenamiento es auto-dirigido e independiente (por tu propia cuenta sin instrucción o ayuda alguna de otro).

4. Criterios

Las soluciones de retos, independiente si son de programacion o de hacking, siempre deben adherirse a la guía de estilo. Las soluciones de programación deberán cumplir adicionalmente con lo siguiente:

  1. No deben tener solución en el repositorio (carpeta del reto) para el lenguaje elegido por ti.

  2. No deben tener solución externa indexada (enlaces OTHERS.lst del reto) para el lenguaje elegido por ti.

  3. El lenguaje de la solución es uno de los aceptados por Codeabbey

  4. Los comandos de compilación y/o linting utilizados, y su salida, deben estar como preludio al inicio del código.

    milogin.rs
    1
    2
    3
    4
    5
    6
    7
    8
    9
    /*
    $ rustup run nightly cargo clippy
    Compiling milogin v0.1.0 (file:///../skhorn)
    Finished dev [unoptimized + debuginfo] target(s) in 0.22 secs
    $ rustc milogin.rs
    $
    */
    
    My solution's first line.
    
  5. Los comandos de ejecución utilizados, y su salida, deben estar como posludio al final del código.

    1
    2
    3
    4
    5
    6
    My solution's last line.
    
    /*
    $ ./skhorn
    over obese obese normal obese obese obese obese ...
    */
    
  6. Si la solución opera sobre un conjunto de datos de entrada, éstos no deben estar quemados en código, es decir, deben leer del archivo DATA.lst en el directorio del reto. Si no existe, debes incluirlo en tu commit.

Las soluciones de retos de hacking deberán cumplir con lo siguiente:

  1. No deben tener solución en Gherkin (*.feature) en el repositorio (carpeta del reto).

  2. No deben tener solución externa indexada (enlaces OTHERS.lst del reto).

  3. Deben ser retos que requieran nivel técnico (no matemático ni de adivinanzas) de WeChall o sus sitios relacionados.

  4. (Opcionalmente) Pueden ser retos que correspondan a explotación en sistemas (ToE) vulnerables intencionalmente listados en:

  5. El formato Gherkin a utilizar debe adherirse estricamente a lo descrito aquí

  6. El código fuente de la solución debe seguir los parámetros de estilo de esta guía

  7. La solución debe haber pasado sin errores ni warnings por un linter del lenguaje correspondiente en su configuración más estricta posible.

5. Puntaje

A medida que realices soluciones a retos, debes reportar el puntaje, ranking y score obtenidos, lo cual permitirá evidenciar tu progreso en esta etapa. Todos estos datos deben ir en el commit message de acuerdo al formato indicado en las reglas de envío.

A continuación, se indica cómo obtener los puntajes y posiciones en el ranking de cada plataforma.

5.1 Programación

  1. Ranking mundial

    1. Ir a la pestaña Ranking en la página de codeabbey: Ranking mundial codeabbey

    2. Baja hasta el final de la página y allí encontrarás tu posición en el ranking mundial: Ranking mundial codeabbey

  2. Ranking Colombia

    1. Estando en la pestaña Ranking, seleccionar el país Ranking Colombia

    2. La página no muestra directamente tu posición, por lo que deberás realizar el conteo manualmente. Puedes facilitar la tarea teniendo en cuenta que cada página muestra 50 usuarios. Deberás avanzar a la siguiente página hasta encontrar tu nombre de usuario en el tablero de ranking. Ranking Colombia codeabbey

5.2 Hacking

Ranking en WeChall

6. Envío

Las soluciones se envían mediante Merge Request (MR) a la rama master del repositorio training. Antes de realizar un MR por favor verifica que cumple con los siguientes criterios:

  1. Solo debes trabajar en una rama cuyo nombre es exactamente tu nombre de usuario en Gitlab.

  2. Todos los archivos relacionados con la resolución de retos deben respetar la estructura indicada

  3. Si la solución requiere archivos adicionales debes incluirlos en el directorio del reto correspondiente.

  4. Cada solución a un reto debe enviarse con 10 soluciones externas (10 URLs en archivos OTHERS.lst).

  5. La solución y los archivos relacionados deben enviarse en 1 solo commit.

  6. Cada commit de solución de retos debe ir en 1 solo MR.

  7. El MR debe realizarse solo cuando tu rama ha integrado satisfactoriamente (verde).

  8. Si el MR es rechazado no debe reabrirse, deben corregirse los problemas indicados y hacer un nuevo MR.

  9. El mensaje de commit para enviar la solución debe adherirse a una de las dos plantillas para retos de hacking de WeChall y retos de programación o para vulnerabilidades de sistemas.

7. Externas

Las reglas para los enlaces (URLs) a soluciones externas (OTHERS.lst) son las siguientes:

  1. Deben ser enlaces directos (HTTP 200) y sin redirección (HTTP 302).

  2. No tienen que ser del mismo reto del que se sube la solución.

  3. Deben ser de hacking si se está solucionando un reto de hacking.

    1. Deben ser OTHERS.lst nuevos, es decir, soluciones externas a retos del cual no tengamos solución externa alguna.

    2. Si tu solución es de hacking de sistemas (systems), las soluciones externas deben ser de hacking de sistemas también.

  4. Los OTHERS.lst deben ser de programación si se está solucionando un reto de programación.

    1. No debes añadir soluciones externas para un lenguaje del que ya se tenga solución externa.

    2. Dentro de un OTHERS de programación las URLs deben estar ordenadas alfabéticamente por extensión,

  5. Si está en Github, la URL debe ser su versión raw (https://raw.githubusercontent.com/),

8. Ejemplos

A continuación presentamos los enlaces para diferentes tipos de MR:

Ejemplos de MR aceptados en el pasado:

  • MR ejemplares de hacking: 1, 2, 3

  • MR ejemplares de programación: 1, 2, 3

Nota Estos enlaces ejemplares no necesariamente siguen todas las reglas mencionadas pues las reglas evolucionan y por ende, en el momento que se hicieron, las reglas pudieron ser otras. En ningún momento los ejemplos tienen prioridad sobre las reglas, sin embargo se relacionan como ejemplo para propósitos pedagógicos.

9. Recomendaciones

  1. Para cumplir los objetivos enunciados, se sugiere buscar retos que no tengan solución ni en OTHERS ni en el repositorio y trabajar en resolver el reto en la respectiva plataforma. Para esto, puedes apoyarte usando el siguiente script.

  2. Al momento de solucionar retos de programación, se sugiere usar un lenguaje no muy usado y resolver los retos en dicho lenguaje.

  3. Solucionar un reto e inmediatamente hacer su envío. No acumules soluciones en tu computador sin enviarlas, pues de este modo nunca tendrás realimentación de lo que estés haciendo de forma errónea y te puede generar múltiples reprocesos tener que corregir tus soluciones más adelante.

10. Repositorio

El envío de soluciones se realizará en el siguiente repositorio git

Es ideal que te familiarices con el versionamiento y la estructura que detallamos a continuación.

10.1 Estructura

Los soluciones a los retos se almacenan en las siguientes carpetas:

Carpeta

challenges

system

Descripción

Carpeta para almacenar retos de programación y hacking.

Carpeta exclusiva para retos de explotación de sistemas vulnerables

Estructura

  • sitio (directorio)

    • código del reto (directorio)

      • login-gitlab.ext (archivo de solución)

  • nombre del sistema o caja vulnerada (directorio)

    • nombre de la explotación realizada (directorio)

      • login-gitlab.feature (archivo de solución)

Ejemplo

El nombramiento de todos los archivos y directorios, a excepción de tus archivos especiales, no debe superar los 35 caracteres, debe realizarse en minúscula, sin caracteres especiales y en caso de requerir espacios usar - (guión) como sustituto.

10.2 Archivos

En algunas carpetas de la estructura se encuentran algunos archivos especiales de control:

  • LINK.lst: Contiene la URL al enunciado del reto en la plataforma correspondiente (ejemplo). Este archivo solo debe contener una linea y visitar el enlace debe generar la respuesta HTTP 200 (sin redirección).

  • DATA.lst: Contiene los casos de prueba con los cuales se han verificado los retos. Este archivo solo debe contener casos de prueba que sean inmediatamente procesables por cualquier archivo de solución.

  • OTHERS.lst: Contiene los enlaces a las soluciones a dicho reto que se encuentran en Internet y que no deben leerse ni utilizarse como referencia para resolver el reto. Este archivo permite que un script automático realice el análisis de similitud con los retos enviados por los candidatos. Deben cumplir con lo indicado aquí

  • SPEC.txt (en systems y programación) y spec.yml (en retos de WeChall): Contiene las especificaciones del sitio de retos o máquina vulnerable con la que se está trabajando, como número de retos o vulnerabilidades, URL y dificultad. Puedes ver un ejemplo aquí.

11. Inicio

Para comenzar esta etapa, deberás:

  1. Registrarte en GitLab usando tu correo electrónico personal y creando el ID de usuario que más te guste. Este ID no debe ser mayor a 12 caracteres y solo estar compuesto de letras minúsculas y/o números.

  2. Unirte a nuestro canal de Slack, en donde encontrarás personal de Fluid Attacks y otros candidatos actualmente en esta etapa, quienes podrán guiarte en caso de tener dudas o inconvenientes.

  3. Solicitar el permiso de acceso al repositorio vía Slack presentándote a los demás en el canal #general con el siguiente mensaje:

He leído y entendido toda la documentación de los retos técnicos, acepto las condiciones y por ende solicito acceso al repo Git con mi usuario [nombre-usuario] en GitLab

12. Fin

La etapa de retos técnicos finaliza en cualquiera de las siguientes circunstancias:

  1. Has completado los objetivos y enviaste vía email los enlaces en master de sus soluciones.

  2. No has tenido movimiento (push al repositorio Git) en 14 días calendario.

  3. Has alcanzado el tope máximo de 10 MR fallidos, esto es, MR que no se le hace merge por cuestiones detalladas en la documentación y que aun así se incumplen.

  4. Si explícitamente manifiestas mediante e-mail tu deseo para retirarse del proceso.

  5. Si presentas como propias soluciones totales o parciales realizadas por otra persona (plagio).

  6. Si realizas soluciones a retos con ayuda de terceros.

En todos los casos la dirección de correo para estos pasos es: careers@autonomicmind.co

Si fuiste retirado por alguna de estas circunstancias, exceptuando las dos últimas, puedes volver a presentarte en cualquier momento y volver a comenzar el proceso haciendo click aquí

13. Builds

Es posible correr integraciones locales con el fin de identificar errores antes de hacer push o merge requests al repositorio.

Para esto, se deben ejecutar los siguientes comandos:

  • En Sistemas Operativos GNU/Linux:

Instalar curl
1
2
sudo apt-get update
sudo apt-get install curl
Instalar Nix
1
curl https://nixos.org/nix/install | sh
Definir tus credenciales de acceso
1
2
export DOCKER_USER=usuario-gitlab
export DOCKER_PASS=contraseña-gitlab
Compilar y probar
1
./build.nix
Si la integración fue exitosa, hacer commit y añadir los cambios a tu rama personal
1
2
3
git add .
git commit
git push origin rama-personal
  • En Sistemas Operativos Windows: La forma de ejecutar la integración no se encuentra todavía disponible para Windows y al basarse la integración en Linux, esto hace que el proceso en Windows sea más complicado.

Se sugiere instalar el software de virtualización Vagrant y sobre este, el sistema operativo Debian de la siguiente manera:

Instala VirtualBox y Vagrant de acuerdo a tu versión de Windows.

Crea un directorio para tu Vagrant box y ubícate en él:
1
2
3
C:\ejemplo\> mkdir mybox
C:\ejemplo\> cd mybox
C:\ejemplo\mybox>
Inicia el box y entra a él:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
C:\ejemplo\mybox> vagrant init debian/stretch64
C:\ejemplo\mybox> vagrant up
C:\ejemplo> vagrant ssh
Linux stretch 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Apr 16 17:49:58 2018 from 10.0.2.2
vagrant@stretch:~$

A partir de ese momento ya no estás en Windows sino en Debian Stretch.

Instala Docker dentro del box:

Instalar prerrequistos para agregar repositorios a Debian
1
2
3
vagrant@stretch:~$ sudo apt-get update
vagrant@stretch:~$ sudo apt-get install -y apt-transport-https curl \
                        ca-certificates software-properties-common
Agregar el repositorio de Docker
1
2
3
4
5
vagrant@stretch:~$ curl -fsSL https://download.docker.com/linux/debian/gpg \
                        | sudo apt-key add -
vagrant@stretch:~$ sudo add-apt-repository \
                   "deb [arch=amd64] https://download.docker.com/linux/debian \
                   $(lsb_release -cs) stable"
Instalar y habilitar Docker para el usuario Vagrant del box
1
2
3
vagrant@stretch:~$ sudo apt-get update && sudo apt-get install docker-ce
vagrant@stretch:~$ sudo usermod -aG docker vagrant
vagrant@stretch:~$ sudo systemctl start docker && sudo systemctl enable docker

Ya puedes seguir los pasos descritos arriba para correr la integración.

14. Preguntas

  • Antes de realizar una pregunta, por favor lee nuevamente este documento y las preguntas realizadas en el pasado por otros participantes.

  • Puede expresar tus dudas en el canal #general de nuestro Slack.

15. Propiedad

  • Los derechos patrimoniales sobre el contenido de este repositorio se encuentran definidos en el archivo COPYRIGHT.

  • La licencia y privilegios que tienen los usuarios de este repositorio se encuentran definidos en el archivo LICENSE.

  • Realizar un merge request implica la cesión de derechos patrimoniales. Por ende, la información aquí contenida puede ser usada por Fluid Attacks para cualquier fin comercial, siempre preservando los derechos morales de sus autores.

16. Plagio

Tener las soluciones disponibles para su visualización propone un reto para el plagio, ¿cómo mostrarle al mundo las soluciones y evitar el plagio? El plagio no es un problema técnico, es un problema moral de atribuirse lo que no fue realizado por uno mismo como propio.

Para evitar el plagio buscamos la visibilidad y la declaración explicita de autoría de cada algoritmo en un lugar centralizado y así, queda evidencia clara de la atribución y puede ser sometido a escrutinio público el acto de plagio.

Es decir, el modelo actual propuesto evita el plagio a partir de la transparencia total.

Igualmente, Fluid Attacks trabaja activamente en aplicar técnicas de detección de similitud algorítmica sobre todo el código que sea enviado. En particular usando:


Estado de los servicios - Términos de Uso