conociendo a NEMESIS 2/3 creacion de paquetes arp[propues y desarrollado]

* Titulo del Laboratorio

Creacion y modificacion de paquetes(peticiones) arp por medio de nemesis

* Objetivos

Conocer el funcionamiento del protocolo tcp/ip y sus debilidades
Conocer el funcionamiento de una peticion arp y explotarlo

* Elementos de hardware necesarios

2 PC
Cableado mas router o modem , en el peor de los casos un hub xD

* Elementos de Software necesarios

Linux o windows
Nemesis
Shell

* Otros elementos necesarios

Conocimientos basicos sobre paquetes arp
Conocimiento sobre analisis de la tablar arp de nuestro pc
Ganas de aprender y de no causar daño


Resumen

Bueno despues de tanta ausencia y espera por la segunda parte de este laboratorio hoy lo desarrollaremos con un poco mas de gracia que el anterior , programaremos para que sea mas productivo y valida la espera.
En resumen lo que vamos a ver hoy es como podemos modificar una peticion arp y asi engañando al router para que no vea un pc victima dentro de nuestra red.
Este ataque es muy basico pero muchos no lo concen , ya hemos hablado de las vulnerabilidades que tienen las capas inferiores del modelo osi y que digamos son trasparentes para un ataque, hoy vamos a ver como podemos dejar sin internet a un pc de nuestra red manipulando paquetes arp.
La idea de todo esto no es generar ataques en red ni muchos menos dejar sin internet al que nos cae mal que esta al lado nuestro, la idea es buscar una solucion a estos problemas.

Desarrollo:

Primero que todo ya debemos tener nuestro nemesis instalado tras haber desarrollado nuestro anterior laboratorio.

Descripcion del entorno:

Bueno el laboratorio se desarrollo de la siguiente forma:

IP Equipo atacante 10.0.18.110
IP Equipo victima 10.0.18.150
IP Router 10.0.18.1

Paso 1: comprobar conectividad




Explicacion:

Comprobamos conectividad con el equipo a atacar:
ping 10.0.18.150

Comprobamos conectividad con el router:
ping 10.0.18.1
aunque si vemos la otra maquina es porque tenemos conectividad xD

Y luego les muestro la configuracion de mi maquina para que vean que esa es realmente mi ip y queno hay trucos.

Paso 2: desarrollo del ataque

Primero que todo vamos a necesitar nuestra consola para programar un shell script.

despues de abierta la shell , ejecutamos el editor vi.

vi script-nemesis

y ahora a programar

i=0
while [ $i -le 100 ]
do
nemesis arp -D 10.0.18.150 -S 10.0.18.1 -H AA:BB:CC:DD:EE:FF
done

listo esto es todo , le damos escape y dos puntos wq para guardar.

Explicacion:

primero vemos un ciclo , eso no hay necesidad de explicar , lo fundamental es entender que esta haciando nemesis, bueno le estamos diciendo a nemesis que mientras dura este ciclo mande una peticion a la ip 10.0.18.150 ose a la direccion de destino(-D) que sera la ip a atacar , donde el origen sea 10.0.18.1 osea la ip del router(-S) con una direccion mac falsa(-H).
Que estamos haciendo , que nuestro router piense que la direccion ip a atacar tiene esa direccion mac , asi logrando un envenenamiento en la tabla arp del pc victima quedando sin internet.

NOTA:
para las personas poco conocedoras del software libre les explicare como ejecutar el script.

Luego de guardar el escript ejecutamos

chmod 777 script-nemesis

con esto tendra todos los permisos en nuestro caso solo importa ejecucion pero de todas maneras asi es valido para no tener problemas despues

luego digitamos en la shell

./script-nemesis

y empezara nuestro ataque

El porque del script?

sencillo la tabla arp actualiza determinado tiempo , si lo ejecutamos solo una vez no tendria mayor efecto , pero si lo ejecutamos seguidamente se notara el ataque.


Paso 3: comprobando el ataque

Bueno antes de ver la imagen les explicare algo.

Se comprobo conectividad con la ip atacante y con el router, ANTES DEL ATAQUE, luego se compro conecctividad despues del ataque y vemos que ya no hay conectividad osea quedo por fuera de la red y ademas les muestro la configuracion del equipo





