I work for a security company, and we’d like to shield our user space service from debugger attachment. I’d like to block code injection, and other attacks as well, but for now I’d be happy stopping debuggers.
Since we have a kernel driver as well, I thought there must be some way to stop a user space debugger from attaching to our service, but in searching the web I didn’t see any.
Some rootkits removed or added token privileges, but did it through direct modification of the process token, and it seems like there should be some official way to protect applications.
Are there courses, or information on protecting applications from attack?
I hear what you’re saying, but preventing a debugger from attaching really
isn’t preventing an attack; it’s preventing debugging, which is a pretty
hostile thing to do on a system that you don’t own.
If you’re interested in attempting to prevent someone from using a debugger
on your code, then don’t allow your code to run on a system with debugging
enabled. There are apis for this.
On Oct 13, 2010 11:31 AM, wrote: > I work for a security company, and we’d like to shield our user space service from debugger attachment. I’d like to block code injection, and other attacks as well, but for now I’d be happy stopping debuggers. > > Since we have a kernel driver as well, I thought there must be some way to stop a user space debugger from attaching to our service, but in searching the web I didn’t see any. > Some rootkits removed or added token privileges, but did it through direct modification of the process token, and it seems like there should be some official way to protect applications. > > Are there courses, or information on protecting applications from attack? > > Thanks > > — > 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
My recommendation is to focus on catching malicious code before it has a chance to run as admin and attack your process.
S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, October 13, 2010 8:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Stop debugger attachment to a service
I work for a security company, and we’d like to shield our user space service from debugger attachment. I’d like to block code injection, and other attacks as well, but for now I’d be happy stopping debuggers.
Since we have a kernel driver as well, I thought there must be some way to stop a user space debugger from attaching to our service, but in searching the web I didn’t see any.
Some rootkits removed or added token privileges, but did it through direct modification of the process token, and it seems like there should be some official way to protect applications.
Are there courses, or information on protecting applications from attack?
I think it was symantec that at one point refused to run if a debugger
was present. That was the end of that product on my system. Hideously
annoying, although the number of people actually running debuggers on
systems is exceedingly small, so it is a viable approach.
Mark Roddy
On Wed, Oct 13, 2010 at 11:51 AM, Martin O’Brien
wrote: > I hear what you’re saying, but preventing a debugger from attaching really > isn’t preventing an attack; it’s preventing debugging, which is a pretty > hostile thing to do on a system that you don’t own. > > If you’re interested in attempting to prevent someone from using a debugger > on your code, then don’t allow your code to run on a system with debugging > enabled.? There are apis for this. > > On Oct 13, 2010 11:31 AM, wrote: >> I work for a security company, and we’d like to shield our user space >> service from debugger attachment. I’d like to block code injection, and >> other attacks as well, but for now I’d be happy stopping debuggers. >> >> Since we have a kernel driver as well, I thought there must be some way to >> stop a user space debugger from attaching to our service, but in searching >> the web I didn’t see any. >> Some rootkits removed or added token privileges, but did it through direct >> modification of the process token, and it seems like there should be some >> official way to protect applications. >> >> Are there courses, or information on protecting applications from attack? >> >> Thanks >> >> — >> 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
Easy. Require that the users on the systems in the field don’t have administrative privileges (and also SE_DEBUG_PRIVILEGE). But you already know that, don’t you?
If you just assume the kernel may be compromised, or the administrative user’s session may be compromised, the game is over. It’s pointless to chase corruption in an already broken system. It’s a shame that corporate customers can’t get it. Part of the blame is on Microsoft for creating the users as administrators by default, and the users just don’t know any better. This was the one of worst decision MS made, and it will cost (already does) MS dearly in the long run.
I work for a security company, and we’d like to shield our user space service from debugger attachment. I’d like to block code injection, and other attacks as well, but for now I’d be happy stopping debuggers.
That’s hopeless. The rootkit hackers are way smarter than you are.
Whatever you can do, they can undo.
Are there courses, or information on protecting applications from attack?
Whatever information there is, was outdated as soon as it was published.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Wed, 13 Oct 2010 13:25:01 -0400
Mark Roddy wrote:
> I think it was symantec that at one point refused to run if a debugger > was present. That was the end of that product on my system. Hideously > annoying, although the number of people actually running debuggers on > systems is exceedingly small, so it is a viable approach.
It took me a while to realise that Skype doesn’t allow a debugger to be attached when it’s running either - it triggers a usermode debug breakpoint which of course causes Windows to freeze without explanation if remote debugging isn’t setup at the time.
Lol. You can make it difficult for malicious code to run and increase the
time that it takes to compromise the system. However, you also need to
focus on detection once the compromise inevitably occurs.
Regards,
George.
“Skywing” wrote in message news:xxxxx@ntdev… My recommendation is to focus on catching malicious code before it has a chance to run as admin and attack your process.
Absolutely. I proposed this merely as better than hacking around, but I
don’t use anything that does this.
Mm
On Oct 13, 2010 1:25 PM, “Mark Roddy” wrote: > I think it was symantec that at one point refused to run if a debugger > was present. That was the end of that product on my system. Hideously > annoying, although the number of people actually running debuggers on > systems is exceedingly small, so it is a viable approach. > > Mark Roddy > > > > On Wed, Oct 13, 2010 at 11:51 AM, Martin O’Brien > wrote: >> I hear what you’re saying, but preventing a debugger from attaching really >> isn’t preventing an attack; it’s preventing debugging, which is a pretty >> hostile thing to do on a system that you don’t own. >> >> If you’re interested in attempting to prevent someone from using a debugger >> on your code, then don’t allow your code to run on a system with debugging >> enabled. There are apis for this. >> >> On Oct 13, 2010 11:31 AM, wrote: >>> I work for a security company, and we’d like to shield our user space >>> service from debugger attachment. I’d like to block code injection, and >>> other attacks as well, but for now I’d be happy stopping debuggers. >>> >>> Since we have a kernel driver as well, I thought there must be some way to >>> stop a user space debugger from attaching to our service, but in searching >>> the web I didn’t see any. >>> Some rootkits removed or added token privileges, but did it through direct >>> modification of the process token, and it seems like there should be some >>> official way to protect applications. >>> >>> Are there courses, or information on protecting applications from attack? >>> >>> Thanks >>> >>> — >>> 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 > > — > 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
Yes Symantec did stop this, and I know several firms that went out and
rented or bought an Arium JTAG debugger to happily bypass all the
checks. As many folks are saying no matter what you do it can be
undone, and your efforts are more likely to piss off legitimate
developers than to stop malicious code writers. I am proud to say I
convinced a firm with 10,000 licenses to dump Symantec because of their
debugger crap.
> I think it was symantec that at one point refused to run if a debugger > was present. That was the end of that product on my system. Hideously > annoying, although the number of people actually running debuggers on > systems is exceedingly small, so it is a viable approach. > > Mark Roddy > > > > On Wed, Oct 13, 2010 at 11:51 AM, Martin O’Brien > wrote: > > I hear what you’re saying, but preventing a debugger from attaching really > > isn’t preventing an attack; it’s preventing debugging, which is a pretty > > hostile thing to do on a system that you don’t own. > > > > If you’re interested in attempting to prevent someone from using a debugger > > on your code, then don’t allow your code to run on a system with debugging > > enabled. There are apis for this. > > > > On Oct 13, 2010 11:31 AM, wrote: > >> I work for a security company, and we’d like to shield our user space > >> service from debugger attachment. I’d like to block code injection, and > >> other attacks as well, but for now I’d be happy stopping debuggers. > >> > >> Since we have a kernel driver as well, I thought there must be some way to > >> stop a user space debugger from attaching to our service, but in searching > >> the web I didn’t see any. > >> Some rootkits removed or added token privileges, but did it through direct > >> modification of the process token, and it seems like there should be some > >> official way to protect applications. > >> > >> Are there courses, or information on protecting applications from attack? > >> > >> Thanks > >> > >> — > >> 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
I have read the posts, and honestly I don’t understand the sentiment.
There is absolutely nothing that can be done to stop a jtag debugger, and a kernel debugger is difficult (I would think) to detect and stop, so it is not the user of a system that I am trying to stop.
Security of ANY type can be defeated, and most security relies on layers of protection.
It seems to me that protecting ALL the applications from injection, debugging, etc. would be a good thing, with the ability to turn the protection off (of course).
I think the guys who post/read here know what they are doing, and can protect their system, but that is not true of 90% of the windows users. Most users get their systems already installed, log in as admin, and go blissfully along.
On Oct 13, 2010 5:58 PM, wrote: > I have read the posts, and honestly I don’t understand the sentiment. > There is absolutely nothing that can be done to stop a jtag debugger, and a kernel debugger is difficult (I would think) to detect and stop, so it is not the user of a system that I am trying to stop. > > Security of ANY type can be defeated, and most security relies on layers of protection. > It seems to me that protecting ALL the applications from injection, debugging, etc. would be a good thing, with the ability to turn the protection off (of course). > > I think the guys who post/read here know what they are doing, and can protect their system, but that is not true of 90% of the windows users. Most users get their systems already installed, log in as admin, and go blissfully along. > > A guiding hand does not seem unreasonable. > > > — > 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
wrote in message news:xxxxx@ntdev… > I have read the posts, and honestly I don’t understand the sentiment. > There is absolutely nothing that can be done to stop a jtag debugger, and > a kernel debugger is difficult (I would think) to detect and stop, so it > is not the user of a system that I am trying to stop. > > Security of ANY type can be defeated, and most security relies on layers > of protection.
To detect kernel debugger: just use well known API (KD_DEBUGGER_ENABLED, KdDisableDebugger() etc). No more comments.
> It seems to me that protecting ALL the applications from injection, > debugging, etc. would be a good thing, with the ability to turn the > protection off (of course).
Maybe. The integrity levels in NT6 address this need /* with arguable success */. http://msdn.microsoft.com/en-us/library/bb625964.aspx Managed code has its own protection devices. Old legacy code has too many problems anyway.
> I think the guys who post/read here know what they are doing, and can > protect their system, but that is not true of 90% of the windows users. > Most users get their systems already installed, log in as admin, and go > blissfully along.
Ok, they get their systems already installed - and will not log on as admin, if their account has been preinstalled as standard user.
> A guiding hand does not seem unreasonable.
Do you mean all these “desktop management” products? IMHO they are IT analogue of perpetuum mobile: They typically cost more to setup and maintain than savings gained on the end user side.
Also, either way, those products are installed by the owner of the system.
Mm
On Oct 13, 2010 11:55 PM, wrote: > wrote in message news:xxxxx@ntdev… >> I have read the posts, and honestly I don’t understand the sentiment. >> There is absolutely nothing that can be done to stop a jtag debugger, and >> a kernel debugger is difficult (I would think) to detect and stop, so it >> is not the user of a system that I am trying to stop. >> >> Security of ANY type can be defeated, and most security relies on layers >> of protection. > > To detect kernel debugger: just use well known API (KD_DEBUGGER_ENABLED, KdDisableDebugger() etc). > No more comments. > >> It seems to me that protecting ALL the applications from injection, >> debugging, etc. would be a good thing, with the ability to turn the >> protection off (of course). > > Maybe. The integrity levels in NT6 address this need /* with arguable > success */. > http://msdn.microsoft.com/en-us/library/bb625964.aspx > Managed code has its own protection devices. > Old legacy code has too many problems anyway. > >> I think the guys who post/read here know what they are doing, and can >> protect their system, but that is not true of 90% of the windows users. >> Most users get their systems already installed, log in as admin, and go >> blissfully along. > > Ok, they get their systems already installed - and will not log on as > admin, if their account has been preinstalled as standard user. > >> A guiding hand does not seem unreasonable. > > Do you mean all these “desktop management” products? > IMHO they are IT analogue of perpetuum mobile: > They typically cost more to setup and maintain than savings gained on the > end user side. > > – pa > > — > 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
Often I don’t question if I’m asked to do such things specially for some prototype not-mass-production type software, so I did this in the past hooking int3, and int 1 if I could recall. I don’t recommend this approach, but it is called the debug disability of a specific software.
Don’t know your project scope in the sense of mass users, but I do agree that any and all security is just to make harder and harder and harder to break, so nothing is perfect in this space I suppose!!! … Like flu vaccination.
I have read the posts, and honestly I don’t understand the sentiment.
There is absolutely nothing that can be done to stop a jtag debugger, and a kernel debugger is difficult (I would think) to detect and stop, so it is not the user of a system that I am trying to stop.
Security of ANY type can be defeated, and most security relies on layers of protection.
It seems to me that protecting ALL the applications from injection, debugging, etc. would be a good thing, with the ability to turn the protection off (of course).
I think the guys who post/read here know what they are doing, and can protect their system, but that is not true of 90% of the windows users. Most users get their systems already installed, log in as admin, and go blissfully along.
>>we’d like to shield our user space service from debugger attachment. I’d like to block code injection, and other attacks as well, but for now I’d be happy stopping debuggers.
So you want to disable live debugging? Any reasoning as anyways they are free to static analysis plus you need to tackle, when they open your process from debugger itself. You can do it but it will not be very effective as there are ways to bypass it.
Additionally I think there are certain MS dlls which also hooks user process (shimengine is one), so you’ll protect yourself from legal apps, rootkits writer can still obviously bypass you.
