The audience for this post is quite limited - not many folks (relatively) use EMC's RSA DPM product. I'm gonna make NO effort to really describe how the RSA DPM system works. If you know the system, this will all make sense. If you do not, it probably won't though the general color and ideas should resonate. In addition, what I'm about to show is a known behavior -- the developer guides for the RSA DPM (at least for java) recommend the steps necessary to mitigate what I'm showing here. The c# and c++ guides make no mention of this that I could find, but the same behavior exists on those frameworks as well. What's not really called out clearly is what the risk entails.
The RSA DPM is a cryptography and key management solution for enterprises. The server-side manages cryptography keys, and clients obtain the keys when needed to perform crypto operations locally on the client. The clients do this by importing the necessary library files, and "registering" themselves with the server. The registration process essentially sets up a certificate-based authentication mechanism between client and server. Once registration is completed, a certificate and some "fingerprint" files are generated. At run-time, the client requests keys from the server over the authenticated channel using the certificate. The "fingerprint" files do some magic to ensure that the client system has not been changed in some way that might indicate compromise or movement of the client.
Here's the "weakness". If the "bad-guy" has read-only access to these registration files, it is a TRIVIAL matter to copy the files to another location on the same system and use the files to make perfectly valid calls to the RSA DPM server via a small custom application, accessing all the crypto keys that should (by intent) only be accessible to the orignal client application.
The example below is in java. You can do the same for c# or c++. The idea/approach is equally valid there. Our outline of activity:
1) Copy RSA DPM registration files to a new location on the original client that is write-able by the user.
2) Use a custom application making reference to these copied registration files to pull crypto keys from the RSA DPM server. This is NOT hard -- the RSA DPM client modules come pre-packaged with sample applications to help developers learn how to use the client. We'll just use one of these sample programs.
3) ??? Well, you now have crypto keys. That's not good for whoever the keys belong to. How you approach mitigating this is up to you and probably depends on how your business operates. It should be NO surprise that the "fix" for this problem is:
4) Lock down read access to the original client registration files. Only the application using these files needs access to them, so nothing/no one else should be able to read them. Basic security principles here. Lock. Down. Access.
Here is the process and minimal code samples that walk through the steps to access crypto keys. Whatever system you are on will almost certainly differ in the details, primarily paths and file names. But this should be enough to get the idea across. We're going to be demonstrating this on a *nix system running WebSphere that has an app incorporating the EMC RSA DPM. This assumes (as I've described above) that the bad guy has read access to the application files, and write/execute access to some path, somewhere, on the same server.
1) Copy all the "registration files" to a new writeable location. These files are (assuming the app developers follow the nomenclature of the RSA DPM examples).
*.p12
*.bin
*.cache
Optionally, copy the RSA DPM client jar files, too. You can always just reference them in their existing location when you run your app later to extract keys.
2) Do some environment setup. Nothing fancy here, we're essentially just setting ourselves up for running java
export Java_Home=/apps/websphere/java/jre
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/apps/websphere/java/jre/bin:/apps/websphere/java/jre/bin/classic:/apps/websphere/java/jre/bin
export CLASSPATH=/home/usr/me/rsadpm/*.*
3) Execute one of the sample RSA DPM client apps, specifying the copied registration files. Note that I'm being a little obtuse here and NOT showing the small modifications made to the demo EncryptAndDecryptData code -- the changes from how this file is delivered from EMC are minor. Just change the path references, and update the the config file to reference the files you copied in step 1.
/apps/websphere/java/jre/bin/java -cp /home/usr/me/rsadpm:/home/usr/me/rsadpm/certj.jar:/home/usr/me/rsadpm/cryptoj.jar:/home/usr/me/rsadpm/cryptojFIPS.jar:/home/usr/me/rsadpm/kmsclient.jar:/home/usr/me/rsadpm/LB.jar:/home/usr/me/rsadpm/LBImpl.jar:/home/usr/me/rsadpm/log4j-1.2.15.jar:/home/usr/me/rsadpm/sslj.jar rkmjc.simpleapi.EncryptAndDecryptData
4) Here's what output looks like. In this, I'm simply encrypting/decrypting a hard-coded value using a key obtained from the server. It'd be just as easy to export the key to file or do whatever else you wanted.
Running Sample EncryptAndDecryptData
Plain Text:
0000: 31 32 33 34 31 32 33 34 31 32 33 34 31 32 33 34 [1234123412341234]
Cipher Text:
0000: 52 4b 4d 43 32 31 30 00 ff ff ff ff 00 00 00 05 [RKMC210.........]
0010: 75 75 69 64 00 00 00 00 10 16 68 f2 8c 96 ca 4a [uuid......h....J]
0020: 86 9c f4 f0 83 30 f6 9a db ff ff ff ff 00 00 00 [.....0..........]
0030: 05 6f 72 69 64 00 00 00 00 20 0b 76 58 dc 76 07 [.orid.... .vX.v.]
0040: 59 7e c5 9d f3 ba 66 cd f9 20 a2 fb 82 8f fd 2b [Y~....f.. .....+]
0050: 88 fe 1b 05 2e a8 a2 6c 63 2b ff ff ff ff 00 00 [.......lc+......]
0060: 00 05 63 73 75 6d 00 00 00 00 20 9f e4 86 dd 57 [..csum.... ....W]
0070: 2a 72 fa 9f cb 08 e6 d5 e8 79 14 89 3d a9 05 17 [*r.......y..=...]
0080: bd 03 94 b7 ea 9d 73 8a 07 3e f8 ce d8 18 71 e8 [......s..>....q.]
0090: 69 c3 02 16 90 65 56 ff 28 8f 29 d8 c3 63 85 6c [i....eV.(.)..c.l]
00a0: 30 1a c9 72 7a b3 15 d8 fe c6 5c [0..rz.....\ ]
Recovered Plain Text:
0000: 31 32 33 34 31 32 33 34 31 32 33 34 31 32 33 34 [1234123412341234]
Successful Ending EncryptAndDecryptData
So, what's the takeaway here? If you are using the EMC RSA DPM client, please be sure to lock down access to the DPM files -- NOTHING should be able to get to them that doesn't absolutely need them. Otherwise you open yourself to exfiltration of keys.
The RSA DPM is a cryptography and key management solution for enterprises. The server-side manages cryptography keys, and clients obtain the keys when needed to perform crypto operations locally on the client. The clients do this by importing the necessary library files, and "registering" themselves with the server. The registration process essentially sets up a certificate-based authentication mechanism between client and server. Once registration is completed, a certificate and some "fingerprint" files are generated. At run-time, the client requests keys from the server over the authenticated channel using the certificate. The "fingerprint" files do some magic to ensure that the client system has not been changed in some way that might indicate compromise or movement of the client.
Here's the "weakness". If the "bad-guy" has read-only access to these registration files, it is a TRIVIAL matter to copy the files to another location on the same system and use the files to make perfectly valid calls to the RSA DPM server via a small custom application, accessing all the crypto keys that should (by intent) only be accessible to the orignal client application.
The example below is in java. You can do the same for c# or c++. The idea/approach is equally valid there. Our outline of activity:
1) Copy RSA DPM registration files to a new location on the original client that is write-able by the user.
2) Use a custom application making reference to these copied registration files to pull crypto keys from the RSA DPM server. This is NOT hard -- the RSA DPM client modules come pre-packaged with sample applications to help developers learn how to use the client. We'll just use one of these sample programs.
3) ??? Well, you now have crypto keys. That's not good for whoever the keys belong to. How you approach mitigating this is up to you and probably depends on how your business operates. It should be NO surprise that the "fix" for this problem is:
4) Lock down read access to the original client registration files. Only the application using these files needs access to them, so nothing/no one else should be able to read them. Basic security principles here. Lock. Down. Access.
Here is the process and minimal code samples that walk through the steps to access crypto keys. Whatever system you are on will almost certainly differ in the details, primarily paths and file names. But this should be enough to get the idea across. We're going to be demonstrating this on a *nix system running WebSphere that has an app incorporating the EMC RSA DPM. This assumes (as I've described above) that the bad guy has read access to the application files, and write/execute access to some path, somewhere, on the same server.
1) Copy all the "registration files" to a new writeable location. These files are (assuming the app developers follow the nomenclature of the RSA DPM examples).
*.p12
*.bin
*.cache
Optionally, copy the RSA DPM client jar files, too. You can always just reference them in their existing location when you run your app later to extract keys.
2) Do some environment setup. Nothing fancy here, we're essentially just setting ourselves up for running java
export Java_Home=/apps/websphere/java/jre
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/apps/websphere/java/jre/bin:/apps/websphere/java/jre/bin/classic:/apps/websphere/java/jre/bin
export CLASSPATH=/home/usr/me/rsadpm/*.*
3) Execute one of the sample RSA DPM client apps, specifying the copied registration files. Note that I'm being a little obtuse here and NOT showing the small modifications made to the demo EncryptAndDecryptData code -- the changes from how this file is delivered from EMC are minor. Just change the path references, and update the the config file to reference the files you copied in step 1.
/apps/websphere/java/jre/bin/java -cp /home/usr/me/rsadpm:/home/usr/me/rsadpm/certj.jar:/home/usr/me/rsadpm/cryptoj.jar:/home/usr/me/rsadpm/cryptojFIPS.jar:/home/usr/me/rsadpm/kmsclient.jar:/home/usr/me/rsadpm/LB.jar:/home/usr/me/rsadpm/LBImpl.jar:/home/usr/me/rsadpm/log4j-1.2.15.jar:/home/usr/me/rsadpm/sslj.jar rkmjc.simpleapi.EncryptAndDecryptData
4) Here's what output looks like. In this, I'm simply encrypting/decrypting a hard-coded value using a key obtained from the server. It'd be just as easy to export the key to file or do whatever else you wanted.
Running Sample EncryptAndDecryptData
Plain Text:
0000: 31 32 33 34 31 32 33 34 31 32 33 34 31 32 33 34 [1234123412341234]
Cipher Text:
0000: 52 4b 4d 43 32 31 30 00 ff ff ff ff 00 00 00 05 [RKMC210.........]
0010: 75 75 69 64 00 00 00 00 10 16 68 f2 8c 96 ca 4a [uuid......h....J]
0020: 86 9c f4 f0 83 30 f6 9a db ff ff ff ff 00 00 00 [.....0..........]
0030: 05 6f 72 69 64 00 00 00 00 20 0b 76 58 dc 76 07 [.orid.... .vX.v.]
0040: 59 7e c5 9d f3 ba 66 cd f9 20 a2 fb 82 8f fd 2b [Y~....f.. .....+]
0050: 88 fe 1b 05 2e a8 a2 6c 63 2b ff ff ff ff 00 00 [.......lc+......]
0060: 00 05 63 73 75 6d 00 00 00 00 20 9f e4 86 dd 57 [..csum.... ....W]
0070: 2a 72 fa 9f cb 08 e6 d5 e8 79 14 89 3d a9 05 17 [*r.......y..=...]
0080: bd 03 94 b7 ea 9d 73 8a 07 3e f8 ce d8 18 71 e8 [......s..>....q.]
0090: 69 c3 02 16 90 65 56 ff 28 8f 29 d8 c3 63 85 6c [i....eV.(.)..c.l]
00a0: 30 1a c9 72 7a b3 15 d8 fe c6 5c [0..rz.....\ ]
Recovered Plain Text:
0000: 31 32 33 34 31 32 33 34 31 32 33 34 31 32 33 34 [1234123412341234]
Successful Ending EncryptAndDecryptData
So, what's the takeaway here? If you are using the EMC RSA DPM client, please be sure to lock down access to the DPM files -- NOTHING should be able to get to them that doesn't absolutely need them. Otherwise you open yourself to exfiltration of keys.
No comments:
Post a Comment