Software Restriction Policy vs Antiexecutable

If the file is run from the command prompt it still gets blocked by SRP with the message in the CLI box, "The system cannot execute the specified program". The block shows up in the event viewer.

 

That confirms SRP blocking execution from a command prompt.

Thanks for adding a screen shot to your post #49 -- I've wondered what the SRP message looks like.


----
rich

 

this is excellent news. thanks to rmus and spikeyb for the tests

 

Sorry to hear about your virus trouble. I do have two questions. Were you using Windows Defender with real time protection turned on and if so, did you choose the be notified by WD when installing software that was not classified according to risk? Thanks.

 

I believe one difference is that Anti-Executable has Copy protection, which prevents an unauthorized (new) executable
from downloading/caching from the internet or external media.

Those with SRP and are set up to test can try this MSN Messenger exploit posted today at sans.org:

http://isc.sans.org/diary.html?storyid=3961

This is not a remote code execution (drive-by) exploit, but obviously a direct link to download an executable,
although you wouldn't know from looking at the URL, which purports to be an image file:


____________________________________________________________

The AE alert message pops up almost immediately. I closed the AE Alert message and tried to force the download,
but after a short time, the download aborted with an error message:



____________________________________________________________

Permitting it to download (below), it's evident that this is not an image file. However,
you might expect that people wouldn't pay attention to the file extension -- which
is .com, so that double-clicking will execute the file. If it were a spoofed .jpg,
d-clicking would open in an image viewer, which would show nothing.

Remember in the previous example of a spoofed .gif file -- that file ran by remote
code execution, and was not intended to have the victim click on the file, as this
exploit is designed to do.

Also, in the original download dialog box -- a person might select "Open" instead of "Save"
and then it could be a mess, if there were not proper protection to keep it from executing:


____________________________________________________________

AE's Copy protection is useful in home situations where kids use the family computer:
No unauthorized executable gets downloaded, so there's nothing for Dad to cleanup/remove
in case of a "buddy list" trick like this.


----
rich

 

Hi

I do not have windows defender running.

After investigating further by loading a FDISR archive that was updated about one hour before I started doing the tests I think it was a false positive after all. During that hour I did not install anything.
Cureit could not find anything bad in the firewall process.

 

i tried going to the link and downloading the file (using my LUA with SRP). the file downloads just fine, firefox saves it to my desktop like other files. but when i try to execute it, i get the SRP error message. it won't run.

http://i227.photobucket.com/albums/dd84/zopzop/msnexploit.jpg

 

A couple of things:
- Even though it shouldn't make a difference, you should also try opening from the browser directly, not double-clicking the file. That's the test imo.
- How does SRP work really? Does it whitelist based on creation time? How do you go about and install something?

If i had it, i would have tried it. Unfortunately, it says XP Home, which means i was conned..

 

If you want something to run you have to put a rule for that app or folder.
I have whitelisted a folder from where executables are allowed to run from.

 

Thank you sukarof, and how did you made a whitelist of your already installed applications?

 

Pedro read this:

http://www.mechbgon.com/srp/

 

There is a place called "Additional rules" in the SRP settings.
You can choose by path or hash. I just put the path to the folder or executable in there and chose "unrestricted" which means that they will run with the rights my account has. You can also black list software there if you want to.
I have also removed the .lnk extension from the extension list that is controlled by SRP. Otherwise shortcuts on the desktop wont run.

 

Glad to hear its a false positive because I'm running about the same setup. I do use WD to let me know what is being changed.

 

TY Mike and sukarof.

