WTF es akamai???
Hoy se me dió por sniffear un poco mi tráfico de internet y encontré algo interesante. Al mirar las resoluciones DNS veía que muchos dominios de facebook se resolvían a direcciones del domionio akamai.net... y ahí es donde surgió el gran WTF!?
Por ejemplo, si abren fotos en facebook se encontrarán con que están hospedadas en el dominio photos-h.ak.fbcdn.net (ya nos fuimos de facebook.com a fbcdn.net), hasta aca todo bien porque fbcdn.net también pertenece a facebook. Ahora, si resuelven photos-h.ak.fbcdn.net se encontrarán con que es un alias de photos-d.ak.facebook.com.edgesuite.net el cual a su vez resuelve a a998.mm1.akamai.net. Los últimos dos dominios (edgesuite.net y akamai.net) son propiedad de Akamai Technologies, Inc.

No es la primera vez que me encuentro con el nombre akamai en los DNS, en algún momento mirando la cache de DNS de Windows había visto entradas que apuntaban a akamai, aún cuando nunca había visitado ese dominio.

Entonces, qué es akamai y por qué direcciones de facebook resuelven a akamai?
Haciendo una búsqueda en google del nombre akamai nos encontramos con algo de información en wiki, así como links a la página comercial de akamai akamai.com. Esta empresa llamada Akamai Tehnologies Inc. se dedica a proveer una plataforma de computación distribuida a importantísimas empresas (Adobe, Sun, MTV, MySpace, y un largo etc).
Akamai se encarga de almacenar copias del contenido (html, css, imagenes, videos, etc) de distintos sites (en nuestro ejemplo sería facebook) y brindar estas copias de forma transparente a los usuarios que navegan de internet. De esta forma, proveen mayor ancho de banda y al tener copias distribuidas por distintos lugares del mundo, hacen que los usuarios accedan copias en servers cercanos a su país o servers con mayor ancho de banda.
En resúmen, Akamai funciona de gran cache de otros sites para mejorar el ancho de banda considerablemente.

Según la página oficial de Akamai, éstos proveen entre un 10 y un 20 por ciento de todo el tráfico Web mundial, alcanzando hasta los 650 GB/s!!!

Realmente esta empresa tiene una presencia monstruosa en la red y por eso es que veremos muy seguido el dominio akamai.net en nuestras resoluciones DNS.
Dando pelea al SPAM: Sender Policy Framework (SPF)
Cuando realicé mi anterior artículo sobre técnicas antispam no conocía una técnica muy interesante y bastante usada actualmente, la cual es Sender Policy Framework (SPF).
SPF es un sistema de validación de e-mail que permite lidiar contra los e-mails que falsifican la dirección de origen, algo muy común entre los spammers. Esto es, con esta técnica podemos verificar que un e-mail que dice venir de @gmail.com, viene realmente de un servidor de gmail y no de un falsificador.


Algo de Background (SMTP)

Para entender cómo es posible que alguien falsifique una dirección de e-mail, necesito que conozcan un poco del protocolo SMTP. SMTP (Simple Mail Transfer Protocol) es el protocolo encargado de transmitir los e-mails entre servidores. Cuando un usuario desea enviar un e-mail, éste se conecta, ya sea directamente o por interfaz web, a un servidor SMTP y provee sus datos así como el cuerpo del mail.
El protocolo SMTP es simple (le queda bien su nombre) y al estar basado en texto podemos utilizarlo con telnet o netcat conectándonos directamente.
Los datos básicos para enviar un e-mail son la dirección electrónica de origen, la de destino, y el cuerpo del e-mail. Debido a que todos estos campos pueden ser entrados a mano, uno puede enviar un mail colocando cualquier dirección de correo como el origen.
Un ejemplo de conexión SMTP es la siguiente:

root@bt:~# telnet mail.ejemplo.com 25
<<< 220 mail.ejemplo.com ESMTP Postfix
>>> HELO mail.ejemplo.com
<<< 250 mail.ejemplo.com
>>> MAIL FROM: godzilla@ejemplo.com
<<< 250 Ok
>>> RCPT TO: kingkong@ejemplo.com
<<< 250 Ok
>>> DATA
<<< 354 End data with .
>>> gorilon inutil, te aplasto como cucaracha
>>> .
<<< 250 Ok: queued as 12345
>>> QUIT
<<< 221 Bye

Las entradas marcadas con <<< son las respuestas del servidor, y las marcadas con >>> son los comandos ingresados por el cliente. Como se ve, primero saludamos educadamente al servidor con un HELO, luego decimos quién es el emisor del mail (MAIL FROM), a continuación entregamos la dirección del receptor (RCPT TO) y luego ponemos el cuerpo del mail, comenzando con el comando DATA y terminando con un "."
En un servidor sin configurar o mal configurado, o configurado especialmente para enviar SPAM, no existe ninguna restricción a la hora de escribir la dirección de orígen. Tranquilamente podría haber puesto support@microsoft.com o admin@gmail.com.


Cómo funciona?

Ahora si, con la pequeña introducción al protocolo SMTP ya tienen una idea de qué trata el spoofing de direcciones de e-mail, es hora de hablar sobre cómo funciona SPF.
SPF utiliza un principio muy simple para verificar direcciones, el cual es consultar al dominio de donde supuestamente viene el e-mail preguntando si la dirección IP desde donde nos llegó el mail pertenece a sus servidores.

