El objetivo es ofrecer una herramienta para el análisis de frases de fácil uso y que pueda servir para todo aquel que necesite, de alguna manera, analizar frases. En la web oficial de Freeling existe un demostrador de la herramienta para que podáis ver todo el potencial que posee. Nuestro servicio está montado sobre la versión de SVN de FreeLing, utiliza Wordnet 3.0 para la desambiguación de los elementos y también ofrece un sistema de traducción de los términos EAGLE para no tener que buscar exactamente qué significa cada elemento. El servicio REST devuelve un JSON con los análisis que, en principio, nosotros hemos necesitado en nuestras investigaciones. Además, también hemos realizado un cliente en Java que hemos dejado en github para que cualquier persona interesada pueda utilizarlo.

Un ejemplo de los resultados que ofrece con el cliente que hemos publicado es el siguiente:
Frase: ME GUSTA LA LECHE. [size:5]

Terna:ME
que es:PP1CS000
que es para humanos:PRONOMBRE
palabra raiz:ME
tipo:PERSONAL
persona:PRIMERA
genero:COMUN
numero:SINGULAR
caso:DESCONOCIDO
poseedor:DESCONOCIDO
cortes:DESCONOCIDO
estructura chunk: [grup-verb][patons][paton-s]

Terna:GUSTA
que es:VMIP3S0
que es para humanos:VERBO
palabra raiz:GUSTAR
tipo:PRINCIPAL
persona:TERCERA
genero:DESCONOCIDO
numero:SINGULAR
tiempo:PRESENTE
modo:INDICATIVO
sentidos:Experience-Mental
WSD:01777210-v
estructura chunk: [grup-verb][grup-verb][verb]

Terna:LA
que es:DA0FS0
que es para humanos:DETERMINANTE
palabra raiz:EL
tipo:ARTICULO
persona:DESCONOCIDO
genero:FEMENINO
numero:SINGULAR
poseedor:DESCONOCIDO
estructura chunk: [grup-verb][sn][espec-fs][j-fs]

Terna:LECHE
que es:NCFS000
que es para humanos:NOMBRE
palabra raiz:LECHE
tipo:COMUN
genero:FEMENINO
numero:SINGULAR
sentidos:Comestible-Liquid-Natural-Substance
WSD:07844042-n
estructura chunk: [grup-verb][sn][grup-nom-fs][n-fs]

Terna:.
que es:FP
que es para humanos:MARCAPUNTUACION
palabra raiz:.
estructura chunk: [grup-verb][F-term]

Como puede verse, da bastante información útil acerca de los términos desambiguados (códigos de Wordnet 3.0) así como del papel que desempeña el elemento dentro de la Frase. Una cosa más, este servicio, en principio, está pensado para investigaciones y pruebas. El mantenimiento lo hacemos nosotros mismos en nuestros ratos libres por lo que si os encontráis con que deja de funcionar o no responde, os agradeceríamos que nos lo dijerais para intentar solucionarlo.

Esperamos que este nuevo servicio os sirva en vuestras investigaciones.

The post Servicio de análisis de frases con FreeLing appeared first on S3lab.

A lo largo del tiempo vuelan muchas muestras de malware por nuestras manos, que analizamos para lograr comprender su funcionamiento (ingeniería inversa). Este proceso es un arduo trabajo que puede llevar bastante tiempo dependiendo de la complejidad del propio malware y del packer o packers utilizados para protegerlo. Existen varios tipos, pero como ejemplo explicaremos como desempaquetar un packer sencillo que únicamente tenga una fase, como puede ser UPX (algunos implementan varias rutinas de empaquetado y desempaquetado).

El primer paso es saber si el binario esta empaquetado o no, para ello existen un gran número de herramientas que pueden ayudarnos, algunas de las más conocidas son RDG Packer Detector y PEiD (basadas en detección de firmas y calculo de entropía principalmente). Las imágenes que se muestran en la galería inferior son de un malware, pero para hacer las pruebas os proporcionamos un binario inofensivo de ejemplo («Hola Mundo» empaquetado con NsPack). El siguiente paso es abrir la muestra con un debugger, en este caso utilizaremos el clásico Immunity Debugger.

