Mensajes

MMMMMMM ESE EXPLOIT NO FUNCIONA...
Y un consejo.... Si cogeis exploits de webs, al menos leer la explicacion... o intentar entender el código y no compileis y lanceis por que quizas algún día os lleveis un susto... O al menos corrobar con muchas webs para ver si el exploit es fiable o algo.....

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:

>gcc -o salidaSSH exploitSSH.c
>./salidaSSH
MIKU! MIKU! MIKU!

   

• HATSUNEMIKU
     
• OpenSSH <= 5.3p1 remote root 0day exploit
     
• By: n3xus
     
• Greetz to hackforums.net
     
• Keep this 0day priv8!
     
• usage: ./salidaSSH <target> <port>
  
  > ./salidaSSH x.x.x.x 22
  MIKU! MIKU! MIKU!
  [-] Exploit failed.
  Violación de segmento

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

Código [Seleccionar] Expandir


courier-imap <= 3.0.2-r1 Remote Format String Vulnerability exploit by ktha at hush dot com
[*] Launching attack against 85.214.226.180:143
[+] Got current ebp(5500): 0xbfbfaa10
[+] Got possible saved ebp(3000): 0xbfbfd8ec
[+] Got possible write on the stack pointer(3012): 0xbfbfd91c
[+] Verifying...failed
[+] Got possible saved ebp(3001): 0xbfbfd8f0
[+] Got possible write on the stack pointer(3013): 0xbfbfd920
[+] Verifying...failed
[+] Got possible saved ebp(3002): 0xbfbfd8f4
[+] Got possible write on the stack pointer(3014): 0xbfbfd924
[+] Verifying...failed
[+] Got possible saved ebp(3003): 0xbfbfd8f4
[+] Got possible write on the stack pointer(3015): 0xbfbfd928
[+] Verifying...failed
......
.....


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.

Esto quiere decir que para hacer uso de ella hace falta estar logueado ¿Verdad?

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...  

parallels plesk panel 10.2.0 CVE-2011-4734

http://cert.inteco.es/vulnDetail/Actualidad_fr/Actualite_Vulnerabilites/detalle_vulnerabilidad_fr/CVE-2011-4734

http://xx.xxx.xxx.xxx:8443/login_up.php3/

alguien sabe como explotar esa Vulnerabilidad?????

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.

http://thehackerway.com/2012/03/28/wireless-hacking-descubriendo-aps-con-ssid-ocultos-y-evadiendo-mac-filters-parte-iv/

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.