Bienvenido a OMSTD (Open Methodology for Security Tool Developers)¶

En primer lugar vamos a solventar el problema del parámetro obligatorio y vamos a obligar a especificar un target:

1
2
3
4
5
6
7

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("-t", dest="targets", help="target", required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level', type=int)
parser.add_argument("--open", dest="only_open", help="only display open ports", default=0)
parser.add_argument("--port", dest="port", type=int, help="port to scan")

params = parser.parse_args()

Vemos cómo, tras en cambio, se obliga al usuario a especificar un target:

usage: st-005-p1.py [-h] -t TARGETS [-v VERBOSITY LEVEL] [--open ONLY_OPEN]
                    [-p PORTS_RANGE]
st-005-p1.py: error: the following arguments are required: -t

Vemos que las opciones verbosity (0-2) y port son tratadas como string (por defecto), pero realmente son del tipo int.

Añadimos la mejora:

1
2
3
4
5
6
7

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("-t", dest="targets", help="target", required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level', type=int)
parser.add_argument("--open", dest="only_open", help="only display open ports", default=0)
parser.add_argument("--port", dest="port", type=int, help="port to scan")

params = parser.parse_args()

Sería interesante contar con valores por defecto para cada tipo de parámetro.

De esta forma evitaremos errores, por ausencia de dichos valores por parte del usuarios, e introduciremos configuración predeterminada, lo que hará el uso de la herramienta más fácil:

1
2
3
4
5
6
7
8

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("-t", dest="targets", help="target", required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level', type=int, default=0)
parser.add_argument("--open", dest="only_open", help="only display open ports", default=0)
parser.add_argument("--port", dest="port", type=int, default=80,
    help="port to scan. Default: 80.")

params = parser.parse_args()

Si observamos, la opción –open, es realmente un booleano. Es decir, que solo necesitamos saber si está a True o a False.

Actualizamos para que dicha opción sea tratada como un booleano.

1
2
3
4
5
6
7
8
9

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("-t", dest="targets", help="target", required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level', type=int, default=0)
parser.add_argument("--open", dest="only_open", action="store_true",
    help="only display open ports", default=False)
parser.add_argument("--port", dest="port", type=int, default=80,
    help="port to scan. Default: 80.")

params = parser.parse_args()

Cuando tenemos muchas opciones en la linea de comandos, es intersante poder poner la opciones en formato más abrevidado.

Para nuestro ejemplo, cuando indicamos del puerto, podríamos crear la opción abreviada -p, además de --port como sigue:

1
2
3
4
5
6
7
8
9

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("-t", dest="targets", help="target", required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level', type=int, default=0)
parser.add_argument("--open", dest="only_open", action="store_true",
    help="only display open ports", default=False)
parser.add_argument("-p", "--port", dest="port", type=int, default=80,
    help="port to scan. Default: 80.")

params = parser.parse_args()

Existen ciertas opciones que tienen más sentido que su valor vaya incrementando en función de las veces que se repite. Por ejemplo:

• -v en lugar de 0.
• -vv en lugar de 1.
• -vvv en lugar de 2.

En nuestro ejemplo, dicho comportamiento es perfecto para el opación verbosity:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("-t", dest="targets", help="target", required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level: -v, -vv, -vvv.',
    action="count", type=int, default=0)
parser.add_argument("--open", dest="only_open", action="store_true",
    help="only display open ports", default=False)
parser.add_argument("-p", "--port", dest="port", type=int, default=80,
    help="port to scan. Default: 80.")

params = parser.parse_args()

Por último, puede que nos interese tener parámetro qeu no van precedidos de ninguna opción que empiece por -. Por ejemplo:

• main.py 127.0.0.1 en lugar de main.py -t 127.0.0.1.

Esta forma de configurar las opciones de la linea de comandos se conoce como opciones posicionales.

Entenderemos mejor esto con un ejemplo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

parser = argparse.ArgumentParser(description='OMSTD Example')
parser.add_argument("targets", metavar='TARGETS', help="targets to scan", nargs="+",
    required=True)
parser.add_argument('-v', dest='verbosity' help='verbosity level: -v, -vv, -vvv.',
    action="count", type=int, default=0)
parser.add_argument("--open", dest="only_open", action="store_true",
    help="only display open ports", default=False)
parser.add_argument("-p", "--port", dest="port", type=int, default=80,
    help="port to scan. Default: 80.")

params = parser.parse_args()

La linea de comando ahora se verá así:

usage: st-005-s1.py [-h] [-v] [--open] [-p PORT] TARGETS [TARGETS ...]

OMSTD Example

positional arguments:
  TARGETS               targets to scan

optional arguments:
  -h, --help            show this help message and exit
  -v                    verbosity level: -v, -vv, -vvv.
  --open                only display open ports
  -p PORT, --ports PORT
                        port to scan. Defaul: 80.

Una ver parseada la linea de comandos, en el objeto params, podremos obtener la lista de los parámetros posicionales leyendo el parámetro params.targets.

Suele ser muy útil para nuestros programas poner pequeños ejemplos al final de la ayuda que nos proporciona la opción -h. Para esto, usamos el parámetro epilog, del módulo argparse:

st-005-s1.py:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

    footed_description = """

    Usage examples:
        + Basic scan:
            %(name)s 127.0.0.1
        + Specifing port to test:
            %(name)s -p 443 127.0.0.1
        + Only diplay open ports
            %(name)s -p 139 127.0.0.1

    """"" % dict(name="st-005-s1.py")

    parser = argparse.ArgumentParser(description='OMSTD Example', epilog=footed_description,
                                     formatter_class=argparse.RawDescriptionHelpFormatter)
    parser.add_argument("targets", metavar='TARGETS', help="targets to scan", nargs="+")
    parser.add_argument('-v', dest='verbosity', default=0, action="count",
                        help="verbosity level: -v, -vv, -vvv.")
    parser.add_argument("--open", dest="only_open", action="store_true",
                        help="only display open ports", default=False)
    parser.add_argument("-p", "--ports", dest="port", type=int,
                        help="port to scan. Defaul: 80.", default=80)

    params = parser.parse_args()

Este es el aspecto que tendría al ejecutar st-005-s1.py -h:

usage: st-005-s1.py [-h] [-v] [--open] [-p PORT] TARGETS [TARGETS ...]

OMSTD Example

positional arguments:
  TARGETS               targets to scan

optional arguments:
  -h, --help            show this help message and exit
  -v                    verbosity level: -v, -vv, -vvv.
  --open                only display open ports
  -p PORT, --ports PORT
                        port to scan. Defaul: 80.

Usage examples:
    + Basic scan:
        st-005-s1.py 127.0.0.1
    + Specifing port to test:
        st-005-s1.py -p 443 127.0.0.1
    + Only diplay open ports
        st-005-s1.py -p 139 127.0.0.1

En Python es un proyecto que puede ser importado, para ser usado como librería.

Éstos deberían tener import relativos, para asegurarse que la librería importada es del propio paquete, y no otra del sistema que tenga el mismo nombre.

Podemos ver la importancia de las rutas relativas en el siguiente ejemplo:

Supongamos que nuestra aplicación de ejemplo lp-006-p1.py

1
2
3

from lp_006_p1.bad import *

lp_006_p1_fn()

El ejemplo tiene la estrutura:

1
2
3
4
5
6
7

lp_006_p1
    \__ random
        \__ __init__.py
    \__ __init__.py
    \__ bad.py
    \__ good.py
\__ lp-006-p1.py

El paquete random tiene el mismo nombre que el incluido en Python, por lo que si escribimos el siguiente código:

lp-006-p1/bad.py

1
2
3
4
5
6

from random import *

# ----------------------------------------------------------------------
def lp_006_p1_fn():

    print(HELLO_VAR)

Cuantro se trata de mostrar la variable HELLO_VAR, no será encontrada porque realmente estamos importando es el paquete global de Python, y éste no contiene dicha variable. Por tanto se nos mostrará el siguiente error:

Traceback (most recent call last):
  File "lp-006-p1.py", line 26, in <module>
    lp_006_p1_fn()
  File "examples/develop/lp/006/lp_006_p1/bad.py", line 30, in lp_006_p1_fn

    print(HELLO_VAR)
NameError: name 'HELLO_VAR' is not defined

Una definición informa de aplicación de Python es aquella que usa como programa independiente y que tiene como finalidad ser importado por una aplicación externa.

El fichero que contiene el punto de entrada a la aplicación, o main, no puede usar rutas relativas.

¿Por qué sucede esto?

Porque el uso de import relativos solo está permitido para paquetes y han de ser llamados desde paquetes externos, no pueden ser lanzados desde el propio paquete (por defecto).

Es decir, que si tenemos la estructura de directorios usada más arriba, el siguiente código no funcionará:

1

lp_006_p1_fn()

Y nos devolverá el error:

File "lp-006-p2.py", line 24, in <module>
   from .lp_006_p1.good import *
SystemError: Parent module '' not loaded, cannot perform relative import

A modo de resumen: No funciona porque se está usando una aplicación como un paquete.

Usar import relativos, en lugar de absolutos, cuando queramos importar paquetes locales y que éstos no se confundan con los globales u otros que podamos tener instalados.

Hay ocasiones en los que querremos usar una aplicación como un paquete como, por ejemplo:

Cuando queramos crear un paquete que, además, pueda ser usado como aplicación.

La solución: forzar la aplicación a que se comporte como un paquete.

La solución es la impotanción relativa o, lo que es lo mismo, indicar a Python que use el paquete local en lugar del global del sistema:

1
2
3
4
5
6

from .random import *

# ----------------------------------------------------------------------
def lp_006_p1_fn():

    print(HELLO_VAR)

hello!

Transformar una aplicación en un paquete no es nada intuitivo ni trivial. Tendremos que tener controlar:

• Detectar si la aplicación es parte de un paquete o no.
• Mover los import de la parte global al ámbido de la función que haga de punto de entrada. Es ha de ser así para que, cuando el intérprete de Python importe todo el código no ejecute ni cargue ninguna librería hasta que no hayamos transformado la aplicación en paquete.

El siguiente código solucionará nuestro problema:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Detect if applitaion is calling out of the box or inside a package.
if __name__ == "__main__" and __package__ is None:
    import sys
    import os

    # Load path of main program file (this file) as a part of path of python interpreter
    parent_dir = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
    sys.path.insert(1, parent_dir)

    # Load parent package as a common package
    import lp_006_p1

    # Set environment package to this package
    __package__ = str("lp_006_p1")
    del sys, os

    # Continue normally
    from .lp_006_p1.good import *

    lp_006_p1_fn()

Explicación line a linea:

• 1: Detectamos si el fichero es el punto de entrada a la aplicación (main) y si es un paquete.
• 7-8: Cargamos el directorio desde el que es llamado el programa en la lista de paquetes disponibles de Python.
• 11: Una vez añadido en el entorno de Python el directorio donde se encuentra nuestro fichero, cargamos el paquete padre, el que contiene el ejecutable, o .py.
• 14: Establecemos la variable de entorno __package__, indicándole a Python que si que existe un paquete.
• 18: Cargamos nuestra librerías con import relativos. Ahora ya no tendremos problemas.
• 20: Continuamos la ejecución de nuestro código, como lo haríamos normalmente.

Celery está formado por 3 piezas principales:

• Un broker.
• El servicio de Celery.
• La aplicación que interactúa con Celery, que será nuestra aplicación.

Esta animación puede que te ayude a comprender mejor su funcionamiento:

Una forma de estructurar Celery es (¡puede haber más!):

Como se puede ver la imagen anterior, tenemos las siguientes carpetas clave:

• framework/
  • framework/tasks/: Contiene nuestro código. Es el que contendrá los ficheros con los fuentes de nuestras tareas que queramos ejecutar.
  • framework/celery/: Contiene el único fichero celery.py con la información sobre cómo ha de ejecutarse Celery.

Archivos importantes:

framework/tasks/main_task.py

Este fichero contiene un ejemplo de código que se ejecutará como parte de una tarea. Dicha tarea se quedará a la espera que se le mande información para procesar.

En este ejemplo, cuando la tarea sea llamada, solamente mostrará un mensaje. Ésta es la forma más sencilla de crear tareas. Usando el decorador de Python @celery.task una función será convertida en una tarea.

framework/celery/celery.py

Contiene la información necesaria para cargar y configurar Celery. A continuación se muestran la lineas más importantes de este fichero:

start.py

Contiene la llamada a la tarea tipo Celery.

Nota

En Celery, para llamar a una tarea de forma asíncrona, debemos de hacerlo como en el ejemplo. Aunque nuestro código sea una función, celery se encargará internamente de convertirla en un objeto con métodos.

Las llamadas (o métodos) para llamar a la tarea son, según el API oficial:

• my_task.delay(...)
• my_task.apply_async(...)

Configuración:

Por defecto, Celery solo importa las tareas que tienen como nombre de fichero tasks.py. Usando un un pequeño truco, podemos localizar todos los ficheros con tareas de Celery, independientemente del nombre de fichero:

Ejemplo BH-001.P01

Ejemplo BH-001.S02

Invocar tareas por su nombre:

Otra forma, algo más avanzada, de invocar una tarea de Celery (además de my_task.delay() y my_task.apply_async()) consiste en realizar una llamada usando el nombre relativo de la tarea, en lugar de usar código Python de programación.

Veámoslo con un ejemplo:

Supongamos que una tarea está situada en: framework.tasks.send_mails, con el nombre de send_mail(). Conforme lo hemos visto hasta ahora la invocación sería como sigue:

1 2 3 4

framework.tasks.send_mails import send_mail if __name__ == '__main__': send_mail.delay()

Con este nuevo método quedría como sigue:

1 2 3 4 5 6 7

from framework.celery.celery import celery if __name__ == '__main__': celery.send_task("framework.tasks.send_mails.send_mail") # Without params celery.send_task("framework.tasks.send_mails.send_mail", ("From my@my.com")) # With params

Cada Broker tiene su propio método de arranque. En esta guía solo se cubrirá, de momento, RabbitMQ:

Para arrancar el servidor de RabbitMQ tenemos que escribir en una consola:

sudo rabbitmq-server &

            RabbitMQ 3.1.5. Copyright (C) 2007-2013 GoPivotal, Inc.
##  ##      Licensed under the MPL.  See http://www.rabbitmq.com/
##  ##
##########  Logs: /opt/local/var/log/rabbitmq/rabbit@localhost.log
######  ##        /opt/local/var/log/rabbitmq/rabbit@localhost-sasl.log
##########
            Starting broker... completed with 0 plugins.

Celery es un software que corre como servicio, actuando de orquestador entre nuestra aplicación y el sistema de mensajería. Debemos arrancar una instancia de Celery por cada aplicación que queramos correr.

La forma de arrancarlo está condicionada por la estructura de nuestro proyecto. La siguiente es una propuesta para de organización para nuestro código:

celery -A framework.celery.celery worker

Si lo queremos con más información de depuración:

celery -A framework.celery.celery worker --loglevel=info

[2014-11-03 16:35:54,223: WARNING/MainProcess] /Users/XXX/.virtualenvs/omstd/lib/python3.4/site-packages/celery/apps/worker.py:161: CDeprecationWarning:
Starting from version 3.2 Celery will refuse to accept pickle by default.

The pickle serializer is a security concern as it may give attackers
the ability to execute any command.  It's important to secure
your broker from unauthorized access when using pickle, so we think
that enabling pickle should require a deliberate action and not be
the default choice.

If you depend on pickle then you should set a setting to disable this
warning and to be sure that everything will continue working
when you upgrade to Celery 3.2::

    CELERY_ACCEPT_CONTENT = ['pickle', 'json', 'msgpack', 'yaml']

You must only enable the serializers that you will actually use.


  warnings.warn(CDeprecationWarning(W_PICKLE_DEPRECATED))

 -------------- celery@localhost v3.1.16 (Cipater)
---- **** -----
--- * ***  * -- Darwin-14.0.0-x86_64-i386-64bit
-- * - **** ---
- ** ---------- [config]
- ** ---------- .> app:         __main__:0x1085dba90
- ** ---------- .> transport:   amqp://guest:**@localhost:5672//
- ** ---------- .> results:     disabled
- *** --- * --- .> concurrency: 4 (prefork)
-- ******* ----
--- ***** ----- [queues]
 -------------- .> celery           exchange=celery(direct) key=celery


[tasks]
  . framework.tasks.export_results_task.export_to_csv
  . framework.tasks.yara_task.yara_task

[2014-11-03 16:35:54,258: INFO/MainProcess] Connected to amqp://guest:**@127.0.0.1:5672//
[2014-11-03 16:35:54,272: INFO/MainProcess] mingle: searching for neighbors
[2014-11-03 16:35:55,297: INFO/MainProcess] mingle: all alone
[2014-11-03 16:35:55,309: WARNING/MainProcess] celery@localhost ready.

Por último, lanzar nuestra aplicación será como ejecutar un script normal en Python:

python start.py

A continuación se puede ver una pequeña demo de funcionamiento de Celery:

Tan solo tenemos que cambiar la configuración de Celery y añadir la tarea que queremos ejecutar y la repetición del mismo:

Ejemplo BH-002.S01

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

from .utils import find_tasks_in_project # Celery taskes package CELERY_MAIN_FOLDER = "framework" # -------------------------------------------------------------------------- # Celery common properties # -------------------------------------------------------------------------- CELERY_TASK_RESULT_EXPIRES = 3600 CELERY_IMPORTS = find_tasks_in_project("framework") BROKER_URL = 'amqp://guest:guest@localhost:5672/' # -------------------------------------------------------------------------- # Celery scheduled tasks # -------------------------------------------------------------------------- CELERY_TIMEZONE = 'UTC' # CELERYBEAT_SCHEDULE = {} CELERYBEAT_SCHEDULE = { 'add-every-30-seconds': { 'task': 'framework.tasks.main_task', 'schedule': timedelta(seconds=30), # 'args': (16, 16) }, }

Para llamar a Celery Beat, tan solo tendremos que ejecutar Celery como se describió en la sección anterior, pero añadiendo el parámetro -B:

celery -A framework.celery.celery worker -B --loglevel=info

Nuestra aplicación se ejecuta a través de la linea de comandos. Para ver todas las opciones disponibles tan solo tenemos que escribir:

python start.py --help

Y como resultado:

usage: start.py [-h] -p SAMPLE_PATH [-v VERBOSITY] [-o OUTPUT_FILE]
            [--rules-path RULES_PATH]

OMSTD Malware

optional arguments:
  -h, --help            show this help message and exit
  -p SAMPLE_PATH, --sample-path SAMPLE_PATH
                        binary sample path
  -v VERBOSITY          enable verbose mode
  -o OUTPUT_FILE        output file name
  --rules-path RULES_PATH
                        yara rules path (default .rules/)

El funcionamiento es muy simple. El analizador está hecho usando Celery, por lo que hay que seguir los mismos pasos explicados en el anexo del caso de estudio BH-001 para ejecutar la aplicación: Pasos para lanzar Celery.

Una vez lanzado el servicio de Celery, así como sus dependencias, nuestra aplicación ya está a la espera de recibir muestras para ser analizadas. Para esto ejecutaremos:

python start.py -p samples/sample.txt -o results

Aquí podemos ver la salida generada: Un CSV con la información:

HelloWorld,True,Data: 'Hello world' (flags: 19 # offset: 0),1,Rule HelloWorld was found a match in binary 'sample.txt' with tags: No tags
HelloWorld,True,Data: 'Hello world' (flags: 19 # offset: 0),0,Rule HelloWorld was found a match in binary 'sample.txt' with tags: No tags
Another,False,,1,Rule Another was NOT found a match in binary 'sample.txt' with tags: No tags
SeeYou,True,Data: 'See you' (flags: 19 # offset: 12),1,Rule SeeYou was  found a match in binary 'sample.txt' with tags: No tags
Another,False,,0,Rule Another was NOT found a match in binary 'sample.txt' with tags: No tags

Puede encontrar muestras y reglas Celery de ejemplo, para poder probar la herramienta inmediatamente:

• Muestras de ejemplo
• Reglas de ejemplo

En la sección Anexo puede encontrar un listado de enlaces con reglas listas para ser utilizadas.

El servicio de recepción de muestras es un tarea de Celery, a la espera de recibir nueva información para analizar de forma asíncrona y en background.

El motor de análisis es muy sencillo. El análisis se hace en dos partes:

• El análisis con Yara.
• La interpretación y transformación de resultados.

Ambas partes están definidas como dos funciones en el fichero yara_task.py.

Analizador con Yara

La función yara_task, convertida en tarea con el decorador @celery.task, es la encargada de hacer la llamada a Yara y:

1. Cargar las reglas Yara, con el método yara.compile(), indicándole el listado de ficheros “*.yara” con las reglas.
2. Usando partials (LP-003) construimos la llamada al callback. Dicho callback será llamado por la librería de Yara, cada vez que ésta ejecute con éxito una regla.
3. Finalmente se lanza la orden para hacer el “match”, rules.match(...), indicándole el partial anteriormente construido.

En el siguiente código se puede ver estos puntos:

• framework/tasks/yara_task.py -> yara_task(...):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

@celery.task def yara_task(input_parameters): """ Celery task that process a binary sample. :param input_parameters: Parameters object with global input parameters :type input_parameters: Parameters """ # Load Yara rules and match with binary rules = yara.compile(filepaths=input_parameters.yara_rules_files) # Make custom callback function callback_function = partial(yara_callback, input_parameters) # Run Yara rules! rules.match(input_parameters.sample_path, callback=callback_function)

Analizador de resultados

La función yara_callback actúa como callback que Yara llamará cuando termine de procesar cada una de las reglas.

En ella, y tras comprobarse la validez de los parámetros de entrada, se llevan a cabo las siguientes acciones: #. Transformar los datos de entrada del formato Yara al formato interno, del tipo Results, según SP-003 #. Enviar la información, de forma asíncrona, a la tarea que se encarga de almacenar los resultados: celery.send_task("framework.tasks.export_results_task.export_to_csv", ...).

En el siguiente código se puede ver estos puntos:

• framework/tasks/yara_task.py -> yara_callback(...):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

# ---------------------------------------------------------------------- def yara_callback(input_parameters, yara_results): """ Call back for Yara match. Retreive Yara yara_results, as dictionary, and call Celery task that stores yara_results. :param input_parameters: Parameters object with global input parameters :type input_parameters: Parameters :param yara_results: Raw Yara match yara_results in format: {'matches': True, 'rule': 'HelloWorld', 'namespace': '0', 'tags': [], 'meta': {}, 'strings': [{'identifier': '$a', 'flags': 19, 'data': 'Hello world', 'offset': 0}]} :type yara_results: dict """ # Inputs validations if not isinstance(yara_results, dict): raise TypeError("Expected dict, got '%s' instead" % type(yara_results)) if yara_results is None: print("Yara rules returned not yara_results") return # Yara input format: # # {'matches': True, # 'meta': {}, # 'namespace': '0', # 'rule': 'HelloWorld', # 'strings': [{'data': 'Hello world', # 'flags': 19, # 'identifier': '$a', # 'offset': 0}], # 'tags': []} # r_rule = yara_results['rule'] r_matches = yara_results['matches'] r_tags = ",".join(yara_results['tags']) if yara_results['tags'] else "No tags" r_namespace = int(yara_results['namespace']) # Fixing payload r_payload = "#".join(["Data: '%s' (flags: %s # offset: %s)" % (x['data'], x['flags'], x['offset']) for x in yara_results['strings']]) # Make Results structure r = Results(rule=r_rule, matches=r_matches, payload=r_payload, namespace=r_namespace, description="Rule %s was %sfound a match in " "binary '%s' with tags: %s" % (r_rule, "" if r_matches else "NOT ", input_parameters.sample_file_name, r_tags)) # Send info to exporter celery.send_task("framework.tasks.export_results_task.export_to_csv", (input_parameters, r))

Los resultados serán generados de forma asíncrona, al igual que la recepción de éstos. Para ello, se ha creado una tarea de Celery, a la espera de recibir nueva información, con la que generar los resultados deseados.

La herramienta genera los resultados a través de la función yara_callback(...). Ésta, una vez hecha la transformación, hace una llamada la a la tarea generadora de resultados, llamada: export_to_csv(...).

Hay varias formas de llamar a una tarea de Celery, como se puede estudiar en BH-001. En este caso nos hemos decantado por la opción my_task.send_task("..."), como se ha visto en la :ref:` sección anterior <mh-001-results-analysis-section>`.

La función, convertida en tarea, export_to_csv(...) hace 3 cosas muy sencillas:

1. Una comprobación mínima de los parámetros de entrada.
2. Abre un fichero, siguiendo las recomendaciones de LP-005, en modo “append” o para añadir información al final de éste.
3. Escribe una nueva linea en el fichero en formato csv

Tal y como podemos ver en la lineas señaladas:

• framework/tasks/export_results_task.py:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

@celery.task def export_to_csv(input_params, results): """ Export results to CSV file. :param input_params: Global Parameters instance with input configuration :type input_params: Parameters :param results: Results object with analysis results. :type results: Results """ if not isinstance(input_params, Parameters): raise TypeError("Expected Parameters, got '%s' instead" % type(input_params)) with open("%s.csv" % input_params.output_file, "a") as f: csv_writer = csv.writer(f) # Title # csv_writer.writerow(["# Rule", "matches", "payload", "description"]) csv_writer.writerow([ results.rule, results.matches, results.payload, results.namespace, results.description ])

Añadir nuevas muestras, es equivalente a decir: enviar nuevas muestras a la cola de análisis, para que sean procesadas cuando toque su turno.

Para este PoC se ha optado por algo sencillo: un linea de comandos (en secciones anteriores se muestra cómo ejecutarse).

Hemos tenido en cuenta las siguientes medidas o recomendaciones:

• Hemos usado la librería standard argparser, siguiendo la sintaxis de la documentación oficial, y teniendo en cuenta las buenas prácticas especificadas en IT-001.
• Además, hemos prevenido la ejecución accidental o a destiempo aplicando LP-004.
• Hemos centralizado la ejecución en un punto, usando ST-004, dejando preparado el proyecto para otras interfaces de usuario.
• Hemos usado un punto central para almacenar los parámetros de ejecución del usuario, como se recomienda en ST-002.

Tal y como podemos ver en la lineas señaladas:

• start.py:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

import argparse from api import Parameters, run_all # ---------------------------------------------------------------------- if __name__ == '__main__': parser = argparse.ArgumentParser(description='OMSTD Malware') parser.add_argument("-p", "--sample-path", type=str, dest="sample_path", help="binary sample path", required=True) parser.add_argument("-v", dest="verbosity", type=int, help="enable verbose mode", default=False) parser.add_argument("-o", dest="output_file", type=str, help="output file name", default=None) parser.add_argument("--rules-path", dest="rules_path", type=str, help="yara rules path (default .rules/)", default=None) params = parser.parse_args() input_parameters = Parameters(sample_path=params.sample_path, output_file=params.output_file, verbosity=params.verbosity, rules_path=params.rules_path) run_all(input_parameters)

La ejecución tiene lugar a través de la función run_all(...), incluido en el fichero api.py. Si observamos el código, podemos comprobar que lo que hace dicha función es una llamada a la tarea de análisis, con sintaxis Celery:

• api.py:

1 2 3 4 5 6 7 8 9 10

from lib.data import Parameters, Results from framework.celery.celery import celery from framework.tasks.yara_task import yara_task # ---------------------------------------------------------------------- def run_all(input_parameters): # Display results yara_task.delay(input_parameters)