Como se ha visto a lo largo de esta serie de entradas relacionadas con TOR y el anonimato, las capacidades que brinda TOR para proteger las comunicaciones que viajan entre dos o más maquinas no siempre son tan “transparentes” para el usuario final y en algunas ocasiones puede ocurrir que existan fugas de información que pueden llevar al descubrimiento de la identidad real del usuario (dirección IP, dominio y/o cualquier otra información sensible), aunque uno de los usos más frecuentes desde el punto de vista del usuario final consiste en la configuración de TorButton para navegar por internet utilizando TOR, aun pueden existir fugas relacionadas con otras aplicaciones que se ejecutan desde un entorno distinto al navegador web (como por ejemplo comandos de red que se ejecutan desde consola). Para mitigar este tipo de problemas que pueden llevar a fugas de información relacionadas con la identidad del usuario, se pueden llevar a cabo algunas medidas para eliminar este tipo de fugas, a continuación se indican algunas técnicas y recomendaciones generales a la hora de utilizar algunas de las aplicaciones más comunes en el arsenal de un atacante.

NMAP

Nmap es probablemente una de las aplicaciones mas utilizadas para el reconocimiento de objetivos, escaneo de servicios, puertos e incluso vulnerabilidades (utilizando scripts de NMAP), anteriormente se ha hablado de esta herramienta en este blog, normalmente se utiliza ProxyChains y TOR para realizar ataques de reconocimiento de forma anónima utilizando la red de TOR, sin embargo, este mecanismo por si solo no garantiza el correcto anonimato de las peticiones (tal como se ha visto en la parte IV de esta serie) ahora en esta ocasión se indica el conjunto de opciones que se recomienda y no se recomienda utilizar:

  1. Evitar fugas DNS (protocolo DNS funciona con UDP) se recomienda utilizar la opción -PN

  2. Evitar que Nmap intente un reconocimiento del objetivo para determinar si esta activo o no (ejecutando Pings con ICMP_ECHO) se recomienda utilizar la opción: -n también se puede utilizar la correspondiente opción de desactivación de pings: -P0

  3. Evitar fugas de cualquier protocolo distinto a TCP (nuevamente recordar que TOR es una solución que solamente funciona con paquetes TCP) se debe forzar el tipo de escaneo TCP-Connect de NMAP, utilizar la opción: -sT

  4. No utilizar nombres de dominios como objetivos de los escaneos activos, ya que Nmap intentará utilizar peticiones DNS para resolver dichos nombres a direcciones IP validas, se recomienda utilizar tor-resolve para determinar la dirección IP de un objetivo.

  5. No utilizar tipos de escaneos diferentes a TCP/Connect ya que cualquier escaneo que no utilice TCP como protocolo de comunicación no pasará por la red de TOR, dejando la identidad del atacante expuesta, esto se ha mencionado en múltiples ocasiones, pero nunca esta de más recordarlo dada su importancia.

  6. Utilizar IPTables para filtrar el trafico saliente, eliminando todos los paquetes que no sean protocolo TCP, por ejemplo si se realiza una petición DNS (protocolo UDP) es mejor eliminar dicho paquete a revelar la ubicación real de dicha petición en la maquina remota.

  7. Especificar los puertos de interés a escanear, dado que el hecho de no especificar aquellos que sean de mayor interés, Nmap intentará escanear todos los puertos de la maquina remota, lo que puede llevar a un consumo innecesario de tiempo y de recursos ya que los escaneos utilizando NMAP y TOR no son especialmente rápidos. Para esto utilizar la opción: -p [puerto1,{puertoN}]

  8. Finalmente, como se ha indicado con anterioridad en otras entradas relacionadas con este tema, se recomienda utilizar TorTunnel y proxychains para utilizar directamente el nodo de salida del circuito TOR, de esta manera las peticiones serán mucho más rápidas.

MetaSploit FrameWork

