Tuesday, May 21, 2013

MoVP II - 2.1 - RSA Private Keys and Certificates

Those of you who downloaded the Volatility Cheat Sheet v2.3 may have noticed a plugin named dumpcerts, which is a relatively new addition to the plugin scene for Windows. Its based on the work by Tobias Klein called Extracting RSA private keys and certificates from process memory. In short, you can find RSA private keys (PKCS #8) and SSL certificates (x509) by scanning for header and version constants found in the ASN.1 representations. The dumpcerts plugin for Volatility uses this scanning approach to find, extract, and parse these keys and certificates from physical memory (useful for determining which ones were found in unallocated/freed memory) or virtual memory (useful for attributing the key/cert to a specific process that was using it).

Here are a few reasons why you may use the dumpcerts plugin:
  • You have a memory dump from a system infected with malware that's using public key cryptography - and you need copies for evidence and/or decryption efforts. 
  • You need help proving or disproving that a private key was stolen from a victim machine (or used on a suspect's machine)
  • You want to scan for the presence of expired, revoked, or self-signed certificates in your memory dump 
  • You're looking for malware that uses stolen private keys to sign trojans (or to load kernel drivers on x64 systems)
Stuxnet is an example of malware that fits the criteria in the last bullet. It included two drivers that were signed with keys stolen from JMicron Technology Corp and Realtek Semiconductor Corp.  There's already a copy of an Stuxnet-infected memory image available from our wiki, so you can follow along if you like. 

To see the usage, call the plugin with the standard -h/--help option:

$ python vol.py -f stuxnet.vmem dumpcerts -h
Volatile Systems Volatility Framework 2.3_beta
Usage: Volatility - A memory forensics analysis platform.

[snip] 

  -D DUMP_DIR, --dump-dir=DUMP_DIR
                        Directory in which to dump executable files
  -s, --ssl             Use OpenSSL for certificate parsing
  -P, --physical        Scan across physical space (in deallocated/freed
                        storage)
---------------------------------
Module DumpCerts
---------------------------------
Dump RSA private and public SSL keys

The -D/--dump-dir=DIR argument is required - its the output directory for keys and certificates. If you have the openssl command-line utility installed, pass -s/--ssl to parse the extracted files with openssl (additional output will be displayed to stdout in this case). The -P/--physical parameter limits the scan to physical layers (i.e. the flat file, with no address translation or virtual memory analysis). Use this option when you suspect keys or certificates may exist in memory marked as deallocated or freed (which would typically not be accessed again by the OS before being re-allocated and overwritten). Sometimes the most volatile evidence can be found in physical space scans.

In the example below, we start off with scanning virtual memory and using openssl to parse the extracted keys and certificates. This tells you the name and pid of the process(es) in which the objects were found, the output file name, and the organization (O) and organizational unit (OU) field from the parsed certificate data. If you want to see other fields, such as the fingerprint, validity dates, or other details, that can easily be customized in the plugin.

$ python vol.py -f stuxnet.vmem dumpcerts -D certs --ssl
Volatile Systems Volatility Framework 2.3_beta
Pid      Process          Address    Type                 Length   File                     Subject
-------- ---------------- ---------- -------------------- -------- ------------------------ -------
     624 winlogon.exe     0x010165d8 _X509_PUBLIC_CERT        1042 624-10165d8.crt          Microsoft Corporation
     668 services.exe     0x000b6b20 _X509_PUBLIC_CERT         576 668-b6b20.crt            VeriSign/VeriSign Commercial Software Publishers CA
     668 services.exe     0x000c8268 _X509_PUBLIC_CERT         665 668-c8268.crt            Fundacion FESTE
     668 services.exe     0x000decb0 _X509_PUBLIC_CERT         642 668-decb0.crt            Equifax Secure Inc.
     668 services.exe     0x000e3f90 _X509_PUBLIC_CERT         787 668-e3f90.crt            Thawte Consulting cc/Certification Services Division
     668 services.exe     0x000e49d8 _X509_PUBLIC_CERT         785 668-e49d8.crt            SecureNet CA Root
     668 services.exe     0x000e4cf8 _X509_PUBLIC_CERT         761 668-e4cf8.crt            FNMT/FNMT Clase 2 CA
     668 services.exe     0x000e5000 _X509_PUBLIC_CERT         780 668-e5000.crt            Unizeto Sp. z o.o.
     668 services.exe     0x000e77b8 _X509_PUBLIC_CERT         506 668-e77b8.crt            GTE Corporation
[snip]

On the Stuxnet image, the plugin gathered a total of 11 private keys and 295 certificates out of memory. You can pipe the output to a file and analyze it later, or you can grep or filter stdout for potentially suspicious objects. In the case below, we're looking for any keys or certificates with the string "realtek" in the O or OU field. As you can see, we came up with three items - in the memory of services.exe, svchost.exe, and lsass.exe. If you read Stuxnet's Footprint in Memory with Volatility 2.0, you'll know Stuxnet performs code injection into all three of these processes, so it makes perfect sense.

$ python vol.py -f stuxnet.vmem dumpcerts -D certs --ssl | grep -i realtek
Volatile Systems Volatility Framework 2.3_beta
     668 services.exe     0x015082e1 _X509_PUBLIC_CERT        1286 668-15082e1.crt          Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
     940 svchost.exe      0x00e182e1 _X509_PUBLIC_CERT        1286 940-e182e1.crt           Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
    1928 lsass.exe        0x009882e1 _X509_PUBLIC_CERT        1286 1928-9882e1.crt          Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN

Once again with openssl, you can get the full details of the suspect certificates. Below you can see the first one's serial number is 5e:6d:dc:87:37:50:82:84:58:14:f4:42:d1:d8:2a:25. You can verify the certificate with the openssl verify command or can query for the serial number in your threat intelligence feed, whatever that may be.

$ openssl x509 -inform der -in certs/668-15082e1.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5e:6d:dc:87:37:50:82:84:58:14:f4:42:d1:d8:2a:25
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)04, CN=VeriSign Class 3 Code Signing 2004 CA
        Validity
            Not Before: Mar 15 00:00:00 2007 GMT
            Not After : Jun 11 23:59:59 2010 GMT
        Subject: C=TW, ST=Taiwan, L=Hsinchu, O=Realtek Semiconductor Corp, OU=Digital ID Class 3 - Microsoft Software Validation v2, OU=RTCN, CN=Realtek Semiconductor Corp
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:b5:6c:5e:03:88:79:57:9a:4f:ce:02:30:b9:05:
                    1f:06:13:7a:57:17:4e:ee:59:d6:b0:20:d0:7c:e9:
                    17:32:bb:03:e8:13:45:1a:3e:22:57:4c:b4:bc:b3:
                    c5:3d:32:62:e8:a9:6c:f2:03:d1:72:ee:1e:f2:65:
                    ce:dd:df:0f:6e:77:08:a7:b2:13:92:db:30:f3:d8:
                    8e:b9:53:46:d5:08:16:4f:6d:92:a5:f2:74:5e:d9:
                    42:d2:89:50:92:53:0a:e6:ff:67:3f:14:59:fe:0d:
                    af:e0:97:8e:1f:f0:eb:6f:c6:e1:93:3e:5e:50:a6:
                    26:65:69:21:84:32:be:a3:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 CRL Distribution Points: 
                URI:http://CSC3-2004-crl.verisign.com/CSC3-2004.crl

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.113733.1.7.23.3
                  CPS: https://www.verisign.com/rpa

            X509v3 Extended Key Usage: 
                Code Signing
            Authority Information Access: 
                OCSP - URI:http://ocsp.verisign.com
                CA Issuers - URI:http://CSC3-2004-aia.verisign.com/CSC3-2004-aia.cer

            X509v3 Authority Key Identifier: 
                keyid:08:F5:51:E8:FB:FE:3D:3D:64:36:7C:68:CF:5B:78:A8:DF:B9:C5:37

            Netscape Cert Type: 
                Object Signing
            1.3.6.1.4.1.311.2.1.27: 
                0.......
    Signature Algorithm: sha1WithRSAEncryption
        bd:ba:23:02:36:e9:76:e9:cb:22:7a:ef:53:7b:3f:66:43:92:
        01:43:e7:90:94:b4:52:d7:2c:89:82:24:39:fe:3f:7b:24:65:
        d0:c2:72:56:18:a4:f6:0b:d3:9b:75:f1:63:62:89:5b:5d:2e:
        9e:f8:1a:51:48:6b:b8:e6:cd:96:b7:f1:32:31:b2:a1:cd:e3:
        bd:d9:04:7b:28:a9:5c:bf:be:3e:f3:e6:03:52:2c:75:88:5a:
        1a:ca:99:de:b9:3f:99:77:10:db:63:ed:68:b4:09:fb:ee:8d:
        c3:6a:c3:82:ec:12:e8:1a:22:61:28:8a:f6:4e:5d:1a:c3:50:
        97:3b:22:da:99:ab:3f:38:9b:4d:d1:da:01:e3:40:14:aa:a5:
        9d:13:1c:71:ea:cb:99:99:52:65:f5:94:af:d7:d0:ca:c7:04:
        20:eb:b7:41:4b:82:cc:07:84:de:6f:2a:51:8f:7b:0a:25:db:
        f0:1d:09:56:cc:30:5b:a2:55:5b:6d:da:8e:d6:a7:dd:1d:c6:
        ff:3d:74:f8:ff:e2:60:35:66:1f:a8:66:72:c1:fb:76:46:ca:
        df:24:ac:1a:66:fa:11:41:b7:f4:51:89:dc:da:49:99:3c:3d:
        d5:77:2d:b3:d3:d3:64:50:18:f4:95:f4:dd:9f:8d:76:41:60:
        25:b4:70:8b
-----BEGIN CERTIFICATE-----
MIIFBjCCA+6gAwIBAgIQXm3chzdQgoRYFPRC0dgqJTANBgkqhkiG9w0BAQUFADCB
tDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNDEuMCwGA1UEAxMl
VmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAwNCBDQTAeFw0wNzAzMTUw
MDAwMDBaFw0xMDA2MTEyMzU5NTlaMIHJMQswCQYDVQQGEwJUVzEPMA0GA1UECBMG
VGFpd2FuMRAwDgYDVQQHEwdIc2luY2h1MSMwIQYDVQQKFBpSZWFsdGVrIFNlbWlj
b25kdWN0b3IgQ29ycDE+MDwGA1UECxM1RGlnaXRhbCBJRCBDbGFzcyAzIC0gTWlj
cm9zb2Z0IFNvZnR3YXJlIFZhbGlkYXRpb24gdjIxDTALBgNVBAsUBFJUQ04xIzAh
BgNVBAMUGlJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDb3JwMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC1bF4DiHlXmk/OAjC5BR8GE3pXF07uWdawINB86RcyuwPo
E0UaPiJXTLS8s8U9MmLoqWzyA9Fy7h7yZc7d3w9udwinshOS2zDz2I65U0bVCBZP
bZKl8nRe2ULSiVCSUwrm/2c/FFn+Da/gl44f8OtvxuGTPl5QpiZlaSGEMr6jJwID
AQABo4IBfzCCAXswCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCB4AwQAYDVR0fBDkw
NzA1oDOgMYYvaHR0cDovL0NTQzMtMjAwNC1jcmwudmVyaXNpZ24uY29tL0NTQzMt
MjAwNC5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBMGA1UdJQQMMAoGCCsGAQUF
BwMDMHUGCCsGAQUFBwEBBGkwZzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy
aXNpZ24uY29tMD8GCCsGAQUFBzAChjNodHRwOi8vQ1NDMy0yMDA0LWFpYS52ZXJp
c2lnbi5jb20vQ1NDMy0yMDA0LWFpYS5jZXIwHwYDVR0jBBgwFoAUCPVR6Pv+PT1k
Nnxoz1t4qN+5xTcwEQYJYIZIAYb4QgEBBAQDAgQQMBYGCisGAQQBgjcCARsECDAG
AQEAAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQC9uiMCNul26csieu9Tez9mQ5IBQ+eQ
lLRS1yyJgiQ5/j97JGXQwnJWGKT2C9ObdfFjYolbXS6e+BpRSGu45s2Wt/EyMbKh
zeO92QR7KKlcv74+8+YDUix1iFoaypneuT+ZdxDbY+1otAn77o3DasOC7BLoGiJh
KIr2Tl0aw1CXOyLamas/OJtN0doB40AUqqWdExxx6suZmVJl9ZSv19DKxwQg67dB
S4LMB4TebypRj3sKJdvwHQlWzDBbolVbbdqO1qfdHcb/PXT4/+JgNWYfqGZywft2
RsrfJKwaZvoRQbf0UYnc2kmZPD3Vdy2z09NkUBj0lfTdn412QWAltHCL
-----END CERTIFICATE-----

The CCSS Forum has a searchable Digital Certificates Used by Malware portal, which you can use to get an initial perspective on whether your memory dumps are infected with certificate-stealing malware. The screen shot below shows the serial number of the certificate we extracted is registered in the portal as malicious.



The page also contains a link (if available) to the VirusTotal results for a particular sample. In this case, the certificate was associated with the MRXCLS.sys kernel driver - detected by 39 of 42 anti-virus engines (28 of them labeling it as "Stuxnet").

Now let's go back and use the -P/--physical switch which additionally scans deallocated/freed storage and see how the results differ. In this case, we found 4 certificates related to Realtek Semiconductor Corp, instead of the 3 we found when only scanning allocated and accessible process memory. This is quite useful because in the event that all 3 processes had terminated by the time our memory dump was acquired, there would still be one certificate still lingering around in RAM and available for recovery if you use the right scanning approach.

$ python vol.py -f stuxnet.vmem dumpcerts -D certs --ssl --physical | grep -i realtek
Volatile Systems Volatility Framework 2.3_beta
-        -                0x04efb2e1 _X509_PUBLIC_CERT        1286 phys.4efb2e1.crt         Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
-        -                0x0dd412e1 _X509_PUBLIC_CERT        1286 phys.dd412e1.crt         Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
-        -                0x161142e1 _X509_PUBLIC_CERT        1286 phys.161142e1.crt        Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
-        -                0x1b4fbb2d _X509_PUBLIC_CERT        1286 phys.1b4fbb2d.crt        Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN

Conclusion

There are a variety of reasons you may want scan for keys and certificates in memory. The dumpcerts plugin gives you the flexibility to perform simple extractions and/or filter results based on specific fields of the key or certificate. Perhaps most useful to investigators and analysts is you can also attribute the data to processes and carve them out of deallocated/freed space.

No comments:

Post a Comment