Software Restriction Policy vs Antiexecutable

You're welcome .

The fact that I used a VBScript was not what I wanted to emphasize. It could have been a buffer overflow exploit instead attempting to download and run an executable with a non-standard extension.

 

Yes, I did that. My question was if those who tested could tell from the code that WinMgmt.exe was the application being used to launch the executable.

 

ok mrbrian, i put it in my /program files directory and then switched to my LUA+SRP to run it, strExe = was set to my limited user accounts desktop's atfcleaner.exe i clicked on the .vbs file (it worked this time, there was no error message) but nothing happened. it didn't execute the file : aftcleaner.exe

let me add that i'm confident i did it right this time because when i ran the file in admin mode, it opened up atfcleaner.exe just fine. but under my LUA with SRP, it didn't open it. the vbs file ran but nothing happened.

 

So SRP worked properly, right? . If you had copied aftcleaner.exe to aftcleaner.zop, for example, SRP also would have done the same thing, assuming you set strExe to atfcleaner.zop. If you turned off SRP, then aftcleaner.zop should execute. My point in all of this was to see if SRP can prevent executable code in non-standard extensions from executing. If you use the standard .exe extension, you're not testing this aspect of SRP.

 

I just found this out yesterday, and I was a litle amazed when I tried it. I hope Microsoft doesn't continue this trend in the future for other types of files. Can you imagine what would happen if MS did the same thing with executable files renamed to something else?

 

I think that this is a special case with MSWord. It's been this way from at least Word 6. See

Description of how Word creates temporary files
http://support.microsoft.com/kb/211632

 

I just tested with the executable given the extension .txt. The script runs the executable with SRP off, but does not run the executable with SRP on. So executable code can be contained in and run from a file that appears to be a text file but isn't. Thankfully though, SRP handled it, at least in this case.

 

But isn't it the operating system that determines what program to run? By the way, you can actually name the Word file with any extension and the Word file will still launch. You can rename a Word file test.rmus and it will still launch from Explorer.

 

Nice test to confirm this type of protection.

thanks,


----
rich

 

Or no file extension at all!

I've been looking for some notes where it is described how MSWord "reads" something in the file header coding that identifies it as a .doc file, no matter the extension (or no extension).

The fact that you don't need a file extension was proven in a recent .swf exploit. The attack had two triggers: the .swf file, and for those with outdated Flash players, the tried and proven i-frame.

The exploit downloaded an executable with random characters as a filename, with no extension. File extensions are so passe!

It's a well -crafted exploit, with encoded VBScript in the HTML page code, and as the exploit progresses, a VBS file is created which triggers the eventual .exe file.

See the attack run here, and look at the sans.org link for further analysis of the code.

http://www.urs2.net/rsj/computing/tests/chliyi


----
rich

 

Thanks for the link Rmus. I'm just glad this same type of functionality doesn't apply to non-standard extension executables run from Explorer.

 

You are welcome.

Another situation:

Theoretically it's possible to make a non-executable file execute code, under the right circumstances. From my link in Post #94:

Actually, it is known, but must not be too practical, for it hasn't shown up in exploits.


----
rich

 

I remember that from a few years ago, but it was patched, right? See here.

 

Just out of curiosity, I renamed notepad.exe to notepad (w/o extension)
and ran your VBS test -- and Notepad did launch.

No file extension necessary.

To see if Anti-Executable will catch, I used a file not on the white list
and it was blocked from running.


----
rich

 

I forgot about that. Maybe that is why no attacks using that exploit ever surfaced?

Hopefully nothing else like that will be discovered.


----
rich

 

Thanks for the test, as I didn't bother to test no extension. Just to be clear to others though, you were not SRP when you did the test, correct? In other words, this was not a failure of SRP.

 

The link I gave previously was wrong. It was for a buffer overflow issue. I believe the issue was actually with WMF files, as referenced here. It was patched.

 

ok sorry i reran the test again twice, once with no extension (atfcleaner) and once with a jibberish extension (atfcleaner.lop) and yes i remembered to change strExe = to "atfcleaner" no extension and again with the "atfcleaner.lop" jibberish extension. both times the vbs script ran but nothing happened in my LUA with SRP, atfcleaner didn't launch.

but then again i can't get it to launch using the script in my admin account with no extension or the ".lop" extension.

 

I don't understand.
Why all these tests after Rmus's link in dslreports? I tried it, and executed a gif file (really an executable but with the extension changed), and with SRP it fails.
What's the difference?

 

Correct. This thread started as a comparison between SRP and AE. I used your test with AE. Disabled, a non-WhiteListed file runs. Enabled, it is blocked. I see from others that SRP also takes care of this!

My link to the DSLR was about jpeg files, so your first patch link may have been the one, although it is a couple of years prior to the discussion at DSLR. I didn't follow the issue subsequent to the DSLR thread, so I can't be sure.

The difference is that renaming a .exe file to .jpg results in the file opening in the image program when d-clicked, and no executable code will run.

The example given in the DSLR thread is a .jpg file with executable code inserted at the beginning of the file. When d-clicked such a file will open in the image program, display the image, and at the same time the executable code will run. (see quote Post #137)

In another forum last year, some criticized the use of the term "spoofed .jpg" to refer to renaming a file from .exe to .jpg, saying that a *real* spoof was as just described.

It's a silly nit-pick because exploits today use spoofed (renamed) .jpg, .gif, .php etc, or no extension, not for the victim to d-click on the file, but to use the file to sneak in remotely to then start the attack with no action taken on the part of the user.


----
rich

 

I meant the vbs test. It does the same thing no?
The real jpg file that carries an executable doesn't have a test, or does it?

BTW, MrBrian, can you throw the vbs my way? TIA

 

OK, I see what you mean.

Yes, the VBScript is just another type of "trigger," if you will.

To my knowledge, a PoC for a real .jpeg file containing executable code that Wayne described was never developed and put up to test.


----
rich

 

I have removed the default rules and set up a white list of allowed files, in the Additional rules folder. Although I have a lot of files, for various software on my list, the ones relating to XP are given in the attachment.

I have the security level set to Disallowed for all users including Admin.

One possible problem for me is that I allow rundll32.exe but I'm happy to take the chance (pain/gain)

I hope this information is useful to you.

 

@SpikeyB

thank you spikey.

 

Maybe add a line such as: msgbox "here"
to the script, just to make sure that the script really is running. That line of code displays a message box with the word 'here'.