MetaSploit cuenta con una gran colección de exploits y módulos auxiliares que permiten realizar ataques remotos, debido a la gran extensión de aplicaciones y usos que abarcan estos módulos, es difícil garantizar el correcto anonimato utilizando TOR y MetaSploit, no obstante se puede conseguir con una correcta configuración sobre la máquina del atacante utilizando el concepto de “Proxy Transparente” que consiste en el análisis y tratamiento del trafico saliente de la maquina local, típicamente utilizando IpTables, eliminando aquellos paquetes que no viajan por el protocolo TCP, no obstante en los casos mas comunes, muchos exploits y módulos utilizan paquetes TCP para llevar a cabo sus acciones, para estos casos se puede utilizar TorSocks o Proxychains del mismo modo que se ha utilizado con Nmap, por ejemplo el siguiente comando ejecutará MetaSploit por medio de TorSocks

>usewithtor msfconsole

Como ya se ha indicado pueden existir módulos que generen DNS Leaks o realicen conexiones directas utilizando ICMP (como por ejemplo un ping) estos casos se trataran en mayor profundidad en la próxima entrada sobre “Proxy Transparente” y algunas opciones de configuración de TOR. Por otro lado también es posible utilizar “ProxyChains” para realizar este tipo de tareas, simplemente indicando en el fichero de configuración (/etc/proxychains.conf) el servidor SOCKS al que debe dirigir la petición, que puede ser privoxy, polipo o directamente TOR y posteriormente ejecutar el comando:

>proxychains msfconsole

Entre estos dos mecanismos se recomienda, evidentemente utilizar el primero, principalmente porque TorSocks puede detectar peticiones UDP o ICMP y automáticamente las rechaza con el fin de evitar un posible DNS Leak.

Nikto

Nikto permite escanear vulnerabilidades y malas configuraciones sobre servidores y aplicaciones web, utilizando técnicas de codificación para evasión de IDS, Chequeos de versiones de servidores y componentes des actualizados, etc.

Para mayor información sobre Nikto se recomienda leer otras entradas sobre dicha herramienta en este blog aquí:

https://thehackerway.wordpress.com/2011/05/12/conceptos-basicos-de-nikto-tecnicas-de-escaneo-de-servidores-y-aplicaciones-web/

https://thehackerway.wordpress.com/2011/05/14/conociendo-las-tecnicas-de-escaneo-incluidas-en-nikto/

https://thehackerway.wordpress.com/2011/05/16/integrando-herramientas-del-arsenal-nikto-y-nessus/

https://thehackerway.wordpress.com/2011/05/17/integrando-herramientas-del-arsenal-nikto-y-metasploit-framework/

https://thehackerway.wordpress.com/2011/05/18/personalizando-nikto/

Ahora bien, con Nikto es posible utilizar TOR para enviar todas las peticiones por dicha red, para esto se debe disponer de un servidor proxy HTTP como Polipo o Privoxy y utilizar el soporte que tiene Nikto para este tipo de tareas con la opción -useproxy

>./nikto.pl -h https://1.2.3.4 -useproxy http://127.0.0.1:8123

En el caso anterior, se utiliza Polipo como servidor proxy, el cual a su vez esta configurado para utilizar TOR. Aunque de esta forma Nikto utilizará TOR aun pueden existir fugas de información en peticiones DNS especialmente cuando el objetivo del escaneo no es una dirección IP como en el caso anterior sino que es un nombre de dominio, en tales casos Nikto necesita resolver tal dominio en una dirección IP valida, esta petición DNS se establece de forma directa sin pasar por la red de TOR, por este motivo, el anonimato puede verse afectado.

Para remediar esto, se puede utilizar TorSocks junto con la opción “-useproxy” de esta manera todas las peticiones viajaran por medio de TOR y TorSocks rechazará cualquier indicio de fuga de información.

>usewithtor ./nikto.pl -h https://1.2.3.4 -useproxy http://127.0.0.1:8123

De esta forma se utiliza Nikto con TOR evitando DNS Leaks.

