sábado, 27 de junio de 2009

Reto: Santa Claus is Hacking to Town

Hace unos días llegó a mis manos a través del trabajo un reto hacking de Ed Skoudis llamado "Santa Claus is Hacking to Town" (Santa Claus está Hackeando la ciudad), que para los que tengan problemas con el inglés y no quieran recrearse leyendo la historia completa ( menuda imaginación, Ed :) ), basicamente el reto comienza en que te encuentras en una celda con tu portatil y unas pocas herramientas de hacking, y según cuenta la historia tienes algunas herramientas disponibles y algunas pistas, que por no reescribir todo lo que pone el resto vamos a ir un poco al grano:

Herramientas:
  • Portatil con una máquina virtual Windows y otra Linux.
  • Metasploit Framework: Actualizada a la última versión y con sus últimos exploits y plugins.
  • NetCat compilado para Linux.
  • NMap.
  • PSExec de Sysinternals.
Mapa de la red:




Objetivo:
  • Ejecutar en la máquina Door1 el binario dooropen.exe sobre el que sólo tiene privilegios el usuario jailmaster, para que la puerta de la celda donde estamos atrapados se abra.

Pistas/Reglas:
  • El punto de acceso permite la conexión sin cifrado ni autentiación, pero no da acceso a Internet.
  • Desde la red con NMap se descubren dos equipos: jaimpasterlaptop y web1.
  • Jailmasterlaptop: Máquina Windows sin parchear que tiene una vulnerabilidad que podemos explotar con Metasploit para ganar privilegios de SYSTEM.
  • Web1: Máquina Linux con IPTables activado que nos permite que extablezcamos conexiones únicamente contra su puerto 80, estando el resto filtrados. Las conexiones salientes están todas permitidas. La aplicación web tiene en algún sitio una vulnerabilidad de inyección de comandos que nos permite ejecutar comandos como el usuario Apache, pero está completamente parcheada y no presenta vulnerabilidades que nos vayan a permitir escalar privilegios.
  • Firewall: Sólo permite conexiones entre Door1 y Web1 (todos los puertos).
  • Door1: Máquina Windows completamente parcheada y aislada del resto.
  • La clave del usuario Jailmaster es superior a 50 caracteres.
  • El usuario Jailmaster es usado en todos los equipos de la carcel con la misma contraseña.
  • Tenemos una especie de comodín, podemos descargar una herramienta de Internet, que sea publicamente accesible y gratuita, y que ocupe menos de 1MB completa.
El reto tiene varias posibles soluciones, pero si nos ceñimos estrictamente a las herramientas que tenemos y a las restricciones las posibilidades se reducen un poco.

Os dejo unos días para pensarlo un poco, aunque lo mejor es montarse un par de máquinas virtuales y probarlo, aunque sea a trozos, ya sabeis, siempre es mejor probar las cosas que pensarlas "en teoría". Como se suele decir: "En teoría, no hay diferencia entre teoría y práctica. Pero en la práctica, sí que la hay.", así que yo lo he probado todo :P

Dentro de unos días iré poniendo mi solución tal y como la pensé, incluyendo las lineas de razonamiento que seguí y aquellas en las que acabé intentando otra cosa, que es algo de lo que siempre se aprende. También pondré otras soluciones que hay publicadas sobre este mismo reto, aparte de la mia, y comentaré que me parece y que mejoras aporta sobre la mia, o en que puntos pienso que la mia es mejor que las otras.

Creo que no me he dejado nada, si alguien detecta alguna información que falta en el documento original que me lo diga y lo añadiré.

A divertirse!!

Step1: Obtenienido acceso a nivel de red
Step2: Explotando JailMasterLaptop
Step3: Obteniendo credenciales de JailMaster y Explotando Door1

lunes, 22 de junio de 2009

Slowloris: Apache DoS

