Pwnium 2 Begins - Chrome Hacked Again

I find that Low Integrity is both too restrictive and not restrictive enough.

What I mean by this is that, as a user, if I have the broker process running at low integrity I'm blocking myself from being able to launch downloads at medium integrity, I'm disabling writing to most of my folders and I have to set those to LI as well, and I'm making things a bit more difficult for myself - I have to rely on manually setting files back to medium etc.

And it's not all that restrictive. Low Integrity still gives reaed and write access to much of the system.

 

Yes, I understand about the restrictive nature of the downloads. I assume you realize that if you copy a download to a default medium IL directory, that Low IL is removed and replaced with medium. This is what I do when I run chromium at low IL. If I want to keep it, I copy it. Don't have to manually change it. This also lets me keep my downloads directory grouped together so I don't lose anything I downloaded until I archive it.

When you say "not restrictive enough" are you meaning it still has read access to perhaps sensitive areas? It should not have write access to anywhere but a few places. I can't recall off the top of my head, but isn't default allowed to read and execute, but not write or modify to higher ILs?

Sul.

 

Yes, I know. I did that for a while when I ran Chrome at LI.

It has write access to the entire user directory. It has read access to the entire system. Read access in this case is more dangerous. Reads lead to data leaks about the system that can make local exploitation easier.

A LI process can read and execute another process at its integrity level but it can't write to it, yes.

 

How does that happen?

By design a lower integrity level object cannot write to an higher integrity level object/container, and MOST of the user directory has a Medium integrity level. And, if you got no use of whatsoever for Internet Explorer/Adobe Reader, you can actually remove the very few low integrity level folders meant to be used by Internet Explorer/Adobe Reader, including the Registry hive with low integrity level, completely removing low integrity level containers from user space.

What it has is both read and execution access. I don't know about you, but I would never have any sensitive information unencrypted in my system, and therefore the fact that a low integrity level object can read other objects is of no concern, of whatsoever.
Regarding execution, well... Windows isn't limited to WMIC, is it? Therefore, you are in part only limited by your knowledge about the operating system you got in hands.

Are we talking about sensitive information being stolen? I'm not sure what you mean with "data leaks about the system". Are you referring to third-party executable with known bugs that could be abused?

 

I thought that parts of the user directory were low integrity but after thinking about it I realize that wouldn't make much sense.

Read access isn't about your sensitive files necessarily. While that's still an issue it can be mitigated through encryption like you said.

Read access allows an attacker to learn about the system they are on. Information about what processes are running, what the user has installed, which patches they have installed/ information about the OS, etc. Knowing this information is dangerous.

On top of that if the broker doesn't have a token for a separate UID (the renderer does, a UID with no rights is assigned to it) it should have read (maybe write?) access to other processes address space from that same UID.

 

Parts of the user directory do have low integrity level containers and objects, which are necessary for Internet Explorer and Adobe Reader X, as I previously mentioned. But, if you got no needs for any of those applications, you can easily check which folders and objects you should removed the low integrity level with Sysinternals AccessChk (I think that's the name of the tool... something like that... ), and make them Medium integrity level.
There's also a Registry key HKEY_CURRENT_USER\Software\AppDataLow... I don't think there's any other... memory doesn't keep track of it all, after a long time...

Yes, which is why I wasn't sure what exactly you were talking about. Whenever I read "data leakage", I immediatly think of sensitive stolen information.

Of course... And, I'd like to have AppArmor functionality to an extent for Windows... I've suggested it to be included in AppGuard (home version)... so, let's see.
But, that does not necessarily mean we're all doomed in any way, because you can actually prevent exploits from being triggered, in the first place... if that fails, then you can mitigate... if that fails you can stop execution... if that fails, you can contain it... if that fails, you can start over from a previous snapshot... But... I'm a believer that a good policy strategy will prevent that from happening.

For instance, you have asked what are my measures... well, without revealing it all, I can say that one of those measures is only to allow connections to a predifined set of websites... which are only a few. This by itself will reduce the probability of having the browser exploited by a lot. Unless I'm wrong. But... let's live dangerously... lol

 

How?

Yes, with a MAC system, which Windows doesn't really have by default.

How? If the kernel is pwned, you aren't stopping anything.

 

By blocking the code that triggers the exploit? The exploit needs to be triggered somehow, doesn't it? That how the old Exploit Prevention Labs LinkScanner worked, which then became AVG LinkScanner (Surf-Shield component). While not flawless, it does provide a line of defense, which will help prevent the exploit from being triggered.

Sure, it's also a mice and cat run, because cybercriminals will always be finding ways to conceal the actual code.

I thought that's what Microsoft EMET was meant to do? To mitigate? It does have exploit mitigation techniques, so I believe the goal is to mitigate. While not part of Windows by default, it's now supported by Microsoft. Hopefully, more and more people will be using it, especially if people like us deploy it to others. There's also ExploitShield... maybe others. 100%? Is there really anything that is?

Hence I also mentioned starting over from a fresh snapshot. Also, If the kernel is pwned wouldn't imply that the exploit code needs to be triggered and successful? And, is it 100% impossible to prevent the exploit code from being triggered? Because, if it is, then I'll accept that truth.

 

I'm not saying LI is weak, I'm just saying it could be stronger. It's overzealous in some ways and not strong enough in others. But it'll still make things more difficult for an attacker.

 

I agree. I wish Microsoft could have gone further with WMIC, like they do in Windows 8 with AppContainer (which I believe is only for Metro apps?).

 

No it's not just for metro apps. Any program can use it AFAIK.

 

Yes, you're right. I was making confusion, because IE10 comes with EPM disabled due to plugins compatibility issues... or, so I think I read about it... anyway, it does work for Desktop applications as well.

 

The problem I have with Windows IL's is the seemingly lack of granularity it has, making it too easy to break functionality when trying to lock something down with it. With Apparmor, however, one can control exactly how a profiled application can influence specific directories and specific file types or even specific files it needs to interact with. Basically one can allow an application only exactly what it needs to do in terms of the minimum functionality required from it without breaking it.

I realize the two architectures are apples to oranges, but they are both applicable to security measures applied to applications (applications only with apparmor) and objects, but with apparmor it's not user-specific.

 

That's true. But, AppArmor has a weakness that the current WMIC does not have - it bases its protection on path names, and AFAIK it doesn't check their integrity.

 

It's based on path names but it's not much of a weakness. It denies mounting for this reason and a sandboxed process can't write to itself (ie chrome.exe can't write to chrome.exe).

 