ImmunityDebugger_0

ImmunityDebugger_1

ImmunityDebugger_2

ImmunityDebugger_3

ImmunityDebugger_4

ImmunityDebugger_5

ImmunityDebugger_6

ImmunityDebugger_7

ImmunityDebugger_8

Una vez abierto, nos indicara que el entry point esta fuera del código (como se especifica en la cabecera PE). A continuación buscaremos el comando “PUSHAD” ya que realiza el push del contenido de los registros de propósito general en la pila. Bastará con hacer click derecho y acceder a “Search for” y dentro a “Command”.

Una vez se ha localizado dicha instrucción, pulsamos F2 para poner un breakpoint. Seguido, pulsamos F9 para que se ejecute el programa hasta la instrucción marcada. Tras pulsar F8 para llegar al “PUSHAD”, vamos a la sección de registros, marcamos ESP (Extended Stack Pointer) y haciendo click derecho en él, elegimos “Follow in Dump” para poder ver lo que se encuentra allí en el HEX Dump.

Ahora se visualizará, en el DUMP, el contenido en hexadecimal de la dirección correspondiente. Para controlar cuándo se vuelve a tener acceso a estos datos (presumiblemente accederá a ellos justo antes de ejecutar el código original o lo que es lo mismo, al final del desempaquetado de los datos) se debe poner un breakpoint hardware de acceso de tipo «Dword» en los primeros bits. Para ello, marcamos los primero 32 bits, hacemos click derecho y elegimos la opción que se ha comentado previamente. Luego, pulsamos F9 para llegar al momento en el que se vuelve a acceder a esos datos. Nos encontremos en un JMP”, pulsaremos F7 para entrar (nos llevará al código original de la muestra). Automáticamente Immunity no interpreta los datos como código, por lo que será necesario indicárselo. Click derecho, elegimos «Analysis» y finalmente «Analyse code».

Con estos pasos hemos logrado conseguir el código real del malware, el cual podremos analizar más en profundidad para entender su funcionalidad. En caso de querer crear el binario sin empaquetar, podremos utilizar el plugin OllyDumpEx para hacer el dump a través de la opción “Dump proccess”. Finalmente solo haría faltaría reconstruir las imports del ejecutable con ImpREC para que funcione correctamente.

Se utilizan varias técnicas anti-debugging para impedir este tipo de análisis, como puede ser utilizar la función KERNEL32.IsDebuggerPresent de winAPI. También suelen comprobar si la ejecución se está realizando en una máquina virtual utilizando el TSC (Time Stamp Counter) entre otros. En caso de que alguno de esos “triggers” salte, la ejecución cambiará y ocultará su funcionalidad real realizando algo inocuo. En otra ocasión explicaremos como intentar evadir esas técnicas de protección contra ingeniería inversa.

Recordad que estos análisis se tienen que realizar en entornos controlados para impedir cualquier infección en caso de que algo no salga como debería.

El que avisa no es traidor.

The post Ingeniería inversa de malware protegido appeared first on S3lab.

Empezemos el análisis.

%pylab inline
Populating the interactive namespace from numpy and matplotlib

Indicamos la ruta la fichero de log.

log_path = r'./log'

Añadimos los imports necesarios. En concreto utilizamos las librerías de numpy y pandas, del sistema operativo; matplotlib para poder obtener gráficas y finalmente, seaborn, que mejora el aspecto visual de matplotlib.

import pandas as pd
import numpy as np
import os
import matplotlib.pyplot as plt
import seaborn

Preprocesado del fichero

Leemos todos los ficheros de log, y todas las entradas, eliminando todas aquellas que sean comentarios.

def parse_logs(path):
    logs = []
    for file in os.listdir(path):
        if file.endswith(".log"):
            # First, we read all the lines of the file, excluding the coments
            file = [x.split(' ') for x in open(path + '/' + file).readlines() 
                    if x[0] is not '#']

            # We append the files
            logs += file
    return logs

logs = parse_logs(log_path)

Cargamos el fichero en un DataFrame de Pandas

df = pd.DataFrame(logs)

Cambiamos el nombre de las columnas para que sea más legible

