Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GrrCon - Crypto Gone Rogue

Pranshu Bajpai
September 03, 2018

GrrCon - Crypto Gone Rogue

https://www.amirootyet.com/

A Tale of Ransomware, Key Management, and the CryptoAPI.

Ransomware such as WannaCry and Petya have been heavily focused upon in news but are their cryptographic models different from predecessors? Key management is crucial to these cryptoviral extortions and they harness the power of resident Crypto APIs available on host for convenience. In other words, they command victim’s resources to lock victim’s resources. In this talk, we examine key management models deployed in infamous cryptovirii with the ultimate objective of providing a deeper comprehension of exactly how resident APIs are being used against users. On a Windows host, CryptoAPI (CAPI) provides cryptographic services to applications. CSPs are sets of DLLs that are associated with CAPI implementing cryptographic functions such as CryptAcquireContext, CryptGenKey, CryptEncrypt, CryptImportKey, CryptExportKey, CryptDestroyKey etc. In Windows Vista and later, CNG replaces CAPI and the ransomware menace persists. We explain cryptographic functions exploited by several ransomware families and explore answers to crucial questions such as how and where the encryption key is generated, where it is stored, how it is protected while encrypting user data, and how it is securely purged. We explore several possibilities of key recovery without paying the ransom. We provide graphical representations combined with pseudo codes embodying real-world Crypto API function calls pertaining to key management in ransomware. We highlight limitations faced by ransomware with respect to key management and examine practical potential defenses. Finally, we explore options available to ransomware developers in absence of CAPI and CNG. For example, RAA uses the CryptoJS library. This talk delves deep into key management in present-day ransomware and is a direct result of real-world case studies of highly virulent infections.

Pranshu Bajpai

September 03, 2018
Tweet

More Decks by Pranshu Bajpai

Other Decks in Technology

