A while back, I was asked if it's possible to fake a VeriSign issued SSL certificate. In theory, this is possible (if you have like unlimited resources), but on the practical side, it's impossible. It is possible however to create a CA which resembles the VeriSign root up to some level.
Everything, apart to some 'details', can be forged. Name, serial number, timestamps, additional fields etc., can be created by OpenSSL and a special crafted config file. It's just finding out how to do it. The tough (and this is a definite understatement) part is the thumbprint, and the public key.
The public key is generated by cryptographic algorithme (along with the private key), and it's impossible to 'regenerate' this. But for the casual user, this is not a problem. For a normal user it's pretty hard to tell the original from the fake CA certificate, since only details are different. Also, these differences are unreadable pieces of hexadecimal strings.
So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is).
The following sections contain the real certificate from VeriSign, and the fake one. Now you figure out which one is the real one.
And the second CA certificate
After creating the CA, I made the SSL certificate (some data has been obscured).
The second CA is the real thing. The first one is the fake CA.
So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is). Or just infect him/her with a trojan to insert the CA for you.
The 'fun' part is that if you should replace the actual (original) VeriSign CA in your crypto store you get warnings/error messages which aren't very clear. The OS/Browser tries to 'tie' the SSL certificate to the CA, but not everything seems to add up :).
Everything, apart to some 'details', can be forged. Name, serial number, timestamps, additional fields etc., can be created by OpenSSL and a special crafted config file. It's just finding out how to do it. The tough (and this is a definite understatement) part is the thumbprint, and the public key.
The public key is generated by cryptographic algorithme (along with the private key), and it's impossible to 'regenerate' this. But for the casual user, this is not a problem. For a normal user it's pretty hard to tell the original from the fake CA certificate, since only details are different. Also, these differences are unreadable pieces of hexadecimal strings.
So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is).
The following sections contain the real certificate from VeriSign, and the fake one. Now you figure out which one is the real one.
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
02:ad:66:7e:4e:45:fe:5e:57:6f:3c:98:19:5e:dd:c0
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Validity
Not Before: Nov 9 01:00:00 1994 GMT
Not After : Jan 8 01:00:00 2010 GMT
Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1000 bit)
Modulus (1000 bit):
00:b8:93:ae:c9:5e:c7:8a:9e:97:c7:c3:32:00:73:
45:54:03:db:29:e2:13:4b:7b:78:6e:57:69:b3:c8:
77:a4:a7:48:40:51:99:1b:86:9f:f2:e7:8d:34:40:
fc:99:91:ac:ed:2e:07:7b:da:f6:97:b3:e7:63:2c:
7c:14:c4:8a:61:8f:e4:96:02:40:40:e4:ba:9a:bb:
6a:cb:d9:75:78:00:b7:5f:b3:ca:1b:a8:1f:6b:5b:
44:e3:65:04:72:98:55:5c:fb:e2:2d:bc:46:eb:c7:
44:78:5c:bf:9a:b4:a3:19:a5:d9:17:47:87:bb:73:
12:60:b9:77:18:59
Exponent: 65537 (0x10001)
Signature Algorithm: md2WithRSAEncryption
61:29:b8:7b:55:3b:c6:c7:7c:ed:86:73:b8:30:4a:02:c0:93:
79:06:83:39:f2:9c:9e:40:ca:42:e6:7f:12:e2:7c:22:d3:2b:
d6:8f:a7:d9:a4:93:20:09:9a:6b:26:71:65:bb:ff:dc:70:fb:
d9:5c:a2:34:c6:88:00:ec:51:8a:65:75:53:d4:18:a3:38:f5:
d3:61:14:7b:8f:e4:d2:b3:fe:39:45:7a:4d:ec:f5:35:61:d7:
22:9a:2c:1a:c8:d2:f7:d1:55:4d:02:83:cc:f0:fc:5c:32:a9:
49:d3:d2:2c:5a:c9:b8:9f:b5:d7:7f:3a:9a:b5:d8:55:9d
And the second CA certificate
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
02:ad:66:7e:4e:45:fe:5e:57:6f:3c:98:19:5e:dd:c0
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Validity
Not Before: Nov 9 00:00:00 1994 GMT
Not After : Jan 7 23:59:59 2010 GMT
Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1000 bit)
Modulus (1000 bit):
00:92:ce:7a:c1:ae:83:3e:5a:aa:89:83:57:ac:25:
01:76:0c:ad:ae:8e:2c:37:ce:eb:35:78:64:54:03:
e5:84:40:51:c9:bf:8f:08:e2:8a:82:08:d2:16:86:
37:55:e9:b1:21:02:ad:76:68:81:9a:05:a2:4b:c9:
4b:25:66:22:56:6c:88:07:8f:f7:81:59:6d:84:07:
65:70:13:71:76:3e:9b:77:4c:e3:50:89:56:98:48:
b9:1d:a7:29:1a:13:2e:4a:11:59:9c:1e:15:d5:49:
54:2c:73:3a:69:82:b1:97:39:9c:6d:70:67:48:e5:
dd:2d:d6:c8:1e:7b
Exponent: 65537 (0x10001)
Signature Algorithm: md2WithRSAEncryption
65:dd:7e:e1:b2:ec:b0:e2:3a:e0:ec:71:46:9a:19:11:b8:d3:
c7:a0:b4:03:40:26:02:3e:09:9c:e1:12:b3:d1:5a:f6:37:a5:
b7:61:03:b6:5b:16:69:3b:c6:44:08:0c:88:53:0c:6b:97:49:
c7:3e:35:dc:6c:b9:bb:aa:df:5c:bb:3a:2f:93:60:b6:a9:4b:
4d:f2:20:f7:cd:5f:7f:64:7b:8e:dc:00:5c:d7:fa:77:ca:39:
16:59:6f:0e:ea:d3:b5:83:7f:4d:4d:42:56:76:b4:c9:5f:04:
f8:38:f8:eb:d2:5f:75:5f:cd:7b:fc:e5:8e:80:7c:fc:50
After creating the CA, I made the SSL certificate (some data has been obscured).
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1a:b6:68:61:a3:c7:c5:ca:a0:b8:4f:09:c1:97:0e:f4
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Validity
Not Before: Apr 18 15:17:43 2007 GMT
Not After : Apr 17 15:17:43 2008 GMT
Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=###########., OU=#####, OU=Terms of use at www.verisign.com/rpa (c)00, CN=www.#######.nl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b5:b7:78:80:6f:a9:3d:d0:d8:99:8e:0c:d3:34:
f2:95:d5:1b:a4:30:44:45:6c:11:71:9b:dc:ae:b7:
3c:1e:0a:5b:81:2d:bd:e6:be:34:cb:7c:e2:de:5f:
20:1f:df:0d:36:ad:83:74:64:b7:52:34:10:f0:bd:
72:09:cf:31:84:77:81:c1:01:16:1d:a5:e9:58:27:
8f:f6:ea:20:15:04:e6:b9:40:d0:16:3f:b9:f3:cb:
06:75:9c:2c:93:d1:55:6e:04:f0:e1:43:6b:53:16:
39:ee:b3:84:62:02:eb:f8:f0:df:74:f4:da:6e:3a:
8a:6b:4a:ab:be:c1:16:9e:d3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
URI:http://crl.verisign.com/RSASecureServer.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.3
CPS: https://www.verisign.com/rpa;
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
Signature Algorithm: sha1WithRSAEncryption
87:d1:47:c7:ea:59:18:9c:8d:e6:17:53:9c:76:d4:fb:bb:ce:
ab:ab:3f:8a:a6:74:98:67:86:53:39:79:98:62:89:e5:07:27:
73:db:65:9f:10:8c:51:6e:ca:bc:cb:25:46:49:49:8f:0c:b4:
2c:f8:3b:47:95:c2:ba:8c:5e:d8:54:52:83:d5:4d:ed:b2:95:
0b:62:13:1e:9a:61:7c:97:b7:f9:02:52:7a:4f:7a:c6:19:f3:
80:3a:99:6e:27:5b:b2:b8:80:c1:43:d1:b9:0b:9f:02:26:9c:
50:39:a1:18:82:cd:cd:89:dd:ca:5e:e1:52:02:ab:bf:b1
The second CA is the real thing. The first one is the fake CA.
So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is). Or just infect him/her with a trojan to insert the CA for you.
The 'fun' part is that if you should replace the actual (original) VeriSign CA in your crypto store you get warnings/error messages which aren't very clear. The OS/Browser tries to 'tie' the SSL certificate to the CA, but not everything seems to add up :).