How would you get infected?

Not quite. That's on my real host system but I usually test on the guest vm which is similar with AppLocker but using Windows fw. Even on my XP Pro vm it's been difficult to infect, such as the recent exploit email I found in my junk folder with the link to the Boston Marathon videos, one of which (the poisoned one) attempts to launch Java and probably attempts to download malware, but it never actually gets off the ground, even if I lower defenses in Firefox by disabling NS, and the Attack and web forgery warning checkboxes, the latter two of which I feel doesn't get the credit they deserve.

 

I understand your points. I agree EMET will not defend your system against everything. It's not a magic solution.
But these Category 4 attacks, could you present some examples on how those are carried out? IMO, you need a hole or weakness to poke into in order to gain system access and that boils down to taking advantage of a system vulnerability. Also, even if system access is a fact, you need multiple stepping stones to gain root.
I've read Hacking Linux Exposed few years ago and while the info is not up to date the basics attack methods should be similar, my impression is that you need vulnerabilities, various stepping stones, perhaps some social engineering etc to be successful. It's not like those Hollywood movies where the hacker simply presses some random keystrokes and gain access to your system (not that you implied that in your post!).

 

@Mman79,

For this topic I'm talking about local attacks though, not network sniffing etc. Though an ISP can't just get all of your information simply by virtue of being an ISP. They can get plaintext, potentially some encrypted data, but that's all. They can't get my local data, they can't control my computer, etc.

But in this case I'm talking about your local system being hacked.

I think people should be more imaginative =P. It's not an easy question. I have a difficult time with it, since I've taken steps, but I feel I've taken considerable steps and I can see ways in. They may not be likely, but they're there.

 

Interesting, thanks for sharing. Seems XP is underestimated.

 

Please share. I need to broaden my horizons.

 

I basically follow the security guide on my site. All internet facing services are disabled, save the ones I require. I patch my kernel with grsecurity, making local privilege escalation incredibly difficult.

My browser is an entryway, an attacker could MITM, and redirect to an exploit page. That wouldn't work well, as I whitelist plugins, and sandbox them manually. They would need to bypass the whitelist by either find a flaw in that whitelisting policy, or have it happen on a page that I don't whitelist. The problem with the second is that I don't ever permanently whitelist Java, only Flash. Flash runs in a very tight sandbox.

The sandbox Flash runs in reduces kernel exposure as well as file exposure. An attacker needs a design flaw, realistically, as between Grsecurity and Seccomp local kernel exploitation is probably not the path of least resistance.

In the case of a design bypass I also run the browser in an Apparmor sandbox. So they can get access to that sandbox, and then potentially have a simpler time running a local kernel vulnerability. Again, Grsecurity makes this much harder. But it's possible. At that point they have everything they need.

Other ways to attack could be a malicious Pidgin instant message. I run Pidgin in a sandbox, and as I've covered it's non-trivial to break a sandbox on Grsecurity kernels. But there's no seccomp, so it's easier than Chrome by far.

Pretty much every other program that opens a file from the internet (VLC, Comix, Jdownloader, Java, etc) are all sandboxed with Apparmor.

RCE in something like the TCP/IP stack would give instant kernel access, and that would be enough to take over the entire system. Again, Grsecurity helps here significantly. Remote kernel exploitation on this system is not likely.

Someone could perform a MITM and a hash collision to attack the update mechanism, as it's over HTTP and relies on digital signatures (including MD5). Not easy, something a government would have to do. I could defend against this by restricting Root on my system, but I won't bother.

Those are the ways I see into my system.

 

System access thru Kernel privilege escalation - how realistic is it if the kernel is patched and there are no zero days and there is no Grsecurity?

The countermeasures you've described for other system breaches are readily available in W7 systems in conjunction with Chrome sandboxing which of course has been bypassed but given the fact that the Chrome devs patch those holes almost immediately, I see very little chance of anyone taking advantage of the vulnerability when the "wide open window" period is so short. Perhaps we need to filter the discussion and focus on what an attacker can do to an unpatched system but with Grsecurity or EMET because if your system is patched and there are no kernel vulnerabilities, becoming root on the system via the conventional way will be so much harder.

