Mis-understandings about Privilege escalation exploits

ssj100 wrote:

Anyway, still waiting on some POC's or live malware to test out. I posted on another forum asking (KernlMode.info), and no one's replied yet:

Hi, does anyone have any live malware files of remote code execution? I am most interested in scripts and macros. For example, malware hiding in a Microsoft Word macro or that executes via cmd.exe, cscript.exe, java.exe etc. Thanks!

There is this one: http://www.f-secure.com/weblog/archives/00001738.html

Sadeghi85 wrote:

ssj100 wrote:

Anyway, still waiting on some POC's or live malware to test out. I posted on another forum asking (KernlMode.info), and no one's replied yet:

Hi, does anyone have any live malware files of remote code execution? I am most interested in scripts and macros. For example, malware hiding in a Microsoft Word macro or that executes via cmd.exe, cscript.exe, java.exe etc. Thanks!

There is this one: http://www.f-secure.com/weblog/archives/00001738.html

Yes, I read about that one the other day. However, I couldn't find a copy of it.

Another one, #3: http://www.avertlabs.com/research/blog/index.php/2009/01/26/abusing-shortcut-files/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+McafeeAvertLabsBlog+%28McAfee+Avert+Labs+Blog%29

Both of those malwares need to download a separate file so I guess SRP would block them.

Sadeghi85 wrote:Both of those malwares need to download a separate file so I guess SRP would block them.

Yes, I would think so. Furthermore, the methods seem to (frequently) require the use of potentially dangerous (although useful) built-in processes like cmd.exe. As described in my security setup/approach post, I recommend directly blocking these with SRP:
https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16

In addition, here are some extra rules I would suggest adding to your SRP deny list with path rules:
To deny scripting execution: cscript.exe, wscript.exe, scrobj.dll, vbscript.dll
To deny registry access: regedit.exe, regedt32.exe
To deny command prompt execution: command.com, cmd.exe (if you’re using Sandboxie like me, make sure to read and carry out step 16 below. This is because Sandboxie relies on cmd.exe by default to delete the sandbox. You will therefore need to tell Sandboxie to use a different command instead)
To deny formatting: format.com
To deny running with elevated privileges: runas.exe
Other: debug.exe

Note that you can still make use of processes such as cmd.exe by simply renaming them. In this way, you as the user will be the only one able to initiate/control it (and not some piece of malware).

ssj100 wrote:As described in my security setup/approach post, I recommend directly blocking these with SRP:
https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16

Do you consider to block ntvdm.exe too? A few months ago there was a vulnerability involving ntvdm and it was advised to prevent access to 16-bit applications via group policy editor, I think it's better to block it with SRP?

http://www.neowin.net/news/windows-has-a-17-year-old-un-patched-vulnerability

Apparently blocking debug.exe would have prevented the attack:
http://www.cncllc.com/news.asp?id=90

This then disables the "DEBUG.EXE" process, which is what will effectively prevent the attack.

I don't know much about this vulnerability though - if anyone has a POC or live malware of it, I can test it out more. Unfortunately, no one ever does haha.

CNC brought up "debug.exe" out of no where. Here is more information and a PoC: http://archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html

This link is cited by the above article and mentions "ntvdm.exe":

Derek Soeder has previously reported some legendary NT bugs, including multiple
vdm bugs that, while unrelated to this issue, make fascinating reading.

- http://seclists.org/fulldisclosure/2004/Oct/404, Windows VDM #UD LocalPrivilege Escalation

Unrelated to the above issue, but I thought blocking ntvdm.exe would prevent this and possible future exploits, however after reading above links I think blocking by group policy editor or the registry tweak is safer, no need to block debug.exe or ntvdm.exe(or any other 16-bit executable) then.

Perhaps, but I'm personally not going to recommend blocking ntvdm.exe etc. Why? Simply because this exploit was one-off, and has long now been patched. Also, I'm not sure about the side effects of blocking ntvdm.exe etc - have you noticed any? Thanks.

EDIT: by the way, this vulnerability (like all similar ones), requires the user to execute "a specially crafted application". Now, I know Tranquility has written recently that the person executing this "specially crafted application" could be YOU etc. However, without any examples of a POC or live malware, there's no way to know if it's possible to exploit this (or any other) vulnerability without the ability to launch via a PE executable. If it requires a PE executable to launch the exploit, SRP would easily block this. That is my understanding anyway. Remember, we are talking about the home environment here - the home user would first need to get new code on to his/her system somehow, and this new code needs to be able to exploit the vulnerability somehow. Therefore, something needs to execute this new code - if it needs to be executed via a PE executable (like all live real-world malware I've ever come across), SRP would block it. Of course, as Tranquility suggests, if it's possible to launch this new code by eg. visiting a web-site which doesn't involve a PE executable, then you could still get owned. However, having NoScript (or similar) enabled would most likely mitigate this. And with my own setup, Sandboxie would easily contain it anyway.

As I've said, I now block 16-bit apps with gpedit.msc, no need to block debug.exe, ntvdm.exe or command.com with SRP then. The only exception in your block-list is format.com which while being 16-bit, it still can be run.

Sadeghi85 wrote:As I've said, I now block 16-bit apps with gpedit.msc, no need to block debug.exe, ntvdm.exe or command.com with SRP then. The only exception in your block-list is format.com which while being 16-bit, it still can be run.

Sorry, when I wrote "etc.", I was including blocking via gpedit.msc. So, any side effects that you've noticed so far? Anyway, what's so hard about specifically blocking various executables?

Not hard, it's just not necessary when there is an option in your OS specifically for dealing with 16-bit apps. ntvdm.exe is 32-bit so it's not blocked but there is no side effect if you block it. I did block it for a long time when I used to use Online Armor.

Sadeghi85 wrote:Not hard, it's just not necessary when there is an option in your OS specifically for dealing with 16-bit apps. ntvdm.exe is 32-bit so it's not blocked but there is no side effect if you block it. I did block it for a long time when I used to use Online Armor.

Thanks for the information. I wonder if the OS ever needs to deal with 16-bit apps in this day and age? I'm talking about the average home user of course (which I myself am on my REAL system haha...I only do "crazy things" like test malware in my sandboxed Virtual Machine).