Usando Google como Web proxy

Hoy estaba leyendo este interesante artículo que trata la ciberguerra que se ha desatado entre los defensores y detractores de Wikileaks (yo soy un defensor de Wikileaks), y por esas cosas de Internet terminé en cualquier otra cosa.
Estaba husmeando los posts en twitter del nefasto th3j35t3r, un payaso que se dedica a provocar ataques DDoS contra diferentes sitios, la mayoría musulmanes, y que además se encargó de efectuar estos ataques contra Wikileaks ("for attempting to endager the lives of our troops, 'other assets' & foreign relatios").

La cuestion es que se me ocurrió visitar uno de estos sitios musulmanes """terroristas""" por
simple curiosidad, y me encotré con estos chirimbolos indescifrables del idioma árabe. Entonces decidí utilizar Google translate para pasar la página al idioma inglés y entender algo.
El sitio en sí era bastante aburrido, pero lo interesante fue que al ver la URL en la barra de direcciones de Firefox, se me ocurrió utilzar a Google como Web proxy (para aquellos que no sepan que es un proxy, pueden buscar en Wikipedia y leer mi artículo anterior).

Además de ocultar nuestro trasero, un proxy nos permite acceder a sitios no permitidos por la política de nuestro dominio (en mi caso, un proxy que filtra, entre otros sitios, facebook, twitter, etc).
Esto nos muestra una vez más cómo se puede abusar de un servicio tan inofensivo como Google translate.

Veamos cómo funciona paso a paso:

Primero veamos con qué IP salimos a Internet visitando el sitio ip-adress.com:



Se observa que salimos con una dirección 200.x.x.x perteneciente a nuestra organización. Ahora ingresamos a Google translate y colocamos la URL en el cuadro de traducción:



Google translate nos muestra la misma página pero dentro de un frame. Observamos que la dirección es ahora 74.125.114.80 que corresponde con un servidor de Google:



Para finalizar, probamos ingresar a un sitio no permitido, como es linkedin en mi caso:



La página no se ve correctamente, pero al menos se puede acceder ;)

De esta forma logramos utilizar a Google como Web proxy.

Espero que lo disfruten!

Proxy chaining... or how to hide your ass

A veces es necesario no dejar rastros cuando accedemos a sistemas de terceros. Sea cual sea el motivo (supongamos que es por razones nobles) y si es un sistema sensible, queremos asegurarnos de quedar lo más ocultos posibles y no dejar huellas como direcciones IP, footprints de encabezados HTTP, etc.

Para esto siempre es conveniente utilizar un servidor proxy como un intermediario que accede al servidor objetivo por nosotros y luego nos devuelve los resultados. De esta forma, si el servidor objetivo loguea nuestra actividad en el sistema, quien quedará "escrachado" en los logs será el proxy en lugar de nosotros. Así quedamos cubiertos en caso de un eventual análisis forense en el servidor objetivo.

Pero... Puede suceder que el análisis forense consulte al proxy y éste entregue información sobre nuestros accesos, lo que nos pondría en evidencia. Esta situación nos obliga a ocultar aún más nuestro rastro utilizando un proxy en el proxy. Es decir un intermediario del intermediario, para crear una cadena lo suficientemente larga que nos oculte más.

Esta técnica que consiste en conectarse a más de un proxy se denomina "proxy chaining". Cuanto mayor sea la cadena más ocultos estaremos, aunque cabe aclarar que no importa cuantos proxies agreguemos a la cadena, nunca seremos 100% anónimos.

De todas formas hay que ocultar nuestro trasero lo más que se pueda...


Proxy chaining

El proceso es bastante simple, primero ingresaremos en algún sitio como whatismyip.com para detectar con qué dirección IP salimos a Internet:


Se observa que nuestra dirección IP es 200.x.x.x. Este sitio además nos informa que estamos saliendo a Internet a través de un proxy.

Luego buscamos en Google una lista de servidores proxy abiertos (sin usuario ni password) y gratuitos:


El sitio Proxy 4 Free es uno de los primeros que aparece en la búsqueda. Es conveniente ordenar los servidores por Rating o Uptime:


Para nuestro ejemplo, el primero que elegí, al azar, fue online proxi:


Ahora, utilizando el cuadro de URL del proxy (no el de nuestro browser) accedemos a whatismyip para ver desde qué dirección IP se hace el pedido HTTP:


Se observa que ahora la dirección IP que hace el pedido HTTP es 173.224.217.162. Hasta ahora estamos ocultos detrás de un sólo proxy. Para comenzar la cadena, vamos a ingresar la dirección del siguiente proxy en el cuadro de URL del primer proxy. Como segundo proxy utilicé openet.info:


Ingresamos a whatismyip desde el cuadro de URL de openet.info y observamos que ahora la dirección IP que hace el pedido HTTP es 94.75.216.169:


Como se observa en la captura anterior, ahora tenemos dos cabeceras de proxy. La primera, de color amarillo, corresponde al proxy online proxi; la segunda, de color gris, corresponde a openet.info.
Siguiendo con el proceso de chaining agregamos otro servidor proxy a la cadena. Esta vez se trata de Safety Proxy:


Ingresamos a whatismyip nuevamente y se observa la dirección 67.159.44.24:


Ahora se observa una cabecera adicional, la cual aparece arriba de las dos anteriores. En el campo de URL de esta cabecera es donde debemos realizar nuestros pedidos HTTP.
Cabe aclarar que cuanto mayor sea la cantidad de servidores proxy que agregamos a la cadena, más lenta se torna la navegación ya que todos los pedidos y respuestas deben atravesar toda la cadena.

El siguiente gráfico muestra la cadena de servidores proxy que atraviesan nuestros pedidos hasta llegar al servidor objetivo:


Que lo disfruten!

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.