No it requires hacking *any* of the 650 CA's and stealing any of their root or intermediary certs. You do that and you can literally impersonate any website on the Internet and the browser won't flag it. And you don't even need to hack them. Some CA's were caught selling root certs to corporations for internal use (of course, nothing stops them from MiTM'ing any site on the net). Some (Geotrust) were selling root certs to *anyone* that "promised" not to use them for MiTM attacks. And then you have the issue of governments forcing CA's to give them root certs for snooping, etc. The whole thing is a mess.

I would like to see some method employed that allowed users to see what cert a website is supposed to have so they can verify it manually if they so choose. For that you would need an honest broker to publish the directory. And you need to make the directory redundant in some way so there is no single point of failure (to stop someone from hacking into the directory for instance). One method would be to use a distributed system much like Bitcoin does (every user has all the transactions downloaded to his own machine so there is no single point of failure). So, essentially, every website owner would voluntarily publish the cert to an open directory so it could be cross-checked. Of course, the CA's will fight this tooth and nail because they don't want their cash cow being diminished.

Convergence sort of achieves this, but the problem is it doesn't verify the cert is definitely the right one, but rather simply reports whether it sees the same cert. The assumption being, if various servers around the web see the same cert, then you *probably* aren't being MiTM'ed. However, it's possible someone could MiTM the convergence notaries and make them report the same fake cert you see at the website. It would just all depend on where the attacker had set up the MiTM attack (it would likely take a powerful entity like NSA to pull this off but it's still possible).

I would also like to see NIST (or some other group like it) bring together cryptographers to write a new SSL standard from the ground up. Let it simmer for a couple of years, let people attack it, tweak it, etc. Then publish it and make it the standard.

Bottom line: while HSTS has some value, it by no means "fixes" SSL whatsoever. Until the CA system is fixed, we won't have any real security.

 

Right, my point is that in one situation you need to somehow acquire a certificate but with SSLStrip you need nothing.

I'm not saying that it isn't a problem I just think SSLStrip is much worse.

I think a combination of Parallels and HSTS would solve most problems with SSL.

And I think the CA issue is less serious than the SSLStrip issue.

 

Well sslstrip is sort of social engineering in a sense. All it does is force the browser to connect via HTTP without the user's knowledge. An astute user would always ensure the padlock icon is enabled. And if sslstrip spoofs a fake icon, one could always be sure HTTPS is in the address bar. Of course, most users wont do that, so I agree it is a problem.

It is for most people since sslstrip is so easy to use. But I think the CA monster needs to be addressed at some point. But since there is so much money involved, it probably wont be.

 

Yeah but it can be bypassed by a skilled attacker. I would wager Jonathan Brossard (from France) could do it. He is mostly a Linux guy, but he has demonstrated bypasses of ASLR/NX/RELRO on Linux (and even on Grsecurity hardened kernels). He is also the guy who came out with that Rakshasa malware recently which infects the BIOS. The only way to get rid of the malware is to throw the hardware away (reflashing the BIOS will not work).

Of course, you would probably need someone attacking you directly to pull most of this off, but it's still very plausible and has been demonstrated in the past.

How do you propose to do that? If there is an exploit in a kernel process and an attacker has a way of reaching it, it's game over.

 

EMET isn't MAC and EMET isn't enough. USER_SHARED_DATA makes ASLR a lot less relevant.

Wiping would still solve this. Unless they're ~ Snipped as per TOS ~ and decide to screw with your hardware lol

It spoofs the lock and I think it spoofs the HTTPS header too.

I agree

 

If there's an exploit in a kernel process, won't the attacker still need the user to go to some URL hosting the exploit? And, won't the exploit be triggered by code? So, first the attacker needs to get the user from point A to point B, and even then, the URL exploit code needs to be triggered. Won't it?

 

According to the linked article; Short of running every imported product through a very stringent series of tests and re-flashing firmware with known-good versions, this risk is unavoidable.
When in your network card firmware, your sool but I don't read it being BIOS flash persistant per se. Unless the mobo has a BIOS crash recovery/backup feature oc, then it could also be placed there.

 

I think the CA issue trumps everything, the only thing worse would be a hardware backdoor.

I bet you any money you like that Thwate who supplies Gmail with SSL CA'S have supplied Governments with fake SSL Certs to MiTM.people

 

Well, perhaps. They're both major issues I think we can agree on that much.

 

Yes we can