How would you get infected?

It means there is NO exploit (e.g. not very difficult; but impossible) just "boom," on its own. Really, nothing's going to exploit the vulnerability other than other malicious code that's "specially crafted" to target it. So, "specially crafted [already-running] code" vs "specially crafted Web page, file, etc." that you seem to apply patches for.

All it means is that another intermediate step is needed. So you better make absolutely sure that no other bad code is running, and then you're fine. Yet other parts of your setup (UAC, AppLocker/SRP, EMET, Jetico, etc.) seem to suggest that you DO expect less than trustworthy code to run on your system. So you either DON'T need that stuff (seriously; why?) or you DO need the EoP updates...

 

You know, I never came out and stated privilege escalation is not possible, only attempted to illustrate that with those MS statements which you all dispute, suggest that that some of these exploits are of less concern than others. Notice the rating of "important" as opposed to "critical" on some of them? It's your guy's words against MS' word.

I earlier asked for clarification from Hungry on what he meant by "Local", he kindly explained, I thanked him, and figure that's it, but someone who has come after me before does it again with a inflammatory post. To me it was trolling and I said so.

No I don't expect other untrustworthy code to run on my system because of my security setup; it should prevent it from running.

These exploits you guys talk about are obviously not standard "cookie cutter" recipes that all work the same way. Clearly some are more difficult to successfully pull off than others. You might note I'm not the only one here who omits some updates, while continuing to remain exploit and infection free.

 

Privilege escalation is already a common tactic used by prevalent malware families, e.g. several rootkits and bootkits I've read up on lately. So I agree, it's better not to be that choosy about which security updates we will or won't install. There's certainly no harm in reading up on the details, but at the end of the day, it's advisable to get them and install them. I fully expect the bad guys to study them for any new attack vectors they might present.

 

No, just DoS. No elevation or code execution to do anything. Just the possible inconvenience of a crash/restart. Very little threat there.

http://blogs.technet.com/b/srd/archive/2013/02/12/ms13-018-hard-to-let-go.aspx


But look at the update it replaces, KB2688338 in MS12-032, which is definitely important (the Firewall bypass sounds more like RCE than EoP).

And what does it replace? KB2588516 in MS11-083!

So while it would be OK to skip KB2790655 if you already had KB2688338, if you have a fresh install and have the latest KB2790655 available, just install that obviously (since it's the latest and doesn't hurt) because it includes ones that DO matter earlier in the update chain!

 

Yes, it is certainly very much true that some of these exploits are of less concern than others. That's certainly also why MS rates one type as important and another as critical. Let's note, though, that "important" is still a pretty strong word, isn't it? I don't dispute MS vulnerability severity ratings in general, only some of their very political style and misleading statements in their security bulletins. Important distinction there. To put it this way...

Remote code execution is critical, because it's bad on its own. The attacker exploits this one vulnerability, and bam, he's got his code running in my system. Nasty. And, if he knows other vulnerabilities, he can then try to exploit them, gaining further access in the system. All of this, possible because of that one remote code execution vulnerability. Time to patch...

Local privilege escalation is important, because if you've got remote code execution first, then you can use local privilege escalation to gain higher privileges and totally root the system. But, it's not critical, since it can't do anything by itself - it needs that attacker code running on the system first, in order to exploit the privilege escalation vulnerability.

All that is one thing. Then there's the issue that every single vulnerability is unique, and some of them are more difficult to exploit than others of the same class, due to the kind of mistake in the code that created the vulnerability (the worse the mistake, the easier it is to create a good exploit). But that just means that creating a reliable exploit for the vulnerability is sometimes more difficult, sometimes less. Once you can code the reliable exploit, then it can be used in the same way in every case: first remote code execution, then local privilege escalation.

Well, we all know how forum discussions - or indeed human discussions in general - can be. Misunderstandings, confusions, disagreements aplenty, and people (like me) preaching on their favoured topics even if it might be a "little" off-topic in any given situation. My point here is just that local privilege escalation is much more "dangerous" and much less "local" than many people realize. All it takes is the help of a remote code execution exploit, and there's an endless supply of those.

