BTW, next time you leave a comment, you might consider logging in, since the URL you specify for your username will be linked from my blog without nofollow (ie. with "follow").

Regards.

(And if I find the linked blog interesting – supposing that it is a blog – I will most probably subscribe to it :-))

Even after these new discoveries about bypassing SRP though, I don't think anyone has ever publicly reported seeing SRP-bypassing malware in the wild, even malware only used in targeted attacks. I've never seen any malware that makes even an attempt to bypass SRP. The few targeted attacks I have seen had no method to bypass SRP. Most were just attempts to exploit new Adobe Reader vulnerabilities by sending personalized and very legit looking email with a PDF attachment to people in the company that deal with PDF files all the time. So I think I'll agree with you that SRP still provides pretty good protection agains malware. =)

My point is that it still can be bypassed, and one needs to be vigilant at all times if one wants to maintain security.

For example, it would not be difficult to confirm if you have macro-capable software or PowerShell installed on systems, and then take actions to limit exposure IOW disable that stuff if at all possible.

Vulnerabilities are a more difficult case, but keeping up with the patches often helps, as the real zero-days are a minority. Many attacks attempt to exploit vulnerabilities that have had a patch out for a long while.

I really do wish that M$ can take SRP into the kernel in the future, so bypassing it can be made more difficult.

Re. the executable code, a lot of stuff is executable, but that goes for Linux too. From window managers to Adobe Flash or Open Office many Linux apps have arbitrary code exec vulnerabilities that could be exploited to execute stuff that some wouldn't realize was executable in the first place. I don't know of any OS that can avoid stuff like that.

Great analysis and blog though. =) Interesting reading. Keep up the good work!

the main point is that any kind of executable code of any privilege level (ie. even limited user) can bypass the SRP. As for limiting the possible exploitation paths – they are quite a few (and these are only the ones which come to mind):

– other applications might have macro capabilities installed which don't have an option to disable it or the option isn't set (relying on non-default settings being set is not a very good method). Example: OpenOffice, CorelDraw, etc

– the same patching is most likely possible from PowerShell (which nowadays gets installed by Windows Update)

– there are a lot of exploits in widely-used third-party products (like Flash, Acrobat Reader, etc) which result in arbitrary code execution

– just these days a new arbitrary code execution vulnerability for some MS ActiveX component has been disclosed

(You might also want to check out my post What is an executable file anyway?)

My point is: there are numerous ways to get executable code on your system, and it is very hard to guarantee that none of those apply to your environment (unless you run Linux :-p).

About these bypassing techniques, though…

The runas method is obviously very easy to prevent by blocking runas.exe in the policy by hash & path.

The method of using Office macros to load a DLL or directly edit the Excel process is also easy to prevent by setting macro security to high.

How about the other methods, though?

Alternative bypass 1, or in-process patching of the SRP check routine? How would one perform in-process patching? Wouldn't you first have to execute code through scripting like Office macros, for example, which is easy to prevent, or by exploiting a bug that allows you to run arbitrary code?

How would one be able to use Alternative bypass 2 or NTCreateProcess to bypass SRP? Wouldn't that require that you could first execute some code and then use that code to NTCreateProcess what you wanted? And wouldn't the initial code execution be preventable, either by SRP or by script language security settings such as the Office macro security settings?

Point is, aren't these methods of attacking SRP rather extremely limited, in that they are mostly preventable?

And you're absolutely right: I've said it before, and maybe I should stress this more, but it's not because there is a way to bypass a protection mechanism, that said protection mechanism becomes useless.
GPOs & SRPs are still very useful, certainly from preventing extra helpd-esk support for users who continually "tune" their configuration.

IMHO, these techniques will only be used in a targetted attack/penetration testing scenario.