Para aclarar un poco más las cosas, pensemos en los datos que tenemos al recibir un mail. Por un lado tenemos el "from", el "to" y los datos, todo falsificable como pudieron observar en el ejemplo anterior, pero a su vez contamos con la dirección IP del servidor que nos envía el e-mail.
Supongamos que recibimos un mail de admin@gmail.com, con IP de orígen 192.168.1.1 (dirección de ejemplo, nunca recibiremos un mail con esa direccion, al menos no de un servidor externo). El servidor que recibe el e-mail consulta al servidor de DNS de google y le pregunta "cuáles son las IPs de los servidores autorizados a enviar mails a nombre de google.com?", a lo cual google.com responderá con las IPs autorizadas. Si entre las IPs entregadas por google no figura 192.168.1.1 entonces sabremos que el mail ha sido falsificado.

En la imagen puede verse mejor cómo funciona SPF. En el paso 1 el emisor (bueno o malo) envía un e-mail a nuestro servidor. Cuando el servidor recibe el mail, éste consulta al servidor DNS del dominio al cual "supuestamente" pertenece el mail (paso 2). En el paso 3 el servidor DNS contesta con los IPs autorizados a enviar mails a nombre de su dominio. Cuando el servidor de mail recibe la respuesta del DNS, éste decide si el mail es válido o no. Si no es válido puede optar por rechazarlo o simplemente informarselo al usuario que recibe el mail.


Cómo usamos SPF?

Para poder utilizar SPF necesitamos un servidor de mails que soporte esta tecnología. Actualmente todos los servidores más conocidos traen soporte, ya sea de forma nativa o implementada como plug-in. En la página de openspf pueden encontrar una lista de los servidores que soportan SPF.
Como siempre, a Microsoft le gusta ser distinto y pasarse los estándares por las bol*s, así que decidió crear una versión propia de SPF la cual llamó Sender ID, pero el principio es exactamente el mismo.

Además del servidor con soporte SPF, si queremos que otros no puedan falsificar e-mails con nuestro nombre de dominio, necesitamos configurar una entrada en el/los servidor/es DNS autoritarios para nuestro dominio con un formato predefinido. Para no andar con problemas, se decidió utilizar el registro de tipo texto (TXT) del sistema DNS e incluir ahí los datos necesarios para el funcionamiento SPF.
Este registro contiene la versión de SPF y las IPs que tienen permitido enviar e-mails a nombre del dominio. El protocolo permite cierta flexibilidad y podemos especificar que todos los registros MX del dominio tienen permitido enviar mails, o incluir otros dominios en la lista de posibles emisores.
Para ver un ejemplo, podemos usar a google. Si hacemos un "nslookup -q=TXT google.com" veremos que nos responde con la siguiente entrada:
google.com text = "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
Este registro es bastante completo y contiene los siguientes datos:
- v=spf1 indica que utiliza la version 1 de SPF.
- include:_netblocks.google.com indica que los servidores del dominio _netblocks.google.com tienen permitido enviar e-mails a nombre de google.com
- ip4:216.73.93.70/31 ip4:216.73.93.72/31 indica que los rangos de IPv4 216.73.93.70/31 y 216.73.93.72/31 son emisores válidos para google.
- ~all nos dice que ningún servidor que no esté listado en los datos anteriores es un emisor válido.

Hay varios registros más que podemos utilizar para describir servidores válidos para el dominio, los cuales pueden ver en la página del proyecto SPF.

Si tienen problemas creando las entradas SPF en el servidor DNS no desesperen! existen wizards en páginas web diseñados para solucionarnos la vida. Por un lado contamos con el wizard de openspf y por si no les alcanza, también pueden utilizar el de Microsoft
Seguramente existen varios más, pero estos son los que primero encontre =P


Reflexión final

SPF puede ayudarnos muchísimo a limitar el SPAM que entra a nuestros servidores utilizando un mecanismo simple y ya implementado en los servidores de mails más importantes.
El mecanismo utilizado es muy similar a otros, como el de resolución inversa de IP, donde al recibir un mail de una dada IP el servidor realiza una consulta inversa (registro PTR en DNS) y resuelve si la IP pertenece al dominio de donde dice venir. Lo bueno de SPF es que es mucho más flexible, permitiendo definir distintos registros y dominios válidos.

La peor desventaja que le veo a SPF es el overhead de red. Utilizando este mecanismo tendremos que hacer una consulta DNS por cada e-mail que recibimos, lo cual, si recibimos cientos o miles de mails por día, puede resultar en alto consumo de ancho de banda y delays en la entrega de los mails.

Algo a tener en cuenta es que este sistema no elimina la posibilidad de enviar mails falsificados dentro de un mismo dominio. Si por ejemplo pepe envía un e-mail a nombre de jose@empresa.com utilizando el servidor de empresa.com, el e-mail será perfectamente válido desde el punto de vista de SPF.


Algunas Referencias
Sender Policy Framework Introduction
Sender Policy Framework (wiki)
news: renace milw0rm! ahora tenemos Offsec Exploit Archive

Hace unos días leí que la gente de Offensive Security estaba en tratativas con milw0rm para poner on-line la base de datos de exploits bajo su dominio y mantenerla actualizada. Ayer me entero que esta base de datos ya está on-line y su flamante nombre es Offsec Exploit Archive.
Esta nueva base de datos cuenta con los exploits de milw0rm así como también con algunos nuevos y ya están aceptando contribuciones.

Para el que no haya conocido milw0rm, ésta solía ser la primer fuente de exploits para investigadores y entusiastas, donde la gente que descubría un exploit lo compartía con el resto, probando que una vulnerabilidad podía ser explotada.
Con el tiempo, el administrador del sitio str0ke decidió que no podía seguir revisando los exploits que suministraban terceros y decidió cerrar el site. A pesar de esto, el site volvió a estar on-line un tiempo y se agregaron nuevos exploits, pero desde hace unas semanas esto se detuvo.