Listo hasta aqui nuestro ataque funcionando maravillosamente, ya podemos dejar sin internet a nuestro jefe xD(BROMA).

Conclusiones:

Una conclusion muy ovbia es la vulnerabilidad tan grande que tiene el modelo osi y sobre todo que si estuvieramos como victimas no podriamos hacer nada contra este ataque , PARA QUE UN ANTIVIRUS?.
Claro que se podrian bloquear ips y cosas por el estilo pero el problema seguiria ahi , por eso me gustaria que plantearan sus soluciones sin mirar las existentes por su puesto.

Espero les haya gustado este segundo laboratorio , el tercero no lo hare tan extenso por que lo profundizare con otra herramienta hecha solo para ese ataque.

saludos roboticos

Links Relacionados:

http://bad-robot.blogspot.com/2009/04/conociendo-nemesis-13-creacion-de.html

Links en las las comunidades donde participo

http://foro.latinohack.com/showthread.php?p=37149#post37149
http://foro.colombiaunderground.org/index.php/topic,5067.0.html

Si lo ven en alguno otro sitio por favor avisar.

Ataques sobre el nivel 2 del modelo osi(dtp)

Como muchos sabemos el protocolo osi en sus capas inferiores es muy suseptible a ataques a nivel de red, por esto hoy voy a ir haciendo un recuento de los posibles ataques que se nos pueden presentar.

Veamos como se efectúa un ataque contra un switch Catalyst 2950T con IOS 12.1(22) EA3. El dispositivo se encuentra configurado con nombre zipi y dos VLANs: Office (puertos Fa0/10, Fa0/11, Fa0/12 y Fa0/13) e Internet (puertos Fa0/20, Fa0/21, Fa0/22 y Fa0/23). El dominio VTP ha sido cambiado a Yersinia. El resto de parámetros
se dejan por defecto.

En el modo GUI de Yersinia, elegimos el protocolo DTP. Si hay tráfico DTP en nuestra red no tardaremos más de treinta segundos en ver datos. También podemos echarle un vistazo al estado DTP del puerto que nos conecta al switch desde la consola del mismo: nuestro puerto es Fa0/10 y el estado es por defecto.Ahora necesitamos rellenar la ventana inferior con valores por defecto tecleando [d]. Tras esto, al presionar [e] nos permitirá modificar el campo Neighbor-ID con el valor 666666666666. Para finalizar la edición es necesario presionar [return].

Ahora, cambiamos a la ventana de ataques DTP presionando [x] y seleccionamos el ataque enabling trunking. El estado DTP del puerto cambiará a TRUNKING y Neighbor address 1 contendrá nuestro ID. Si además miramos los puertos asignados a cada VLAN como antes, veremos que nuestro puerto Fa0/10 ya no se encuentra en la lista (ver Listado 9). En la ventana principal de Yersinia veremos nuevos paquetes; los creados por Yersinia son los que tienen el campo Neighbor-ID con 666666666666. De ahora en adelante, seremos capaces de llevar a cabo ataques contra los protocolos 802.1Q y VTP. Y lo que es más importante, seremos capaces de comportarnos como otro switch lo cual hace posible acceder a tráfico de otras VLANs.

Puertos de VLANs tras el ataque
zipi# sh vlan
VLAN Name                          Status    Ports
---- ----------------------------- --------- -------------------------------
1    default                       active    Fa0/1, Fa0/2, Fa0/3, Fa0/4
                                      Fa0/5, Fa0/6, Fa0/7, Fa0/8
                                      Fa0/9, Fa0/14, Fa0/15, Fa0/16
                                      Fa0/17, Fa0/18, Fa0/19, Fa0/24
                                      Gi0/1, Gi0/2
100  Office                        active    Fa0/11, Fa0/12, Fa0/13
200  Internet                      active    Fa0/20, Fa0/21, Fa0/22, Fa0/23

La única contramedida viable contra ataques DTP es desactivar el auto-trunking con el comando: switchport mode access. El administrador se ve entonces obligado a activar el trunking manualmente (configurando el switch) para activar cada trunk.

