AppGuard

Kees1958 wrote:Text files are never contained by DW because they can't contain code.

While I would agree that "Notepad.exe" would be highly unlikely exploited (not 100% of course), this wasn't the main point I was trying to make (in that link). By the way, it's interesting how you seem to ignore some of the statements I write, even though some are statements correcting you haha. You've also taken your "mocking" tone to the next level. All good though haha.

Kees1958 wrote:
WMF exploits are tacked by DW, BZ, GW. Try your text file test with other formats (e.g. a video or a picture) and you will see they are all protected. So your conclusion is based on a file type which is never contained.


Yehaa beware of text based exploits, nice work around, I will implement it for sure when text based intrusion occur in the wild

I don't quite understand why you've brought up WMF exploits? I demonstrated that picture and video files (not sure if video files have been fixed, but I know picture files at least still have the same issue) are not protected if Windows Picture and Fax Viewer etc is your default picture viewer. Picture files have been exploited (several times?) in the past.

Have a look here for another reason to sandbox explorer.exe:
https://ssj100.forumotion.com/t385-defensewall-personal-firewall-at-bits-du-jour#3322
Didier Stevens himself demonstrated such an exploit (a similar concept anyway), although I don't think it's ever been seen in-the-wild.

Kees1958 wrote: Any idea how a staged intrusion developes through an exploit?

Are you doubting the accuracy of my statements? I'm pretty sure that ssj's POC has demonstarted behavior that supports the mechanisms I've just described. I have devoted a lot of time to understand what are and how bufferoverflows operate. I can say with all confidence that Ive mastered these concepts.
I'm assuming that its not a rhetorical question, so will post the anwser:

Shellcode injection phase: Code purposed to subvert the web browser is downloaded by exploiting a vulnerable component of the web browser.
Shellcode execution phase: The downloaded code is then injected into the web browser process.
Covert binary install phase: The web browser, now compromised, tries to retrieve malware from the attacker’s web server. That code installs on the victim’s computer.

BTW have you ever tried Sandboxie? You should, cause you'd be missing out on alot otherwise.

Rico, which POC are you talking about? Is it the recent DLL exploit one? If so, I'm actually not sure exactly how it worked and whether AppGuard would protect from all variants of it. Perhaps Kees will enlighten us.

However, what Kees has been describing is that even though AppGuard doesn't block DLL loading directly, it indirectly blocks it by blocking the two methods of DLL loading:

DLL needs to be loaded by another executable (e.g. Com or Exe): AppGuard user space protection stops this.

Another way of executing a DLL is to inject it in another proces. AppGuard's memory protection stops this

The thing is, I'm pretty sure I tested a recent version of AppGuard to see if it blocked DLL injection - it failed. There are a of couple reasons I can think of for this:
1. I tested it with Windows XP - perhaps AppGuard's memory protection isn't as reliable with this OS.
2. I tested it in a VM - its protection may not function so well in VM's.

And yes, pretty sure Kees has tried Sandboxie - I think he's just trying to let everyone know (or strongly remind them) of alternatives, particularly myself haha.

EDIT: actually if I recall correctly, I think what I tested was the loading of a DLL by a "Guarded" application:
https://ssj100.forumotion.com/t341p15-question#2928
I observed that AppGuard failed to block this DLL loading. Not at my usual computer right now, but I may try testing it again later if I get time. I'm not sure if this is a good test in this context. If I recall correctly, the problem is that the test was a bit artificial in that I had to disable AppGuard in order to create the DLL (although I think the DLL could be obtained via other methods without having to execute "firehole.exe"), and then re-enabled AppGuard to continue carrying out the test. I suppose the point is that if "firehole.exe" was in fact a white-listed application, the user could then download a malicious DLL which is loaded via the white-listed application, even though the application is "Guarded".

By the way Kees, I'm now quite confused about this DLL protection:
http://www.urs2.net/rsj/computing/tests/AE2-3/

because AE v.3 does not white list DLLs, it permits the DLL file to load and carry out the commands

This really sounds like a weakness in version 3. What happened to all that "alternative" protection? And how about DLL's with spoofed extensions? Seems like version 3 (and I think 4) failed this too:
http://www.wilderssecurity.com/showpost.php?p=1832392&postcount=27

