Posted by admin on 4 September, 2009 – 5:47 pm
A feature of Apache Web Server allows anyone to establish an SSH connection through the boundaries of any enterprise network. This is done completly stealthy and undetectably, fooling firewalls, proxyes, and any other enterprise network filtering wildlife. As a matter of fact, virtually any protocol might be tunnelized this way -except, of course, for IPoAC 
. But I will take the example of SSH since it opens a very interesting, wide-spectrum, vector to further analisys.
Quite esoteric, ah? This is how all this black magic work
It is simple, most proxyes will allow outgoing HTTP trafic to any website. Proxys want the users to surf the web. That is their purpose to exist. And that is what we will expliot. But most of the proxyes will only let their users through the paths they know safe (or whatever filtering their administrators may have set). In the best scenario, the proxy will not allow one particular HTTP method called CONNECT. This method is the one used for SSL/TLS protocol. It establishes a tunneled connection between the client and a remote server, through the proxy server. Since it is used by SSL/TLS, some proxys will let the CONNECT method free to certain sites, and most probably only on port 443. This, plus some L7 filtering and maybe some DPI, describes the most secure environment one might ever find inside any enterprise network. On the other hand we have lazy-administrated proxys that will allow you do whatever you want. If this last is your scenario, don’t waste your time reading any further, go use it for some SSH simple tunneling Read more... (1786 words, 4 images, estimated 7:09 mins reading time)
This is a preview of
Hell’s Library, Bypassing Transparent Proxy Using Apache
.
Read the full post (1786 words, 4 images, estimated 7:09 mins reading time)
Posted by admin on 11 June, 2009 – 4:48 pm
Imagino que todos conocen este bonito software que desarrolla un ruso que se hace llamar Dimoniusis, que encima tiene su web en ruso (que es comprensible, dado que es ruso el muchacho).
También muchos de ustedes deben conocer otros programas similares como el JDownloader o el Tucan. O a lo mejor incluso piensen que utilizar sitios de descarga directa es muy "leecher" y que sería más cómodo y noble usar eDonkey o BitTorrent.
Pero los cierto es que este programa es bien simple. Para ejecutar en GNU/Linux lo único que se necesita es Wine (el traductor del API de Microsoft Windows) y un sistema de ventanas como Xorg (en esta guía será XVFB, ya vamos a ver por qué).
El objetivo de esta guía es lograr un sistema base basado en Ubuntu Server 9.04 para ejecutar el USDownloader y administrarlo mediante su interfaz web.
Nota: Si bien esta guía se basa en la instalación de un sistema GNU/Linux como es Ubuntu Server, esto mismo podría funcionar para otros sistemas como BSD, OSX, y Solaris. Solo que la instalación de los paquetes, las configuraciones, y el cómo se ejecutan podría requerir que se haga de otra manera. No voy a responder comentarios pidiendo ayuda fuera de la plataforma explicada ya que no lo he probado. Read more... (2269 words, 0 images, estimated 9:05 mins reading time)
Posted by admin on 1 August, 2008 – 4:55 pm
Este es un tutorial que escribí para el foro de DonkeyFire, que es una extensión de Firefox para monitorear MLDonkey de la barra de estado, creado por mi amigo Buanzo.
Si no saben qué es MLDonkey, pase por ACA PRIMERO (auqnue pueden adaptar esta técnica a cualqueir otro tipo de sistema web).
Esto en realidad surge como solución a un problema un poco más complejo que se me presnetó. Yo tengo un webserver corriendo con Apache, en mi casa, que hostea algunos sitios personales. En mi casa, en otro servidor, tengo corriendo MLDonkey. Yo necesitaba acceder a la interfaz web de MLDonkey desde fuera de mi casa. Para eso no tenía más que aplicar la correspondiente regla de port forwarding de mi firewall para que el puerto 4001 fuese accesible desde Internet. Hasta acá todo bien. El problema surje cuando quiero aplicar un poco de seguridad a esto, porque usa HTTP plano que pued epermitir que cualqueira acceda a la interfaz del MLDonkey y pueda manipular msia rchivos y configuraciones -sin mencionar posibles vulnerabilidades que puedan aprovecharse con ese acceso, aunque no conozco ninguna aún-.
Bien, la mejor forma de implementar un poco de sguridad a todo esto es usar HTTP con TLS/SSL, o sea HTTPS. para esto, utilizé mi servidor Apache. Él recibe las consultas por HTTPS y las redirecciona como HTTP normal a la interfaz Web de MLDonkey en el otro servidor. Luego devuelve las respuestas al cliente por HTTPS. Todo de manera transparente. Read more... (1167 words, 0 images, estimated 4:40 mins reading time)
Posted by admin on 28 July, 2008 – 12:18 am
Primero lo primero: Esto no es mío. Es solo una traduccción de este post en el blog de mi buen amigo Buanzo -a quien le robo noticias seguido, solo que las publico más tarde, en castellano, y con mayor porcenataje de errores ortográficos XD-.
Sacado de Barrapunto:
La idea básica del ataque, que puede considerarse a estas alturas de dominio público, es la combinación de DNS Forgery y DNS RRset poisoning. Se trata de conseguir, mediante la repetición de peticiones, que un servidor DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3, y que ésta incluya información sobre la IP de otros dominios de nivel 3 del mismo dominio de nivel 2. En otras palabras, si se consigue que el servidor acepte como válido un paquete que le dice que xhstrn.google.com tiene como IP 1.2.3.4, aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc. Fascinante.
La explicación completa:
Falsificación efectiva de DNS en el 2008: Un descubrimiento de Kaminsky, en Matasano Chargen, escrito por ecopeland.
[0] El gato se escapó de la bolsa (nota de traducción: no me convence esta frase en castellano). Sí, Halvar Flake se dio cuenta de la falla que Dan Kaminsky va a anunciar en la Black Hat. Read more... (2247 words, 0 images, estimated 8:59 mins reading time)
Posted by admin on 11 July, 2008 – 2:19 pm
Sí, así como lo leen. Leo en Slashdot y en New Tee Vee que los muchachos de The Pirate Bay se lanzan en otro de sus ambiciosos proyectos -que esperemos que llegue a un buen fin-. Esta vez, preocupados por las recientes medidas legislativas que se están empezando a adoptar en Europa para la “protección de la propiedad intelectual” -propiedad intelectual, ¡ja! en algun otro post indagaré mejor sobre este concepto que creo que es absurdo-, pretenden encontrarle una salida. Y parece ser que la salida se llama IPETEE (“Transparent end-to-end encryption for the Internets”), algo así como “Encriptación transparente punto a punto para Internet”.
Resulta que estas medidas descansan sobre la posibilidad de analizar el contenido del tráfico de Internet, y así poder impedir intercambio “ilegal” de contenidos protegidos por Copyright. Bien, entonces IPETEE pretende dificultar esta labor. En principio será un software que trabajará a nivel del sistema operativo para encriptar toda comunicación de red, y así evitar la necesidad de soporte por parte de las aplicaciones -por eso mismo su transparencia-. Lo que no hace esto es ofrecer anonimidad, no confundir con proyectos como tor e i2p, que ofrecen anonimidad a traves de diversos modelos como el enrutamiento en cebolla. Read more... (272 words, 0 images, estimated 1:05 mins reading time)
