Securing An Insecure System

As Windows XP begins to roll to the end of its life I think it’s worth stating something that may be a bit obvious to people – Windows XP is not secure. Furthermore, it can’t be secured, and once it’s out of support that will get far worse.

As I’ve stated multiple times, security belongs in the systems kernel. It’s the core component and when policy isn’t enforced by the kernel it’s weaker. The reason for this is simple – a policy enforced by one level of the system can be bypassed by an attacker who controls code at that level or higher. So if I have a sandbox working at Low Integrity any process low integrity or higher can escape. If I have a sandbox running as Admin any process Admin or higher can escape. And, as follows, if I have a sandbox running as Kernel, any process Kernel or higher (such as hardware) can escape.

So why is this so critical to understand? Because XP has an insecure kernel. No matter how much policy, how many programs, etc, you have protecting your XP machine if the attacker gets Remote Code Execution in a process they can bypass it all through kernel exploitation. An insecure kernel like XP’s can not be trusted to handle any policies. As there is no method on XP to limit kernel attack surface an attacker has, essentially, the entire kernel to exploit.

XP came at a time when Microsoft hadn’t implemented many security techniques. DEP still wasn’t prevalent throughout the system, even MS services, and ASLR is nonexistent. Remote code execution against a program that has no DEP, SEHOP, or ASLR isn’t difficult, and even with DEP a single vulnerability will likely be effective.

Beyond that there’s a very poor implementation of privilege control. A class of attacks known as ‘shatter attacks’ abused this, allowing trivial elevation from a limited user to administrator. Microsoft attempted a fix to this in an update but attacks can still take place.

For a program with administrative access getting a local kernel exploit in a kernel as insecure as the one powering XP should not be difficult. Attacks against Vista/7 have shown that, even with security techniques, local vulnerabilities are ripe in areas such as TrueType, which is in the kernel.

And without patches users have no way to protect themselves.

What I’m trying to get across is that no matter the strict policies, numerous programs, etc, that you use you can’t secure an XP system let alone one without frequent patching. I understand that new hardware costs money, but Windows 7/8 have fairly low minimum requirements considering the hardware out there right now and it’s truly time to move on. Attempting to implement overly-strict policies will only cripple your experience and provide the illusion of security.

5 thoughts on “Securing An Insecure System

  1. Hi Hungry,

    That was a great writeup although I dont understand security soo deeply i.e.kernelly. Am a regular on wilderssecurity(exus69). I think the two most common attack vectors are:

    1)Running illegal software on the pc under admin account
    2)Visiting malicious sites under admin account

    So if we provide security keeping those two attack vectors in mind I think we can avoid majority of the attacks what say?

    As far as mitigating illegal software on the pc is concerned NOT running as an admin, configuring SRP will stop the remote execution process in its first step itself i.e.No execution, no worries.

    As far as mitigating malicious sites is concerned we can use the latest version of the browsers, not run as an admin, run the browser under Sandboxie, install security plugins like noscript, opendns etc.

    Dont you think these counter measures can help to mitigate exploits on XP to a large extent??

    • Hey Sunny,

      It’s unclear where the most infections ‘sprout’ from. Various research/ studies have shown different results, ranging from social engineering, to exploits, to a combination.

      The issue with running a restricted account on XP is that malware authors shouldn’t have a hard time getting Admin/ kernel privileges. The focus of this particular blog post surrounds that issue – because the kernel (the heart of the operating system) is insecure, attackers can control the system too easily to make XP a secure OS.

      In terms of antiexecutable software, I think the misconception you have is very common. Specifically:

      will stop the remote execution process in its first step itself i.e.No execution, no worries.

      Execution of a separate process is actually one of the last steps taken in an attack. The attacker has execution of arbitrary code long before they drop their malware. What this means is that if Firefox.exe is compromised an attacker can run code long before they launch malware.exe. So an Antiexecutable won’t prevent an attacker from using a local exploit to run Firefox.exe (which is now controlled by the attacker) as kernel/admin. At this point they can unhook your other security products (like Sandboxie, especially if it isn’t running at the kernel, and potentially even if it is). This is why a secure kernel is so critical to a system.

      Running things like noscript, opendns, etc, is a good idea. NoScript really does prevent attacks at an early level, and it’s great for XSS. It would be effective, but it is one of the very very few techniques that would work, and I wouldn’t rely on it alone as it does lose significant protection after a site is whitelisted.

  2. Hi Hungry,

    Thanks for the detailed explanation. I deal with a lot of clients still having XP systems(Majority of the comp users here in India still use XP other than pre loaded Vista/7/8 on laptops) and its next to impossible to explain them to upgrade to 7/8 in order to reduce their recurring virus problems to a large extent. The general tendency here is if the work is going on smoothly why upgrade??

    Assuming someone forced you to use XP and no other system for your routine work what hardening steps would you take(apart from group policies) to atleast make it very difficult if not impossible for the bad guys to get in keeping those two attack vectors in mind which I mentioned above??

    Sorry I hope am not asking for too much but when a knowledgeable person like you ruthlessly dismisses XP for its lack of security it does raise curiosity as to what he thinks should XP be well protected with.

    Thanks again 🙂

    • In the case where moving away from XP is not an option I’d follow similar goals with Windows 7/8.

      I’d disable absolutely every service I didn’t require. For example, I don’ t use any printing services, so I’d disable the print spooler. That’s the service exploited by Stuxnet.

      I’d use EMET to force DEP to Always On, and I’d force SEHOP as well. I’d use EMET 3.5, with anti-ROP mitigation techniques, on every binary I could.

      I’d use Chrome with Click To Play plugins, and whitelist Javascript.

      At this point Chrome is still severely weak because it has no ASLR, making remote code execution attacks much easier. EMET helps, but only so much. And once they’re on the system they have a sandbox to deal with, but not a great one, and it’s enforced by a weak kernel.

      What you can then do is consider something like Sandboxie for other programs, such as an IM client, or torrent client. Give direct access to a downloads folder and then block read access to areas like the security accounts manager area of the registry, and other areas of the OS that might help an attacker.

      Again, without ASLR getting into an IM client won’t be difficult. And after that neither will local privilege escalation.

      I’d say the most important things to do here are disabling as many services you can and EMET.

  3. Pingback: Chrome Gets Hacked - Pwn2Own 2013 » InsanityBit InsanityBit

Leave a Reply

Your email address will not be published. Required fields are marked *