Alfredo Andrés

David Barroso

S21sec e-crime

FUENTE:http://blog.s21sec.com/2009/06/ataques-sobre-el-nivel-2-del-modelo-osi_19.html

instalacion de un servidor shh

Este texto es sacado del sigueinte post orignial

INSTALANDO UN SERVIDOR SSH SECURIZADO

1. INTRODUCCIÓN.

Uno de nuestros clientes nos ha pedido que le instalemos, con urgencia, un servidor de ssh securizado, teniendo en cuenta que va a estar "abierto a internet", ni siquiera un triste firewall delante. Dicho servidor se usará como "puerta trasera" para acceder a ciertos servicios en caso de caída del firewall. Un poco rebuscado, pero es lo que han decidido ... Mientras lo voy preparando, voy a aprovechar para explicar las medidas a adoptar.

Con lo feliz que estaba yo poniendo en producción mi IPS ...

2. INSTALANDO EL SERVIDOR.

El servidor dará el servicio VPN para alcanzar ciertos servidores de la empresa. Hay un firewall detrás del servidor, pero no hay nada delante. VPN, en principio, puede considerarse un servicio seguro. Eso sí, el software de vpn es considerablemente más complicado que el de ssh, así que he decidido que voy a poner un servidor de ssh y que, una vez loggeado, root levantará el software de vpn.

Si recordáis, mis temores no son infundados. Hace poco tiempo hubo una vulnerabilidad gravísima que permitía sacar todos los certificados hechos con ciertas versiones del openssl (openssl -- predictable random number generator).

Lo primero es elegir el sistema operativo que, por supuesto, NO va a ser windows. Si bien es cierto que los BSD's son los más seguros que el resto de *nix, también lo es que son un poco latazo de configurar. Y como nosotros queremos que el servidor esté configurado en una tarde (bueno, yo no, pero los que mandan sí), y que podamos arreglar cualquier inconveniente en segundos e instalar software adicional (openvpn), vamos a elegir un RHE5, última versión.

3. DESHABILITAR SERVICIOS.

Lo primero será deshabilitar todos los servicios innecesarios. Aparte de poner IPTABLES es importante que ningún servicio esté escuchando en las interfaces de red, ya que un descuido podría ser fatal. Para ello, miramos los servicios activados con el commando setup y quitamos aquellos que no hacen falta, como gpm, hplip, mcstrans, setroubleshoot, atm, ... y también el siempre olvidado portmap.

Después de esto, el único que debería escuchar es ssh. Esto lo comprobamos así:

#netstat -nlp|grep -v 127.0.0.1
tcp 0 0 :::61022 :::* LISTEN 2428/sshd


En caso de una caída o vulnerabilidad de IPTABLES, esto nos salvará de que alguien se conecte a algún servicio "olvidado", como pudiera ser cups, y nos entre con algún exploit. Conviene recordar que los firewalls sólo ayudan en caso de descuidos. Nada más.

Esta es la lista de servicios que ha quedado tras hacer limpieza:


acpid
apmd
autofs
cpuspeed
crond
haldaemon
hidd
iptables
irqbalance
lm_sensors
mdmonitor
messagebus
microcode_ctl
network
ossec
readahead_early
smartd
snortd
sshd
syslog
sysstat



4. MODIFICAR SSH.

Vamos a hacer que ssh escuche en un puerto por defecto que no sea el 22. Para ello, modificaremos la línea PORT en el fichero /etc/ssh/sshd_config y pondremos uno conveniéntemente elegido, en nuestro caso el 50127. Con esta medida, nos quitamos de encima escaneos automatizados.

Aparte, para que no sepan qué servicio está escuchando en el puerto 50127, vamos a modificar el banner del ssh. Creamos un fichero /etc/ssh/sshd_banner vacío y cambiamos la correspondiente línea en /etc/ssh/sshd_config (buscar Banner). De esta forma, nmap ni se entera del servicio que hay escuchando en el puerto. Podéis comprobarlo con nmap -sV -p0 -p 50127 192.168.1.1. Nota: un día de estos hablaremos de los scanners de vulnerabilidades (nessus, metasploit, nmap, cain&abel, ... y su utilidad REAL, no lo que nos venden).

