Tienes razón, es importante saber para que sirven y que vulnerabilidad explotan, (por ese motivo he pedido referencias sobre el mismo) sin embargo compilar y ejecutar un exploit para comprobar su funcionamiento no deberia dar "ningun susto" a menos que se sea lo suficientemente torpe como para ejecutarlo directamente desde la máquina y no en un entorno de pruebas como por ejemplo, una maquina virtual, creo que eso es básico cuando se realiza cualquier procedimiento de pentesting.

Hola h1t.

 
Ya he probado tu exploit, resultado:



El exploit falla, sin embargo se trata de un 0day para versiones recientes de SSH, en concreto en que foro lo haz visto? y cual es la vulnerabilidad que explota?

Gracias m0rf
Era justo el mismo exploit que estaba revisando... 
Pero existe un problema... el servidor tiene una versión del kernel superior a la 2.6.7 y tiene activado el ASLR (Stack Randomization), por lo tanto no sabemos cual es el valor que asumirá la stack en cada ejecución al ser está dinámica, en consecuencia cuando se ejecuta se obtiene algo como lo siguiente


Se ha partido la posición 0xbfbfaa10 pero claro, esa posición es para FreeBSD, en este caso concreto se desconoce cual será la posición en la que se encuentra la stack para el proceso del servicio, (por el tema de ASLR, ver: http://en.wikipedia.org/wiki/Address_space_layout_randomization)

Supongo que si se logra evadir o determinar de alguna forma la posición de la stack para el servicio, será suficiente para que el exploit funcione... a ver si hay alguien que se le ocurra como hacerlo, ya que si se consigue, se logrará acceder al servidor.

Si, solamente con un usuario logueado y en algunas páginas del panel de control, como por ejemplo en la sección de file manager.

En realidad me ha faltado ser más especifico (y más claro) en mi mensaje   os comento.

Las vulnerabilidades de SQLi sobre Plesk que se han comentado afectan al Control Panel de Plesk, no afectan al mecanismo de autenticación o la parte pública del gestor, de todos modos he ejecutado las pruebas de SQLi estandar contra el formulario de autenticación (sin exito), en concreto, algunas han sido:

usuario: ' OR 1=1--
pass: '

usuario: admin
pass: pass+union+select+0+from+users

usuario: admin
pass: pass' union select '1','2','3

usuario: 1' having 1=1 --
pass: pass

De todos modos, las he realizado manualmente, en cuanto llegue a casa probaré con Sqlninja por si me arroja algo más...
Tambien haré algunas pruebas con Burp, webscarab y Mantra para intentar modificar los headers de las peticiones HTTP (a ver si suena la flauta y encuentro algo)... Sin embargo, como dije anteriormente, es posible que existan más probabilidades intentando explotar el servicio POPD o IMAPD, necesito indagar más sobre el servidor.

Ah, se me olvidaba... por si alguno habia pensado en utilizar Shodan (y para los que no sepais que es: http://www.shodanhq.com/)
Este servidor no se encuentra en los "radares" de Shodan, cuando se busca por

net:xx.xx.xx.xx
o
hostname:dns-name-servidor

Shodan dice:
Note: Your search for - net:x.x.x.x - did not match any hosts.
Note: Your search for - hostname:dns-name-servidor - did not match any hosts.

Bueno... aun quedan bastantes cosillas por probar a ver si se consigue algo...  

Probadas, Al parecer esta parcheado y no es vulnerable. 
No es tan sencillo acceder a este servidor, sin embargo, creo que hay más "luz" en los servicios popd e imapd dado que se trata de versiones muy antiguas... Tambien realizaré algunas pruebas contra el servicio de base de datos que esta instalado (mysql por el puerto 3306).

En las redes cableadas puedes ver los paquetes que se encuentran en el mismo segmento de red si la interfaz de red se encuentra en modo PROMISCUO. En el caso de las redes wifi ocurre lo mismo, pero el nombre que se asigna es modo MONITOR, en esencia son terminos distintos pero significan lo mismo: La tarjeta de red recibirá paquetes cuyo origen/destino son distintos a la interfaz local.
Debes poner tu interfaz wifi en modo monitor y utilizar dicha interfaz con tu wireshark.
puedes usar aircrack-ng para hacerlo.

No, solamente ataques por diccionario.
WPA/WPA2 con PSK son mecanismos de cifrado fuertes y a la fecha no se han encontrado vulnerabilidades lo suficientemente serias como para corromper su integridad.

Dada la naturaleza de las redes inalambricas, este tipo de ataques son fácil de llevar a cabo y difícil de detener, puedes intentar estableciendo filtros por MAC y ocultando el SSID de tu red, pero son mecanismos de seguridad muy fáciles de evadir.
Una forma es modificando directamente el firmware de la tarjeta inalambrica, hace algunos meses me enfrente a lo mismo que tu, como detener un ataque de deauth. y para hacerlo he tenido que modificar el driver mac80211/ath9k para Linux y me ha funcionado siguiendo algunas pautas que he leído por internet, pero vamos que no es una tarea trivial y necesitas ganar algunos conocimientos previos antes de conseguirlo, si es en windows, creo que no puedes hacerlo, dado que no creo que puedas modificar el driver de la tarjeta inalambrica.