Para los que no sepan qué es un método HTTP, pueden encontrar información sobre los mismos en el RFC2616:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Recomiendo que antes de leer este paper se tengan unas nociones básicas de estos métodos. En este artículo no se tratarán las ya conocidas de sobra vulnerabilidades por PUT y DELETE y tampoco otras que a día de hoy, debido a la evolución de los exploradores web, apenas tienen validez, como Cross Site Tracing por medio del método TRACE.

HTTP CONNECT:

Algunos servidores web, ya sean Apache, IIS, Tomcat... soportan el método CONNECT. Esto puede suponer una puerta de entrada para spammers o para atacantes que quieran evaluar otro servidor suplantando la identidad de terceras personas.

Tomemos como ejemplo la página www.victima.com. Para saber si tiene habilitado el método CONNECT, tendremos que hacer uso del método OPTIONS así que manos a la obra. Procedemos a conectarnos por telnet o netcat al servidor en el puerto 80 y mandamos la petición. Es importante que especifiquéis el nombre del servidor en el campo "Host:" ya que muchas veces, debido a mecanismos de proxy inversos del propio servidor con otros servidores, no coinciden, lo que puede dar lugar a resultados negativos. Para dar con posibles servidores que hagan de proxy inverso entre tú y el servidor original, se puede proceder a realizar una transferencia de zona DNS. En esta n3t-datagrams tenéis información sobre como realizar consultas avanzadas a servidores DNS (http://n3t-datagrams.net/guias/dns.html):



Podemos comprobar en el campo Allow, que el método CONNECT está permitido. Es posible que el método OPTIONS no esté habilitado, por lo que se procedería a utilizar de forma directa el método CONNECT. Una vez estamos seguros de que el servidor soporta el método y además lo tiene permitido, procedemos a realizar el ataque. Para este ejemplo, nos haremos pasar por unos Spammers e intentaremos conectarnos al puerto 25 (SMTP) de un servidor de correo.



Y a partir de aquí, si todos conocen el protocolo SMTP, saben lo que pueden hacer. Un spammer podría aprovechar este error de seguridad para que su verdadera IP no apareciese en las listas negras de las empresas de correo electrónico como hotmail, gmail, yahoo...

HTTP POST:

El método POST, puede ser también utilizado para acceder a equipos o mandar correos a lo Spam-style. No hay mucha información sobre esta vulnerabilidad así que espero que si tú, "querido lector", no has leido nunca nada acerca de esta vulnerabilidad: enjoy it. Si por el contrario sí, repasar nunca le hace mal a nadie. La técnica es similar a la que hemos visto anteriormente con el método CONNECT. El módulo mod-proxy para Apache en su versión 1.3.27 lleva por defecto una configuración que permite explotar este falla de seguridad.



Y a partir de aquí, lo mismo que para el CONNECT (ehlo, auth login, etc...).

Que tal.

Bueno, en el metodo CONNECT se ha dejado lo mas importante para mi relacionado al hacking.
Para mi si es un ataque el siguiente, pero que esta basado en la mala configuracion de algunos servidores proxies, como SQUID.
En ciertas ocasiones SQUID es mal configurado, permitiendo hacer el CONNECT ( silo soporta ) y, en vez de irnos a cualquier servidor externo a esa Red, pues se podria conectar con PCs internos a esa Red para la cual SQUID ( u otro mal configurado ) esta actuando como servidor proxy.

Bueno, eso era todo amigos.

Saludos.

No, estas diciendo que el tener un servicio que tu pusiste ahi, (en este caso un servidor Proxy) es una vulnerabilidad. Y eso es falso. Una vulnerabilidad es una falla que existe en una aplicacion que permite hacer algo no contemplado por el desarrollador, y que puede vulnerar la confidencialidad, integridad o disponibilidad de la informacion en este sistema.

En este caso, supondria que el servidor SQUID esta en una DMZ (porque si no si seria peligroso), y si no lo estuviera la vulnerabilidad estaria en que no este en una DMZ (y con un firewall configurado a que no sea un relay de spam como tu ejemplo), y no en la existencia del proxy..

Y el tener un servidor SSH no protegido contra bruteforce no es una vulnerabilidad.. Tienes que ver las diferencias entre vulnerabilidades, amenazas, riesgos, etc..