Securing An Insecure System

I found this post by HungryMan interesting

http://www.insanitybit.com/2013/01/16/securing-an-insecure-system/

I'm pretty sure there'd be those who would disagree. A few members here already comes to mind...

 

I actually had Linux in mind when I wrote it, but I decided that XP was a more blatant example.

As with many posts on my blog, users here have already heard it. That's why I rarely bother linking to it.

 

I can think of a few points of contention:

- Unless there's something I don't understand about the NT kernel, drivers (such as used by Sandboxie, or by any FW/HIPS software) are kernel level.

- OS kernels IIRC don't usually use the same exploit mitigation techniques that the rest of the OS does, because it would be slow and introduce a lot of complexity. Granted it would help to use an OS that's actively supported with kernel updates; even using a shiny, new, up-to-date OS may not protect your from kernel exploits.

- Most stuff related to SRP, default deny setups, etc. is about about malware prevention, which is probably pretty doable even on a legacy system. Protecting your OS from a human attacker is a whole other matter, and much more difficult.

That said, I have to (somewhat grudgingly) agree with you. I've been looking around for a long time for a sane way to secure legacy Windows systems, and I've come to the conclusion at this point that there isn't any.

My main caveat here is just that the rapid turnover rate of computer technology is driving a humanitarian and environmental crisis of enormous proportions. As much as I'm pro computer security, I feel that people should know just what their money is going into before they shell out for a new machine.

BTW

Linux in what context? Distros with bad update practices?

 

My explaining of sandboxing was more to give a quick understanding of how software/ security models work, not why an insecure system is insecure. It's not that the sandbox is not running as the kernel, it's that an attacker who is running at that level will bypass almost any level of security implemented.

That's really the 'illusion of security' I'm referring to. You can break run of the mill malware, but anyone who takes 5 seconds to modify their payloads will break through that level of protection.

In relation to Linux kernel development, PaX/Grsecurity, and things like that. The idea for the article took a few hops from those initial thoughts.

 

Integrity levels (UIPI - User Interface Privilege Isolation) were introduced in Windows Vista. XP security is based more on the rights and privileges of the logged in user.

 

OTOH, even modern OSes like Linux and Win 7 are hugely insecure; the daily barrage of critical updates attests to that. In theory, no general-purpose digital computer is secure, period.

In practice though, most users will never have to deal with anything more than the dumbest of dumb automated malware.

(That said, if enough people started using SRP, I'd bet we'd see some SRP-bypassing malware.)

Yep, DAC... Like on most Linux distros.

 

I'm really digging your website Hungry Man, Insanity Bit already added to my bookmarks

Keep up the good work!

 

Thanks, I appreciate that.

 

On 64-bit systems, Kernel Patch Protection means security software vendors have to use provided APIs or other means to get what they need..

Take a look at these:
64-bit systems and anti-malware software (linked to page 3 onwards where Ilya, Tzur and PrevxHelp discussed on-board)
Sandboxie Experimental Protection
Sandboxie Internals Redesigned in Version 4

Of course, on XP (and older OS), security products have no problems hooking the kernel. These security programs extend the life of such OS. What I'm thinking of is for how long can one depend on such a solution. Taking Sandboxie as an example, it's changing it's design to accommodate newer OS and possibly dropping support for older OS. Now, I'm sure other security vendors also would drop support for older OS as their security programs evolve.

"Internally, SRP rules enforcement happens in the user-mode which is less secure."

http://technet.microsoft.com/en-us/library/hh994620

 

Thanks re the stuff on 64-bit systems.

For SRP, yeah, it can be bypassed. A kernel exploit could do it, or... hey way a minute...

- Because it's in user space, a privileged service being compromised would also do the trick
- And privileged services on XP can be pretty easily compromised through shatter attacks

So SRP is in all likelihood only useful because nobody uses it. You know, I hadn't thought of that at all. Thanks.

 

Sandboxie doesn't start malware from running. It stops separate payloads from running.

Attackers have full code execution as soon as your process is exploited. That's why it's called remote code execution.

From there they have access to the kernel, they can talk to it, and interact with it, and exploit it. With a kernel like XP an attacker is working with a program over a decade behind on security.

 

Isn't this latter additional control from a remote code execution only possible with a successful attempt at "privilege escalation"? not too easy I thought unless the software is so buggy as to allow it more administrative privileges than intended by its developer when the program is run from a limited account type? Maybe there's more of these type of sloppy programs in common use than I think, but I've been under the impression for a long time, maybe wrongly so, that these type of serious bugs when discovered are usually patched very soon after, sometimes mere hours later. However, I would admit Java is a rare exception

 