El pasado miércoles día 17 de Junio vio la luz una nueva herramienta de DoS llamada Slowloris, escrita por RSnake, inspirado por el conocido (aunque aún oculto, por lo que yo sé) Sockstress, que consiste en una herramienta que aprovecha debilidades del protocolo TCP para realizar denegación de servicio contra todo tipo de servicios de red que utilicen dicho protocolo.

Sin embargo, aunque inspirado por Sockstress, Slowloris opera a nivel de aplicación, en lugar de en capa de red, por lo que no es aplicable a todo tipo de servicios, sino que aprovecha una debilidad en los protocolos a nivel de aplicación de los servicios web para provocar una denegación de servicio basada en agotar todos los recursos disponibles sin necesidad de grandes recursos como una BotNet o una conexión de gran ancho de banda.

Para descargar y probar la aplicación únicamente es necesario pinchar sobre este enlace y antes de ejecutarlo tener la precaución de instalar dos librerías que requiere para su ejecución:

# perl -MCPAN -e 'install IO::Socket::INET'
# perl -MCPAN -e 'install IO::Socket::SSL'


Yo lo he probado sobre la BackTrack 4 Beta en VMWare, para lo cual he arrancado el servicos Apache2 que viene con esta misma distribución y lo he lanzado utilizando el siguiente comando:

# perl slowloris.pl -dns 127.0.0.1


Obteniendo el siguiente resultado:



Como se puede observar (pinchar sobre la imagen para verla más grande), la aplicación lanza cerca de 1000 paquetes y luego espera durante 100 segundos para volver a lanzar, lo cual evidentemente no requiere disponer de un gran ancho de banda ni de realizar ningún ataque distribuido. Una vez lanzado el ataque, al intentar conectar por medio de un navegador al servicio web, nos encontramos con que se queda Waiting y nunca llega a conectar, por lo que el ataque DoS ha surtido total efecto, ha consumido todas las conexiones del servidor web y este no puede procesar más conexiones.

Una vez probada su efectividad y a pesar de que en el artículo original del autor comenta como funciona, reinicié mi servidor web, lance mi Wireshark y me dispuse a ver que hacía exactamente este script perl para realizar la denegación de servicio, obteniendo el siguiente resultado:



Como podeis ver, lanza conexiones HTTP aparentemente normales pero las deja a mitad, diciendo que la longitud es de 42 Bytes pero dejando el mensaje sin terminar de ser enviado y sin cerrar la conexión, por lo que el servidor web mantiene las conexiones establecidas hasta un determinado timeout, por lo que estas se acaban agotando.

La detección de este tipo de ataques mediante IDS no es tan trivial como buscar una cadena de texto, ya que este ejemplo de ataque puede ser variado con sencillez conservando sus resultados, por lo que este tipo de firmas no valdrían.

En Emerging Threads han publicado ya una regla para Snort para que detecte este tipo de ataques, observemosla:
#by Kevin Ross
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"ET DOS Possible Slowloris Tool HTTP/Proxy Denial
Of Service Attempt"; flow:to_server,established;
content:"GET /"; depth:5; content:"User-Agent\:
Mozilla/4.0 (compatible\; MSIE 7.0\; Windows NT 5.1\;
Trident/4.0"; offset:30; depth:90; threshold: type
threshold, track by_src, count 100, seconds 30;
classtype:attempted-dos;
reference:url,isc.sans.org/diary.html?storyid=6601;
reference:url,www.packetstormsecurity.com/filedesc/slowloris.pl.txt.html;
sid:2009413; rev:1;)
Como podemos observar, la regla detecta el contenido del UserAgent y unn "GET /", lo cual por lo que he podido observar no se corresponde con el ataque, y aunque lo hiciera está concretando mucho en la aparición de información que no está basada en la vulnerabilidad, sino en el exploit, algo altamente desaconsejado por Snort por motivos obvios (cojo el script, una pizca de sal, otra de pimienta, y ya tengo un nuevo script que hace el mismo ataque y que no es detectado).