W3AF

W3AF es una framework para realizar tareas de pentesting sobre aplicaciones y servidores web, viene estructurado en distintos módulos que permiten realizar determinadas funciones en cada una de las etapas de una prueba de penetración contra un servidor web remoto. Se trata de una herramienta que se encuentra actualmente en constante desarrollo y casi a diario existen actualizaciones implementado mejoras y solución a diferentes problemas. Aunque aun no puede ser catalogada como una herramienta “estable” implementa características muy interesantes que otras herramientas libres y privadas aun no logran conseguir, además de esto, cuenta con soporte a Proxy HTTP con lo cual, el mecanismo para ejecutar W3AF utilizando la red de TOR es bastante similar al mecanismo empleado anteriormente en Nikto, solamente es necesario establecer el proxy HTTP (aunque pueden ser Polipo o Privoxy, en este caso simplemente se utilizará Socat como relay de la conexión) y posteriormente ejecutar los comandos necesarios ya sea desde consola interactiva o desde la interfaz gráfica de WA3F.

Para conocer a un nivel de detalle más profundo las capacidades y características de W3AF se recomienda leer entradas anteriores de este blog en:

https://thehackerway.wordpress.com/2011/05/28/conceptos-basicos-sobre-w3af-web-application-attack-and-audit-framework/

https://thehackerway.wordpress.com/2011/05/30/funcionamiento-de-w3af-introduccion-al-framework-parte-i/

https://thehackerway.wordpress.com/2011/05/31/321/

https://thehackerway.wordpress.com/2011/06/01/funcionamiento-de-w3af-%e2%80%93-encontrando-vulnerabilidades-y-ejecutando-exploits/

https://thehackerway.wordpress.com/2011/06/02/integrando-herramientas-del-arsenal-metasploit-framework-y-w3af-hot-topic/

https://thehackerway.wordpress.com/2011/06/03/funcionamiento-de-w3af-%e2%80%93-tools-scripts-y-gui-de-w3af/

Con W3AF existe una característica que en este caso concreto es útil, se trata de la capacidad de ejecutar pequeños scripts que realizan una serie de acciones al momento de iniciar la consola de W3AF, en este caso, puede ser útil crear un script que establezca de forma automática el proxy a ejecutar que como ya se ha dicho será Socat:

Primero iniciar el relay de la conexión hacia TOR:

>socat TCP4-LISTEN:4444,reuseaddr,fork SOCKS4A:127.0.0.1:77.109.169.139:80,socksport=9050

Una vez iniciado el Relay se puede indicar crear un script para establecer el proxy en el inicio de W3AF que contendrá el siguiente contenido

http-settings set proxyAddress 127.0.0.1

http-settings set proxyPort 4444

Posteriormente iniciar W3AF con el siguiente comando

>w3af_console -s scriptProxy.txt

Ahora se pueden ejecutar comandos directamente a un objetivo determinado pasando por la red de TOR.

Por otro lado también puede emplearse el relay iniciado con socat para realizar la prueba de penetración directamente sin establecer la dirección como proxy, por ejemplo:

>w3af_console -s scriptProxy.txt

w3af>>> target set target https://1.2.3.4:80

w3af>>> plugins discovery serverHeader

w3af>>> plugins discovery serverStatus

w3af>>> plugins discovery findBackdoor

w3af>>> plugins discovery fingerprint_os

w3af>>> plugins audit sqli

w3af>>> start

Finalmente, como todas las aplicaciones que se ejecutan en consola, W3AF puede ser ejecutada con TorSocks para asegurarse de que no existen DNS Leaks.

>usewithtor ./w3af_console

THC Hydra