Por suerte, la gente de Offensive Security, encargados entre otras cosas de la genial distribución BackTrack, decidió tomar la posta y encargarse de la labor que llevaba a cabo str0ke, brindándonos un nuevo site, muy similar a milw0rm, donde la gente pueda compartir exploits.
El nuevo site lo pueden visitar ingresando en http://exploits.offensive-security.com/ o en http://explo.it
curiosidades: ARPANET en 1977
Leyendo un compilado de la historia de internet en The History of Internet in a Nutshell, me encontré un gráfico de cómo se veía ARPANET (la red precursora de Internet) en el 77. Si bien como dice el mismo gráfico, es una aproximación en base a los datos que tenían, refleja la arquitectura del momento.
Como verán, las PDP eran muy populares, habiendo algunas pocas DEC y UNIVAC entre otras.
El gráfico está sacado de wiki, donde pueden encontrar un poco más de información sobre ARPANET.

Server TFTP + Actualización IOS
Hoy me tocó realizar un trabajo que deja buena experiencia, cambiar el sistema operativo de algunos switchs Cisco. Para el que no conozca, los switchs Cisco traen un sistema operativo llamado IOS, y cuenta con su propio interprete de comandos, y utiliza comandos bastante distintos al mundo *nix. Además los switchs no tienen puerto USB, ni disketera, ni cd-rom, desde donde copiar información a la memoria =P

Para acceder a la configuración de uno de estos switchs necesitamos una conexión serie a la consola del aparato, o bien, si ya tiene una configuración básica (como una IP y métodos de acceso), podemos accederlo con cable UTP conectado a la máquina.

Ahora bien, el problema sigue siendo, cómo le copiamos una nueva imagen de IOS a la memoria del switch? la conexión por consola (para lo cual podemos usar minicom en Linux, o HyperTerminal en Windows) no nos permite enviar archivos, solo ejecutar comandos. La conexión por UTP sigue siendo lo mismo. Lo que necesitamos es utilizar un protocolo de transferencia de archivos, y por default, en muchos de estos switchs sólo contamos con TFTP. En algunas versiones más modernas de IOS podremos utilizar SCP, pero si andan en el mundo de las redes, probablemente se encuentren con que cuentan sólo con TFTP .


Qué es TFTP?

Eso mismo me pregunté en el momento que lo leí, el nombre nos dice que es FTP, pero de qué juega la T del principio? Aquellos administradores con más años en el rubro seguramente lo han utilizado, pero para los más modernos como yo, encontrar este protocolo en la actualidad es muy raro, salvo que se dediquen al bajo nivel
Una búsqueda rápida en internet nos revela que TFTP es una versión "Trivial" de FTP. Qué quiere decir esto? que no tiene una mierd*, sólo funciones put, get y algunos otros pocos comandos. Es decir, es la implementación mínima de un protocolo de transferencia de archivos.
A diferencia del FTP común, este protocolo funciona sobre UDP, no cuenta con autenticación alguna, es decir, uno se conecta directamente al server sin proveer ninguna credencial de acceso. Además es un protocolo bastante lento para la transferencia de archivos por lo que pude experimentar.
Por todo esto, usen TFTP solamente si no cuentan con otra cosa!


Instalando y usando TFTP

En Linux contamos con server y cliente TFTP y, dependiendo la distribución, es muy fácil de instalar. En debian sólo hace falta ejecutar:
# apt-get install tftpd

Una vez instalado tftp, al menos en debian, ya se comienza a ejecutar. Sino, puede reiniciar el demonio inetd el cual suele ser el encargado de levantar el servicio:
# killall inetd
# inetd

Ahora si, ya teniendo el server tftp funcionando, nos preguntamos cuál es el home donde se guardan los archivos por default! Por si no se dieron cuenta con la explicación en el párrafo anterior, con tftp no tenemos forma de navegar por directorios! solo copiar desde o hacia el server. Es decir, cuando nos conectamos a un servidor tftp sólo podremos copiar archivos en la carpeta default, no podremos navegar por los directorios para elegir otra fuente/destino de los archivos.
Para que la copia de archivos funcione, debemos tener configurado un home y tener permisos de escritura en ese directorio. El directorio default lo pueden ver en la configuración de inetd, la cual se encuentra en /etc/inetd.conf donde tendrán una línea similar a esta:
tftp dgram udp4 wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /var/lib/tftpboot
El último path de la línea es el path que utiliza tftp como home. Supuestamente (no lo comprobé) si no especificamos path, tftp toma el directorio /tftpboot como default. En la mayoría de las explicaciones que encontré recomiendan configurar ese directorio con permisos 777 y cambiarlo en la configuración de inetd.conf. Para esto, primero creamos el directorio y le cambiamos los permisos:
# mkdir /tftpboot
# chmod 777 /tftpboot

después cambiamos la configuración de inetd.conf para que quede el nuevo path:
tftp dgram udp4 wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot
Ahora si, reiniciamos inetd para que el server tome los cambios:
# killall inetd
# inetd

Bien, ya tenemos nuestro server TFPT configurado, ahora estaría bueno probarlo... he aquí donde llega la parte más "bizarra" de todo esto. No solo no podemos movernos por la estructura de directorios, sino que, además, si queremos copiar un archivo al servidor, este archivo debe existir ya en el servidor!!!, bueniiiiiiiisimo, antes de copiar cada archivo que deseen al servidor, primero deberán crear un archivo vacío con el mismo nombre, de otra forma, el servicio no funciona. Esto es, si queremos copiar el archivo prueba.txt de nuestra máquina (o desde el switch como haremos después) al servidor tftp, primero deberemos crear en el servidor en la carpeta /tftpboot un archivo vacío que se llame prueba.txt. Además debemos recordar de darle los permisos correspondientes para que el cliente pueda escribir en el server. Esto lo podemos hacer con:
# touch /tftpboot/prueba.txt
# chmod 777 /tftpboot/prueba.txt