Yo tiraría más al hecho de detectar muchas conexiones simultaneas desde la misma IP y bloquearla, aprovechando de que al requerir establecer una conexión la IP de origen es más difícilmente falseable, aunque todavía no me he podido poner a desarrollar una regla. Si lo hago ya la publicaré.

Por último, aparte de la detección, la protección contra este tipo de ataques es complicada, ya que no basta con aumentar el número de conexiones. Parece que la única opción de las opciones que Apache nos proporciona es configurar la directriva TimeOut para que las conexiones caduquen antes y el ataque sea menos efectivo. Otra opción sería utilizar algún otro módulo como mod_limitipconn, pero ya es poner algo externo al código original de Apache y... no sé, piropeadme, llamadme paranóico :)

Bromas aparte, parece una buena opción también para limitar el número de conexiones simultaneas para una IP, dejando que una sola IP sólo consuma una parte de nuestras conexiones totales, para de esta manera evitar que una sola IP nos pueda provocar una denegación de servicio.

jueves, 18 de junio de 2009

Bastionado Perezoso de Windows Vista (I)

Si sóis de esa especie que cada vez que instaláis vuestro sistema operativo Microsoft Windows Vista os entra una pereza descontrolada que imposibilita que dediquéis tiempo a bastionarlo, esta entrada está creada a medida para nosotros. Nuestro principal argumento es que no encontramos un hueco para bastionar nuestros equipos o los equipos que instalamos a familiares, amigos, conocidos de conocidos, etc. En muchas ocasiones esto es verdad, pero en otras podríamos decir que estamos siendo un poquito perezosos :D.

El otro día mientras me maldecía por tener mi bichito (así llamo a mis pequeñines) sin haberle dedicado un poquito de tiempo, me planté y decidí que esto no podía durar más, aprovechando ese momento de motivación inicié una dura búsqueda en el universo de Google a la caza del bastionado para perezosos (no el bastionado ideal ... el casi ideal pero para perezosos).

Tras un tiempo de búsqueda, me topé con "Security Compliance Management Toolkit Series" en la página de Microsoft, al leer de qué iba, ver la documentación, empezaron caerme las lágrimas a chorro de alegría cuando veía un "siguiente > siguiente" que podría hacerme sentir mejor ante mi dolor interno de dedicarle poco tiempo a mi pequeñín.


Una vez encontrado el diamante era hora de pulirlo, para lo que deberemos ir a la página del toolkit y descargar el .zip para nuestro Windows Vista. Una vez descargado miramos la documentación (parte muy importante ;)) y observamos que explica que existen dos tipos de bastionado, el bastionado "Enterprise Client" (EC) y el bastionado "Specialized Security-- Limited funcionality" (SSLF). Como os podéis imaginar el bastionado SSLF es mucho más restrictivo sobre nuestro sistema respecto al EC, por lo que en este instante cada uno debe decidir sobre qué bastionado se ajusta más a sus necesidades. En esta primera entrada hablaremos sobre el tipo EC.

Con el fichero .zip descargado encontramos un instalador de nombre GPOAccelerator.msi, que nos ayudará a tener el bastionado en varios "siguiente > siguiente", como se muestra a continuación. Deberemos ejecutar GPOAccelerator.exe que está en la carpeta de instalación.



Una vez disponemos de nuestro sistema un poco más bastionado, podemos hacer unos pequeños retoques que se ajuste más a nuestro gusto. El primer retoque que vamos a hacer es permitirnos poder hacer escalada de privilegios con la opción "Ejecutar como Administrador" (que es un "sudo aplicación" de sistemas Linux), ya que al aplicar el tipo de bastionado EC queda restringido. Con esto estoy asumiendo que todos usamos nuestro Windows Vista con un usuario que no tiene permisos de Administrador, ¿verdad?. Para permitir la escalada de privilegios nos vamos a Panel de Control > Herramientas Administrativas > Directiva de Seguridad Local. Después nos movemos por el árbol y nos dirigimos hasta llegar a Opciones de Seguridad, donde dejaremos la opción que os muestro a continuación (Control de cuentas de usuarios: comportamiento del indicador de elevación para los usuarios estándar) así:



Otro pequeño aspecto que me gusta es activar algunas de las directivas de auditoria, para tener siempre información almancenada de qué está pasando. La configuración que suelo poner para un equipo es (recordar que esta entrada está orientada a nuestro equipo personal, quedando muy de lejos de cómo realizar un bastionado en un servidor, equipo de cliente de una organización etc.):




En futuras entradas seguiremos hablando del bastionado SSLF, la diferencias con el EC, resumen de los cambios que aplican ambos tipos sobre nuestro sistema y comentaremos una configuración más afinada del firewall de Windows Vista, sus ámbitos, nuevas reglas etc. Como véis dista bastante de un bastionado elaborado y controlado, pero es un pasito más y rápido; principal objetivo de la entrada.

domingo, 14 de junio de 2009

TargetSearch v0.2

Hace unos días publiqué un post con una herramienta llamada TargetSearch que desarrollé para facilitarme la tarea de buscar en Google nombres de objetivos para test de intrusión. Tras publicarla, Pedro Laguna me notificó un problema al buscar dominios que contengan webs muy grandes, ya que Google te devuelve un número de resultados limitado y, si una de las webs encontradas es muy grande, es posible que sus resultados copen la gran mayoría de resultados, por lo que habrá otras webs que no serán encontradas.

Para solucionar esto, cambié ligeramente la manera en la que el script realizaba las búsquedas, de tal manera que en cada búsqueda toma el primer resultado encontrado, lo guarda como un resultado válido y añade la cadena "-site:resultado.dominio.es" a la cadena de búsqueda, y vuelve a repetirla, con lo que todos los resultados de esta web que ya hemos encontrado habrán desaparecido.

Se ha optado por usar site ya que las pruebas realizadas usando "-www" o "-mail" corrían el riesgo de eliminar cualquier resultado que contuviera la cadena "www" o "mail" en cualquier parte de la web, y no únicamente en la URL.

Aún así, se observan aún algunas anomalías en el funcionamiento de esta versión 0.2, como por ejemplo algunos nombres de host que desde la web se pueden encontrar pero que no son devueltos usando el API de Google. Este problema parece más un problema de Google que del script, pero en cualquier caso le pegaré una pensada a ver si se pudiera solucionar.

CORRECCIÓN: Según he mirado a posteriori, parece ser que estos nombres de hosts que no aparecen en el Script pero sí en la web de Google no existen, por lo que es altamente posible que sea el Script el que ofrece mejores resultados al atacar directamente al API de Google (La web accederá a una caché local?).

El segundo problema, en este caso teórico porque no he encontrado ningún sitio donde probarlo, es el problema en dominios que contengan varios niveles de subdominios, ya que el excluir "-site:resultado.dominio.es" eso va a excluir de la siguiente búsqueda también todos sus subdominios, es decir, "mail.resultado.dominio.es" también sería excluido, y por desgracia Google no proporciona ninguna palabra clave para hacer un "site exclusivo". Es algo sobre lo que también intentaré mejorar en futuras versiones.

Mientras tanto, acabo de colgar en tools.pentester.es la nueva versión, así que os animo a que la probeis y me mandeis cualquier otro problema que podais encontrar por correo electrónico (mirad en mi ficha personal, ahí se ve más o menos mi correo).

DESCARGA

Muchas gracias a todos por vuestro feedback :)

miércoles, 10 de junio de 2009

TargetSearch v0.1

Nota: Ya existe una nueva versión que corrige los problemas encontrados en esta versión.