Finalmente, crearemos un usuario, NO root, que será el único que tenga permitido el acceso por ssh: useradd miusuario. Para restringir el acceso a sólo este usuario, añadimos una nueva línea al final del /etc/ssh/sshd_config que ponga AllowUser miusuario, lo cual impide el acceso a root al mismo tiempo que lo abre a nuestro nuevo usuario. Y para permitir que este usuario pueda hacer su root modificamos /etc/group y lo metemos en el grupo wheel. Observar que no le hemos puesto password al usuario. Esto es porque queremos que SOLO se entre con certificado. Nada más.

Para hacer login con nuestro usuario: ssh -p 50127 miusuario@servidor.com -i /path/to/private/key

5. IPTABLES.

Aparte de quitar todos los servicios posibles, vamos a crear nuestro propio firewall con iptables. Lo que haremos es:

- permitir todas las conexiones entrantes al puerto del ssh, el 50127.
- denegar todo lo demás.
- permitir sólo el tráfico desde direcciones ip de España (excelente medidad para evitar sustos).

Nuestras reglas, aparte de un montón de DROPs para cortar ssh desde subredes peligrosas, quedarán básicamente como siguen:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport $PUERTO_SSH -m state --state NEW -j ACCEPT
-A INPUT -j DROP


6. CERTIFICADO.

Por supuesto, no entraremos con password y nada más. Vamos a crear un certificado dsa de 1024 bits para el usuario "miusuario". De esta forma, nadie podrá reventar el password por fuerza bruta. Deberemos guardar una copia del certificado en sitio seguro, y esto incluye un backup convenientemente cifrado en algún lugar apropiado.

Para generar las claves públicas y privadas, hacemos ssh-keygen -t dsa -b 1024. El archivo id_dsa.pub tenemos que copiarlo al home del nuevo usuario que hemos creado y la clave privada será la que usemos para entrar.


7. DETECCIÓN DE INTRUSOS: snort y ossec.

No es el momento de dar detalles de cómo se instalan estas herramientas. Simplemente decir que instalaremos ambos detectores de intrusos, y pondremos ossec a leer los logs de snort y enviar alertas por correo a nuestra cuenta del trabajo.

Al instalar ossec es importante poner la opción respuesta activa a yes, para que cuando alguien intente entrar por fuerza bruta ossec banee su IP.

Dentro del ossec.conf, para evitar que nos fría con falsos positivos, vamos a eliminar todas las reglas excepto las siguientes:


rules_config.xml
pam_rules.xml
sshd_rules.xml
syslog_rules.xml
ids_rules.xml
ossec_rules.xml
attack_rules.xml
local_rules.xml


Es posible que en el futuro tengamos que quitar más, pero de momento lo que hemos quitado es más que suficiente. Notar también como la respuesta activa de ossec se ha activado sola, suponiendo que hayamos elegido active response => yes al instalar ossec..

8. QUITAR PAQUETES INNECESARIOS.

Si nos entran con un 0-day de ssh, nos damos por jod****. Si alguien es capaz de hacer algo así, podemos estar seguros de que no encontrar el rpm de gcc no va a suponer un gran problema. Este paso, en el que tanto se suele insistir, nos lo vamos a saltar.

9. PARTICIONES.

De la misma forma, no necesitamos preocuparnos de cómo está configurada la tabla de particiones. Rotaremos los logs normalmente y punto. No es un apache en el que puede haber una denegación de servicio a base de freir el servidor a peticiones.

10. LYNIS.

Ya hemos hablado de esta herramienta. Lynis chequea defectos de configuración para buscar posibles fallos (p.ej. ficheros setuidados) y da un report al final con las indicaciones que necesitamos. Ejecutarla es tan sencillo como esto:

wget http://www.rootkit.nl/files/lynis-1.2.6.tar.gz
tar xzf lynis-1.2.6.tar.gz
cd lynis-1.2.6
./lynis --check-all -Q


Y al final tenemos nuestro report. En nuestro caso, la lista de sugerencia es bastante inútil:

- [09:52:49] Suggestion: Confirm that freshclam is properly configured and keeps updating the ClamAV database [test:MALW-3286]

No haremos caso, porque nuestro servidor es sólo una pasarela hacia otros servidores, sin discos compartidos ni nada así. De hecho, tener una tarea del cron corriendo y bajándose cosas de un servidor, clamav, e instalándolas es peligroso. Podrían hackear el servidor y, a la vez, usarlo para entrar en el nuestro.


11. CONCLUSION.

En este artículo, hemos visto como se configura un servidor ssh seguro abierto a internet. Los pasos son sencillos y el nivel de seguridad conseguido es bastante alto (la única forma de entrar es con un exploit para ssh, imposible a día de hoy). El servidor puede ser usado para acceder a segmentos de red sensibles desde internet de forma segura, siempre y cuando el sitio desde el que accedemos sea seguro.

Saludos y hasta pronto.

PD: si alguien quiere hacer alguna sugerencia, estaré encantado de escucharla ...

FUENTE:http://hacking-avanzado.blogspot.com/2009/04/instalando-un-servidor-ssh-securizado.html

¡¡OLE !! tus metadatos...

este post va dedicado a esta entreda de conexion inversa donde nos habla sobre este programa y muchas cosas mas.

MergeStreams

Esta utilidad está disponible desde NTkernel.com e implementa un aspecto interesante de como se tratan los objetos OLE en documentos Microsoft Office, la idea es 'mezclar' o combinar una hoja de cálculo en un documento Word.

El uso es muy sencillo, dispone de una GUI que permite seleccionar el documento word y la hoja excel y a partir de estos datos en el propio documento word mezcla la hoja de cálculo.



El resultado es el mismo documento word.

Una vez meclado, comprobamos que:

• El tamaño en disco del documento Word no ha variado y sigue siendo el mismo
• Si abrimos el documento, vemos que el contenido es idéntico al original (no aparece nada de hoja de cálculo)
  
• La cadena HASH si que ha cambiado, por lo que sabemos que ha habido modificaciones

A continuación vamos a ver la funcionalidad de MergeStreams:

1.- Eliminamos la hoja de cálculo que hemos utilizado para 'mezclar' (este paso no es necesario)


2.- Seleccionamos el documento 'DocumentoWord.doc' y lo renombramos a XLS 'DocumentoWord.xls'


3.- Abrimos el documento y vemos que se trata de una hoja de cálculo.















Si volvemos a renombrar a .DOC, podremos comprobar que sigue siendo un documento Word.

Esta utilidad demuestra un aspecto importante en el ámbito de la ofuscación o de fuga de información, dado que de esta forma te puedes llevar un documento u hoja de cálculo importante sin que nadie lo advierta.

¿Como lo detectamos?

La siguiente cuestión es como podemos saber de estos metadatos, para ello vamos a utilizar diversas utilidades entre ellas la del maligno en su web de FOCA Online, la de LibExtractor y una utilidad en local llamada TrID que permite la identificación de ficheros.

Estos son los resultados:



Vagamente TrID identifica que hay un componente MULTISTREAM (29%) embebido dentro del documento Word, pero no es capaz de mostrar de que tipo es, las demas herramientas no identifican el objeto OLE.

Para poder identificar este tipo de objetos suelo utilizar dos herramientas en local, una es 'oledmp.pl' de Harlan Carvey realizada en Perl y que permite ver los metadatos de objetos OLE. La otra quizas más sencilla y orientada al mundo Windows es OLEDeconstructor de SandersonsForensics

Aquí tenemos un resultado final de como identifica los objetos con OLEDeconstructor de nuestro fichero de ejemplo



Conclusiones:

Parece ser que el mundo de los documentos se ha construido a base de metadatos y lo mejor de todo es que no sabemos la información que se almacena o puede ser guardada de forma intencionada o no por un usuario (o automáticamente por la aplicación que lo genera. )
Herramientas como FOCA, Metagoolfied o libextractor, ayudan y permiten ver ese tipo de información, pero aun queda largo camino.