Algunas referencias sobre cómo instalar tftpd en linux que pueden encontrar son estas:
http://onlamp.com/pub/a/bsd/2003/06/05/FreeBSD_Basics.html
http://www.debianhelp.co.uk/tftp.htm


TFTP en Windows?

Si todavía no tienen la suerte de utilizar un *nix, también pueden contar con un servidor TFTP en Windows. Pueden encontrar una versión open source en http://tftpd32.jounin.net/tftpd32_download.html aunque aclaro que no la probé, así que no tengo idea de la configuración necesaria.

UPDATE (20/11/09): Hace un par de días probé el servidor TFTP de Windows y funciona perfecto, tan solo hay que correr el ejecutable. La forma de trabajo es la misma que describí para Linux, hay que crear a mano cada archivo a copiar en el servidor.


Actualizar el IOS del switch

Una vez que tenemos instalado el bastante incompleto TFTP en la máquina desde donde actualizaremos el IOS, podemos empezar el proceso de actualización.
Lo que les voy a contar no es nada nuevo y lo pueden encontrar en la página oficial de Cisco, pero me pareció interesante traducirlo y darle mi toque personal.
Los pasos que describo se basan en la explicación de Upgrading Software Images on Catalyst 2950 and 2955 Series Switches Using the Command Line Interface donde explican el update del IOS para un Cisco Catalyst 2950.

Para la configuración voy a asumir que cuentan con una máquina conectada a la consola del switch y que tienen un servidor TFTP (que puede ser la misma máquina) con IP 192.168.1.1.

Como siempre en este tipo de tareas, lo mejor es arrancar con un buen backup. Para poder usar TFTP, deberemos darle un IP al switch (o a alguna vlan como en el ejemplo), si es que todavía no lo tiene. Esto lo hacemos de la siguiente forma:
switch # configure terminal
switch (config) # interfaces vlan 1
switch (config−if) # ip address 192.168.1.100 255.255.255.0
switch (config−if) # no shutdown
Ahora lo mejor es probar la conectividad a nuestro server y ver que funciona la transmisión de paquetes:
switch # ping 192.168.1.1
si dice "Success rate is 100 percent" estamos bien =)

Llegó la hora del backup. Lo que vamos a resguardar es la imágen IOS actual y la configuración del switch. Para el que no tenga mucho contacto con estos switchs, les comento que la configuración que el switch se encuentra ejecutando se llama runnin-config, la configuración que monta el switch cuando se inicia se llama startup-config. Por su parte, la imagen del IOS se encuentra en la memoria flash, la cual referenciamos con flash:
Recuerden la explicación sobre TFTP, antes de copiar los archivos del switch, deberán crear archivos vacíos con exactamente los mismos nombres en el servidor tftp en la carpeta /tftpboot, de otra forma la transferencia dará error! Además presten mucha atención con qué nombre copia el switch el archivo startup-config, porque le pone otro nombre (perdí un rato con esto ¬ ¬)
switch# copy startup-config tftp://192.168.1.1
switch# copy flash:c2950−i6q4l2−mz.121−11.EA1a.bin tftp://192.168.1.1
Con todo backupeado, podemos proceder a instalar la nueva imágen. Si tenemos espacio en la flash del switch podemos dejar la imagen vieja y copiar la nueva, pero, al menos en los 2950 q me toco testear, no tienen espacio (solamente cuentan con 8MB de flash!), así que primero debemos borrar la imagen vieja...

Aca es donde el lector suspicaz se preguntará "qué pasa si borro la imagen vieja y por alguna razón no puedo copiar la imagen nueva al switch?, el switch se transforma en un lindo ladrillo?"... bueno, al menos es lo que yo me pregunté antes de borrar la imagen. Por suerte la gente de Cisco pensó en esto, y si falla algo en este movimiento, podemos bootear el switch desde una imagen que se encuentre en un servidor TFTP. Es decir, el switch todavía es usable =D
Para borrar la imagen vieja, deberemos ejecutar lo siguiente:
switch # delete flash:c2950−i6q4l2−mz.121−11.EA1a.bin
Una vez que tenemos el espacio suficiente, ya podemos copiar la nueva imagen a la flash del switch, esto lo haremos nuevamente a través de TFTP. Recuerden que la imagen debe encontrarse en el directorio /tftpboot de otra forma, el switch no la va a encontrar:
switch # copy tftp://192.168.1.1/c2950−i6q4l2−mz.121−13.EA1.bin flash:
Por las dudas verificamos que la imagen es correcta:
switch # verify flash:c2950−i6q4l2−mz.121−13.EA1.bin
lo que nos debería dar "Verified flash:c2950−i6q4l2−mz.121−13.EA1.bin"

El próximo paso es configurar el switch para que bootee con la nueva imagen:
switch # configure terminal
switch (config)# boot system flash:c2950−i6q4l2−mz.121−13.EA1.bin
Y por las dudas nos aseguramos que el path de boot quedó bien con:
switch # sh boot

Llegando al final de esta super actualización deberemos salvar los cambios que se encuentran en memoria, y luego recargamos el switch para que inicia desde la nueva imagen:
switch # write memory
switch # reload
Ahora sí, como última prueba de que todo fue bien y que estamos ejecutando la nueva versión de IOS, ejecutamos lo siguiente:
switch # sh version
donde deberíamos ver la versión de nuestro flamante IOS nuevo =)


Sarasa final

Como verán actualizar un IOS no es algo tan complicado, aunque si es un trabajo bastante molesto usar el extremadamente pobre TFTP! A mi me llevó 2hs hacer la actualización y eso que no tenía ni idea de cómo hacerlo antes de empezar y perdí como 1.20hs inalando y probando el TFTP ¬ ¬
Suplantación de Proxy en redes switcheadas
Para el artículo del día de la fecha les traigo un más que interesante tutorial sobre sniffeo de red capturando todo el tráfico del proxy de la red local.