Transcript

  1. Crypto Gone Rogue A Tale of Ransomware, Key Management, and

    the CryptoAPI -Pranshu Bajpai, Richard Enbody
  2. 2 1. Introduction 2. Key Management 3. Implementation Details 4.

    Understanding the CryptoAPI Functions 5. Ransomware Pseudo Code 6. Conclusion Agenda
  3. About Us 4 Pranshu Bajpai @amirootyet ▪ PhD candidate at

    Michigan State University ▪ Previously worked as an independent penetration tester ▪ Active speaker at security conferences: DEFCON, GrrCon, ToorCon, BSides, APWG eCrime... ▪ https://www.linkedin.com/in/pranshubajpai ▪ http://www.cse.msu.edu/~bajpaipr/ Richard Enbody ▪ Associate Professor at Michigan State University ▪ Books: Targeted Cyber Attacks, The Practice of Computing using Python ▪ http://www.cse.msu.edu/~enbody/
  4. Why Key Management? Key management is crucial to ransomware operation:

    8 ▪ Attacker needs exclusive access to the decryption key ▪ Key management is complex and attackers frequently make errors ▪ Ransomware will always find victims – flaws in key management imply we can recover files without paying the ransom
  5. Evolution of Key Management ▪ Hybrid encryption ▪ A Key-Management-Based

    Taxonomy for Ransomware – Pranshu Bajpai, Aditya K Sood, Richard Enbody https://ieeexplore.ieee.org/document/8376213/ 9
  6. The Windows CryptoAPI, CSPs, and CNG CryptoAPI ▪ Microsoft’s Cryptographic

    API (CAPI) ▪ Maliciously used by ransomware ▪ Provides cryptographic services to userland applications ▪ Cryptographic primitives are buried in DLLs and divided among CSPs ▪ Provides abstraction to programmers CSPs ▪ Cryptographic Service Providers ▪ Each CSP offers cryptographic primitives ▪ Responsible for actually implementing the CAPI ▪ CAPI is just a bridge between application and CSP – CSP is the crux of cryptographic functionality ▪ Must be signed by Microsoft CNG ▪ Cryptography API: Next Generation ▪ Started with Windows Vista ▪ Replacement for CryptoAPI 11
  7. Why Use the Native CryptoAPI? Ransomware developers: 13 ▪ Make

    design, implementation, and operation errors ▪ Frequently engage in cargo-cult programming ▪ Often end up creating ineffective ransomware that is actually scareware
  8. CryptAcquire Context ▪ Acquires handle to a key container within

    a CSP ▪ Returned handle use to make calls to selected CSP 21 // Get a handle to the default PROV_RSA_FULL provider if(!CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, 0)) { printf("Error %x during CryptAcquireContext!\n", GetLastError()); return; }
  9. CryptGenKey ▪ Generates a random symmetric key or a public-

    private key pair ▪ Handle is returned to the key/key-pair 23 if(CryptGenKey( hCryptProv, ENCRYPT_ALGORITHM, KEYLENGTH | CRYPT_EXPORTABLE, &hKey)) { printf("A key has been created.\n"); } else { printf("Error during CryptGenKey.\n"); exit(1); }
  10. CryptEncrypt CryptDecrypt ▪ Encrypt and decrypt data 25 ▪ Handle

    to the key to use for encryption and decryption ▪ Key determines the encryption and decryption algorithm deployed
  11. CryptImportKey ▪ Transfers a key from a key blob to

    a CSP 28 if(CryptImportKey( hProv, pbKeyBlob, dwBlobLen, 0, 0, &hPubKey)) { printf("The key has been imported.\n"); }
  12. CryptExportKey ▪ Securely transfers a key from CSP 30 if(CryptExportKey(

    hKey, NULL, dwBlobType, 0, NULL, &dwBlobLength)) //Allocate memory for public key blob if(CryptExportKey( hKey, NULL, dwBlobType, 0, *ppbKeyBlob, &dwBlobLength)) // Actual exporting into key blob
  13. CryptDestroyKey ▪ Releases the handle to the key parameter ▪

    Invalidates key and ensures it cannot be used again 32 BOOL CryptDestroyKey( HCRYPTKEY hKey );
  14. CryptRelease Context ▪ Releases the handle to the CSP 34

    BOOL CryptReleaseContext( HCRYPTPROV hProv, DWORD dwFlags );
  15. Ransomware Design 36 void thread_encrypt() { // main calling function

    ... HCRYPTKEY symKey; // handle to key HCRYPTPROV hProv = [...]; // handle to CSP symKey = generateKey(hProv); // call to key generation function encryptData(hProv, symKey); // call to file encryption procedure cleanup(symKey); // clean up procedure CryptDestroyKey(symKey); // destroy key in memory CryptReleaseContext(hProv, 0); // release handle to CSP } HCRYPTKEY generateKey(hProv) { HCRYPTKEY symmKey; // handle to key CryptGenKey(hProv, CALG_AES_128, 1u, &symmKey); // generate AES-128 key DWORD mode = CRYPT_MODE_CBC; // use CBC cipher mode CryptSetKeyParam(symmKey, KP_MODE, &mode, 0); DWORD padData = PKCS5_PADDING; // PKCS 5 padding method CryptSetKeyParam(symmKey, KP_PADDING, &padData, 0); // set the padding mode return symmKey; // return generated key } void encryptData(hProv, symKey) { for each file type F: // search for specific file types cryptFile(hProv, symKey); // locate and encrypt files } void cleanup(hProv, symKey) { HCRYPTKEY asymPubKey = getasymPubKey(hProv): //acquire RSA public key void* symKeyEncryptb64 = exportKey(symKey, asymPubKey); //encrypt and encode AES key //...write ransomnote.txt... //...write base64 encoded encrypted AES key... //... LocalFree(symKeyEncryptb64); //free allocated memory }
  16. Conclusion ▪ Assume ransomware has infiltrated host. What can we

    do from here? ▪ Empirical analysis suggests that many vulnerabilities lie in the key management in these ransomware ▪ Ransomware developers continually introduce design, operation, and implementation flaws ▪ Understanding key management allows us to quickly attack flaws in ransomware to recover files 38