DEP - Stackguard ... Moving Forward??

NutJob

Discussing the buffer/heap overflow. The coming of age of DEP and Stackguard and are we moving in the wrong direction regarding Hardware solutions to a string handling problems. Your opinions on all that is technical with hacking/security? Please don’t bring up what’s the best spyware and anti-virus remover!!! Technical questions and technical answers please. Anything technical 802.11a/b/g Wep …………

NutJob

Looks like im going to have to kick off then.


Eircom are distributing wonderful access points. These “wireless modems” not alone allow you to check your e-mail in the garden but allow any Muppet with ferrite or some Linux scripting to park outside your house and use your broadband to check ur e-mail two :-) while u are.

You may consider this alarmist but iv stumbled upon some of these networks left with no password allowing anyone to join. DHCP was enabled to make life even easier for anyone to connect.

I have also seen a number of companies using medium range wireless networking across towns as a cheap link. There’s nothing wrong with doing this if you use decent encryption not WEP.

Any sensible medium rang network that requires any degree of privacy should be using VPN on top of WEP. There is an open source VPN software ported to windows called OpenVPN works great and is under GPL.

So ur comments pleaseeeeeeee.


-End of Rant

Martyr

OK, seeing as nobody else relied, yet.

I don't know what the state of wireless security is, as i don't have any hardware.

I've heard lots of people talking about how they go "wardriving" or whatever..its just a way for them to amuse themselves.
Some neighbours and businesses have their bandwidth used for downloading warez and porn with P2P clients among other nefarious things.

About DEP, i've read about stackguard and W^X on unix-variants, again, don't know much about them, but it seems like its the nail in the coffin for buffer overflows..from a remote perspective, aslong as the software being exploited supports the o/s feature.
obviously, these ideas are more securely applied with hardware.

I've read over some source code that bypasses DEP, but they usually require special privileges, which kind of defeats the purpose of an "exploit"

..i could be wrong, but, i don't think its possible, you can write to a buffer, but you can't execute anything in it with DEP(windows) enabled.

this is taking into account that you can change paged memory permissions, ..requires special privileges on process, so whats to exploit?

NutJob

Important articals on Bypassing DEP and how it works thanks to Phrack

http://www.phrack.org/phrack/63/p63-0x0f_NT_Shellcode_Prevention_Demystified.txt
http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.
pdf

Not trying to teach people how to hack but if your a sysadmin or interested in security no point in sticking your head in the sand.

Any suggestions on how dep should be updated in windows to pevent these bypasses.

How about combineing stackguard approach with dep (a super stackguard if you will) ??

Martyr

I haven't read those yet, but will later when i get some time..
My understanding of DEP on windows is that it is possible for HEAP or STACK memory to be READ or WRITE, but never EXECUTE, much like CODE sections are READ and EXECUTE, but never WRITE.

So while it is perfectly legal to read or write some shellcode to a buffer in DATA section, if any attempt is made to EXECUTE it, the CPU will generate an exception, much like any attempt to WRITE to code section generates a fault.

Now, ALL the solutions i have seen for bypassing DEP thus far are based on having LOCAL read/write access to the process, in order to change memory permissions..using something like VirtualProtect..

Problem for me is, how on earth do you execute VirtualProtect in a buffer overflow exploit, when DEP won't allow you to execute code on the STACK or HEAP?????

All i'm saying is, the whole point of "exploit" is to elevate privileges, right?
But if you already have access to the privileged process you're exploiting..there is no need to exploit it, is there?

If you can already use VirtualProtectEx locally,why bother with an exploit?
I don't understand what any of these authors are trying to point out, what am i missing?

I am not denying that you can bypass DEP with the correct privileges, but what is the point? .. its no amazing accomplishment.

NutJob

the workaround tampers with the exception handler.

If this happened on a linux system there would have been a patch in 24 hours after release.

In the case of microsoft its another one of those 6,000 or so knowen "issues"

Martyr

the workaround tampers with the exception handler.

There is no workaround for microsofts DEP provided in either paper that i could tell, and source code at end assumes you have read/write access to the process you're trying to exploit. which would mean, you'd have to have started the process yourself, or be part of ADMINISTRATORS group..etc

If this happened on a linux system there would have been a patch in 24 hours after release.

There is nothing to patch, because DEP is not broken, it seems to work well enough.
The fact that you can bypass it, with appropriate privileges, proves nothing, you can no doubt do that on unix systems with similar protections also, its just that nobody bothered to write a paper about it, probably because its pointless.

On most UNIX-variants, from what i can remember, if you're root, you can legally use 'rm -rf /' and it should work fine.. *shrug* should linux developers provide a patch for root users so they aren't allowed to do that?

All i'm saying is, if you have the correct privileges, and you're sitting locally at a computer..you can do what you want, can't you? pretty much anyway.