ACLARACION: el artículo está dirigido a aquellos que quieran aprender redes y penetration test, gente dedicada a la seguridad que utiliza el hacking ético para descubrir problemas a solucionar y reportarlos. Para hacer este tipo de ataque deben contar con la aprobación del encargado de la red o quien corresponda.


Mini Background

Por si alguno todavía no conoce de estas cosas, vale aclarar que sniffear es husmear los paquetes que pasan por la red, lo cual, dependiendo el tipo de red, nos permite ver cosas que no nos pertenecen. En las redes armadas con hubs (o viajas redes de cable coaxial) es posible ver todo el tráfico de todas las máquinas sin necesidad de herramientas especiales, simplemente necesitamos un sniffer y una placa que se pueda poner en modo promiscuo. El modo promiscuo indica que la placa de red atiende todos los paquetes como si fueran dirigidos a ella, incluso aquellos que tengan diferente MAC (dirección ethernet).

En el mundo de las redes switcheadas (redes donde todas las máquinas están conectadas a switchs) esto no es posible, a menos que realicemos algún tipo de ataque, o bien que los switchs sean de mala calidad (o esten saturados) y nos envíen tráfico que no deberían enviarnos =/ Esto se debe a que los switchs asocian cada port con la/s MAC/s que se encuentran enchufadas en el, así que si alguien envía un paquete al switch, éste lo entregará solo en la boca donde se encuenre la MAC, en lugar de entregarlo en todas las bocas como lo haría un hub.

El protocolo ARP (Address Resolution Protocol) se encarga de averiguar cuál es la MAC (dirección de red) que se encuentra asociada a una determinada IP. El mecanismo que usa es simple, envía un mensaje en la red preguntando quién es la máquina con una dada IP, cuando recibe una respuesta (ARP Reply), ya sabe a qué máquina debe enviarle los paquetes dirigidos a esa IP.

Un proxy es un servidor que acepta peticiones (por ejemplo http) y las reenvía al servidor externo que corresponda (por ejemplo google.com). Los proxies permiten controlar el tráfico que sale a internet, y además optimizar los pedidos. Si un usuario hace un pedido que ya hizo otro usuario, responde el proxy utilizando las entradas guardadas en su cache, y de esta forma se ahorra la necesidad de salir a internet a buscarlo. El tipo de proxy más conocido es el proxy web, que intercepta toda la navegación web, ya sea http o https.


Attacking!

El ataque que voy a explicar está dirigido a las redes switcheadas, donde todas las máquinas están conectadas a ports de algún switch. Dado que la mayoría de las redes medianas a grandes usan proxies para el tráfico http, todo el tráfico web pasa por estos servidores, por lo que si logramos engañar a las máquinas diciendo que nuestra máquina es el proxy, entonces tendremos el mundo a nuestros pies =P
Más precisamente, si hacemos que todos piensen que nuestra máquina es el proxy, podremos ver todo el tráfico web. Claro que el tráfico web encriptado (https) solo lo veremos pasar sin poder descifrar, pero el tráfico que no esté cifrado estará visible para nosotros.
A través de algunos ataques al protocolo ssl (como el reportado hace unos días) podríamos hacer alguna maldad con https, pero eso quedará para otro artículo =)


Tools

Antes de seguir, les paso la recopilación de herramientas que voy a utilizar, cosa que no lleguen a la mitad del artículo y digan, uhh me falta esto, me falta lo otro...
La lista es la siguiente:
- Linux o algún otro *nix - necesitamos de un sistema operativo que nos facilite la vida =D
- arpspoof - envía paquetes ARP indicando que nuestra IP (IP del atacante) está asociada a la MAC de la máquina que queremos suplantar (en el ejemplo del artículo, el proxy).
- iptables - la gloriosa herramienta del kernel de linux para decidir que hacer con los paquetes que llegan a nuestra máquina. En el caso de este tutorial, la usaremos para redirigir pedidos.
- WebScarab - proxy provisto por OWASP que nos permite observar los pedidos de los usuarios y redirigirlos al destino real.

Todas estas herramientas ya están incluidas en la distribución Back|Track.


Action!

Ahora sí, llega la parte buena!
Si bien con toda la introducción esto puede parecer trabajo realizable solamente por un hacker experimentado, la realidad es que con las herramientas que poseemos, lo puede hacer cualquier novato (por no decir cualquier idiota) que lea y entienda un poco.

Para el ejemplo, tendremos en cuenta que:
- el proxy tiene la dirección IP 192.168.1.1
- la MAC del proxy es 11:11:11:11:11:11
- el proxy escucha pedidos en el port 8080
- la IP del atacante es 192.168.1.128
- la MAC del atacante es 22:22:22:22:22:22
- la IP de la víctima es 192.168.1.120
- la MAC de la víctima no es relevante en este caso

El trabajo que realizaremos será:
- hacer que la víctima con IP 192.168.1.120 crea que la IP del proxy está asociada a la MAC 22:22:22:22:22:22, en lugar de la MAC real (11:11:11:11:11:11). Es decir, todo el tráfico que la víctima quiera enviar a la IP 192.168.1.1 (proxy) irá al atacante. Ver imágenes.










- redirigir internamente el tráfico que llega a la máquina del atacante con IP del proxy a la IP del atacante.
- montar un proxy que intercepte todos los pedidos de la víctima y los rediriga al proxy real. Redirigiendo los pedidos logramos transparencia para el usuario, dado que sus pedidos serán contestados correctamente.

Teniendo la idea de lo que vamos a hacer, ahora les explico cómo lo haremos:
- redirigimos los paquetes enviados al proxy original hacia el proxy que montaremos en el port 8008:
# iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 8008

