|
|
|
date: Wed, 4 Jun 2008 13:51:02 -0700,
group: microsoft.public.platformsdk.security
back
Re: how to avoid spoofing of system dlls
"Kellie Fitton" wrote:
> On Jun 4, 1:51 pm, dan clarke
> wrote:
> > Hi,
> >
> > i'm working on a directshow application and I want to ensure that the dlls I
> > load into my memory space cannot be spoofed. For the dlls I control this is
> > possible via signatures etc, but for dlls that are part of the system this is
> > not possible; a subsequent windows update could break such a mechanism
> >
> > So is there a secure way I can bind to operating system functions when a
> > hacker controls the system? e.g. how can I be sure that the when I call
> > winverifytrust() that it calls the real version and not some spoofed version
> > hiding in a fake wintrust.dll injected by the attacker?
>
>
>
> Hi,
>
> Windows's system files donot contain embedded signatures,
> they are signed. If you want to verify the signed files
> you need to calculate the SHA1 hash value of a system file,
> then use the catalog file that contains this hash to verify the
> system files. You can use the following APIs to accomplish
> this task:
>
> CryptCATAdminAcquireContext()
>
> CryptCATAdminCalcHashFromFileHandle()
>
> CryptCATAdminEnumCatalogFromHash()
>
> CryptCATCatalogInfoFromContext()
>
> CryptCATAdminResolveCatalogPath()
>
> CryptCATAdminRemoveCatalog()
>
> CryptCATAdminReleaseContext()
>
>
> http://support.microsoft.com/kb/841290
>
> http://msdn.microsoft.com/en-us/library/aa379889(VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/aa379891(VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/aa379892(VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/aa379898(VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/aa379896(VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/aa379895(VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/aa379894(VS.85).aspx
>
> Kellie.
>
>
Thanks, that's really good information - I think there's still some
elements of the problem unanswered though..
For instance, to use the functions you give I need to call LoadLibrary,
GetProcAddress and then functions in the wintrust.dll. If kernal.dll or
wintrust.dll is compromised then the results of the authentication process
could fail...
Also, if the attacker manages to inject another dll into my address space
(e.g. is there a windows equivalent of LD_PRELOAD, or maybe through the
detours mechanism) .. he could provide different definitions of these
functions. The dynamic linker current behaviour seems to be to bind to the
first function it sees when multiple dll provides the same symbol..
date: Thu, 5 Jun 2008 00:50:00 -0700
author: dan clarke
Re: how to avoid spoofing of system dlls
If the system kernel is compromised, you have absolutely no hope to verify
anything - not even YOUR dlls (as they can be compromised and your
verification code bypassed). It always depends on how targeted the attack is.
If you just want to show "due diligence" then you can
1. make sure you always use system dlls from the system directory (although
you can only use LoadLibrary if kernel32.dll is already persent - and if
that's compromised, you are out of luck)
2. as suggested, you can use signature verification and hope for the best.
(again, the attacker could have replaced the root certificates and can sign
anything - unless you are "hard wiring" your public keys into your code -
which is probably OK for your DLLs but not for system DLLs.
Laszlo Elteto
SafeNet, Inc.
"dan clarke" wrote:
>
>
> "Kellie Fitton" wrote:
>
> > On Jun 4, 1:51 pm, dan clarke
> > wrote:
> > > Hi,
> > >
> > > i'm working on a directshow application and I want to ensure that the dlls I
> > > load into my memory space cannot be spoofed. For the dlls I control this is
> > > possible via signatures etc, but for dlls that are part of the system this is
> > > not possible; a subsequent windows update could break such a mechanism
> > >
> > > So is there a secure way I can bind to operating system functions when a
> > > hacker controls the system? e.g. how can I be sure that the when I call
> > > winverifytrust() that it calls the real version and not some spoofed version
> > > hiding in a fake wintrust.dll injected by the attacker?
> >
> >
> >
> > Hi,
> >
> > Windows's system files donot contain embedded signatures,
> > they are signed. If you want to verify the signed files
> > you need to calculate the SHA1 hash value of a system file,
> > then use the catalog file that contains this hash to verify the
> > system files. You can use the following APIs to accomplish
> > this task:
> >
> > CryptCATAdminAcquireContext()
> >
> > CryptCATAdminCalcHashFromFileHandle()
> >
> > CryptCATAdminEnumCatalogFromHash()
> >
> > CryptCATCatalogInfoFromContext()
> >
> > CryptCATAdminResolveCatalogPath()
> >
> > CryptCATAdminRemoveCatalog()
> >
> > CryptCATAdminReleaseContext()
> >
> >
> > http://support.microsoft.com/kb/841290
> >
> > http://msdn.microsoft.com/en-us/library/aa379889(VS.85).aspx
> >
> > http://msdn.microsoft.com/en-us/library/aa379891(VS.85).aspx
> >
> > http://msdn.microsoft.com/en-us/library/aa379892(VS.85).aspx
> >
> > http://msdn.microsoft.com/en-us/library/aa379898(VS.85).aspx
> >
> > http://msdn.microsoft.com/en-us/library/aa379896(VS.85).aspx
> >
> > http://msdn.microsoft.com/en-us/library/aa379895(VS.85).aspx
> >
> > http://msdn.microsoft.com/en-us/library/aa379894(VS.85).aspx
> >
> > Kellie.
> >
> >
>
> Thanks, that's really good information - I think there's still some
> elements of the problem unanswered though..
>
> For instance, to use the functions you give I need to call LoadLibrary,
> GetProcAddress and then functions in the wintrust.dll. If kernal.dll or
> wintrust.dll is compromised then the results of the authentication process
> could fail...
>
> Also, if the attacker manages to inject another dll into my address space
> (e.g. is there a windows equivalent of LD_PRELOAD, or maybe through the
> detours mechanism) .. he could provide different definitions of these
> functions. The dynamic linker current behaviour seems to be to bind to the
> first function it sees when multiple dll provides the same symbol..
>
date: Thu, 5 Jun 2008 09:52:00 -0700
author: lelteto
Re: how to avoid spoofing of system dlls
I dont agree that it would be impossible... If microsoft signed all their
dlls then we could hide the microsoft public key in our code, and we could
check that the system dll corressponded with its hash, and that the hash was
signed with microsofts key.. To beat this scheme an attacker would have to
find and change microsofts public key in our code and this can be made a
difficult problem
The first responder spoke of a catalog of hashs, is this catalog signed by
Microsoft I wonder? If it was then that would solve the trust issue on
system dlls but it would still leave the problem of api hooking ...
Anyone have any idea how to protect against a hacker gaining access to an
application's secrets by api hooking system dlls?
"lelteto" wrote:
> If the system kernel is compromised, you have absolutely no hope to verify
> anything - not even YOUR dlls (as they can be compromised and your
> verification code bypassed). It always depends on how targeted the attack is.
>
> If you just want to show "due diligence" then you can
> 1. make sure you always use system dlls from the system directory (although
> you can only use LoadLibrary if kernel32.dll is already persent - and if
> that's compromised, you are out of luck)
> 2. as suggested, you can use signature verification and hope for the best.
> (again, the attacker could have replaced the root certificates and can sign
> anything - unless you are "hard wiring" your public keys into your code -
> which is probably OK for your DLLs but not for system DLLs.
>
> Laszlo Elteto
> SafeNet, Inc.
>
> "dan clarke" wrote:
>
> >
> >
> > "Kellie Fitton" wrote:
> >
> > > On Jun 4, 1:51 pm, dan clarke
> > > wrote:
> > > > Hi,
> > > >
> > > > i'm working on a directshow application and I want to ensure that the dlls I
> > > > load into my memory space cannot be spoofed. For the dlls I control this is
> > > > possible via signatures etc, but for dlls that are part of the system this is
> > > > not possible; a subsequent windows update could break such a mechanism
> > > >
> > > > So is there a secure way I can bind to operating system functions when a
> > > > hacker controls the system? e.g. how can I be sure that the when I call
> > > > winverifytrust() that it calls the real version and not some spoofed version
> > > > hiding in a fake wintrust.dll injected by the attacker?
> > >
> > >
> > >
> > > Hi,
> > >
> > > Windows's system files donot contain embedded signatures,
> > > they are signed. If you want to verify the signed files
> > > you need to calculate the SHA1 hash value of a system file,
> > > then use the catalog file that contains this hash to verify the
> > > system files. You can use the following APIs to accomplish
> > > this task:
> > >
> > > CryptCATAdminAcquireContext()
> > >
> > > CryptCATAdminCalcHashFromFileHandle()
> > >
> > > CryptCATAdminEnumCatalogFromHash()
> > >
> > > CryptCATCatalogInfoFromContext()
> > >
> > > CryptCATAdminResolveCatalogPath()
> > >
> > > CryptCATAdminRemoveCatalog()
> > >
> > > CryptCATAdminReleaseContext()
> > >
> > >
> > > http://support.microsoft.com/kb/841290
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379889(VS.85).aspx
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379891(VS.85).aspx
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379892(VS.85).aspx
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379898(VS.85).aspx
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379896(VS.85).aspx
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379895(VS.85).aspx
> > >
> > > http://msdn.microsoft.com/en-us/library/aa379894(VS.85).aspx
> > >
> > > Kellie.
> > >
> > >
> >
> > Thanks, that's really good information - I think there's still some
> > elements of the problem unanswered though..
> >
> > For instance, to use the functions you give I need to call LoadLibrary,
> > GetProcAddress and then functions in the wintrust.dll. If kernal.dll or
> > wintrust.dll is compromised then the results of the authentication process
> > could fail...
> >
> > Also, if the attacker manages to inject another dll into my address space
> > (e.g. is there a windows equivalent of LD_PRELOAD, or maybe through the
> > detours mechanism) .. he could provide different definitions of these
> > functions. The dynamic linker current behaviour seems to be to bind to the
> > first function it sees when multiple dll provides the same symbol..
> >
date: Fri, 6 Jun 2008 01:43:00 -0700
author: dan clarke
Re: how to avoid spoofing of system dlls
Hi,
Just to say that it's not very difficult to change keys hidden in the code
and the experience have learned us that this is not a strong protection
scheme. Of course, you can invest hundreds of dollars on an anti-cracking
software but even with that you can never have a 100% assurance because with
enough time and money every software is breakable.
Regarding API hooking, you can not do much about it. Nowadays, there are
very powerful techniques that are publicly available. Moreover, many people
are starting to use "Wine" under Linux to run Windows applications in order
to better understand how they work and eventually bypass all there protection
schemes. This example shows you that if the system the application is running
on is compromised, then you can't protect your application effectively.
That being said, I'll be very happy if someone is able to find THE solution
that will help us as software developers in this task even if I'm not very
optimistic about that.
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
to reach : mounir_idrix_fr (replace the underscores with the at and dot
characters respectively)
"dan clarke" wrote:
> I dont agree that it would be impossible... If microsoft signed all their
> dlls then we could hide the microsoft public key in our code, and we could
> check that the system dll corressponded with its hash, and that the hash was
> signed with microsofts key.. To beat this scheme an attacker would have to
> find and change microsofts public key in our code and this can be made a
> difficult problem
>
> The first responder spoke of a catalog of hashs, is this catalog signed by
> Microsoft I wonder? If it was then that would solve the trust issue on
> system dlls but it would still leave the problem of api hooking ...
>
> Anyone have any idea how to protect against a hacker gaining access to an
> application's secrets by api hooking system dlls?
>
date: Fri, 6 Jun 2008 03:35:01 -0700
author: Mounir IDRASSI am
Re: how to avoid spoofing of system dlls
embedding somebody else's public key in your application is not a good idea:
if the vendor (in this case Microsoft) changes the key pair - which it does
from time to time - then your application would stop working and you would be
forced to send out updated application to everybody. That's why Microsoft
doesn't embed public keys in its code but uses the root certs installed in
the system.
Anyway, if a computer is compromised, there is little hope to protect your
code. And experience shows that if your application is worth something and it
is protected (software only), it WILL be cracked. (I've been working in the
software protection area in the past 22 years - so I have some experience...)
Laszlo Elteto
SafeNet, Inc.
"dan clarke" wrote:
> I dont agree that it would be impossible... If microsoft signed all their
> dlls then we could hide the microsoft public key in our code, and we could
> check that the system dll corressponded with its hash, and that the hash was
> signed with microsofts key.. To beat this scheme an attacker would have to
> find and change microsofts public key in our code and this can be made a
> difficult problem
>
> The first responder spoke of a catalog of hashs, is this catalog signed by
> Microsoft I wonder? If it was then that would solve the trust issue on
> system dlls but it would still leave the problem of api hooking ...
>
> Anyone have any idea how to protect against a hacker gaining access to an
> application's secrets by api hooking system dlls?
>
> "lelteto" wrote:
>
> > If the system kernel is compromised, you have absolutely no hope to verify
> > anything - not even YOUR dlls (as they can be compromised and your
> > verification code bypassed). It always depends on how targeted the attack is.
> >
> > If you just want to show "due diligence" then you can
> > 1. make sure you always use system dlls from the system directory (although
> > you can only use LoadLibrary if kernel32.dll is already persent - and if
> > that's compromised, you are out of luck)
> > 2. as suggested, you can use signature verification and hope for the best.
> > (again, the attacker could have replaced the root certificates and can sign
> > anything - unless you are "hard wiring" your public keys into your code -
> > which is probably OK for your DLLs but not for system DLLs.
> >
> > Laszlo Elteto
> > SafeNet, Inc.
> >
> > "dan clarke" wrote:
> >
> > >
> > >
> > > "Kellie Fitton" wrote:
> > >
> > > > On Jun 4, 1:51 pm, dan clarke
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > i'm working on a directshow application and I want to ensure that the dlls I
> > > > > load into my memory space cannot be spoofed. For the dlls I control this is
> > > > > possible via signatures etc, but for dlls that are part of the system this is
> > > > > not possible; a subsequent windows update could break such a mechanism
> > > > >
> > > > > So is there a secure way I can bind to operating system functions when a
> > > > > hacker controls the system? e.g. how can I be sure that the when I call
> > > > > winverifytrust() that it calls the real version and not some spoofed version
> > > > > hiding in a fake wintrust.dll injected by the attacker?
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Windows's system files donot contain embedded signatures,
> > > > they are signed. If you want to verify the signed files
> > > > you need to calculate the SHA1 hash value of a system file,
> > > > then use the catalog file that contains this hash to verify the
> > > > system files. You can use the following APIs to accomplish
> > > > this task:
> > > >
> > > > CryptCATAdminAcquireContext()
> > > >
> > > > CryptCATAdminCalcHashFromFileHandle()
> > > >
> > > > CryptCATAdminEnumCatalogFromHash()
> > > >
> > > > CryptCATCatalogInfoFromContext()
> > > >
> > > > CryptCATAdminResolveCatalogPath()
> > > >
> > > > CryptCATAdminRemoveCatalog()
> > > >
> > > > CryptCATAdminReleaseContext()
> > > >
> > > >
> > > > http://support.microsoft.com/kb/841290
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379889(VS.85).aspx
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379891(VS.85).aspx
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379892(VS.85).aspx
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379898(VS.85).aspx
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379896(VS.85).aspx
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379895(VS.85).aspx
> > > >
> > > > http://msdn.microsoft.com/en-us/library/aa379894(VS.85).aspx
> > > >
> > > > Kellie.
> > > >
> > > >
> > >
> > > Thanks, that's really good information - I think there's still some
> > > elements of the problem unanswered though..
> > >
> > > For instance, to use the functions you give I need to call LoadLibrary,
> > > GetProcAddress and then functions in the wintrust.dll. If kernal.dll or
> > > wintrust.dll is compromised then the results of the authentication process
> > > could fail...
> > >
> > > Also, if the attacker manages to inject another dll into my address space
> > > (e.g. is there a windows equivalent of LD_PRELOAD, or maybe through the
> > > detours mechanism) .. he could provide different definitions of these
> > > functions. The dynamic linker current behaviour seems to be to bind to the
> > > first function it sees when multiple dll provides the same symbol..
> > >
date: Fri, 6 Jun 2008 07:33:00 -0700
author: lelteto
|
|