I disagree. I protected myself well enough on XP even without patches some years ago. I know, it's bad practice and that shouldn't be done by anyone, but saying that any OS can't be secured is as wrong as saying that it can be 100% secure.

 

All that is required for privilege escalation is the ability to interact in any way with privileged code. All code can interact with the kernel in some way or another, and there is no mechanism to limit this in any way on Windows natively, and AFAIK no public way through any third party software (at least not as a direct goal of that software).

So if you can interact with the XP kernel and the XP kernel is insecure, it should be clear that privilege escalation is not just possible but not necessarily difficult.

Beyond that, shatter attacks were patched somewhat but the design issue is still present, it's just that MS removed the vectors they could control.

@Nebulus,

Being protected 'well enough' is trivial. Using EAF in commonly attacked programs is enough to stop nearly 100% of attacks on common systems. EAF is a pseudo-mitigation, completely trivial to bypass entirely, as has been demonstrated, and as MS has stated.

There's a big difference between that and security, in my opinion.

 

Well, before they decide to run some malware.exe they could simply execute code straight from the compromised process.

For example, if I'm an attacker and I compromise Firefox, I may normally drop a new payload and execute it, but I'm perfectly free to control Firefox in a multitude of ways, like using it to set registry values, access files, make system calls, interact with other processes, etc. All of which can be used to further compromise a system before I ever drop my new payload.

On a system where an EXE isn't allowed to run I'd likely want to perform a shatter attack, or exploit the kernel, and then simply unhook the AE, or perform some other action.

Then shatter attacks won't work. It can still interact with the kernel, though.

 

Re arbitrary code execution, just to cover all bases: doesn't the scope of the code execution (probably the wrong term - I mean, how much code and what sort of code can be executed) depend on the exploit?

e.g. maybe I can overflow a buffer in Firefox such that it overwrites a return address in the call stack, and calls my own code instead of whatever it should normally invoke. How much code would I typically be able to execute from that call, without loading a DLL or running some external binary? Furthermore, how would I typically inject my own code, assuming this was a remote attack? Wouldn't it take a fair amount of work to e.g. get a command shell as the exploited process?

(But note that I had to wiki "buffer overflow" for that example, so I'm not sure I'm even talking sense here... )

 

If you're working with an exploit that's able to download a file and execute it, you're working with an exploit that can do everything I've stated.

 

Okay, thanks.

 

I don't take it as a personal attack at all, I'm happy to engage in a conversation, and I agree that as much information should be provided so that users know how safe they are, and to what extent they can protect themselves.

Is it? It doesn't seem like it. The 'if' here is simply whether or not exploit kits start packaging a few extra features. You can still, actually, allow customize payloads, so from the business side very little would truly change.

If you have a restriction that only whitelisted files can run, sure, you've avoided 99% of malware. Probably 100% of what's out there, outside of targeted attacks.

But, again, the same goes for EAF and any attack that uses shell. Is EAF really providing security? Well, against current attacks. But it's known to be trivially bypassed, it's been known, and I believe even MS refers to it as a 'pseudo-mitigation'.

I think the real disagreement is about how we define security. Many people define security by the current threat landscape, I prefer to measure it by the level of skill needed to bypass that security. It's theory vs practice, and historically practice has followed theory - the biggest changes in ROP, that allowed for far more arbitrary exploits, was started through research, we didn't discover it in the wild. This is typical.

Spender has echoed similar notions as in my blog post. Many others have similar ideas, and with sandboxing becoming more common, believe that local exploits will likely be paired with remote exploits in the future to bypass security features. On a system like Windows 8 those local exploits will be potentially expensive (various features like SMEP/SMAP, which we'll see in 2013/2014, will add to this) but on a system like XP they'll be cheap, especially once patching ends.

 

I think you misread HM. I believe what he's saying is that, if an exploit is capable of running a binary, then it is also capable of executing code without the binary as an intermediary.

i.e. In your hypothetical situation, the exploit could be used to take control of Firefox itself. A kernel exploit could then be run from within Firefox's memory space, bypassing Sandboxie and e.g. loading a rootkit driver.

AFAIK there aren't any exploit kits that do this though. Maybe because it's harder to pull off; or rather, because Java applets and binary installers are easier to pull off. I think the point HM is trying to make, is that the nastier methods may become more prevalent as the low hanging fruit disappear.

 

The problem there is that what's conceptual now may become common in the future. e.g. With the appearance of more walled-garden app stores, kernel exploits to bypass those might become more common.

That said, there's only so much thinking ahead one can do with any accuracy.

IMO the one constant is that personal computers will remain insecure no matter what, through bad programming practices, bad hardware design, uninformed users, and just overall complexity.