- habilitamos el forwarding para que el resto de las conexiones del cliente sean entregadas en donde corresponde:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A FORWARD -j ACCEPT

- para que el usuario crea que la MAC asociada a la IP del proxy es la nuestra, usamos arpspoof de la siguiente manera:
# arpspoof -t 192.168.1.120 192.168.1.1
con -t indicamos que la víctima del ataque ARP es la IP 192.168.1.120, si no especificamos este parámetro, todas las máquinas de la red pueden ser víctima. A continuación especificamos la IP que queremos spoofear, osea, la del proxy.

- ahora sí, montamos nuestro proxy con WebScarab para interceptar y reenviar las conexiones web. Decidí utilizar WebScarab porque es muy flexible y permite ver de forma detallada los pedidos, ademas de poder hacer muchas otras cosas.
Dado que WebScarab está escrito en java y está empaquetado en un jar, lo ejecutamos con:
# java -jar webscarab.jar
otro programa que se puede utilizar para le propósito es webmitm, aunque en este no pude configurar la redirección al proxy original.
Si es la primera vez que arrancamos WebScarab, nos encontraremos con muy pocas opciones y parecerá un programa un tanto pobre. Para habilitar todas las opciones, debemos ir Tools y tildar "Use full-featured interface". Cerramos el programa, y al abrirlo de nuevo, tendremos todas las opciones.
Primero configuramos WebScarab para que escuche pedidos web en nuestra IP con port destino 8008 (por defecto solo escucha pedidos de localhost:8008). Para esto vamos a la solapa Proxy, y dentro de esta solapa, vamos a la solapa Listeners. Ahí nuestra IP, el port que deseamos (para el ejemplo sería 192.168.1.128 port 8008) y le damos Start.
Una vez configurado el Listener, procedemos a configurar el proxy real al que le redirigimos los pedidos. Vamos a la opción Tools -> Proxies y ahí colocamos la IP y el port del Proxy real (en el ejemplo 192.168.1.1 port 8080).
Con el programa ya configurado, vamos a la solapa Sumary y veremos pasar toooodos los pedidos del usuario.



Moraleja

Esto nos muestra lo simple que es suplantar un proxy (o cualquier otra máquina) en una red armada incluso con switchs y sniffear el tráfico o incluso modificarlo!
Una de las formas de prevenir este tipo de ataques es utilizar switchs de capa 3, que entiendan de IPs, donde se les pueda fijar el port donde se encuentra enchufada la IP del proxy, o incluso fijar el mapeo IP -> MAC.
Otra forma de evitar esto, es utilizar IPSec, aunque sea con los servidores importantes como el proxy, servers de mail, etc.
Error al iniciar kdm
Continuando con la lista de soluciones que empecé planteando en Problema -> Posible Solución, hoy les traigo una nueva solución.
Al no tener mucho tiempo para toquetear, hacía rato que no tenía problemas con mi debian, pero hoy toco volver a las andadas.
En realidad es un error que ya me había aparecido antes, pero que no documenté y por culpa de eso, me tocó investigar de nuevo.

Problema
El tema es que hoy enciendo la máquina y el maldito kdm me arroja el siguiente error:
no se puede abrir el archivo de tema @@@ToBeReplacedByDesktopBase@@@
sin cargar nada más, y con la única opción el apretar "Aceptar"... aca es donde uno dice "bueniiiiiiiiiisimo"....

El problema parece estar en el archivo que indica el tema a kdm, el cual se encuentra en /etc/default/kdm.d/, aunque en ningún momento toqué ese archivo (que en mi caso se llama 10_desktop-base)... reviso que las carpetas que referencia dicho archivo estén en su lugar y tengan los permisos adecuados y todo parece estar bien =S

Solución
La solución que encuentré en la lista de bugs de ubuntu es modificar la configuración base de temas de kde. Para esto, editamos el archivo /etc/kde4/kdm/kdmrc (o /etc/kde3/kdm/kdmrc en kde3) y buscamos la sección [X-*-Greeter]. Ahí comentamos la línea:
Theme=@@@ToBeReplacedByDesktopBase@@@
y en su lugar ponemos un Theme que exista (puede ser el mismo que nos figuraba en /etc/default/kdm.d/10_desktop-base). El ejemplo en mi caso quedó así:
Theme=/usr/share/apps/kdm/themes/moreblue-orbit
WALLPAPER=/usr/share/apps/kdm/themes/moreblue-orbit/background.png
Ahora reiniciamos kdm y debería funcionar (si es que el Theme y el WALLPAPER existen claro...).

Si alguien tiene alguna pista de por qué falló la interpretación del archivo /etc/default/kdm.d/ le estaré agradecido me lo explique =)
Estadisticas: malware!
Hoy les traigo no una, ni dos, sino tres estadísticas!, todas sobre malware y encontradas en Help Net Security. Como ya he comentado anteriormente en el blog, me encantan las estadísticas, así que estoy contento de haber encontrado varias interesantes para compartir.

Por un lado tenemos el caso de comparación de antivirus según su capacidad para eliminar malware realizado por AV-Comparative.org. En este caso no se tuvo en cuenta la capacidad de los antivirus para detectar el malware dado que se utilizó malware que aparece en la base de datos de los antivirus, sino que se testeó la capacidad de eliminar el malware de nuestras máquinas. Si bien este no es un ranking (no se rankean los antivirus con números), se puede ver cómo se desempeña cada software.
Como se ve en el gráfico, ninguno pudo sacar un "muy bien" en capacidad de remover malware o sobras de malware. Los únicos en sacar un "bien" tanto en capacidad de remover malware y sobras fueron eScan, Symantec y, curiosamente, Microsoft.

----------------------