Reverse engineering in tcp/ip stack is the most interesting point in the discussion so far, since it does not require any vulnerability in the kernel.

 

So if I were to answer this question do I sit back and wait for it to happen?

 

I've been waiting... for a virus to... come into my life...
yeah waiting... for the next exploit... to come into my life...

Aren't we all? What fun would there be if there wasn't some danger involved I wonder.

Like going for a hike in North Dakota vs Yellowstone I guess

Sul.

 

Actually, tcp/ip stack is managed by the tcp/ip driver in the kernel. So any exploit to that tcp/ip kernel driver vulnerability will get to kernel mode immediately(root). Just like those used by the internet worms of yesteryears bypassing any usermode protections.

Hence, his statement:
"RCE in something like the TCP/IP stack would give instant kernel access, and that would be enough to take over the entire system."

 

Thanks for clarifying. So the success of the attack will heavily depend on a vulnerability in the driver itself?

 

Yup. Fortunately, there are only a few vulnerabilities on that kernel driver. The most recent ones affect only newer Windows version(now patched) while Cloneranger's beloved XP is spared.

No need to worry if you are using a firewall even if there's any zeroday.

 

Yeah, well, I've opened my door and tried to invite the viruses in but they seem too shy

Even with all defenses lowered they steer clear of me I wonder if my ISP is interfering somehow?

 

@HM: Yeah, I know this is more about local attacks. The thing I mentioned with ISPs is not really what they can do by default, even though they can do enough. I was talking more along the lines of what the NSA is doing, which is something that no, the ISP bit its little old self couldn't do and legally wouldn't be able to even attempt.

@New2Security: My "Category 4" instances are like, again, what the NSA is doing, which is actually tapping into the networks at their source. It could also include things like what China's Unit 61398 has been doing for years now, and was just recently found out about. They've been conducting a cyber-espionage campaign against corporation and government facilities and databases and used some common and homegrown tools. They would of course use known techniques like spear-phishing emails, but once the system flaw was exploited and the backdoor opened, they smartly disguised their traffic as common, widely used internet services like Jabber/XMPP. This keeps firewalls and such in the dark and allows the attacker to merrily gather whatever they require, from emails to even VPN logins, which causes a very big issue since now they have remote access to the network and don't have to rely on "That guy" anymore two rows over with the compromised system.

The NSA example is perhaps the better of examples, since Unit 61398 has a few "That guy" types themselves (Some members accessed their personal Facebook accounts from the compromised systems/network, for example).

 

I think the most influential factor to staying free of common problems is when you deviate from default. Shut down services you don't need, modify browser and OS settings, the list goes on and on. I would say that a HUGE majority of machines I have cleaned up have been default machines, fully patched with current AV files etc. Users can be true neophytes or seasoned veterans, it seems to make no difference.

Yet with some I know who may not be into "security" but are into changing things because they like to personalize things, don't have many problems at all.

There are many things mentioned in this thread that won't work on non-standard systems and many that will work on any system. But as I say, when you are obscure with your system, I think you relieve yourself from a large portion of potential problems.

Just my thoughts anyway.

Sul.

 

I see what you're saying. But if a gov't body is interested in what you are discussing about and with whom, I'm inclined to think they will most likely take the easier route by compelling your ISP / mail provider to hand over any necessary information they want ; email correspondence, chat sessions, passwords etc. If they have that, they have gained what would be an urgent interest for them ; live information. Of course, establishing a permanent access to your computer would then be a high priority if the live information they acquired proved to be interesting.

 

@New2security,

Pre-Windows 8 kernel exploits are easier, but not trivial. Remote ones aren't likely or common at all. Local ones are getting more attention, and there are plenty. On a properly set up Grsecurity kernel it's still less likely.

Unfortunately the countermeasures aren't quite available on Windows.

