RE: MSCAPI integrity checks of CSPs - Downgrade Attack
- From: lelteto <lelteto@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 28 Jun 2006 08:44:02 -0700
One thing you can do (in your own application) is to go to the Registry, get
the CSP dll file name from the crypto provider entry the VERIFY the dll
yourself (not as much for signature / integrity - that's done by Windows -
but as for the VERSION info in it, which would tell you if it's YOUR DLL file
or not).
Laszlo Elteto
SafeNet, Inc.
"j-dog" wrote:
Agree, however....
locking down all clients and remote systems is operationally difficult and
expensive, especially for unmanaged workstations. It doesn't seem to be
practiced. It would seem like a security architecture that allows a simple
replacement of a dll or depends on a simple registry setting would not be
leveraged so heavily. A design that at initialization there was a mechanism
to check the integrity of the code that is being called to verify it is the
correct code would be part of this plug-in design from the beginning. No?
Thanks for the reply
"lelteto" wrote:
As you found the security of a system is the security of its weakest link.
1. If your users can change protected Registry entries you have a big
problem anyway. It means they have Admin rights.
2. An Admin can do a lot more than just change Registry (eg. it can patch
the advapi32.dll file to completely bypass CSP signature check so can install
absolutely rogue CSPs, too). If you really need FIPS solution you would need
a FIPS SYSTEM (not just a tiny part of the system FIPS certified). The only
way to do that is to LOCK DOWN the computer configuration.
Laszlo Elteto
Safenet, Inc.
"j-dog" wrote:
Can someone please tell me that this is not so easy to circumvent?
I have a FIPS 140-2 certified solution that uses a signed CSP:
CSP Name: MyCertifiedCSP
CSP dll: /mycertcsp.dll
I configure certificate server templates or xenroll to only issue
certificates to the CSP named "MyCertifiedCSP". In this way I know all
500,000 client machines have private keys protected by my FIPS certified CSP.
What I have found is that a simple registry hack I can completely circumvent
this and the end user and IT will never know. If I change the registry to
the following:
CSP name: MyCertifiedCSP
CSP dll: /rsaenh.dll
or
if I simply rename rsaenh.dll to mycertcsp.dll
In either case the keys are generated by the rsaenh.dll and are protected to
a lower security level. This downgrade attack is simple. Are there any
mechanisms within the MSCAPI so that I can check the integrity of the actual
dll used?
Comments? Thanks.
- Prev by Date: Re: What is generating the values for this key?
- Next by Date: CryptQueryObject, Need help in compiling the MSDN sample code.
- Previous by thread: Re: CryptCreateHash() with SHA2?
- Next by thread: CryptQueryObject, Need help in compiling the MSDN sample code.
- Index(es):
Relevant Pages
|
|
