Vulnerability analysis part 2: Host discovery using nmap

I know IP address on my attacking machine is 192.168.238.137, and I know the subnet mask is 255.255.255.0. In CIDR notation, this means the subnet is /24. This tells me which part of my IP address is the network prefix (192.168.238), and which part is the host number (.137).

We can list out all the IP addresses in this range by using a list scan (-sP). This scan sends no packets to listed IP addresses, but it will attempt a reverse DNS resolution on each host.

# nmap -sL 192.168.238.0/24

Since there are 256 addresses outputted by this command, I will not paste them here.

Let’s explore other machines with ping sweep. This scan does not scan any ports, but only reports on which hosts are up by pinging them. Older versions of nmap us -sP. Newer versions will use -sn

# nmap -sn 192.168.238.0/24
Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-06 18:49 EDT
Nmap scan report for 192.168.238.1
Host is up (0.00039s latency).
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 192.168.238.2
Host is up (0.00012s latency).
MAC Address: 00:50:56:EA:8D:7F (VMware)
Nmap scan report for 192.168.238.137
Host is up (-0.10s latency).
MAC Address: 00:0C:29:54:6E:48 (VMware)
Nmap scan report for 192.168.238.254
Host is up (0.00011s latency).
MAC Address: 00:50:56:EF:B0:9E (VMware)
Nmap scan report for 192.168.238.136
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.28 seconds

I know the 192.168.238.2 addresses is my default gateway, and 192.168.238.136 is my local machine. What are those other three addresses? One of them is the Metasploitable machine. I’m not sure what the other two are.

A little digging, and I find out what these addresses are.

192.168.238.1: Host machines
192.168.238.2: Default gateway
192.168.238.254: VMware DHCP server
192.168.238.136: Kali machine
192.168.238.137 must be our Metasploitable VM.

The ping scan will ping the host, send a TCP SYN, a TCP ACK, and request an ICMP timestamp. If any of these requests receive a response, we know the host is alive. If there was a firewall or other device blocking these requests, the ping scan might show that no host is up at an IP address, and you will need to use a different method of host discovery. The -Pn scan will attempt a port scan on every IP address in the given range. We’ll speed it up with the -F flag to only scan 100 ports.

# nmap -F -Pn 192.168.238.0/24
Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-07 17:12 EDT
Nmap scan report for 192.168.238.1
Host is up (0.00032s latency).
Not shown: 97 filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 192.168.238.2
Host is up (0.00011s latency).
Not shown: 99 closed ports
PORT STATE SERVICE
53/tcp open domain
MAC Address: 00:50:56:EA:8D:7F (VMware)
Nmap scan report for 192.168.238.137
Host is up (0.00018s latency).
Not shown: 82 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
513/tcp open login
514/tcp open shell
2049/tcp open nfs
2121/tcp open ccproxy-ftp
3306/tcp open mysql
5432/tcp open postgresql
5900/tcp open vnc
6000/tcp open X11
8009/tcp open ajp13
MAC Address: 00:0C:29:54:6E:48 (VMware)
Nmap scan report for 192.168.238.254
Host is up (-0.10s latency).
All 100 scanned ports on 192.168.238.254 are filtered
MAC Address: 00:50:56:F7:A6:AC (VMware)
Nmap scan report for 192.168.238.136
Host is up (0.0000020s latency).
All 100 scanned ports on 192.168.238.136 are closed
Nmap done: 256 IP addresses (5 hosts up) scanned in 16.43 seconds

Some additional scan types:

TCP SYN pings initiate the first step in the TCP handshake on a given port. If the host responds with TCP ACK, we know the host is alive, and we close the handshake with a RST packet.

TCP ACK pings send the ACK to a host, making the host think a handshake was initiated. Since the host knows it didn’t send a SYN, it will respond with a RST packet to stop the handshake, letting us know the host is alive.

UDP pings send a UDP packet to a certain port. It receives an ICMP port unreachable packet if the port is closed, but that lets us know the host is alive.

Up next: Port scanning

Vulnerability analysis part 1: Setup

I set up a Kali VM and a Metasploitable VM.

I will set up an IDS in the Kali machine to monitor traffic across the network. I will then perform different stages of an attack and monitor which attacks alert the IDS. We will look at both stealthy attacks and loud smash-and-grab attacks.

Since Snort doesn’t exist in the Kali 2.0 repos, I will use Suricata.

# apt-get install suricata

Make some changes to the Suricata configuration file like so.