The Chrome sandbox on Windows only limits file access, not kernel access. So it doesn't make kernel exploitation much more difficult. The design bypasses are few and far between though on both systems, though on Linux you can sandbox further with Apparmor to limit the effect of those as well.

I agree that the time to patch for Chrome leaves little time for an attacker to exploit the system.

But still a possibility.

Attacking my system in general is just not simple.

Remote kernel exploitation via TCP/IP is possible, but grsecurity protects you anyways. It's not bullet proof, it just works well.

Like trismegistos says, this'll get you kernel access, but remote kernel vulns aren't so common anymore.

 

If I understand correctly, you mean "local" as in someone having physical access to the machine in order to exploit the kernel? Because if that's the case, then I don't care how "non-trivial" they are to exploit under this condition, because if someone has physical access to my machine, it matters squat how much security I have in place, because it's game over anyway. It is for this reason why I don't keep anything of extreme value or sensitive nature on my machine's anyway. I use encryption for all personal data.

 

By local access you imply -> remote payload (not kernel related vulnerability) -> gaining local access -> local kernel access and privilege escalation if there is a local kernel zero day?

Yes that is certainly possible but take Chrome as an example since it was mentioned, even if its sandbox does not limit kernel access (it doesn't?!), the attacker still has to force himself out of the sandbox in order to abuse the kernel in a meaningful way yes?

I agree grsecurity, pax or selinux are more powerful..too bad they're not there for Windows, well except for EMET that is.

 

edit: Posted after new2security, here's an edit.

@Wat,
No, I don't mean that.

Remote kernel vulnerability: A vulnerability that attacks the kernel straight away, without first gaining access to the system.

Local kernel vulnerability: A vulnerability that takes place on the system. No physical access required, just remote code execution.

This isn't a matter of physical access it's a matter of attack surface. From a remote attack not much of the kernel is exposed. You get TCP/IP stack but you can't just send the kernel system calls. When you attack a program like Firefox, you can now have Firefox exploit the kernel *locally* for you.

Hopefully that clears it up.

@n2sec,

No.

http://labs.mwrinfosecurity.com/blog/2013/04/19/mwr-labs-pwn2own-2013-write-up---webkit-exploit/

RCE -> Local Kernel Vuln. No steps in between, except to make the RCE more reliable.

EMET is purely userland hardening (it does nothing to prevent a kernel exploit), whereas PaX/Grsecurity are *primarily* kernel, though not nearly entirely.

 

That clears it up, thanks! I figured I was missing the boat

 

Interesting link, thks. Didn't understand it all but obviously they found a neat way to bypass ASLR and didn't need break out of Chrome's sandbox. That's pretty scary. But I didn't get this straight - would not EMET 3 divert this attack since only (?) EMET 3.5 protects against so called ROP attacks? I am not sure though if 3.5 would protect you against this abuse since the kernel is not protected by EMET.

 

Might make it more difficult, wouldn't make it anywhere near impossible. Might not even have an effect on it at all, actually.

It wouldn't change the kernel exploit in any way.

 

Yes, they can do that, and do do that when it's time to take the information to a judge. However, in the case of the NSA, it isn't really required to really try and establish a presence on the target system. Instead, they have several "mini-facilities" set up at a number of ISP buildings that tap into the actual backbone traffic. It enables them to monitor and analyze all traffic, foreign and domestic coming in and out of those buildings (network traffic of internet users, not just on-site traffic). So basically, they're monitoring traffic of criminal and innocent alike and have all the data they need to take to court without having to go through the ugly mess of exploits and getting past your security. Your security won't alert you because there is nothing to alert you about. It's all normal traffic, no tricks, no "strange" packets and no break-ins.

I'll let things get back to the original topic of local attacks though.

 

Now you understand...? (I'm pretty sure) you are the one that was hung up on "physical access, running a special local application," etc. and not thinking the Elevation of Privilege updates were important?! I told you basically what Hungry Man said.

In Microsoft bulletin terms, EoP isn't really that different than RCE. It is, but just in that it requires an intermediate step (of any other exploit code), rather than an immediately successful exploit. That's how I think of it.