|
|
|
date: Tue, 6 Dec 2005 10:02:15 +0100,
group: microsoft.public.platformsdk.com_ole
back
Re: Authenticode check on a DCOM component
"Jan Spooren" <jspooren@nospam.nospam> wrote in message
news:eCxRCPk%23FHA.2324@TK2MSFTNGP11.phx.gbl
> We are building an application in which it is important that client
> components can verify the authenticity of the server component, in
> order to prevent a 'man-in-the-middle' attack, where an adversary
> could create a COM component with the same signature (Guid, TypeLib)
> as the real server component.
> The server component that we want to verify the integrity of is a
> Service, running under SYSTEM credentials. The way we do this on a
> single machine is by looking up the LocalServer32 registry key and
> then performing an Authenticode check on the component's .exe file.
> Only if this check succeeds, and the component has been signed with
> the private key belonging to the public key we have (obfuscated) in
> the client we call CoCreateInstance().
Wait a minute. Are you saying somebody might have a privileged enough
access to your machine to be able to replace a service executable? But
somehow you still trust the authenticity of your client executable.
What's to stop that attacker to simply insert a jump around your
verification code straight to CoCreateInstance? Or hook CoCreateInstance
so that, when a particular CLSID is requested, it instantiates a
malicious server rather than the one listed in the registry?
As a simpler attack, I wonder if you are checking for the presence of
TreatAs key under your CLSID.
> Now we would like to do something similar for DCOM use: Before a
> client calls the server component (running on a different computer)
> it should verify the integrity of the server component.
>
> Could someone please confirm to me (or correct me) that no standard
> solution exists to verify the authenticity of a DCOM component before
> calling the component?
Not as far as I know. I believe you can ensure the authenticity of the
remote machine - essentially, that the domain controller believes the
machine is who it says it is. But I don't see how you can validate the
integrity of the executable running on a remote machine.
For crypto solutions to work, the remote agent needs to know some
secret, and you then verify that it indeed knows that secret. But no
part of Authenticode signature is secret, so it alone cannot be used for
remote authentication where you cannot physically examine the bits of
the executable.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Tue, 6 Dec 2005 08:18:29 -0500
author: Igor Tandetnik
Re: Authenticode check on a DCOM component
Thanks Igor for your feedback!
That's indeed what I thought too.
FYI, what stops an attacker to bypass the verification code is that in the
local machine scenario, that code in question is a Cryptographic Service
Provider, which in turn is signed by Microsoft, and which won't work when
patched. This is one of the very few scenarios where such a verification
mechanism really makes sense. :-)
In the remote scenario, this is a management application that can be used to
manage smart cards remotely. But since you cannot know who the other
component is (in the case that the user has admin rights) we will need to
pass through challenges from the smart card right up to the management
station to make this secure.
Thanks,
Jan.
"Igor Tandetnik" wrote in message
news:uOPLJem%23FHA.2520@TK2MSFTNGP15.phx.gbl...
> "Jan Spooren" <jspooren@nospam.nospam> wrote in message
> news:eCxRCPk%23FHA.2324@TK2MSFTNGP11.phx.gbl
>> We are building an application in which it is important that client
>> components can verify the authenticity of the server component, in
>> order to prevent a 'man-in-the-middle' attack, where an adversary
>> could create a COM component with the same signature (Guid, TypeLib)
>> as the real server component.
>> The server component that we want to verify the integrity of is a
>> Service, running under SYSTEM credentials. The way we do this on a
>> single machine is by looking up the LocalServer32 registry key and
>> then performing an Authenticode check on the component's .exe file. Only
>> if this check succeeds, and the component has been signed with
>> the private key belonging to the public key we have (obfuscated) in
>> the client we call CoCreateInstance().
>
> Wait a minute. Are you saying somebody might have a privileged enough
> access to your machine to be able to replace a service executable? But
> somehow you still trust the authenticity of your client executable. What's
> to stop that attacker to simply insert a jump around your verification
> code straight to CoCreateInstance? Or hook CoCreateInstance so that, when
> a particular CLSID is requested, it instantiates a malicious server rather
> than the one listed in the registry?
>
> As a simpler attack, I wonder if you are checking for the presence of
> TreatAs key under your CLSID.
>
>> Now we would like to do something similar for DCOM use: Before a
>> client calls the server component (running on a different computer)
>> it should verify the integrity of the server component.
>>
>> Could someone please confirm to me (or correct me) that no standard
>> solution exists to verify the authenticity of a DCOM component before
>> calling the component?
>
> Not as far as I know. I believe you can ensure the authenticity of the
> remote machine - essentially, that the domain controller believes the
> machine is who it says it is. But I don't see how you can validate the
> integrity of the executable running on a remote machine.
>
> For crypto solutions to work, the remote agent needs to know some secret,
> and you then verify that it indeed knows that secret. But no part of
> Authenticode signature is secret, so it alone cannot be used for remote
> authentication where you cannot physically examine the bits of the
> executable.
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
date: Tue, 6 Dec 2005 15:01:17 +0100
author: Jan Spooren am
Re: Authenticode check on a DCOM component
Jan Spooren <jspooren@nospam.nospam> wrote:
> Thanks Igor for your feedback!
>
> That's indeed what I thought too.
> FYI, what stops an attacker to bypass the verification code is that
> in the local machine scenario, that code in question is a
> Cryptographic Service Provider, which in turn is signed by Microsoft,
> and which won't work when patched.
An attacker having unrestricted access to the machine could patch the OS
files that perform the checking. Or sign the modified executable with
her own certificate, then install it as trusted.
Come to think of it, what secrets does your client keep that the
attacker cannot just extract from the client executable, and has to go
to the trouble of spoofing the server? What can you possibly have access
to that an attacker cannot directly lay her hands on? Again, your
assumption is that the attacker has unrestricted access to, and
presumably physical possession of, the machine you are running on.
Are you running on some kind of Trusted Computing platform, with crypto
performed in hardware? As far as I know, nothing short of that can
secure a machine to which an adversary has unrestricted access.
> This is one of the very few
> scenarios where such a verification mechanism really makes sense. :-)
> In the remote scenario, this is a management application that can be
> used to manage smart cards remotely. But since you cannot know who
> the other component is (in the case that the user has admin rights)
> we will need to pass through challenges from the smart card right up
> to the management station to make this secure.
I guess. Sounds somewhat similar to SSL tunneling. Make sure your
protocol is resistant to man-in-the-middle and replay attacks.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Tue, 6 Dec 2005 11:15:32 -0500
author: Igor Tandetnik
|
|