# gedit /etc/default/suricata

Untitled

We will use Oinkmaster to fetch the Snort rules.

# gedit /etc/oinkmaster.conf

Add this URL:

url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz

Now let’s run Oinkmaster to fetch the Emerging Threats rules.

# oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules

We can see the Snort rules here:

# ls /etc/suricata/rules
botcc.portgrouped.rules         emerging-icmp_info.rules       emerging-user_agents.rules
botcc.rules                     emerging-icmp.rules            emerging-voip.rules
BSD-License.txt                 emerging-imap.rules            emerging-web_client.rules
ciarmy.rules                    emerging-inappropriate.rules   emerging-web_server.rules
classification.config           emerging-info.rules            emerging-web_specific_apps.rules
compromised-ips.txt             emerging-malware.rules         emerging-worm.rules
compromised.rules               emerging-misc.rules            files.rules
decoder-events.rules            emerging-mobile_malware.rules  gen-msg.map
dns-events.rules                emerging-netbios.rules         gpl-2.0.txt
drop.rules                      emerging-p2p.rules             http-events.rules
dshield.rules                   emerging-policy.rules          rbn-malvertisers.rules
emerging-activex.rules          emerging-pop3.rules            rbn.rules
emerging-attack_response.rules  emerging-rpc.rules             reference.config
emerging-chat.rules             emerging-scada.rules           sid-msg.map
emerging.conf                   emerging-scan.rules            smtp-events.rules
emerging-current_events.rules   emerging-shellcode.rules       stream-events.rules
emerging-deleted.rules          emerging-smtp.rules            suricata-open.txt
emerging-dns.rules              emerging-snmp.rules            tls-events.rules
emerging-dos.rules              emerging-sql.rules             tor.rules
emerging-exploit.rules          emerging-telnet.rules          unicode.map
emerging-ftp.rules              emerging-tftp.rules
emerging-games.rules            emerging-trojan.rules

Start Suricata to sniff on the eth0 network interface.

# suricata -c /etc/suricata/suricata-debian.yaml -i eth0

Monitor the log file

# tail -f /var/log/suricata/fast.log

Now we have the IDS configured with the Emerging Threats ruleset.

Next up we will look at network reconnaissance.

Ashley Madison part 2: Cryptanalysis

Lets look at these password hashes:

$2a$12$6YEtyM93L2EQkHzs/PSP6OKEiW6fS3dSZCozzDrMKhHqRmI6NjS1S
111111Iwillneverdoitagain
$2a$12$3V0bFXAv1b4DT1KHh3uqjumaRYysI.NNpgXlcFEfulNUoBYtBEtTG
111111Iwillneverdoitagain
$2a$12$8b5m318FP10GzXI.mtJyh.L.LFjK5iZMwen9gJ68OrkrSLJrKsq1e
111111Iwillneverdoitagain
$2a$12$XC2CQOA5agBimTPHdvcsKOVgKkDwfjXFPyZjNhCFxhxj0yZS/T9f.
111111Iwillneverdoitagain
$2a$12$4FOWYjeL4AtnSuWqP7.1NeeBejEvwBFI/K3Pjt2r0jg5RhnPF38ja
$2a$12$zK2RRlnbtzm/0X0ZSuMrJ.L8v4KSOGnOuXDtDcPkw.ic6qeV.cg4i

Now when looking at the passwords, I notice that they all start with the marker “$2a$12$”.

This is Linux /etc/shadow notation. Linux keep the passwords in the /etc/shadow file. This file is readable only to root accounts. It contains the password hashes of all users. We call “shadow” because it is a shadow file of the /etc/passwd file. /etc/passwd is world readable, so we obviously don’t want to store our password hashes in this file. When we shadow the password file, /etc/passwd will only store an “x” for the password.

$ sudo cat /etc/passwd
...
david:x:1000:1000:david,,,:/home/david:/bin/bash
...

This contains our username:password (shadowed)

Now if I look at the contents of our shadow file (I changed the salt and hash)

$ sudo cat /etc/shadow
...
david:$1$HSnwkd2ajf$Aadhj20idhjSd8djv9d:16663:0:99999:7:::
...

This contains our username:$algorithm$salt$hashed password, followed by information regarding password changes. In this case, the $1$ means the hash was MD5.

Some other prefixes I found:

$0$ – DES
$2$, $2a$ = Blowfish
$3$ = NT hash
$5$ = SHA-256
$6$ = SHA-512