df.columns = ['date',
              'time',
              's-ip',
              'cs-method',
              'cs-uri-stem',
              'cs-uri-query',
              's-port',
              'cs-username',
              'c-ip',
              'cs(User-Agent)',
              'sc-status',
              'sc-substatus',
              'sc-win32-status',
              'time-taken']

Ahora, convertimos combinamos la fecha y la hora, y lo sustituimos en el dataFrame.

df.insert(0, 'datetime', pd.to_datetime(df.apply(lambda x: x['date'] + ' ' + x['time'], 1)))

df = df.drop(['date', 'time'], 1)

# Creamos un índice con el tiempo
df.index = df['datetime']

df.drop('datetime',1)

Y vemos de un primer vistazo los datos.

df.describe()

Análisis de tiempos

En primer lugar, vamos a analizar la frecuencia con la que el serividor recibe peticiones.

# Nos quedamos con la columna de tiempo
datetimeDF = df.ix[0:, ['datetime']]

server_times = []
for i, row in datetimeDF.iterrows():
    server_times.append(row['datetime'])

# Y ordenamos la lista    
server_times.sort()

time_until_next = []
for i in xrange(1, len(server_times) - 1):
    time_diff = (server_times[i] - server_times[i-1]).seconds
    time_until_next.append(time_diff)

Creamos el histograma inicial

time_to_next_series = pd.Series(time_until_next)
time_to_next_series.hist(normed=True)

<matplotlib.axes._subplots.AxesSubplot at 0x97bcb00>

Análisis de las IPs

A continuación, analizamos la información de las IPs desde las que se conectan.

Para ello, primero agrupamos las IPs y calculamos cuantas peticiones hay de cada IP.

ip = df.groupby('c-ip').size()

Analicemos ahora las 10 que más visitan.

ip.sort()
ip[-10:].plot(kind='barh')

<matplotlib.axes._subplots.AxesSubplot at 0x78abac8>

Análisis de las respuestas

A continuación se obtienen datos de los distintos tipos de respuestas posibles. Creamos un DataFrame para cada uno de los tipos de error que contemplamos. También vamos a hacer un resample, con una frecuencia de «5t», es decir, por cada 5 muestras de tiempo t se genera una.

# Convertimos la columna a columna de ints
df['sc-status'] = df['sc-status'].astype(int)

t_span = '5t'
df_404 = df['sc-status'][df['sc-status'] == 404].resample(t_span, how='count')
df_403 = df['sc-status'][df['sc-status'] == 403].resample(t_span, how='count')
df_301 = df['sc-status'][df['sc-status'] == 301].resample(t_span, how='count')
df_302 = df['sc-status'][df['sc-status'] == 302].resample(t_span, how='count')
df_304 = df['sc-status'][df['sc-status'] == 304].resample(t_span, how='count')
df_200 = df['sc-status'][df['sc-status'] == 200].resample(t_span, how='count')



status_df = pd.DataFrame({'Not Found':df_404, 'Forbidden':df_403, 'Moved Permanently':df_301, 'Moved Temporaly': df_302, 'Not Modified':df_304, 'OK':df_200})
status_df

Normalizamos los datos a 1 para ver el gráfico de forma más clara

normed_subset = status_df[['OK','Moved Temporaly']].div(status_df[['OK','Moved Temporaly']].sum(1), axis = 0)

normed_subset.plot(kind='barh', stacked=True)

<matplotlib.axes._subplots.AxesSubplot at 0xc284a58>

Esto es sólo un pequeño ejemplo de las cosas que se pueden hacer con este tipo de herramientas.
Ahora os toca a vosotros jugar con vuestros logs y empezar a analizarlos.

The post Análizando logs de IIS con Pandas appeared first on S3lab.

Permite bloquear las apps instaladas y del sistema, permite utilizar plantillas por defecto para cada nueva app instalada, permite utilizar valores inventados, permite el bloqueo “on the fly” de peticiones de la app, permite guardar y compartir las configuraciones, te muestra el uso de recursos que ha tenido la app y es gratuita, aunque también tiene versión PRO de pago que ayuda al desarrollador a evolucionar la aplicación.