En un caso intencionado de 'antiforensics' (y pongo de ejemplo MergeStreams en este post) dudo mucho que la tecnología actual (antivirus, IDS's) detecte este tipo de fugas de información, salvo que sea por un avezado analista que tras una sospecha se dedique a analizar este tipo de ficheros.

Quizas para el 'malo' lo sencillo sea cifrar el fichero o utilizar esteganografía y de esta forma dificultar o imposibilitar el trabajo del analista

No obstante aquí queda esta información para el disfrute de todos y con lo visto hoy me planteo la siguiente pregunta que dejare para el pensamiento de los lectores:

¿Si hubiera incluido un virus de macro en la hoja de cálculo y la hubiera mezclado con el documento, lo detectarían los antivirus?

Eso es todo lectores ;-)

FUENTE:http://conexioninversa.blogspot.com/2009/05/ole-tus-metadatos.html

Mapas de memoria

esta es la continuacion de un gran trabajo de nuestro amigo de conexion inversa, aqui les traigo el "mirror" para los lectores de este blog, muchas gracias a el.

Hace tiempo en este post hable de como parsear la memoria y poder obtener datos de ella, en ese post finalizaba indicando que es posible tracear la memoria y obtener un mapa-dibujo detallado para seguimiento de esta.

Hoy quiero compartir otra de las utilidades que nos puede venir estupendo para poder 'dibujar' esos procesos de una forma cómoda.

PTFINDER

Las PTFinder son un conjunto de utilidades en perl desarrolladas por Andreas Schuster y que como dije anteriormente permite obtener los procesos de memoria y convertirlos o 'dibujarlos' a un fichero con formato JPG o GIF

Esta herramienta permite obtener y dibujar:

• PID del proceso.
• Nombre del ejecutable.
• Offset dentro del fichero.
• Fecha y hora de fin de ejecución del proceso
  

Antes de explicar su funcionamiento deberemos de disponer las siguientes herramientas:

Primero deberemos de disponer un volcado de memoria en formato dd, dmp o vmram (vmware). En mi caso dispongo del fichero '2K3FURootkit.dmp' y que pódeis descargar desde aquí para vuestro disfrute.

Este fichero contiene la imagen de la memoria RAM de un Windows 2003 con el rootkit FU corriendo y creando procesos en la memoria.

Segundo, deberemos de tener instalado Graphviz.

Graphviz es una aplicación que es capaz de representar información estructural como diagramas y gráficos de resumen redes.

Tercero, deberemos de disponer de las herramientas PTFinder disponibles desde aquí y un interprete en PERL como el de ActiveState para Windows

¿Como funciona?

El proceso es muy sencillo, como primer ejemplo vamos a ver como obtener los procesos de memoria, para ello pondremos el siguiente comando:

c:\Perl\bin\perl c:\forensics\ptfinder_w2003.pl --nothreads c:\forensics\2K3FURootkit.DMP

El cual nos mostrará la siguiente pantalla:


Procesos que había iniciados en el sistema operativo

En segundo paso vamos a 'pintar' estos procesos con el siguiente comando:

c:\forensics\ptfinder_w2003.plptfinder_w2003.pl --nothreads --dotfile Mifichero.dot 2K3FURootkit.DMP

(mifichero.dot es creado por ptfinder con el parámetro --dotfile. Este fichero .DOT contiene los parámetros de imagen, entre ellos la posición, altura, textos y dimensiones de las imágenes)

En tercer paso vamos a cargar el fichero 'Mifichero.dot' en la aplicación Graphwiz para convertirlo en una imagen con extensión JPG.



Una vez ejecutado este es el resultado:




Pantalla ampliada

Como se puede apreciar en la gráfica se hace un seguimiento de la ejecución de los procesos.

Conclusiones.

las PTFinder son un buen conjunto de herramientas que si bien dejan el análisis y la investigación a decisión del analista, permiten ayudar de una forma gráfica a ver los vínculos entre procesos y aplicaciones e inclusive permite de una forma sencilla analizar intrusiones, exploits y malware.

Referencias:

Paper
Presentación
Neoforensics

El paper y la presentación son publicados por Andreas Schuster

FUENTE:http://conexioninversa.blogspot.com/2009/05/mapas-de-memoria.html