Back to the marker “$2a$12$” in the database. I know that the passwords were hashed with the Blowfish algorithm. The bcrypt algorithm implements Blowfish, so I’m that was the algorithm the website used to hash password. The $12$ means a cost factor of 12, or 12 rounds of bcrypt.

bcrypt, along with scrypt and PBKDF2 are a family of algorithms for hashing passwords. They are all considered “slow” for a computer to perform in relation to other algorithms like MD5 or SHA, so that if a database is compromised and the hashes revealed to an outsider, any brute force or dictionary attacks will be handicapped.

bcrypt has the advantage of being hard for a GPU to do. GPUs are many times faster at performing hashes then the CPU, so crackers often utilize one or more GPUs in parallel to crack passwords. According to https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

“Bcrypt happens to heavily rely on accesses to a table which is constantly altered throughout the algorithm execution. This is very fast on a PC, much less so on a GPU, where memory is shared and all cores compete for control of the internal memory bus.”

With that being said, it is unlikely I will be able to crack any passwords from this database.

Another thing I noticed was the repeated password of “111111Iwillneverdoitagain”. I would assume that this is how the website disabled accounts, since it would be extremely difficult to find a string whose hash equals “111111Iwillneverdoitagain”.

Ashley Madison part 1: Getting the database

I downloaded the Ashley Madison database dump.

The dump was available here http://pastie.org/10360347. I downloaded it in an Ubuntu VM for safety precautions.

The files available:

am_am.dump.gz
aminno_member.dump.gz
aminno_member_email.dump.gz
ashleymadisondump.7z
CreditCardTransactions.7z
member_details.dump.gz
member_login.dump.gz

The file member_login.dump is a MySQL database backup. First I installed the database with:

$ sudo apt-get install mysql-server

Start MySQL with

$ mysql -u root -p

Now we need to create a new database and restore from the backup. We’ll go ahead and import member_login.dump and member_details.dump:

$ mysql

> create database AshMad

> use AshMad

$ mysql -u root -p < Downloads/dmps/member_login.dump

$ mysql -u root -p < Downloads/dumps/member_details.dump

And now MySQL will import the database.
Note: Do not use the MySQL source command to import large databases. Source is designed to run a small number of SQL queries, and will take a long time to import a large database.

Let’s explore the imported tables.

mysql> use AshMad;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

mysql> show tables;
+------------------+
| Tables_in_AshMad |
+------------------+
| member_login     |
| member_details   |
+------------------+
2 rows in set (0.00 sec)

mysql> show columns from member_login;
+----------+--------------+------+-----+---------+----------------+
| Field    | Type         | Null | Key | Default | Extra          |
+----------+--------------+------+-----+---------+----------------+
| pnum     | int(11)      | NO   | PRI | NULL    | auto_increment |
| username | varchar(28)  | NO   | UNI |         |                |
| password | varchar(128) | NO   |     |         |                |
| loginkey | varchar(36)  | NO   | MUL |         |                |
| notify   | int(4)       | NO   |     | 0       |                |
+----------+--------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

Now we’re going to dump the password column into a text file for a password cracker. This might take a few minutes, as there are almost 4 million rows.

> select password from member_login into outfile 'ashmadpasswords.txt' lines terminated by '\n';

Now we have the passwords in a .txt document in the file /var/lib/mysql/AshMad/ashmadpasswords.txt;

Lets check the file to see what we have:

$ head -10 /var/lib/mysql/AshMad/ashmadpasswords.txt 
$2a$12$6YEtyM93L2EQkHzs/PSP6OKEiW6fS3dSZCozzDrMKhHqRmI6NjS1S
111111Iwillneverdoitagain
$2a$12$3V0bFXAv1b4DT1KHh3uqjumaRYysI.NNpgXlcFEfulNUoBYtBEtTG
111111Iwillneverdoitagain
$2a$12$8b5m318FP10GzXI.mtJyh.L.LFjK5iZMwen9gJ68OrkrSLJrKsq1e
111111Iwillneverdoitagain
$2a$12$XC2CQOA5agBimTPHdvcsKOVgKkDwfjXFPyZjNhCFxhxj0yZS/T9f.
111111Iwillneverdoitagain
$2a$12$4FOWYjeL4AtnSuWqP7.1NeeBejEvwBFI/K3Pjt2r0jg5RhnPF38ja
$2a$12$zK2RRlnbtzm/0X0ZSuMrJ.L8v4KSOGnOuXDtDcPkw.ic6qeV.cg4i

And that’s it for part 1.