The Password Attacks on Kali Linux [Part 2]

Offline Password attack
The service that use as authentication a keyword needs to store it somewhere and somehow. Think about /etc/shadow or SAM in Windows, but also browsers, routers, switches and any kind of client (ftp, e-mail, smb). The password can be stored in clear text, in databases or hashed in files; every time you copy these files and then you try, even in other environment, to extract the passwords you are doing an offline password attack. With administrative rights is possible, for example, to dump password hash from Windows and Linux system. The same operation can be done mounting the target system disk on the Kali system, also without credentials, or starting the system to attack using a bootable Kali distribution.
Files that contain hashed or plaintext passwords can be found in every place: sometimes the database backup is directly hosted in a web folder, let alone files named password.txt that can be found directly using Google; also htaccess and htpasswd can be dumped sometimes. FTP client, zip files, RDP connection files are a mine of keywords easy to collect too. Sniffing traffic waiting for a pop3/ snmp clear-text request or taking a 4 way handshake from an access point are just other options you have to perform an offline attack.
Remember that keys are often reused throughout the network, so a complex password simply sniffed with Wireshark in a not encrypted packet like pop3 (see Figure 1) can be the same unbreakable and encrypted 15-chars password used for ssh service.

Figure 1

Windows SAM file and Linux shadow
Windows stores the hash of local passwords in a file named SAM “Security Accounts Manager” present in c:\windows\system32\config\. Of course the file isn’t plain text, but it has to be merged to another file (SYSTEM) present in the same folder. The union of these two files leads to a readable one where you can see the passwords hash just like thise in Figure 2.
These two files can be accessed only when the operating system is down or using tolls like PWdump or FGdump. The other choice is to dump the system backup of these; in fact, up to Windows Vista, you can find them in c:\windows\repair\ folder. To merge the SAM and the SYSTEM file you can use bkhive and samdump2; after getting the hash, John the Ripper is used to extract the password.

As said previousely, if you own the target machine, you can take advantage of tools like FGdump too or, if you have established a meterpreter session, of the hashdump command (see Figure 2).

Figure 2

Note that you need to be Admin or System to launch these commands and you have to upload to the target machine some lines of code that sometimes can be blocked by antivirus.
Since it’s one of the “most wanted” tools, let’s see also JtR in action:

Note that most passwords are immediately decrypted (nina, administrator, user, jasmine, albert, peru) when others only in part.
This is caused by the old windows method to store password called LM. This kind of hashing, putted next to the newer NTLMv2, is present by default up to Vista to guarantee the backward compatibility. LM can be disabled and Microsoft recommended that, but de facto this is a vulnerability that users are carrying on for many years.
The LM hash works as follow:
• the user password is converted in an all upper case string;
• the password is cutted after 14 bytes (max password length);
• the password is splitted in 2 pieces of 7 bytes max;
• this two pieces are encoded using DES.
This is a simple view of what is LM, but your interest is that JtR has the task to crack an hash with no more than 7 chars-upper-case. This is really different from finding a key with 14 chars, upper and lower case. in addition to this DES kind of encrypting is well known and john use this to speed up the work.

Also, Linux stores keys in two files: /etc/passwd and /etc/shadow. In this case it’s not essential the merge of the two files, but it’s better for decrypting. You can use the JtR command unshadow to join the two.
In Kali Linux you will be able to call any tool from anywhere on the system as every application is included in the system path so you can call unshadow and john just like this:

Then you use john to decrypt:

Sometimes you can try to use john on /etc/shadow without unshadowing it, but in this case john will not use the GECOS info (complete name, telephone number…) that helps to perform a better crack. Also the use of some features like -shells will be lost if you don’t perform the unshadow.

Some small words about using Google as hash cracker.
Google is a big container of everything. It’s not unusual to take an encrypted string, paste it in the browser and find the key.
One of the easiest hash to find is the MD5 one. The Message Digest algorithm 5 is an old method of hashing; it is already obsolete and insecure, but users and programs still employ it to encode passwords. If you try to paste an MD5 string in Google you’ll likely find it. Before trying everything else paste the hash in the search engine or use some online rainbowtable program.

The cache and the sniffing
Although the cache and the packet analysis are not pure offline password attacks, they deserve to be mentioned. If you finally own a PC in the net you have to test, squeeze it. Extract all what you are able to take.
First start a sniffing session using Wireshark or, if you can’t, use Ettercap to perform a man in the middle and wait for unencrypted password. These are some normalized output of Ettercap. The first is the capture of a webmail account on an insecure http page instead of more secure https:

Then some capture of POP3 and FTP packets:

This is why is always better to use an ssl version of all protocols, also in internal communications.

If you have access to a PC search for client’s programs like FileZilla or browsers and take note of passwords archived using meterpreter or search in Internet where the client stores it:

Then use ms-cache option of JtR or program like Windows Credentials Editor that locate system cached password: if you are lucky a sysadmin has been logged or some service is misconfigured and the password is stored (not encoded) in the cache.
In the following case of study the user HP\Nina, present in Domain Administrators group, is simply logged on. In this machine is present an agent misconfigured that use HP\administrator credential to work:

Note that cache keys “ninaanin” and “password” are not encoded.

SMB pass-the-hash
Like in the previous example, not always you’ll have to spend time in decrypting operations. Sometimes you can use the hash you get as it is. Ok, you can’t take the string and just paste it in a authentication window request and login using Remote Desktop, but there is a quite controversial feature in Windows on the authentication management of shared folders.