From what i can see (and correct me if i'm wrong), the major difference is in usability.
In order to avoid adding programs to the whitelist 1 by 1, you have to whitelist folders.
While it is not a major hole in security, it still leaves a potential problem, from my limited view. It is the weak link if used. The alternative is adding 1 by 1, tedious but effective.

Because:

A script (1 example) could place an executable in Program Files for instance. This is not likely to happen (i think) but worth examining. Locally executed scripts should be the only ones that it can handle, as opposed to scripts interpreted by the browser. We set aside browser ones for now, since it is arguably a separate issue. Then for local ones:
-How does the script blocking work in SRP against embedded scripts? (in docs etc). Is it left to the program handling them (Word) ?
-And how usable is SRP with scripts, for those who use scripts regularly.

-1 final question : in the window where you exclude the .lnk extension, are you guaranteed that you see all extensions possible, and it is a matter of selecting them?
It seems obvious, since this is Windows securing itself, but i ask anyway for a clearer picture. TIA!

PS: i hope i didn't confuse myself..

 

I am not sure if I understand you right but no files can be copied to the C drive, including "Program Files" folder, unless you first give permission as admin. That is standard LUA behaviour.

A malware can of course be added if hidden in a software you are installing, but that is always the risk when installing software. But you have to white list it before it can run anyway.
Personally I didnt find it that tedious to white list software that I use. I´d rather do that than answer endless popups from HIPS. But sure, it would be nice if there where a faster way to white list the apps I want to run.

The extensions you see in the exclude window are those that are predefined. You can add extensions you think should be there.

I dont know about that, I have not encountered such.

 

I just got timed out here, and going back didn't recover my long post... this is a big Opera + and FF - .. i wonder if there's a setting or extension to go back properly, as in with history, not reload

Access rights, didn't think of that. That takes care of it.

It still leaves me two concerns:

1)you have to find and add extensions; is that number fixed and known, or does it change? Does it change with Windows updates, or possibly some program instalation (that adds executable extensions?).
If fixed, it should list them all, and it would be a matter of selecting them.
If not, the correct behavior would be block any executable by default, regardless of extension, and besides whitelisting, add extensions and folders to ignore. And it should detect new extensions and add to the list (i don't know if feasible, but just a thought).

2)how the script blocking works

 

I tried both ways, and the file loads into the browser each time as an empty image.

This is what happens with the AwfulPlasticSurgery explolit -- a script places an executable file into a folder.

The HTML page code downloads the spoofed .gif file which is then copied to the Startup Folder as "Update_...exe"

Here are excerpts from the de-obfuscated script code from the SloanTreeFarm exploit. The file names are different but the result is the same:


___________________________________________________________

Refer back to SpikeyB's post #49 -- his screen shot shows SRP blocking the execution of that Update_...exe file from the Startup folder.

Note that SRP doesn't block the spoofed .gif file -- it doesn't execute, rather, just downloads/caches to be copied as a .exe file to another folder.

As per this thread topic -- this example highlights the copy protection of Anti-Executable. Note the second screen shot in my Post #48: Because AE prevents the .gif file to download, it can't be copied to the Startup folder. So, when the code calls for executing that file, it can't be found.


----
rich

 

The part of the script i was worried about was saving the exe to program files and then executing, if you exclude the program files folder. But sukarof explains that LUA doesn't permit copy to that kind of folders (system folders i presume), so that's that.
BUT:
The script could potentially do harm by itself though, so the doubt on how it works stands for me.
And the usability of the whole adding extentions to block (default allow in place, instead of default deny, at least an option anyway).

 

So i googled a bit, and hit this page. Can anyone comment on it? Among the interesting parts (the whole page!), read points 11- MIME Types, 12- Unregistered Extensions and 19- Special Filenames (19 is more about general possibilities; what i intend to show is how tricky it is to block by extension only). Possibly 10 as well, but mainly 11 and 12 that concerns this thread.

PS:there's useful info in there besides this, such as showing ALL hidden extensions through the registry. It's one of those things, when you go to folder options and select to show hidden extensions, not all of them are shown... reminds me of the whole DEP in OptOut not working as intended either. Who are we kidding anyway..

 

Where is that link/page?

 

Sorry, I fixed it. And edited a bit.

 

I have these links:
- Software Restriction Policies
- Windows File Associations
- File Types
- Unmask Exploitable Files
- Google search
I think that I have more links in my (huge) favorites folder.

 

Bookmarked, thank you Lucas
But, pretty much all these try to enumerate file extensions, blacklisting sort of.

I just remembered this utility, which could be of use for SRP users, LExE (from the makers of Trojan Hunter):
http://www.misec.net/freeware/

 

Yep, it seems that we can't get out of Penetrate and Patch and Enumerating Badness

Interesting. I'll give it a try, altough it doesn't seem to do much

 

From MSDN Magazine:
Understand Common Virus Attacks Before They Strike to Better Protect Your Apps