Also, what's up with this?:
http://www.wilderssecurity.com/showpost.php?p=1832606&postcount=33

Versions 3 and 4 don't run on Win2K.

I'm even more confused now, since you wrote:

Kees1958 wrote:About Faronics: would you think an innovator of deny execute of the first hour would suddenly introduce a hole in their protection? Come on, get real. They put it back on because of marketing reason (no discussion with people in Social Media who do not understand what they are talking about) or for people running older OS-ses (Rmus runs Win95 or 2000 as I recall).

Regardless, it's pretty clear that "Exploit Analyst" Rmus is very keen to have direct DLL blocking back in version 4, at least for systems that run Windows XP. This doesn't sound like a marketing stunt to me!

Hello ssj100,

I'm currently looking into AppGuard and with some searching found this topic. I'm a bit concerned about the low frequency of updates with regards to vulnerabilities. I saw your LNK test from July '10 which AG failed, and with the retest here from Feb '11 against a newer version it still fails. I was browsing some AG topics on Wilders and around the same time of the retest, someone posts that it still fails and the reply is that is being looked into, but I didn't see any confirmation that it was fixed. Would you be willing to retest the latest version agains the LNK/Excell macro exploits and the buffer-overflow tests?

Did you delete your account on Wilders btw? I was unable to find it and only found a few posts through Google.

BoerenkoolMetWorst wrote:Hello ssj100,

I'm currently looking into AppGuard and with some searching found this topic. I'm a bit concerned about the low frequency of updates with regards to vulnerabilities. I saw your LNK test from July '10 which AG failed, and with the retest here from Feb '11 against a newer version it still fails. I was browsing some AG topics on Wilders and around the same time of the retest, someone posts that it still fails and the reply is that is being looked into, but I didn't see any confirmation that it was fixed. Would you be willing to retest the latest version agains the LNK/Excell macro exploits and the buffer-overflow tests?

Did you delete your account on Wilders btw? I was unable to find it and only found a few posts through Google.

Hi BoerenkoolMetWorst, I'm not too sure about the development of AppGuard, but I do know that they worked on it quite hard from version 3. Version 2 in my opinion was a bit of a joke, as it couldn't even block command prompt and scripting executables or control DLL loading. I think they're at version 4 now? From memory, they've done even more work on it and developed some form of MemoryGuard. I think this "MemoryGuard" can block many forms of buffer-overflow exploits, but most likely not all of them.

Unfortunately I don't really do exploit testing anymore. What I do know is that sandboxing (and knowing when to delete/terminate the sandbox) is still your best bet against all the exploits/malware. Technology like "MemoryGuard" or anti-logging (ala Webroot) can only protect against so many exploit variants before it starts breaking normal processes.

EDIT: oh and I got banned from Wilders a long time ago. Still not sure why.

ssj100 wrote:
Hi BoerenkoolMetWorst, I'm not too sure about the development of AppGuard, but I do know that they worked on it quite hard from version 3. Version 2 in my opinion was a bit of a joke, as it couldn't even block command prompt and scripting executables or control DLL loading. I think they're at version 4 now? From memory, they've done even more work on it and developed some form of MemoryGuard. I think this "MemoryGuard" can block many forms of buffer-overflow exploits, but most likely not all of them.

Thanks for replying They're currently still at 3.4.2.4

ssj100 wrote:
Unfortunately I don't really do exploit testing anymore. What I do know is that sandboxing (and knowing when to delete/terminate the sandbox) is still your best bet against all the exploits/malware. Technology like "MemoryGuard" or anti-logging (ala Webroot) can only protect against so many exploit variants before it starts breaking normal processes.

True, though sandboxing is not the only solution to properly protect against exploits, you could block execution and in case it does not write to disk, limit the browser and other applications with solutions like Defensewall's Untrusted/AppGuard's Guarded/customize the applications rights with custom HIPS rules/Low Integrity level etc.

ssj100 wrote:
EDIT: oh and I got banned from Wilders a long time ago. Still not sure why.

Hmm, a stupid move to ban such a knowledgable user..