El módulo de Xprivacy (de Xposed) es un firewall en toda regla. Te permite bloquear accesos que ni tan siquiera quedan registrados en los permisos de la aplicación. Para ver las posibilidades que tiene esta herramienta, voy a poner el ejemplo de una app que casi nadie tiene, Whatsapp.

En la imagen de la izquierda podemos ver qué elementos nos deja restringir para que la app no pueda acceder. Como podemos ver, están los elementos que, en principio más nos deberían de importar como son el acceso a nuestros datos almacenados, los contactos, las cuentas almacenadas en el dispositivo, las llamadas, los medios (cámara y micrófono), los sensores (proximidad, orientación del dispositivo, luz…), el teléfono (llamadas y registros) y el terminal.

Por otra parte, las plantillas sirven para que los valores que nosotros pensemos que son más importantes, los tengamos siempre a buen recaudo. Las plantillas se pueden aplicar al instalar cualquier aplicación, quitándonos bastante trabajo a la hora de decidir qué le permitimos hacer a la nueva app. En mi caso, lo tengo todo puesto para que me pida consentimiento sobre qué permite o qué deniega. La primera vez que instalas una app, suele ser un peñazo debido a que te saltan muchas peticiones.

Pero entonces piensas qué para que narices tiene que acceder un juego a la parte de telefonía, o geolocalización (como es el caso de Andry Birds), sin necesidad aparente, y te agrada saber que hay una herramienta que te avisa y te permite decidir. Llegados a este punto, y volviendo a la situación (no ficticia) de la vida real del principio, ya tenemos varias estratagemas, de mala educación, para que nuestros datos no sean comercializados. El problema surge cuando negación tras negación, la app deja de funcionar debido a que no puede acceder a recursos que ella determina como necesarios y no tiene un sistema para la gestión de recursos nulos. La app deja de funcionar y no la podemos usar.

Pero claro, ahora es donde viene la pillería. Y si queremos ejecutar sí o sí una app, pero no queremos que sepa dónde estamos, ni que lea nuestros contactos, ni viole nuestra privacidad y que además funcione bien. Pues Xprivacy nos da la opción de inventarnos los datos. En la imagen de la derecha podemos ver qué datos nos permite inventarnos, además de iniciar estos valores al arrancar nuestro dispositivo. Estos son los que suelen pedir las apps normalmente.

Una vez que hemos visto cómo funciona esta herramienta, os tengo que confesar que hay una trampa, lógica, para que funcione. Debemos de ser root para poder utilizarla. Existen apps firewall para usuarios no root, pero dudo bastante de sus posibilidades y protección.

The post Xprivacy, un firewall para Android en toda regla appeared first on S3lab.

¿Y qué podemos hacer nosotros como usuarios para configurar nuestras opciones de privacidad? Por eso, iniciamos el repaso a las opciones de privacidad que nos ofrecen distintas operadoras en España, empezando por Vodafone. Para ello, accedemos a la sección de “Mi Vodafone” dentro de la web y entramos dentro de la sección “Mis datos personales”. Allí encontraremos una sección dedicada expresamente a gestionar la privacidad de nuestros datos.

Como podemos ver, hay varios elementos dentro de la sección de privacidad de los datos que, cuando menos, llaman la atención, mientras que otras podríamos enclavarlas dentro de prácticas más habituales de este tipo de operadoras. Cosas como que cedan tus datos a entidades titulares de ficheros de solvencia patrimonial o que se cedan a la Asociación Centro de Cooperación Interbancaria. Por otro lado, también cabe destacar la diferenciación que hace entre los datos de tráfico y facturación; y los datos de navegación. Una cosa que me llama la atención es la opción “No deseo recibir publicidad”. Mi pregunta es ¿si ofrece mis datos a otras empresas, estás también se comprometen a no mandarme publicidad? La verdad es que me surge la duda.

En cualquier caso, es reseñable la capacidad que te ofrece Vodafone de poder gestionar esos datos. En próximos post iremos analizando las posibilidades que nos ofrecen los distintos operadores a la hora de gestionar la privacidad de nuestros datos.