Consider this example:
Computer A has a c:\share and Computer B tries to connect to that share. B sends its credential in hash format (“hello! I am Administrator and my password is e52cac67419a9a224a3b108f3fa6cb6d”) and A verify if it has this credential, if so it connects Computer B to the share. If not it prompts for username and password.
All this process is in clear text!
So, what about If the Computer A is an attacker and has a network sniffer? It collects the Computer B hash! Now attacker on Computer A can try to decode the hash, but not only that. He can use Metasploit, taking advantage of the module pass the hash, and own the B machine.
He uses the Administrator hash to connect to ADMIN$ of B and execute some code like reverse shell. The SMB_relay exploit, present in Metasploit, has everything you need to test this Windows vulnerability: it creates a fake sharing folder, captures the hash, pushes a payload and establishes a connection. Of course the pass the hash function can be also used with hashes previously collected:

Are you still secure to connect to a network shared folder? So, if you have to secure a network, remember the users: force a strong domain policy, patch the systems, use SSL wherever you can, set different passwords for different services and, above all, educate the people.

I continue my tests about EMETv4. This time I’ve installed EMETv4 on the same machine HP-CLI01 and HP-SRV01 (note that framework 4 is required ). The only configuration I set is the “recommended” one.

Test4
Target: Windows Server 2003 SP2 eng; Host Name: HP-SRV01; IP Address: 192.168.34.135
Vulnerability: CVE-2008-4250 (SMB)
Exploit used: ms08_067_netapi from metasploit
EMET agent: installed with recommended settings.

This is MSFConsolle ouput of the exploit:

The target is powned. Take a look at the process number 4016: 4016  3560  EMET_Agent.exe
The EMET_Agent is running but the exploit still works.

Test 5
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2008-4250 (IE6)
Exploit used: ms10_002_aurora from metasploit
EMET agent: installed with recommended settings.

I setup the exploit exactly as test 2 but this time EMET works well and stops me.
When I start IE6 on the target machine and point to the evil page the aurora exploit cause the crash of Internet Exploter as wished. so I restart the target machine and retry: same result, IE6 crash. I want to double check this and I exclude iexplorer.exe from EMEC configuration and this time the exploit has worked.

This is a drow: exploit 1 – EMEC 1.

Test 6
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2003-0264 (slmail55_4433)
Exploit used: my version of this well known exploit
EMET agent: installed with recommended settings.

Also in this case, with defaul settings the exploit works:

Again, after a reboot, EMET doesn’t stop the attack, so I try to adjust some settings. If I modify the profile template from “recommended” to “maximum” and reboot, EMET doesn’t allow the execution of code: the DEP block the execution from the address space. I double check it and retry my attack with basic settings: the exploit is not stopped. Also in this case let’s take 2 steps back and debug the application while EMET is blocking the execution (Image1)

Image 1

Conclusions
I consider the EMET idea extremly useful and I think that this program, if implemented, will be able to increase the system security. Nowaday the bigest problems, from my viewpoint, are:
– not all moules are present and activated (SEHOP e ASLR)
– not all installed programs are controlled by default
– On my tests, on Windows XP, I have a problem with the EMET_agent when start the GUI (image2) and when I reboot (image3).
– I would be happier if FrameWork4 is not a requirement.

Image 2

Image 3

The practice
I will test 3 attacks:
– To Operating system vulnerability (SMB)
– To Microsoft software (IE6)
– To non Microsoft Software (SLMail)

Target machines:
– Windows XP SP3 eng (Host Name: HP-CLI01; IP Address: 192.168.34.134)
– Windows Server 2003 SP2 eng (Host Name: HP-Srv01; IP Address: 192.168.34.135)

Attack machine:
– Linux BackTrack 5R2 (Host Name: bt; IP Address: 192.168.34.132)

Note that both Operating systems and vulnerability are rather old. I use these because I hope that EMET will work well on known exploits, better than with unknown one. So let’s start the phase 1: system without EMETv4.

Test 1
Target: Windows Server 2003 SP2 eng; Host Name: HP-Srv01; IP Address: 192.168.34.135
Vulnerability: CVE-2008-4250 (SMB)
Exploit used: ms08_067_netapi from metasploit

Look at the Metasploit Framework Consolle running on Linux machine:

Test 1 succesfull

Test 2
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2008-4250 (IE6)
Exploit used: ms10_002_aurora from metasploit

On the Linux machine I start a http server with evil page (https://192.168.34.132:8080/evil) using Metasploit:

Now in the target machine I start Internet Explorer 6, browse to the evil page and the msf consolle continues:

Test 2 succesfull

Test 3
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2003-0264 (slmail55_4433)
Exploit used: my version of this well known exploit

Take a look at the target machine:

Now, let’s run the exploit from the attacker machine and re-run netstat

The payload of the exploit was a bind shell on port 4444, indeed a TCP listener is now working this port.
On the Linux machine I am able to connect to this listener a get a remore shell:

The following screenshot is the exploit in acrion:

Image 1

Image 2

[end of phase 1] Take a look at the [phase 2]

The domain is called LAB.local based on Windows 2008R2. LABServer07 is the primary DC.
The exploited machine is joined to the domain and we got a Meterpreter shell with local PC admin rights.

Basic command used after exploit:
Find process –> meterpreter > ps
Load incognito extension –> meterpreter > use incognito
Listing available tokens –> meterpreter > list_tokens -u
Impersonate token –> meterpreter > impersonate_token
Get a command shell using the token –> meterpreter > execute -f cmd.exe -i -t -H -c
Add a domain User –> C:\WINDOWS\system32>net user USER PASSWORD /add /domain
Add the creted user in domain admin –> C:\WINDOWS\system32>net localgroup administrators USER /add /domain

Interact with session 1 and list process:

Load extension, list token and impersonate domain admin:

Get a domain admin shell:

Create new domain user and join to the domain admins group:

Obviously the victim PC is an Italian version, “esecuzione comando riuscita” means “Command completed successfully”