Para el segundo dato estadístico, les tengo los países más infectados con bots según datos relevados en octubre por PandaLabs. En el top del ranking está España con un 44.49% de máquinas infectadas con bots... realmente una barbaridad!
A España le sigue de lejos Estados Unidos con un 14.41% de las máquinas infectadas, lo cual parece poco al lado del gran ganador. La seguidilla continúa con México (9.37%), y Brasil (4.81%).
Muchachos, tengan cuidado con lo que ejecutan!

----------------------

Por último tengo el clásico malware Top10 de BitDefender en octubre. No hubo muchos cambios con respecto al top 10 que publiqué hace unos meses, pero es igualmente interesante citar la nueva lista para ver como estamos. Una vez más, los troyanos son los que mayor presencia tienen en este mercado de malware.
El ranking es el siguiente:
1. Trojan.Clicker.CM 9.47% - usado típicamente para mostrar molestas propagandas en el browser.
2. Trojan.AutorunInf.Gen 8.54% - mecanismo genérico para distribuir malware en medios removibles.
3. Win32.Worm.Downadup 5.29% - nuestro ya viejo conocido conficker sigue presente en muchísimas máquinas del mundo...
4. Trojan.Wimad 4.90% - este troyano afecta archivos ASF, el cual usa un ASF modificado para descargar troyanos en lugar de codecs...
5. Exploit.PDF-JS.Gen 4.84% - detección genérica para archivos PDF modificados que aprovechan vulnerabilidades JavaScript en nuestro Adobe (Vulnerable) Reader, y así descargar malware.
6. Win32.Sality.OG 2.31% - infector polimórfico de archivos que agrega código infectado en ejecutables.
7. Trojan.Autorun.AET 2.20% - otro troyano que aprovecha el Autorun de windows para propagarse, así como también los archivos compartidos.
8. Worm.Autorun.VHG 1.49% - worm que aprovecha la vulnerabilidad MS08-067 para ejecutarse remotamente usando una llamada RPC.
9. Trojan.Swizzor.6 1.22% - troyano que intenta guardar y ejecutar otros malwares en la máquina afectada. Este troyano guarda una clave en el registro para que Windows lo ejecute cada vez que se inicia.
10. Gen:Adware.Heur.wq0@j4oukhei 1.21 - rutina genérica detectada en varias aplicaciones adware.


Bueno, eso es todo en este review de estadísticas de malware. Como siempre digo, tengan cuidado cuando naveguen por la red... Linux is safer! =P
Scanner de redes
Hace un tiempo tenía ganas de escribir un scriptcito que me automatice el escaneo de la intranet de la empresa, y con la necesidad de descubrir los IPs de ciertos dispositivos, me puse a escribir el demorado script.

El script no es para nada complejo, simplemente utiliza los fingerprint devueltos por un escaneo de nmap para diferenciar los distintos dispositivos. Lo que hace básicamente es escanear las IPs entre dos valores pasados por parámetro, y por cada IP decide si se trata de un web server, un database server, un switch, un router, un firewall, un mail server, una impresora, y los clasifica guardando las IPs con los ports en archivos separados.
Existe un programa llamado autoscan que es mucho más completo y utiliza interfaz gráfica, pero a mi nunca me anduvo, me satura la red y el programa colapsa sin dejarme guardar los resultados. Por eso cree este script que hace todo lo q necesito.

La licencia del script es GPLv2.
El gran mérito se lo lleva el nmap que es el que realiza el verdadero trabajo, sin dudas el programa más útil que he encontrado para mi trabajo.

Espero que les sea de utilidad y que si hacen alguna derivación lo comenten en el blog, tal vez me sea de utilidad a mi también =)

Los comentarios están en inglés porque me acostumbré a programar así, con comentarios en inglés, éste le puede servir a mucha más gente.

#!/bin/bash

######################################################
# Created by: d3m4s1@d0v1v0
# Date: 2009-11-04
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License v2 as published by
# the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.

######################################################