Hace alguna semanas tomando un café con un colega profesional de la seguridad le comentaba que me había hecho un pequeño Script en Perl llamado TargetSearch que pretendía automatizar una tarea que realizaba yo anteriormente para descubrir objetivos sobre los que realizar un test de intrusión. Una tontería, según le comenté, pero su contestación diciéndome que a veces esas pequeñas tonterías son las más útiles me ha hecho decidirme a publicarlo.

Aparte de muchos otros métodos más "a lo bestia" como el escaneo del rango, la resolución inversa de cada IP del rango o el intento de transferencias de zona, búsqueda de nombres por fuerza bruta, obtener algunos mediante correos y luego buscar nombres relacionados con Google Sets (algo que ya comenté en otro momento), y un largo etcetera, una de las técnicas que suelo emplear es buscar en Google "sites:dominioabuscar.com", lo cual nos saca todas las webs que tiene cacheadas Google, de todos los nombres de ese dominio e inferiores que contengan alguna web, lo cual ya resulta muy útil para localizar objetivos sobre los que hace una auditoría de las webs que nos pueda servir como ayuda durante la realización del test de intrusión, y todo esto de forma totalmente invisible para los sistemas objetivo. Target Search hace esto, pero de forma automática y mostrándonos una única aparición de cada nombre de dominio.

Esto me ha resultado especialmente útil, sobretodo en empresas grandes y con un control descentralizado de los sistemas de información, porque siempre encuentras el sistema del año catapum sin actualizar, que entre unos y otros se ha quedado ahí, y que nadie encuentra ni sabe que está. Nadie... salvo Google, que lo sabe todo :)

El Script se puede desgargar de la nueva sub-web que acabamos de crear desde pentester.es: tools.pentester.es, una web en la que iremos poniendo estas pequeñas herramientillas (porque la verdad es que por el momento no tenemos tiempo de programarnos un gran suite, aunque nos gustaría) que nos vamos haciendo para facilitar nuestro trabajo diario. De momento sólo está la herramienta que os presento, pero poco a poco esperamos ir poniendo más, que por supuesto iremos publicando también en este blog.

Y como se suele decir, como a pentestear se aprende pentesteando... vamos con un ejemplo de lo que encuentra este script por ejemplo en mi Alma Máter, la Universidad de Valencia:

$ ./TargetSearch.pl uv.es
##############################
# TargetSearch v0.1 - 10/06/2009 #
# Buscador de nombres de dominio #
# Jose Selvi - http://www.pentester.es #
##############################

Buscando nombres de hosts victima.........

Objetivos encontrados:
eees.uv.es(147.156.222.65)
uvpress.uv.es(147.156.164.76)
www.uv.es(147.156.1.4)
alufis35.uv.es(147.156.98.243)
extensio.uv.es(147.156.1.29)
debian.uv.es(147.156.2.72)
auladeedicion.uv.es(147.156.5.7)
eee.uv.es(147.156.26.170)
edumic.uv.es(147.156.17.54)
ific.uv.es(147.156.163.23)
industrial.uv.es(147.156.26.134)
grev.uv.es(147.156.13.180)
parnaseo.uv.es(147.156.1.51)
mcuser.uv.es(147.156.28.38)

IPs encontradas:
Buscando nombres extra para 147.156.222.65
Buscando nombres extra para 147.156.164.76
Buscando nombres extra para 147.156.1.4
Buscando nombres extra para 147.156.98.243
Buscando nombres extra para 147.156.1.29
Buscando nombres extra para 147.156.2.72
Buscando nombres extra para 147.156.5.7
Buscando nombres extra para 147.156.26.170
Buscando nombres extra para 147.156.17.54
Buscando nombres extra para 147.156.163.23
Buscando nombres extra para 147.156.26.134
Buscando nombres extra para 147.156.13.180
Buscando nombres extra para 147.156.1.51
Buscando nombres extra para 147.156.28.38

lunes, 1 de junio de 2009