As you said the examples "tamper with the exception handler", it says also the attacker would first have to either remove/replace current SEH with his own..only way this can be done is through executing some instructions which DEP will not allow from heap/stack (assuming exploited buffer in stack/heap)

Any execution whatsoever from this type of memory is going to cause access violation..the worst that can happen, is the application crashes.
denial of service.

Martyr

I found a discussion on way to exploit DEP, but as the author already admits, it isn't really practical..having to hardcode api address of VirtualProtect, also taking into account null bytecodes in parameters placed on stack, but couldn't be copied to stack buffer if exploiting a function like strcpy...(if encoded, how would it be decoded without execution of code?)

http://woct-blog.blogspot.com/2005/01/dep-evasion-technique.html

Although its a interesting idea, it wouldn't work.
alright, maybe it would work..in very very very rare circumstances, perhaps an exploit we may not ever see.

But even if it were possible on just 1 individuals system, the chances of a successful worm being deployed are slim and none, as most of the versions of windows don't have static libraries.

In conclusion, Microsoft's Hardware DEP protection does not prevent future exploits from being successful; it only adds a trivial amount of complexity to the attack.

I'd say alot of complexity to the attack.

NutJob

Looks like i need to do some more reading.



But from what i can see once the process you’re exploiting has administrative access you inherit those permissions.



Admittedly hard coding Api addresses is just nasty.



This may stop a worm but will it stop someone who is a little smarter than a piece of code and your not limted to 1 attempt :-)

Martyr

Good article on some methods of bypassing DEP.
Its best info i read about it so far, not overhyped as much as other stuff.
Worth a look.

http://www.uninformed.org/?v=2&a=4&t=sumry

NutJob

Thanks

will give it a read

i have one that is loosely pointing in the same direction of why dep isnt
up to scratch.



http://www.securityfocus.com/news/11346

Same is true for attacking multi threaded servers. Just cause you dont win first time doesnt mean you cant give it a few more tries.

NutJob

Average Joe wrote:

Good article on some methods of bypassing DEP.
Its best info i read about it so far, not overhyped as much as other stuff.
Worth a look.

http://www.uninformed.org/?v=2&a=4&t=sumry

Great piece tells it straight with no sensationalist crap

Martyr

There are still a few issues

What if the process being exploited doesn't have NTDLL.DLL loaded into memory?
If the exploited function is like.. strcpy() then there will be the problem of null bytes.
LoadLibrary will require null terminated string as parameter.

the_syco

I didn't bother checking out the links, as I'd proberly get flagged if they're hacking sites (only started the job recently).

=-=

Companies tend to think that by having a firewall, or router, that they're safe, and that the firewall should keep _all_ the bad people out. Not so. Symantec's products were found to have a bug in their software recently, and as most people leave the passwords to a default on the router, there's not much security on them, and that no product is 100% fail-safe. The FBI have shown how they can crack a 128-bit WEP key in about 3 minutes. And as 70% have no security, and the other 30% use WEP, it shows that nothing stops all.

=-=

I haven't looked up DEP yet, but if its seen as the next "holy grail", it just means more people will try to hack it.

NutJob

the_syco wrote:

I didn't bother checking out the links, as I'd proberly get flagged if they're hacking sites (only started the job recently).

=-=

Companies tend to think that by having a firewall, or router, that they're safe, and that the firewall should keep _all_ the bad people out. Not so. Symantec's products were found to have a bug in their software recently, and as most people leave the passwords to a default on the router, there's not much security on them, and that no product is 100% fail-safe. The FBI have shown how they can crack a 128-bit WEP key in about 3 minutes. And as 70% have no security, and the other 30% use WEP, it shows that nothing stops all.

=-=

I haven't looked up DEP yet, but if its seen as the next "holy grail", it just means more people will try to hack it.

Takes me 5min last time i tried to break 128bit Wep and WPA aint much better. But being involved in wireless setups all i can say is lock to mac adresses.

Wep is wayyyy too weak and sublect to packet injection aswell which mekes it even easier to use wepcrack/wepcrack2

Use the MAC adresses.

Not that anyone need break in iv spotted areas on a wardrive that have a 1/3 of routers wide open(some industrial estates)

NutJob

Average Joe wrote:

There are still a few issues

What if the process being exploited doesn't have NTDLL.DLL loaded into memory?
If the exploited function is like.. strcpy() then there will be the problem of null bytes.
LoadLibrary will require null terminated string as parameter.

The old fashoned way was to xor the overfolw so there was no nulls. Not going to work in this case unless you can get the stub to have no nuls and then xor the rest.

As for an ap with no NTDLL.DLL is unlikely but possible just have to aim somewhere else idealy pull your two adresses inside another know Dll.

Since NTDLL.DLL is one of the main bridges between user and kernell mode i fancy my chances of it being there(somewhere):).