hi all,
is there is kernel API that lets me know the loaded DLLs in a user mode
process from kernel drivers? I want to use this method to detect if an
attacker is injecting a DDL into my process.
Thanks
AP
On Mon, Jan 5, 2009 at 9:41 AM, A P wrote:
> hi all,
>
> is there is kernel API that lets me know the loaded DLLs in a user mode
> process from kernel drivers? I want to use this method to detect if an
> attacker is injecting a DDL into my process.
>
I don’t think that there is any kernel API.
Only thing you can do is that get the PEB address of your process (which is
a constant address before XP SP2).
In PEB you can find list of all loaded modules in the process.
But with this method you will get only the information about loaded DLLs.
If you want to get control before DLL gets loaded, try hooking LoadLibrary
(in user space).
I guess you can also hook “LdrInitializeThunk” in NTDLL (I am not sure
whether LoadLibray calls LdrInitializeThunk) to get the control before DLL
gets loaded.
Again there can be many methods. Above methods will require structure of
PEB and other windows internal structure definitions
which vary from one windows version to another (sometimes in between service
packs too).
What do you want to exactly do “Detect the loading of DLLs into your
process?”
or “Preventing the loading of DLLs into your process?”
> Thanks
>
> AP
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Well, I’ve never used it, but it sounds like
‘AuxKlibQueryModuleInformation’ might do what you want.
‘The Auxiliary Kernel-Mode Library enables drivers to access some system
capabilities that are not available from kernel-mode subsystems.’
The docs don’t say whether it works with user mode modules or not, so if
you’re interested, you’ll have to give it a try, though I imagine that
someone out there knows the answer to this and will be along later this
morning with a better answer. In particular, if memory serves me
correctly, I’m pretty sure that Doron has mentioned this one a few
times, and as in most other cases, I imagine he knows the definitive answer.
That being said, in my personal opinion, any security technique that
relies on image name is fundamentally broken. Unless your attacker is
completely unaware of yours or others’ efforts to thwart him or her, or
is just a moron, it’s trivial to circumvent, so while it’s quite
effective and easy to implement for any one specific case in which you
are ‘correct,’ as long as they can respond to your measures, I don’t see
a lot of upside to the approach. On the other side of this coin, if you
are unaware of the identity and up to the minute MO of your attacker -
which is the vastly overwhelmingly more common case, because damn close
to no one really has active attackers out there in any numbers that are
chartable, and certainly not coordinated ones - you’re not likely to be
effective without also incurring collateral damage that come with false
positives. I imagine what you know is the name of one or more hostile
dll’s, but that’s not necessarily the same think as the identity of your
attacker. In my personal opinion, the identity problem is not
addressable in the general case, even assuming that your attackers are
forthright about who they are, though there are some rare cases where
you have to just do the best you can, but I would not personally
consider, say, licensing, one of them, if that applies. Even if you
work it out well enough, the thing is you may still very well piss the
user off, either by crashing their machine or quite likely breaking
their other stuff, which really isn’t yours to mess with to begin with,
in my personal opinion. Moreover, if you have a real advesary worth his
or her salt, there are plenty of situations where a DOS style attack is
just as effective or at least better than nothing, and using a technique
like this one in the presence of such an advesary is just begging for it.
Good luck,
mm
A P wrote:
hi all,
is there is kernel API that lets me know the loaded DLLs in a user mode
process from kernel drivers? I want to use this method to detect if an
attacker is injecting a DDL into my process.Thanks
AP
>>I want to use this method to detect if an attacker is injecting a DDL into my process.
You will only detect that whether a DLL is already injected or not at a given point of time. This technique will not going to help if you want to detect and react as soon as someone tries to inject a dll.
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Well, I’ve never used it, but it sounds like
> ‘AuxKlibQueryModuleInformation’ might do what you want.
>
> ‘The Auxiliary Kernel-Mode Library enables drivers to access some system
> capabilities that are not available from kernel-mode subsystems.’
>
> The docs don’t say whether it works with user mode modules or not,
It doesn’t, it only finds kernel modules. It’s just a wrapper around
ZwQuerySystemInformation with SystemModuleInformation. What may be of help
is the PsSetLoadImageNotifyRoutine or the undocumented
RtlQueryProcessDebugInformation.
//Daniel
On Mon, Jan 5, 2009 at 3:36 PM, wrote:
> “Martin O’Brien” wrote in message
> news:xxxxx@ntdev…
>
>> Well, I’ve never used it, but it sounds like
>> ‘AuxKlibQueryModuleInformation’ might do what you want.
>>
>> ‘The Auxiliary Kernel-Mode Library enables drivers to access some system
>> capabilities that are not available from kernel-mode subsystems.’
>>
>> The docs don’t say whether it works with user mode modules or not,
>>
>
> It doesn’t, it only finds kernel modules. It’s just a wrapper around
> ZwQuerySystemInformation with SystemModuleInformation. What may be of help
> is the PsSetLoadImageNotifyRoutine or the undocumented
> RtlQueryProcessDebugInformation.
Does “PsSetLoadImageNotifyRoutine” gives you the control before image has
been loaded and initialized?
or it is just a notification and does not guarantee that image is not
already loaded.
>
> //Daniel
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
“Deepak Gupta” wrote in message news:xxxxx@ntdev…
> Does “PsSetLoadImageNotifyRoutine” gives you the control before image has
> been loaded and initialized?
>or it is just a notification and does not guarantee that image is not
already loaded.
The doc says: "is called whenever an executable image is mapped into virtual
memory, whether in system space or user space, before the execution of the
image begins. ". It doesn’t say in what thread context this is called and
what are the locks held at this point and how much “control” you have here.
There was another thread about this a few days ago. But I’m quite confident
that without too much research and engineering efforts you will be able to
block the image from executing.
//Daniel
folks,
thanks for all the replies. i wanted to know the injection because i want to
protect my process and i wanted to protect my driver from the attacked
process. There seems t be no way to guarentee that the caller is who is
claims.
If I go for challenge response between the driver and the app, then I need
to ensure that the app’s private key(or driver’s) is not compromised. There
is no way to do that, as long as the species called ‘debuggers’ and
‘disassemblers’ are alive. If any one of you know how to get challenge
response right, please let me know.
So my solution, try to catch a dll injection ‘also’ with challenge response
and proper ACL/ACE. BTW, I was thinking, why not at install time create a
seperate account in the system that has privileges equiv to SYSTEM a/c (>
admin) and install my app (which is a service) and the driver thru it. Also
set the Driver’s ACLs so that only system a/c can access it (my the app is a
service). Do you people think, it will make it a wee bit more secure?
thanks
AP
On Mon, Jan 5, 2009 at 2:59 AM, wrote:
> “Deepak Gupta” wrote in message news:xxxxx@ntdev…
>
>
>> Does “PsSetLoadImageNotifyRoutine” gives you the control before image has
>> been loaded and initialized?
>>
> >or it is just a notification and does not guarantee that image is not
> already loaded.
>
>
> The doc says: "is called whenever an executable image is mapped into
> virtual memory, whether in system space or user space, before the execution
> of the image begins. ". It doesn’t say in what thread context this is
> called and what are the locks held at this point and how much “control” you
> have here. There was another thread about this a few days ago. But I’m quite
> confident that without too much research and engineering efforts you will be
> able to block the image from executing.
>
>
> //Daniel
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
folks,
thanks for all the replies. i wanted to know the injection because i
want
to protect my process and i wanted to protect my driver from the
attacked
process. There seems t be no way to guarentee that the caller is who
is
claims.If I go for challenge response between the driver and the app, then I
need
to ensure that the app’s private key(or driver’s) is not compromised.
There is no way to do that, as long as the species called ‘debuggers’
and
‘disassemblers’ are alive. If any one of you know how to get challenge
response right, please let me know.So my solution, try to catch a dll injection ‘also’ with challenge
response and proper ACL/ACE. BTW, I was thinking, why not at install
time
create a seperate account in the system that has privileges equiv to
SYSTEM a/c (> admin) and install my app (which is a service) and the
driver thru it. Also set the Driver’s ACLs so that only system a/c can
access it (my the app is a service). Do you people think, it will make
it
a wee bit more secure?
If yours is a custom solution for your use only, and nobody wants to
‘attack’ you in particular then you are probably safe.
If you are developing a solution to sell far and wide, and the ‘bad
guys’ get a copy to play with, they’ll find a way of subverting it. It
only has to be broken once.
James
Of course, an attacker could just call SetThreadContext or WriteProcessMemory directly. If the OP is running under the same security context as their adversary, then they’ve already lost.
? S
From: Deepak Gupta
Sent: Monday, January 05, 2009 00:40
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] against rootkits
On Mon, Jan 5, 2009 at 9:41 AM, A P > wrote:
hi all,
is there is kernel API that lets me know the loaded DLLs in a user mode process from kernel drivers? I want to use this method to detect if an attacker is injecting a DDL into my process.
I don’t think that there is any kernel API.
Only thing you can do is that get the PEB address of your process (which is a constant address before XP SP2).
In PEB you can find list of all loaded modules in the process.
But with this method you will get only the information about loaded DLLs.
If you want to get control before DLL gets loaded, try hooking LoadLibrary (in user space).
I guess you can also hook “LdrInitializeThunk” in NTDLL (I am not sure whether LoadLibray calls LdrInitializeThunk) to get the control before DLL gets loaded.
Again there can be many methods. Above methods will require structure of PEB and other windows internal structure definitions
which vary from one windows version to another (sometimes in between service packs too).
What do you want to exactly do “Detect the loading of DLLs into your process?”
or “Preventing the loading of DLLs into your process?”
Thanks
AP
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
AuxKlib is just kernel mode modules.
? S
-----Original Message-----
From: Martin O’Brien
Sent: Monday, January 05, 2009 00:49
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] against rootkits
Well, I’ve never used it, but it sounds like
‘AuxKlibQueryModuleInformation’ might do what you want.
‘The Auxiliary Kernel-Mode Library enables drivers to access some system
capabilities that are not available from kernel-mode subsystems.’
The docs don’t say whether it works with user mode modules or not, so if
you’re interested, you’ll have to give it a try, though I imagine that
someone out there knows the answer to this and will be along later this
morning with a better answer. In particular, if memory serves me
correctly, I’m pretty sure that Doron has mentioned this one a few
times, and as in most other cases, I imagine he knows the definitive answer.
That being said, in my personal opinion, any security technique that
relies on image name is fundamentally broken. Unless your attacker is
completely unaware of yours or others’ efforts to thwart him or her, or
is just a moron, it’s trivial to circumvent, so while it’s quite
effective and easy to implement for any one specific case in which you
are ‘correct,’ as long as they can respond to your measures, I don’t see
a lot of upside to the approach. On the other side of this coin, if you
are unaware of the identity and up to the minute MO of your attacker -
which is the vastly overwhelmingly more common case, because damn close
to no one really has active attackers out there in any numbers that are
chartable, and certainly not coordinated ones - you’re not likely to be
effective without also incurring collateral damage that come with false
positives. I imagine what you know is the name of one or more hostile
dll’s, but that’s not necessarily the same think as the identity of your
attacker. In my personal opinion, the identity problem is not
addressable in the general case, even assuming that your attackers are
forthright about who they are, though there are some rare cases where
you have to just do the best you can, but I would not personally
consider, say, licensing, one of them, if that applies. Even if you
work it out well enough, the thing is you may still very well piss the
user off, either by crashing their machine or quite likely breaking
their other stuff, which really isn’t yours to mess with to begin with,
in my personal opinion. Moreover, if you have a real advesary worth his
or her salt, there are plenty of situations where a DOS style attack is
just as effective or at least better than nothing, and using a technique
like this one in the presence of such an advesary is just begging for it.
Good luck,
mm
A P wrote:
> hi all,
>
> is there is kernel API that lets me know the loaded DLLs in a user mode
> process from kernel drivers? I want to use this method to detect if an
> attacker is injecting a DDL into my process.
>
> Thanks
>
> AP
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Only if an attacker doesn’t have administrator or physical access to the computer.
If you are trying to “defend” your program against the computer owner, then you’re wasting your time.
? S
From: A P
Sent: Monday, January 05, 2009 03:52
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] against rootkits
folks,
thanks for all the replies. i wanted to know the injection because i want to protect my process and i wanted to protect my driver from the attacked process. There seems t be no way to guarentee that the caller is who is claims.
If I go for challenge response between the driver and the app, then I need to ensure that the app’s private key(or driver’s) is not compromised. There is no way to do that, as long as the species called ‘debuggers’ and ‘disassemblers’ are alive. If any one of you know how to get challenge response right, please let me know.
So my solution, try to catch a dll injection ‘also’ with challenge response and proper ACL/ACE. BTW, I was thinking, why not at install time create a seperate account in the system that has privileges equiv to SYSTEM a/c (> admin) and install my app (which is a service) and the driver thru it. Also set the Driver’s ACLs so that only system a/c can access it (my the app is a service). Do you people think, it will make it a wee bit more secure?
thanks
AP
On Mon, Jan 5, 2009 at 2:59 AM, > wrote:
“Deepak Gupta” > wrote in message news:xxxxx@ntdev…
Does “PsSetLoadImageNotifyRoutine” gives you the control before image has been loaded and initialized?
>or it is just a notification and does not guarantee that image is not already loaded.
The doc says: "is called whenever an executable image is mapped into virtual memory, whether in system space or user space, before the execution of the image begins. ". It doesn’t say in what thread context this is called and what are the locks held at this point and how much “control” you have here. There was another thread about this a few days ago. But I’m quite confident that without too much research and engineering efforts you will be able to block the image from executing.
//Daniel
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
It is a common myth that it is possible to create protection mechanisms
that cannot be cracked. There is no such mechanism possible today. What is
possible is to raise the cost of the cracking to where it is no longer
cost-effective for the attacker. That said, many attackers simply take this
as a challenge: that it isn’t an issue of cost-effectiveness, it is a test
of their programmerhood to crack the security. They always win.
A friend of mine did a PhD dissertation in the 1970s, which boiled down to
“as long as executable programs exist as plaintext [meaning binary
instruction sequences that are unencrypted] in memory, there is no
security”. His dissertation was on building secure, real-time-decrypted
execution architectures, where the private key was built into each chip. It
is safe to assume that any alleged security mechanism is crackable; you only
have to deal with the cost-effectiveness of it.
The scheme you are proposing is so trivially crackable that it is not worth
worrying about… Unless you are somehow securing the private key in a
trusted computing base, it will be visible. And no mechanism that exists
outside the TCB kernel can protect you.
As pointed out already, anyone who has physical access to a machine can do
whatever they want, and anyone with admin privileges can do whatever they
want, and there is nothing you can do to stop them. Also note that while it
is more difficult in Vista to get privilege escalation, it is not impossible
(especially with social engineering), so consequently as long as systems
maintain the ability to create an administrative account or “runas” an
administrator, no protection schemes are going to be really effective.
What amazes me about people trying to invent security mechanisms is that I
see the same mistakes repeated, decade after decade. First rule: security
is extremely hard to achieve. Second rule: if you think rule 1 does not
apply, you are right. It is actually much harder that rule 1 would suggest.
Third rule: if you think you have a security mechanism that is going to
work, consult rule 1 and rule 2.
I worked with people in the 1970s and early 1980s that really, really cared
about security, and again in 2002. As long as there is physical access,
there is no security. For years, and possibly still, DoD would not allow
paging on secure computers (you could leak one bit of information by
changing the paging patterns of your program, e.g., “Will there be an attack
within 24 hours?”). When I was working with TCB people in 2002, I learned a
lot more about modern security techniques. I can tell you their reaction to
your proposed solution: “A waste of time. Trivial to crack. Next topic for
discussion?”
You cannot protect your process. I don’t even need a rootkit to examine
your driver, I can do that fairly trivially, and in fact this is a 30-minute
exercise for my students in my security course. And that’s to create a
nominally remote attack. A debugger means it is a 2-minute exercise to
figure out how to examine your driver. Windbg is a free download. The
download time of WinDbg is probably the major time factor in getting to your
driver code. Given that you already know this, what exactly are you trying
to protect?
Vendors learned years ago that the legal system (the EULA: no reverse
engineering, disassebly, etc.) is their only effective means to protect
their intellectual property, along with copyright and patent. There are no
good technological solutions to the problem.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, January 05, 2009 7:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] against rootkits
folks,
thanks for all the replies. i wanted to know the injection because i
want
to protect my process and i wanted to protect my driver from the
attacked
process. There seems t be no way to guarentee that the caller is who
is
claims.If I go for challenge response between the driver and the app, then I
need
to ensure that the app’s private key(or driver’s) is not compromised.
There is no way to do that, as long as the species called ‘debuggers’
and
‘disassemblers’ are alive. If any one of you know how to get challenge
response right, please let me know.So my solution, try to catch a dll injection ‘also’ with challenge
response and proper ACL/ACE. BTW, I was thinking, why not at install
time
create a seperate account in the system that has privileges equiv to
SYSTEM a/c (> admin) and install my app (which is a service) and the
driver thru it. Also set the Driver’s ACLs so that only system a/c can
access it (my the app is a service). Do you people think, it will make
it
a wee bit more secure?
If yours is a custom solution for your use only, and nobody wants to
‘attack’ you in particular then you are probably safe.
If you are developing a solution to sell far and wide, and the ‘bad guys’
get a copy to play with, they’ll find a way of subverting it. It only has to
be broken once.
James
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
A P wrote:
folks,
thanks for all the replies. i wanted to know the injection because i
want to protect my process and i wanted to protect my driver from the
attacked process. There seems t be no way to guarentee that the caller
is who is claims.If I go for challenge response between the driver and the app, then I
need to ensure that the app’s private key(or driver’s) is not
compromised. There is no way to do that, as long as the species called
‘debuggers’ and ‘disassemblers’ are alive. If any one of you know how to
get challenge response right, please let me know.
For this, you need something like a hardware TPM. Not easily doable.
–PA
is there is kernel API that lets me know the loaded DLLs in a user mode
process from kernel drivers? I want to use this method to detect if an
attacker is injecting a DDL into my process.
You will lose this battle. You cannot inspect the integrity of a system from
within the system itself. Anything you ask of the OS, a rootkit can provide
a forged answer to.
You cannot ensure the integrity of your process from within the process.
Period. It’s a losing battle. Don’t even try.
And if you’re worried about a rootkit that’s compromised the OS itself, then
you can’t rely on any process in the OS or running on the OS to ensure
integrity either.
This is a battle you can’t win. You’re wasting your time trying.
You never mentioned what is the purpose of all these? Are you developing
security software??. Have you defined or articulated the attack surface???
Or the scope and depth of security???
As already pointed out by many that there is no such “silver bullet”, but
security softwares does these kind of hardening,AFAIK …
-pro
On Mon, Jan 5, 2009 at 3:52 AM, A P wrote:
> folks,
> thanks for all the replies. i wanted to know the injection because i want
> to protect my process and i wanted to protect my driver from the attacked
> process. There seems t be no way to guarentee that the caller is who is
> claims.
>
> If I go for challenge response between the driver and the app, then I need
> to ensure that the app’s private key(or driver’s) is not compromised. There
> is no way to do that, as long as the species called ‘debuggers’ and
> ‘disassemblers’ are alive. If any one of you know how to get challenge
> response right, please let me know.
>
> So my solution, try to catch a dll injection ‘also’ with challenge response
> and proper ACL/ACE. BTW, I was thinking, why not at install time create a
> seperate account in the system that has privileges equiv to SYSTEM a/c (>
> admin) and install my app (which is a service) and the driver thru it. Also
> set the Driver’s ACLs so that only system a/c can access it (my the app is a
> service). Do you people think, it will make it a wee bit more secure?
>
> thanks
>
> AP
>
> On Mon, Jan 5, 2009 at 2:59 AM, wrote:
>
>> “Deepak Gupta” wrote in message
>> news:xxxxx@ntdev…
>>
>>> Does “PsSetLoadImageNotifyRoutine” gives you the control before image has
>>> been loaded and initialized?
>>>
>> >or it is just a notification and does not guarantee that image is not
>> already loaded.
>>
>>
>> The doc says: "is called whenever an executable image is mapped into
>> virtual memory, whether in system space or user space, before the execution
>> of the image begins. ". It doesn’t say in what thread context this is
>> called and what are the locks held at this point and how much “control” you
>> have here. There was another thread about this a few days ago. But I’m quite
>> confident that without too much research and engineering efforts you will be
>> able to block the image from executing.
>>
>>
>> //Daniel
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Joseph M. Newcomer wrote:
What amazes me about people trying to invent security mechanisms is that I
see the same mistakes repeated, decade after decade. First rule: security
is extremely hard to achieve. Second rule: if you think rule 1 does not
apply, you are right. It is actually much harder that rule 1 would suggest.
Third rule: if you think you have a security mechanism that is going to
work, consult rule 1 and rule 2.
This is an excellent summary of the situation. About 20% of the
questions on this list could be answered by pointing them to this
posting and requiring that it be memorized…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Very well put.
James
It is a common myth that it is possible to create protection
mechanisms
that cannot be cracked. There is no such mechanism possible today.
What
is
possible is to raise the cost of the cracking to where it is no longer
cost-effective for the attacker. That said, many attackers simply
take
this
as a challenge: that it isn’t an issue of cost-effectiveness, it is a
test
of their programmerhood to crack the security. They always win.A friend of mine did a PhD dissertation in the 1970s, which boiled
down to
“as long as executable programs exist as plaintext [meaning binary
instruction sequences that are unencrypted] in memory, there is no
security”. His dissertation was on building secure,
real-time-decrypted
execution architectures, where the private key was built into each
chip.
It
is safe to assume that any alleged security mechanism is crackable;
you
only
have to deal with the cost-effectiveness of it.The scheme you are proposing is so trivially crackable that it is not
worth
worrying about… Unless you are somehow securing the private key in a
trusted computing base, it will be visible. And no mechanism that
exists
outside the TCB kernel can protect you.As pointed out already, anyone who has physical access to a machine
can do
whatever they want, and anyone with admin privileges can do whatever
they
want, and there is nothing you can do to stop them. Also note that
while
it
is more difficult in Vista to get privilege escalation, it is not
impossible
(especially with social engineering), so consequently as long as
systems
maintain the ability to create an administrative account or “runas” an
administrator, no protection schemes are going to be really effective.What amazes me about people trying to invent security mechanisms is
that I
see the same mistakes repeated, decade after decade. First rule:
security
is extremely hard to achieve. Second rule: if you think rule 1 does
not
apply, you are right. It is actually much harder that rule 1 would
suggest.
Third rule: if you think you have a security mechanism that is going
to
work, consult rule 1 and rule 2.I worked with people in the 1970s and early 1980s that really, really
cared
about security, and again in 2002. As long as there is physical
access,
there is no security. For years, and possibly still, DoD would not
allow
paging on secure computers (you could leak one bit of information by
changing the paging patterns of your program, e.g., “Will there be an
attack
within 24 hours?”). When I was working with TCB people in 2002, I
learned
a
lot more about modern security techniques. I can tell you their
reaction
to
your proposed solution: “A waste of time. Trivial to crack. Next
topic
for
discussion?”You cannot protect your process. I don’t even need a rootkit to
examine
your driver, I can do that fairly trivially, and in fact this is a 30-
minute
exercise for my students in my security course. And that’s to create
a
nominally remote attack. A debugger means it is a 2-minute exercise
to
figure out how to examine your driver. Windbg is a free download.
The
download time of WinDbg is probably the major time factor in getting
to
your
driver code. Given that you already know this, what exactly are you
trying
to protect?Vendors learned years ago that the legal system (the EULA: no reverse
engineering, disassebly, etc.) is their only effective means to
protect
their intellectual property, along with copyright and patent. There
are
no
good technological solutions to the problem.
joe-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, January 05, 2009 7:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] against rootkits>
> folks,
> thanks for all the replies. i wanted to know the injection because i
want
> to protect my process and i wanted to protect my driver from the
attacked
> process. There seems t be no way to guarentee that the caller is who
is
> claims.
>
> If I go for challenge response between the driver and the app, then
I
need
> to ensure that the app’s private key(or driver’s) is not
compromised.
> There is no way to do that, as long as the species called
‘debuggers’
and
> ‘disassemblers’ are alive. If any one of you know how to get
challenge
> response right, please let me know.
>
> So my solution, try to catch a dll injection ‘also’ with challenge
> response and proper ACL/ACE. BTW, I was thinking, why not at install
time
> create a seperate account in the system that has privileges equiv to
> SYSTEM a/c (> admin) and install my app (which is a service) and the
> driver thru it. Also set the Driver’s ACLs so that only system a/c
can
> access it (my the app is a service). Do you people think, it will
make
it
> a wee bit more secure?
>If yours is a custom solution for your use only, and nobody wants to
‘attack’ you in particular then you are probably safe.If you are developing a solution to sell far and wide, and the ‘bad
guys’
get a copy to play with, they’ll find a way of subverting it. It only
has
to
be broken once.James
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> You cannot ensure the integrity of your process from within the process. Period.
I would rather replace the term “process” with the “machine” - you cannot know for sure that your machine is not compromised while running checks on the target machine. A rootkit may load itself well before the OS does, hook BIOS calls so that the OS gets “modified” memory map at the boot time, and, at this point, it can do whatever it likes - the OS is just totally out of luck here. Ironically by introducing VM extensions Intel and AMD make life of sub-OS -level rootkit developers even easier…
Anton Bassov
Despite it’s long and discursive nature, Joe’s post is candidate for Best Post Of The Week… just for the quote above, which is Wisdom itself.
Peter
OSR