if [ $# -lt 2 ]
then
echo "usage: $0 "
exit -1
fi

INI_IP=$1 # from which IP do you want to scan? // take into account the "this network" direction (e.g. 192.168.0.0)
FINAL_IP=$2 # until which IP do you want to scan? // take into account the broadcast direction! (e.g. 192.168.0.255)

time=$( date +"%m-%d-%y %H:%M" )

echo "Starting dv-scan-network 0.1.1beta at $time..."

IP=(${INI_IP//./ })
IP_FIN=(${FINAL_IP//./ })

timestamp=$( date +"%s" )

mkdir report-$timestamp &> /dev/null
cd report-$timestamp

webservers=0
printers=0
switchs=0
routers=0
remote_access=0
dbservers=0
mailservers=0
firewalls=0
hosts=0
down=0

for (( A=${IP[0]}; A<=${IP_FIN[0]}; A++ )) do for (( B=${IP[1]}; B<=${IP_FIN[1]}; B++ )) do for (( C=${IP[2]}; C<=${IP_FIN[2]}; C++ )) do for (( D=( ${IP[3]} ); D<=${IP_FIN[3]}; D++ )) do scanIP="$A.$B.$C.$D" echo -n "scanning $scanIP..." hostscan=$( nmap -sV $scanIP -O ) if [ $? == 0 ] then echo " [done]" else echo " [failed]" fi if [[ "$hostscan" =~ "Host seems down" ]] then echo "$scanIP" >> down.txt
let down++

else
if [[ "$hostscan" =~ switch ]]
then
printf "%s $hostscan" >> switchs.txt
echo "" >> switchs.txt
echo "--------------" >> switchs.txt
echo $scanIP >> switchs-ip.txt
let switchs++
fi

if [[ "$hostscan" =~ router ]]
then
printf "%s $hostscan" >> routers.txt
echo "" >> routers.txt
echo "--------------" >> routers.txt
echo $scanIP >> routers-ip.txt
let routers++
fi

if [[ "$hostscan" =~ printer ]]
then
printf "%s $hostscan" >> printers.txt
echo "" >> printers.txt
echo "--------------" >> printers.txt
echo $scanIP >> printers-ip.txt
let printers++
fi

if [[ "$hostscan" =~ Apache ]] || [[ "$hostscan" =~ IIS ]]
then
printf "%s $hostscan" >> web-servers.txt
echo "" >> web-servers.txt
echo "--------------" >> web-servers.txt
echo $scanIP >> web-servers-ip.txt
let webservers++
fi

if [[ "$hostscan" =~ smtp ]] || [[ "$hostscan" =~ pop3 ]] || [[ "$hostscan" =~ imap ]]
then
printf "%s $hostscan" >> mail-servers.txt
echo "" >> mail-servers.txt
echo "--------------" >> mail-servers.txt
echo $scanIP >> mail-servers-ip.txt
let mailservers++
fi

if [[ "$hostscan" =~ oracle ]] || [[ "$hostscan" =~ mysql ]] || [[ "$hostscan" =~ ms-sql ]] || [[ "$hostscan" =~ 3051 ]]
then
printf "%s $hostscan" >> db-servers.txt
echo "" >> db-servers.txt
echo "--------------" >> db-servers.txt
echo $scanIP >> db-servers-ip.txt
let dbservers++
fi

if [[ "$hostscan" =~ ssh ]] || [[ "$hostscan" =~ microsoft-rdp ]] || [[ "$hostscan" =~ vnc ]] || [[ "$hostscan" =~ telnet ]]
then
printf "%s $hostscan" >> remote-access.txt
echo "" >> remote-access.txt
echo "--------------" >> remote-access.txt
echo $scanIP >> remote-access-ip.txt
let remote_access++
fi

if [[ "$hostscan" =~ firewall ]]
then
printf "%s $hostscan" >> firewalls.txt
echo "" >> firewalls.txt
echo "--------------" >> firewalls.txt
echo $scanIP >> firewalls-ip.txt
let firewalls++
fi

printf "%s $hostscan" >> scan.txt
echo "" >> scan.txt
echo "--------------" >> scan.txt
echo $scanIP >> hosts-ip.txt
let hosts++

sleep 10
fi
done
done
done
done

endtimestamp=$( date +"%s" )
scantime=$(( endtimestamp - timestamp ))
echo $scantime

endtime=$( date +"%m-%d-%y %H:%M" )

hours=$((scantime / 3600))
seconds=$((scantime % 3600))
minutes=$((scantime / 60))
seconds=$((scantime % 60))

echo ""
echo "scan ended at $endtime in $hours:$minutes:$seconds"
echo "dv-scan-network resume:"
echo "scanned hosts = "$hosts
echo "hosts that seems down = "$down
echo "web servers found = "$webservers
echo "mail servers found = "$mailservers
echo "database servers found = "$dbservers
echo "switchs found = "$switchs
echo "routers found = "$routers
echo "remote access found = "$remote_access
echo "printers found = "$printers
echo "firewalls found = "$firewalls
echo ""
echo "for more information about the hosts, read the report at the report-timestamp/ directory"
Lo más leido en Octubre
A falta de tiempo para investigar y crear artículos nuevos, relleno un poco con la ya clásica (?!) sección de lo más leído del mes, así el que entra al blog por primera vez encuentra los artículos que otros encontraron interesantes =)

Durante octubre se mantuvo el número de visitas y como siempre, los artículos sobre Linux son los más visitados, aunque esta vez aparece uno de Windows, el cual es el resultado de varios días de investigación, así que me alegra que les sirva a otros.
Veamos la lista de una buena vez...

1. Crear máquina virtual en CentOS usando Xen. Al igual que el mes pasado, este artículo aparece nuevamente como el más leído. El artículo es el resultado de varias pruebas, investigación, instalaciones fallidas y otros dolores de cabeza, donde pude lograr una instalación existosa de un CentOS sobre una máquina virtual Xen... creo que vale la pena leerlo para cualquiera que necesite virtualización =)

2. Cómo crear un corrector ortográfico. Realmente me sorprende que aparezca en segundo lugar este artículo, el cual si bien considero extremadamente interesante, en su momento pasó sin pena ni gloria =P
No muchos saben cómo funciona un corrector ortográfico, pero estos son muchísimo más simples de lo que puedas imaginar, tan solo 21 líneas de código en python!

3. Tunear logs de SQL Server. El único artículo de la lista relacionado a Microsoft y el único escrito en octubre. Imaginé que iba a escalar rápido en cantidad de lecturas porque no encontré mucha información sobre logs de SQL Server... espero que les sea de utilidad a todos aquellos que tienen la desgracia suerte de usar las herramientas de MS.

4. Programando tareas con cron. Y si, programar tareas es fundamental para cualquier administración de sistemas y cron es un demonio muy flexible y útil. Es claro porque este artículo sigue apareciendo entre los más leídos, a pesar de que existe bastante información sobre cron en la red.

5. Hora en Linux y diferencias con Wdinows. Cuando uno viene de windows y su sistema para setear la hora local, se encuentra que en linux con el sistema basado en el horario UTC. Una vez más, este artículo surge de la necesidad de cambiar la hora y coordinar los horarios de Windows y Linux en la misma máquina, por suerte ahora anda todo bien.

Eso es todo por ahora, espero tener tiempo para meter un par de artículos interesantes este mes. Vengo algo corto de tiempo para investigar y escribir artículos bien completos como me gusta y por eso la escacez, pero estoy viendo muchos temas interesantes sobre los cuales espero escribir pronto.