NCat, el sucesor de NetCat

Hace algún tiempo leí en SecurityByDefault una entrada que se titulaba "La suite de herramientas de Fyodor". Como ya sabreis Fyodor es el desarrollador de la conocidísima herramienta NMAP, imprescindible en el "arsenal" de cualquiera que se dedique a la seguridad.

El caso es que Fyodor, como parte del Google Summer of Code, ha desarrollado algunas herramientas muy interesantes que "resucitan" herramientas ampliamente utilizadas pero no actualizadas desde hace mucho tiempo. Este es el caso de NETCAT, la llamada "navaja suiza de la seguridad en redes", cuya última versión data de Enero de 2004 y que los que la utilizamos frecuentemente nos encontramos con algunos problemas como el cifrado de las comunicaciones, el tener que crear un pipe para poder encadenar dos netcats, etc. Por ello, Fyodor ha desarrollado la herramienta NCAT, cuyo desarrollo tiene los siguientes objetivos:
  1. Mantener toda la funcionalidad de la última versión de netcat.
  2. Aprender de las contribuciones de diferentes versiones de netcat que han ido surgiendo (como por ejemplo cryptcat para cifrado).
  3. Realizar redirecciones de puertos sin necesidad de utilizar pipes intermedios.
  4. Poner a la escucha dos puertos y hacer que los que se conecten a ellos se conecten a su vez entre si.
  5. Cifrado SSL de una forma cómoda.
  6. Multihilo.
  7. Filtrado tipo TCP Wrappers.
  8. Soporte para cliente y servidor proxy HTTP y SOCKS.
Como se puede ver, NCAT va a mejorar algunos de los aspectos que siempre he echado de menos de NetCat y los va a hacer mucho más sencillos.

Veamos algunos ejemplos de las acciones en las que más útil nos va a resultar las nuevas capacidades de la herramienta NCAT:
  • Redirección de puertos NetCat: NetCat no implementa una manera cómoda de hacer una redirección de puertos, algo imprescindible muchas veces cuando estamos realizando un test de intrusión y hemos conseguido acceso a una máquina y desde ella queremos conseguir acceso a otras máquinas que en principio tenemos filtradas por medio de un Firewall, ACLs de un router, NULL routing o cualquier otro tipo de medida. Para hacerlo nos vemos obligado a usar la tubería típica de shell entre dos NetCats, pero a su vez utilizar un pipe adicional para que la respuesta de esa conexión llegue al primer NetCat. Veamos un ejemplo, imaginaros que tenemos acceso a una web abandonada y que desde ahí hemos comprodo que una máquina de la misma LAN a la que no tenemo acceso tiene una vulnerabilidad en los servicios de recursos compartidos que queremos explotar (los cochetes para los signos de redirección los pongo porque sino, no sé por qué, Blogger me interpreta algo raro y no he conseguido solucionarlo, si alguien tiene alguna sugerencia... :P):
# mknod tuberia p
# nc -l -p 80 0[<]tuberia | nc 192.168.1.100 445 1[>]tuberia
  • Redirección de puertos NCat: Con NCat la consa se simplifica, ya no es necesario crear una tubería adicional para realizar la redirección ni pararnos a pensar como tenemos que redirigir las entradas y las salidas de los dos comandos NetCat. Con NCat, dejariamos expuesto el puerto 445 de la otra máquina a través del puerto 80 al que sí que tenemos acceso de esta manera:
# ncat -l 80 --sh-exec "ncat 192.168.1.100 445"
  • Cifrado de comunicaciones NetCat: NetCat no incorpora ningún tipo de mecanismo de cifrado, por lo que es necesario tirar mano de Cryptcat para estas tareas, una modificación de NetCat que incorpora cifrado. Esto es en ocasiones necesario, bien sea en proyectos de análisis forense y gestión de incidentes para sacar de un equipo comprometido información sin que esta vaya por la red o bien sea porque estamos realizando un test de intrusión y queremos evitar que el IDS situado en el firewall detecte el exploit que lancemos contra el puerto 445 al ser lanzar hacia el puerto 80 que nos redirigirá. Veamos un ejemplo de como hariamos lo mismo de antes pero cifrando el tráfico que cruzará la red. Como ahora no tendremos el puerto a la excucha tal cual, tendremos que hacer 2 redirecciones, una en nuestro equipo y otra en el servidor, tunelizando el tráfico con cryptcat:
servidor# mknod tuberia p
servidor# cryptcat -k p4t4t4 -l -p 80 0[<]tuberia | nc 192.168.1.100 445 1[>]tuberia
pentester# mknod tuberia p
pentester# nc -l -p 445 0[<]tuberia | cryptcat 192.168.1.100 80 1[>]tuberia


  • Cifrado de comunicaciones NCat: NCat aporta la ventaja que se encuentra todo integrado en la misma herramienta, por lo que no hay que ir jugando con NetCats y Cryptcats, pero por contra el mecanismo de cifrado SSL se hace un poco más farragoso, ya que hay que generar el par de claves, lo cual puede ser incluso mejor para determinadas aplicaciones, pero cuando se refiere a la realización de un test de intrusión el uso de una shared key es claramente más cómodo. Espero que en las próximas versiones de NCat veamos la opción para realizar cifrado por medio de shared key (si es que no está ya y no he visto la opción, pero la he buscado bastante).
  • Multihilo y Persistencia en NetCat: NetCat no proporciona ningún tipo de capacidad multihilo ni de persistencia, salvo en su versión Windows en la que se añadió una opción "-L" mediante la que se puede obtener persistencia (que no multihilo). En linux David Pérez (Consultor Independiente y GIAC GSE) realizó otra modificación recientemente a la que llamo nc2 que también implementaba esta opción "-L". Sin embargo, seguía sin existir nada que dotara a NetCat de capacidades multihilo, algo molesto ya no tanto en proyectos de test de intrusión como en proyectos de análisis de malware, donde queremos usar NetCat para levantar servicios ficticios para que el bicho a analizar interactue con él y podamos ver que tipo de información intercambia, ya que es posible que este lance varias conexiones consecutivas, con lo que perderemos información. Veamos un ejemplo de como utilizariamos las capacidades de persistencia de las modificaciones de NetCat (clásicamente se hacía mediante un shellscript que lo iba lanzando infinitamente cada vez que se cerraba, pero ya que ha habido gente que ha trabajado para ahorrarnos este trabajo prefiero mostraros estas versiones, que son mucho más sencillas):
# nc2 -L -p 80
# nc 192.168.1.100 80
# nc 192.168.1.100 80
# nc 192.168.1.100 80
# nc 192.168.1.100 80
  • Multihilo y Persistencia en NCat: NCat es sencillamente multihilo y persistente de por si, es decir, cualquier NCat a la escucha que lances puede ser accedido desde tantos NCats clientes (o NetCats, o telnets, por supuesto) como quieras y conectar y desconectar infinitamente sin que este muera o haya que hacer ninguna acción adicional.
# ncat -l 80
# nc 192.168.1.100 80
# nc 192.168.1.100 80
# nc 192.168.1.100 80
# nc 192.168.1.100 80

Creo que estas son las opción que, al menos a mi, me han parecido más interesante de la nueva herramienta NCat, que la pone en clara ventaja con respecto a las otras herramienta, sobretodo porque viene todo en la misma herramienta.

Yo personalmente estoy empezando a utilizar NCat para todo, salvo para el cifrado de comunicaciones, en las que hago interactuar NCat con CryptCat, ya que me resulta mucho más cómodo en términos generales usar un shared key, pero supongo que es cuestión de tiempo hasta que Fyodor saque la opción.

Quizá le manda un correo con la sugerencia :)