Se trata de una herramienta muy popular para realizar ataques de fuerza bruta contra diferentes tipos de servicios tales como HTTPS, POP, SSH, SMB, entre muchos otros. Cuando se realiza un ataque de fuerza bruta, es necesario realizar múltiples conexiones contra el sistema remoto y probablemente dicho sistema puede tener mecanismos de defensa para restringir este tipo de ataques en función de la dirección IP de la maquina que realiza la conexión. Es aquí donde TOR puede ajustarse perfectamente, aprovechando la red de TOR como pivote para realizar este tipo de ataques. (para ver en detalle el funcionamiento de THC Hydra, ver una entrada anterior de este blog aquí: https://thehackerway.wordpress.com/2011/04/08/hydra-ataques-de-fuerza-bruta/)

NOTA: A la fecha de la escritura de este documento, la versión de Hydra es la 7.0 y como con sus versiones anteriores, existen problemas para ejecutar Hydra contra un servicio SSH, se recomienda seguir los siguientes pasos si se desea utilizar Hydra contra SSH.
1- Descargar la librería LIBSSH (la versión actual es la 0.5.1) desde: http://www.libssh.org/ descargar el tarball y descomprimirlo, posteriormente realizar la siguiente secuencia de pasos para instalarla

>mkdir build

>cd build

>cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DWITH_LIBZ=OFF ..

2. Compilar (o recompilar) Hydra para soporte SSH, ahora debe encontrar la librería SSH, al ejecutar el comando ./configure debe aparecer que la librería SSH ha sido encontrada

./configure

…………………..

Checking for libssh (libssh/libssh.h) …

… found

>make

>make -B

>make install

3. Probar que se encuentra correctamente configurado ejecutando Hydra utilizando SSH como protocolo.

Retomando el hilo del post después de la aclaración anterior, en Hydra es posible establecer un proxy (SOCKS o HTTP). En Hydra el mecanismo empleado para utilizar un proxy consiste en el establecimiento de variables de entorno, en concreto es necesario editar el fichero ~/.bashrc y allí indicar el servidor proxy utilizado por Hydra. El contenido de dicho fichero debe incluir la siguiente linea:

export HYDRA_PROXY_CONNECT=127.0.0.1:9050

Suponiendo que TOR se encuentre en ejecución como servidor SOCKS en el puerto 9050, así cuando se ejecute el comando correspondiente (hydra o xhydra) en realidad todas las peticiones viajaran por TOR.

>hydra -l hacker -P userPass.lst -t 2 192.168.1.34 ssh

Hydra v7.0 (c)2011 by van Hauser/THC & David Maciejak – for legal purposes only

Hydra (http://www.thc.org/thc-hydra) starting at 2011-09-18 02:45:28

[INFO] Using Connect Proxy: 127.0.0.1:9050

[DATA] 2 tasks, 1 server, 3 login tries (l:1/p:3), ~1 try per task

[DATA] attacking service ssh on port 22

[22][ssh] host: 192.168.1.34 login: hacker password: peraspera

[STATUS] attack finished for 192.168.1.34 (waiting for children to finish)

1 of 1 target successfuly completed, 1 valid password found

Hydra (http://www.thc.org/thc-hydra) finished at 2011-09-18 02:45:31

Es importante notar que durante la ejecución del comando Hydra debe arrojar un mensaje informativo indicando que se esta utilizando un Proxy para realizar la conexión y que dicho proxy es el que se encuentra definido en el fichero de configuración.

Del mismo modo que con los comandos anteriores, se recomienda utilizar TorSocks en conjunto con el proxy establecido con el fin de evitar cualquier tipo de fuga.

>usewithtor hydra -l hacker -P userPass.lst -t 2 192.168.1.34 ssh

Finalmente, las recomendaciones aquí indicadas son bastante útiles, sin embargo, como es posible determinar en primer lugar si una aplicación determinada tiene algún tipo de fuga o utiliza un protocolo de comunicación distinto a TCP para contactar con otra maquina (evidentemente sin informarlo de forma explicita) esta será una de las técnicas de depuración más útiles, conocer cuando una aplicación tiene algún tipo de fuga de la cual no se tiene conocimiento, esto se verá en una próxima entrada.

Hacking, Networking, Services – Software