Who needs to worry about local privilege escalation? People who are limiting their privileges, like people who run as limited users. People who think their system might fall victim to a successful exploit of a remote code execution vulnerability - if you're running with limited privileges, and if you're concerned about remote code execution, then logic dictates you should be concerned about local privilege escalation as well but on a scale of "how worried am I" a remote code execution should indeed rank higher.

I think that's all I got, and my glass is empty again. Have a fine weekend, guys!

 

Then why use UAC? Much more convenient if it was off, no? So annoying (still at default, yeah, I know can be bypassed < MAX) on the WMC HTPC (BTW: 0 updates after SP1 ISO install; should be no risk exposure the way it is). So I'm going to try to get something cool working for myself soon before XP updates end next year (and I'd of course make it available) so I could hopefully disable the UAC junk (please, I hope my idea works) and still keep high-risk stuff restricted like in XP and be able to USE my computer otherwise, as Admin, when I know what I'm doing.

Anyway, no need for UAC if you trust everything of course.

Why AppLocker/SRP? They'll never block anything.

Why EMET? That's only to protect against unpatched vulnerabilities, which you won't have.

Why Jetico's Process "Attack" filter? What would be "attacking" your processes?


Other than EMET (which can't stop everything of course), the other things would only apply AFTER untrustworthy/exploit code has already been running. I hope you understand that. NOT "prevent."

 

I was wondering if DoS meant DoS or if MS were adding a political twist in their description, as they do with some of their other vuln. reports. Obviously they were not.

Thx for the links. I apply almost all security patches except for those malicious file removal tools.

 

Ok, perhaps this post wasn't supposed to be replied by me but I believe SRP /AE will protect you even if hostile code has executed in your RAM. The hostile code that has been running to presumably own your browser session needs more than a RAM execution to gain privilege escalation and permanent access to your system. Afaik, permanent access in 99% of the cases demands infiltration using malware. SRP and ACL (deny execution in drive-by folders) will stop those. Unless the attacker is very dedicated (which has been discussed earlier. HM posted a link earlier showing how Chrome and System were rooted).

 

Just to touch on these two layers, they can be considered as secondary defenses, with the browser and its configuration along with NS + firewall setup running on a Standard account as the primary defenses. Applocker/SRP and Jetico may not ever have to block anything, but if something were to get by the primary layers, they could (no guarantees, but could) block something:

http://www.sans.org/reading_room/wh...ication-whitelisting-panacea-propaganda_33599

As for EMET, it's there to guard against anything not yet patched against zero days.

Sorry I forgot to mention the one benefit is IE's Protected mode, but I rarely use IE so I suppose in this context I wouldn't need UAC, but I keep it enabled at maximum, because if I'm in logged in the administrative account for maintenance reasons, I might launch the brower to look something up or download, so UAC enabled runs the browser with a Standard user token.

 

They certainly do block stuff, give them a try sometime. SRP is good enough that the NSA recommends it, and has their own config tips yonder: http://www.nsa.gov/ia/_files/os/win2k/Application_Whitelisting_Using_SRP.pdf App whitelisting is one of the "top four" security countermeasures in the Top 35 Security Controls, right up there with routine patching. Overall security effectiveness is rated "Essential."

Before I used SRP, I used custom behavior-blocking rules in an enterprise security package to accomplish most of the same effect. The results, as shown in my central logs, left no doubt that it was saving my users from both exploit payloads and their own gullibility.

 

Hostile code executed in RAM is all that's needed to target an EoP vulnerability. And once something is running as SYSTEM, for example, it can do anything and everything to gain permanent access (the elevation has of course already occured in memory/shellcode/etc.).

AppLocker/SRP doesn't apply to stuff running as SYSTEM anyway. SRP/deny execute doesn't apply (or at least I hope it doesn't) to stuff in the Windows/system or Program Files folder, all of which can be written to once elevation is gained.

Of course SRP and anti-executables (joke like Hungry Man already said) could prevent something, depending if they try to drop something to a temporary, user-writable location first. But that's absolutely not necessary.

Once something is running from memory/shellcode, it can attempt to build up and do everything from there (while working around DEP/ASLR/EMET/etc.). Once something can allocate memory and mark it executable, DEP/ASLR are out of the equation, I believe (EMET will still block some calls if they don't come from memory occupied by a REAL executable/DLL). Other complete programs and anything else can be loaded inside your exploited program without ever creating or loading another file.

One example: http://blog.didierstevens.com/2010/02/08/excel-with-cmd-dll-regedit-dll/

Especially this: http://blog.didierstevens.com/2010/01/28/quickpost-shellcode-to-load-a-dll-from-memory/
Maybe this: http://blog.didierstevens.com/2010/02/04/cmd-dll/

EXE -> DLL -> stealth load of DLL into memory (Not that an exploit has to do any of that, just that anything is possible in just memory.)

But it doesn't protect against everything, so any other 0-day that gets past it and tries to exploit and EoP vulnerability... will fail if you've applied those maybe-I-can-skip updates.

Yeah, I know. I'll have to see if there's any trick to use Protected Mode if UAC is disabled (since it would be related to the thing I will try to implement). Probably not, and it wouldn't apply in Sandboxie anyway (I heard it disables Protected Mode), but I'm always curious about making things work that aren't supposed to.

Anyway, again, IE's Protected Mode doesn't matter if there's nothing to "protect" against! And that (mostly) only applies to limiting what the IE process itself can do, NOT malicious code that still manages to execute (no more difficult than non-Protected), and possibly be able to elevate to full SYSTEM, etc. privileges.

 

Read my sig. Reattached again (usually only in my first post in a thread). I even rigged up "2-level" SRP -- how do ya like them apples? That means that SRP applies for stuff running with dropped rights (via SRP, of course) in my Admin account, but does NOT apply at all for stuff running with Admin privs. Default deny. Reg key to re-allow everything (*) is only readable by Administrators. Since SRP is user-mode, all works perfect. And yeah, I saw your site right after I discovered SRP (years too late ).

Bypass SRP: Shift + right click > Run as Administrator (added by me), script takes care of that. Would be handled by future EXE (for XP I guess this part mostly only applies to).

And I will soon release a patch for XP that fixes the built-in/by-design SRP bypass (breaking news right now ). At least (and first) for stuff in Sandboxie (dead simple; that's all I need and care about), but hopefully for the system as a whole for others, if it's not too complicated. Will be within a month for Sandboxie, and should be in assembly (if I'm not overlooking anything).

That's in addition to what could be MY biggest project yet, for Windows 7 (very much about SRP). Well, all Windows, but major for 7.


Anyway now, what you said: No, NO, NO, they absolutely do NOT block stuff in the context of what I'm talking about!

wat does not have any untrustworthy code, so what's there to block? That's what I was talking about.

And also, once there's Elevation of Privilege, SRP/AppLocker doesn't apply, and any sort of exploit can fully succeed without SRP/AppLocker ever being a factor. They're merely a speedbump. Albeit a large, pretty-good-for-now one. Can be made a complete non-factor.

That's all I'll say now that you know that I am in fact familiar with SRP, etc. I might be a bigger fanboy, BTW.

 

1. For abusing memory space you need app & system vulnerabilities. To gain local access and from there also gaining the coveted privilege escalation involves dedication.

Enterprise / business environments presumably use Applocker / SRP if IT department take security seriously. It's there the big money is, why haven't we heard of these targeted attacks against thousands of enterprises if it were so easy to bypass the mentioned security measures?
Getting shellcode and having access to your system, bypassing SRP, EMET etc all sounds plausible in theory, but where are the massive incident reports?

I'm also assuming and depending on the patches being timely delivered. Note that I don't tout SRP being a magic bullet. I go for layered defense, which includes among many, EMET.

The Didier's links you've posted, I don't see how this really has to do with SRP. You can enforce dll protection in SRP too.
"Faking" or converting an exe to become a *.dll will not fool SRP.

 

Seems like the discussion is moving towards a debate on the aspect of Windows security updates now. The ones involved and discussing so far - don't you guys notice that you're all mostly on the same page as far as Windows hardening goes? I can't help but to wonder why we're having this unnecessary disagreement.

UAC/LUA/SUA - enforce least-privilege
EMET - aims to break exploit in the early stage
SRP/Applocker - aims to deny payload (secondary stage)
Security updates - patch known vulnerabilities

None of these replaces the other. No amount of Windows hardening replaces patching. There's no doubt that most of us here can survive without patching...but that's besides the point.

Just think about it: Out of many others, here "we" are investing time and effort into improving our security base using what Windows offer itself. So, why risk it by being picky over security updates that MS releases to patch known vulnerabilities?

 

Oh, gotcha. Yeah, if stuff gets to SYSTEM then...

I appreciate the point that if something achieves EoP, it can bypass lots of defenses.

If you want to get extra-granular with your SRP, you can create a new GPO that applies to certain users or groups and then you'll have, I dunno, 3-stage SRP and it naturally can apply other settings as well. Guide here: http://www.sevenforums.com/tutorials/151415-group-policy-apply-specific-user-group.html

 

Must resist urge to throw up hands for n-th time today.

Yes, both are plentiful. That's why we patch, patch, patch, of course.

Umm, that's what any exploit IS.

"Dedication?" Umm, no.

I agree, these methods (SRP......EMET) are very effective. I was just answering your question (or rather, replying to your statement) about stuff ONLY running in RAM. So just trying to give an example and state that anything can be done that way.

Basically EVERY exploit IS shellcode!!! (It sounds like you think it's a mythical thing.) So there's nothing to "get" but an exploit. Bypassing SRP/AppLocker is very, very easy, and by design (yet I don't know that any wild malware even tries) -- unless the fix has been applied for Win 7 and (k, not Vista). If you don't know:

http://blog.didierstevens.com/2011/01/24/circumventing-srp-and-applocker-by-design/
http://blog.didierstevens.com/2011/...-applocker-to-create-a-new-process-by-design/
http://blog.didierstevens.com/2011/11/17/hotfix-for-srpapplocker-bypass/

Hopefully I'll be able to get a fix this summer for XP/Vista in general if anyone wants it (and for inside Sandboxie will be very soon, as I said).

There's nothing to "fool," since nothing is ever called that would trigger an SRP/AppLocker check. Thus, they can be bypassed with the fix applied (yes, this is pretty hardcore/complicated to load a DLL (manual memory set up, etc.) without calling normal DLL loading functions!).

The DLL checking checking part of SRP is no more or less bypassable than the EXE part. (Hmm, I wonder if an EXE can be loaded with LoadLibrary (maybe as DATA) and, and... well I guess that wouldn't serve much purpose. /pondering).

I'm not talking about renaming an .exe to .dll (if you meant that), but just (re)compiling as a DLL (basically the same, both PEs, just compile difference). But these last 2 paragraphs don't really have anything to do with anything anyway.

 

The discussion should be focused on what can be done to your system, realistically, not what could happen if the patches were delivered late, if the zero day vuln lived for three weeks instead of 2 days and the hacker had both financial and other resources to work with and so on. If there are no known vuln, or if the critical vuln was quickly patched there will be no hostile code execution in memory.

So, in theory I could fear my defenses are not enough.
Realistically, I don't lose my sleep.

 

Isn't this wonderful? It all comes down to many ifs... If this, if that, if something else...

I tell you this: Come up with a way to infect my system with a browser profile only allowing comms to www.wilderssecurity.com... Yes... another If www.wilderssecurity.com becomes compromised and host malicious crap....

Ifs and more ifs...

 

1. Yes we patch, it's a long lived habit of mine.

2. Gaining local access from remote perhaps is trivial but to abuse the system you need more stepping stones / vulnerabilites. Chaining a complicated attack is not trivial if it's automated, that's where dedication comes in.

3. IF there is no further vulnerability, after the attacker has gained local access, you mean it is still trival to gain root access? I'd say it takes dedication to gain root access if there's nothing to abuse, or, even if there were additional vulnerabilities, chaining a successful attack calls for dedication. Just look at Chrome Pwniums.

4. It wasn't my intention to make it sound as if shellcode was a mythical thing. Anyway, I agree SRP would not block memory execution but depending on the route the attacker takes SRP could play a vital role. OTOH, If the attacker is satisfied with working with app / system vulnerabilities that in the end grants him privilege escalation, and he certainly does not need an executable to gain permanent access, fine, SRP won't help a bit.

Bypassing applocker /srp - I know about the MS fix that remedies a serious bypass scenario. I am also wondering about the almost meta-discussion we're having. So it's been said that SRP is so very easy to bypass, because execution is done in the memory etc, but instead of describing the attack scenario in such a very general and generic way, why not show how this realistically can be carried out. More details describing each step please. What would you do to gain permanent root access on my (see signature) system?

5. No, I'm not talking about renaming an exe to dll either. My goodness, it's Didier's blog we're discussing! No I meant since dll protection can be enforced in SRP/applocker, wouldn't it protect against "dll attacks" too.

 

"What if" discussions can be fun and I can say I learn a lot. But in the end, most of them are theories, some not so plausible and very often, these attacks would heavily depend on zero days that most likely will not be left unpatched..

 

I don't disagree. We share similarity in our setup. Of course, there's no need to lose sleep over it today but my point is patches are important. Theory and practice goes hand in hand. What is theory today is today's minority and may possibly be tomorrow's practice.

 

Isn't that's what it's all about? "Ifs". If scientists, mathematicians didn't make theories out of "ifs", we wouldn't have advanced to our present state. "Ifs" are not just important...they are a necessity in most aspects of life but I digress...

 

No, just take a combination of remote & elevation. Ones that exist can be varying degrees of trivial or not, of course. But combining them together should be fairly trivial (seemingly the easiest part; unless you're stealing other exploits probably, then the combining work would have to be done, but still, that's simple).

Of course not!

pwn2own, etc. is with fully updated stuff! So yeah, they're doing new things they've discovered. Of course if you keep stuff updated, and you'd need a combination of new exploits (vs a new combination of existing ), then things are really safe... That's what this whole discussion is about. Of course if some people choose not to apply certain updates, then only a new remote (discovered all the time) is needed to exploit an elevation one that may have been fixed forever ago.

Didier's blog describes/shows and even has the downloadable demo of how it's done to try it.

Once some shellcode is running, I don't know anything that would prevent loading a DLL from memory (e.g. not a file). Of course that's not necessary, and the entire "thing" the attacker wants to run could be shellcode I guess, but that's more complicated. So if it can be a normal DLL that can be loaded without being detected, that helps. Of course, I guess that DLL could be in a file (even though I said not), but instead of a "normal DLL load" (detectable), just read it in like any file (including remote) and do the "load as DLL from memory."

That's easy! Are you all updated? Then absolutely nothing of course! If everyone would just understand that.

 

The topic's kinda moving into well-worn territory. In terms of discussing the issues with SRP I've covered it extensively.

@m00n,

Yes, the idea is to come up with "if's", that's basically the point. None of my "if's" are likely, it's just something fun to think about - a challenge to hack yourself.

As for needing credentials...

Needing credentials = needing ability to run code = needing remote code execution

They should all, for the sake of this conversation, be considered logically equivalent statements.

Moreover, Wat, you are correct. Not all kernel vulns are created equal - some are quite difficult to exploit, some are unreliable (newer OS's make reliability more difficult). But don't use "you need login details" as an indicator, that's just MS's poor wording meaning that an attacker needs the abilities that a logged on user has.

 

I don't really care myself, I won't apply any of those patches until they come in service pack format. And further, odds are very high that I will never have an issue because I am not patched.

But as to this discussion, we have one party with the viewpoint that if the creator of the stupid OS and the patch says, very explicitly, there must be X criteria for exploit to happen, then by the gods that should be the way it is. And of course there is the other party who see this as well, but understand it isn't that simple or just plain not true.

The discussion is the way it is because both parties are correct, from 180 degree viewpoints. While one party is informing the other about the fact that you cannot always trust what you read, that other party is actually using what is written as a guage for what updates are applies. How are you supposed to make a decision if you can't trust what is written then? Quite a predicament for wat0114 actually.

Wat, maybe you have to spend even more time on each KB to determine if they are even telling the truth lol. Or you just don't update or take whatever they give you. But then, if they aren't correct in the description of the KB in the first place, how do you know it won't in fact screw something else up? lol, I am blissfully ignorant my friend.

Sul.