The post La privacidad y las operadoras (Vodafone) appeared first on S3lab.

Pero claro, una vez que ya hemos obtenido cierta información sobre el sitio web y su servidor, es necesario determinar la gravedad de la vulnerabilidad. Dabo nos mostró el proyecto OWASP y que es una buena metodología la catalogación de las vulnerabilidades en base a este proyecto.Ya que habíamos visto algunas de las herramientas necesarias para hacer auditorías a servidores web y en base a que metodología mostrar los resultados, ahora tocaba la parte de pentesting. Vimos ataques en tiempo real contra sus servidores. Algo temerario, pero muy visual e instructivo. Empezamos con nmap y un parámetro que me gustó mucho debido a la información que nos brinda, -sC. Vimos que el servidor nos daba toda la información sobre los puertos, por lo que, como dijo Dabo, es como no tener firewall. Modifico la configuración del firewall y de los IDS-IPS para que al hacer otro nmap, la información fuera nula. Utilizamos la herramienta hydra para atacar mediante fuerza bruta su servidor mediante el puerto ssh y ftp. También la herramienta hulk para hacer una denegación de servicio. Ninguna de las dos funciono debido a que él tenía bienurado Apache para evitar ataques de fuerza bruta y DDoS. Todo ello, con una simple revisión a fondo de la configuración de Apache.

Todos estos ataques fueron registrados por los sistemas de logs con la IP, la hora y que se atacaba. Los logs, son otro de los grandes pilares de la seguridad en servidores. Los logs que nos enseñó Dabo abarcaban tanto los de tiempo real como los históricos. Esto mostraba una radiografía completa de todo lo que había sucedido con el servidor, algo muy importante para su optimización, para aprender nuevos ataques y para gestionarlo. Por otra parte, algunos ataques podían tumbar algunos servicios críticos como Apache o MySQL, pero la herramienta Monit, mitigaba ese problema volviendo a levantar el servicio. Para evitar muchos de los nuevos ataques o fallos de seguridad en el propio kernel vimos cómo funcionaba grsecurity y las comparativas con otros sistemas como SELinux o AppArmos. Estos ataques controlados nos dejaron una idea clara, un atacante hace lo posible para que no se le pueda detectar o al menos, hacerlo lo más difícil posible su detección. Para anonimizarse, los atacantes suelen utilizar la red TOR. Nosotros vimos Tails, un sistema operativo basado en Debian para navegar de manera anónima en el cual se pueden instalar todas las herramientas que hemos visto.

Para el último día nos reservó una sorpresita. Teníamos una máquina virtual con un Debian y apache montado. No enseño la herramienta maldetect que buscaba malware en páginas web. Instalamos la aplicación y, al poco tiempo de haberla ejecutado, diciéndola la ruta donde se alojaban las webs, nos encontró un elemento sospechoso. A primera vista era un archivo .htaccess, pero como la herramienta maldetect nos lo había marcado como malo, y el comando file nos decía que era un script php, la cambiamos la extensión a php y sin darnos cuenta, Dabo nos había metido un rootkit en nuestro servidor. Además, estaba codificado, lo que hacía un poco más difícil su detección. Al final, a lo tonto, aprendí bastante sobre los servidores, el poco tiempo que se les dedica para ponerlos en condiciones, lo sencillo que es configurarlos, los diferentes tipos de ataques que se realizan contra ellos y los potentes y necesarios que son los sistemas de logs. También aprendí bastante sobre las diferencias entre los tipos de servers, conceptos como escalabilidad o disponibilidad y laconfigimportancia tanto de elegir una buena base para el servidor en el proceso del desarrollo web, como la importancia de saber auditar no sólo de forma externa mediante herramientas Software, sino también configuraciones críticas del server.

Fue genial tener a Dabo compartiendo sus conocimientos y “engorilandose” contra sus propios servidores. Es una experiencia magnifica que te enseñen los mejores lo que hacen, como lo hacen y, que además lo hagan de manera práctica.

Un placer Dabo, esperamos verte pronto de nuevo.

Auditando un servidor con Dabo (Parte I)

The post Auditando un servidor con Dabo (Parte II) appeared first on S3lab.