malware enbeded in .jpg, .doc

I do not know how HIPS products work. However, I think that most have some type of execution protection, and as I mentioned above, ProcessGuard - an early type of HIPS, successfully blocked the executable from running, so the malware had no chance to control GDI32.DLL.

I don't know exactly, and I confess to not being very interested in taking the time to learn how these complicated things work once they run - rather, in keeping the exploit from running in the first place and getting malware onto the computer.

This advisory has some details:

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

Search for those DLLs and see what you come up with. Also search for 'WMF exploit' -- there were lots of articles written in 2005/2006.

In the WMF exploit, IExplorer is initially used, which will be trusted by the firewall for those whose default browser is IE. See the second screenshot in the link from above, where IExplore.exe is the program that called out and attempted to download the malware:

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

On the otherhand, some malware, if successfully installed, uses its own binary to call out for more malware, in which case it would be blocked by a software firewall with outbound rules, as in this exploit using a fake svchost.exe. Since it will have a different MD5 signature/path than the authorized svchost.exe, the firewall will alert:

​

In the WMF exploit, I don't know the sequence of events once the malware installs - which program is used to call out, etc.


----
rich

 

If you check the threads from that time , you might see how a hips fared against the threats.
IMHO, A HIPS would see no reason to prevent the dll from being used.

Malware was able to use the trusted windows dll as an entry point into your system.
How ? It was an flaw in Windows that the malware exploited.

And then, once in, in general, malware can do what it likes .
Non-Admin accounts & HIPS may block some malware at this stage.

IMHO, it might alert .
However again you would need to see the threads from then to see how FW's fared.

 

Previous WMF test files Zip link removed and replaced, please see - https://www.wilderssecurity.com/showthread.php?t=251946

 

I've tested the graphics vulnerabilities test files or wmf test files. Thanks, StevieO.

First, I tested on my current system which has a few very critical patches(not very fond of automatic updates because it might bloat netbook's lean disk space). Obviously, clicking on those image files gave only empty spaces and no other behaviour. GRC mouse trap obviously said I'm free from MICE or Metafile Image Code Execution vulnerability or simply the wmf vulnerability.

And so, I took out my old previous image back ups of a clean install windows xp sp2 and restored it back into the system. I enabled Hardware DEP, installed a HIPs(tweaked a tight configuration) and a buffer overflow monitoring application and added no other patches. GRC mouse trap said that I have MICE.

One very revealing behaviour I have noticed is that just hovering the mouse's pointer over an icon of a .tif image file without even clicking will trigger a prompt on my HIPs that the application utility 'calculator' would want to execute.

An instance, where the windows explorer would crash.

Two instances, where my buffer overflow protections would prompt heap overflows. And if I allowed those to progress, the HIPS will prompt that 'calculator' wanted to execute.

One or two instances, where the DEP warned of memory violations.

For the rest of the exploits tests, the HIPS would always prompt the PAYLOAD, that the 'calculator' would want to execute.

So even in an unpatched system with just a tightly configured HIPS, some Hardware DEP and buffer overflow protections in place; one can be protected from most of these and those old and new exploits ,and perhaps even future zero day exploits taking advantage of various vulnerabilities undisclosed or soon to be discovered due to the ever growing code complexities of both the applications and of the operating system. Ofcourse, a tightly configured HIPS will break some accustomed ease of use perhaps one can opt for ssj100's sandboxie option which could give similar zero day malware protections with some added advantage of simplicity and ease of use.

 

Any chance you could check what sandboxie would do for this file ?

 

Good HIPS protection will stop these types of malware. I have experienced these malwares in the past, and Online Armor stopped them dead in their tracks. You just need the knowledge to choose what to allow, and what to block. Anti-Executable's, and policy restriction's are also a good option.

 

While it is still possible for programs running inside the sandbox to manipulate and communicate with programs outside of the sandbox its not as bad as it used to be. In the latest sandboxie versions Tzuk has now FINALLY limited these type of activities. I also use Malware Defender to help control the behavior of programs inside Sandboxie. That said if we all were to deny all unknown executables from running in the first place our chances of winning lotto are probably higher than getting infected.


Going back on topic I did have a strange experience a few years back. I had the old stand alone comodo firewall and AVG. I downloaded some porn JPG images. And when ever I opened this certain image Comodo firewall always got terminated and shutdown. It was a JPG file because as per normal it showed an image but comodo was always shutdown.

 

I've done some quick and not so thorough testing with sandboxie on a vulnerable unpatched system since I'm quite busy and haven't jotted down the results to make it as accurate as possible(so pardon for not having some screenies) and will just give what I remember...

Before I begin, if any of these similar and newer wmf vulnerabilities will be discovered and more zero day exploits and malwares taking advantage of those would resurfaced, it will be kinda scary if you don't have LUA-SRP or AE or HIPS or a sandboxing or virtualizers protections. For one thing, you don't even have to click on a suspected file, one just hover the mouse pointer to the icon or you'll just open a folder containing those files on the default windows explorer and you are owned or rooted.

So, we now have to reconsider the usual admonition, i.e. 'to think twice before you click'. That you only get infected when you double click an executable or a file. Because in this wmf exploits, you just view the folder containing the image files via the windows explorer or point on it even without clicking or viewing with the default Windows Picture and Fax Viewer, you can get owned or infected.

Fortunately, this wmf vulnerability which Steve Gibson termed as an intentional "Backdoor" has long been patched or closed for now. Any security experts can correct me if there's an existing vulnerability of a similar nature as this wmf vulnerability.

With the default configuration of Sandboxie, opening a sandboxed explorer, and then opening one of the folders of exploit file tests, immediately the payloads will breakout of the sandbox calling out either 'calculator' or 'notepad'. Hovering the mouse pointer on an icon of one .tif image file, will trigger the opening of the application utility 'calculator. Twice instances where the sandboxed windows explorer would crash when opening folders containing those graphics vulnerabilities exploit files tests.

And that's with the default config, but when one will tweak for a default-deny or a limited start/run access, the payloads would not execute when one will click on those image files containing the malware-embedded codes or exploits. So, with a defaul-deny policy for sandboxie you have indeed a nice zero day protection in there.

EDIT: I have done a quick retest, with the default config of sandboxie even without the start/run access tweak, the Payloads in this case calculator or notepad is called out as sandboxed. Nice protection of sandboxie for these types of exploits of arbitrary or remote code execution or buffer overflows vulnerabilities.

 

Does sbie's start/run access affect all executable types or only exe's? If its only exe's wouldnt it be relatively easy to bypass?

 

Hi Rmus,

the thing is ALL of these WMF exploits require an unknown executable of some type to run fully and infect you right? Hence an AE/HIPS would provide the necessary protection right? The thing is SSJ gave me the impression that the exploit would merely needed to use gdi32.dll, a trusted executable to call out to the malware writer at which point he/she would gain control of the OS. Off course since gdi32.dll is a trusted exe, your HIPS/AE wouldnt warn you and the malware writer would own your system before you even knew what hit you. Or atleast that was the impression I had got. Steve Gibson's posts about this 'exploit' being an intentional backdoor further re-inforced this impression. But what you're saying is ALL of these exploits at some point will run an unknown exe which can be picked up by HIPS/AE right?

 

Hello Dregg Heda,

Remember first, that the WMF file is not a true executable. See the thread --"Take care when running some file types with "double click"-- for the distinction.

See also my post in that thread: https://www.wilderssecurity.com/showthread.php?p=1531948#post1531948

The mal-crafted WMF file contains Shell Code that is executed if the image viewer uses that particular DLL. (That's why image viewers other than the Windows Picturer Viewer were vulnerable). A vulnerability in the DLL allowed the Shell Code to execute. Here is the description from the CVE advisory I linked in the above post:

Patch the DLL and the exploit no longer works.

It's the same with PDF: a vulnerability in the Reader allows the Shell Code in the mal-crafted PDF file to execute. Patch the Reader and the exploit no longer works.

In both cases -- PDF and WMF -- as I showed in the post, the Shell Code uses an embedded URL to connect out to the internet to download the malware. Hence the title of the article I linked to in the other post, "Shellcode analysis -- download n' exec."

Any security product with Execution Protection will block the malware from executing and the exploit is effectively nullified at this point.

Note that the CVE advisory says, "Execute arbitrary code." In the test WMF files, the Shell Code launches the Calculator instead of connecting out to the Internet.

----
rich

 

Rmus,

i think Ive got it. It doesnt matter if gdi32.dll calls out because, whatever malware gets downloaded will be stopped by AE/HIPS.

But what about these so called 'true executables'? As long as they are unknown executables wont AE/HIPS simply stop them in their tracks?

 

I don't know - they are image files with executable code prepended (placed at the beginning). I've never seen any to test.

----
rich

 

Thanks trismegistos for posting again.

Just one last thing, do you remember if the payloads of calculator or notepad have a sandbox border around them to indicate they are sandboxed , with the default config ?

I find it very interesting how sandboxie could handle an internal windows exploits.

 

Alright, thanks anyway Rmus for your detailed explanations!

 

They would be useless. If the prepended code is executable code, then the file will be an executable (no matter if there is a jpeg code appended, it won't be shown unless someone looks for it).

 

How do you mean "breakout of the sandbox"? Is "calculator" or "notepad" opened unsandboxed? Otherwise, that's not a breakout right? And it's pretty simple to know what to do if you see unexpected behvaviour like that - empty the sandbox!

 

Its always better to have a HIPS working along side sandboxie. with my MD rules in place nothing in the sandbox would have any chance of calling up and starting calculator' or 'notepad.

 

It's also better not to switch the computer on - I'm 100% bullet-proof if I had that approach haha.

But seriously speaking, I'm quite curious as to whether Sandboxie was truly bypassed with this malware - I doubt it.

However, arran does have a good point here. What if you recovered the solitary .jpeg file out of the sandbox and on to your real system? You don't even need to cilck on the file (just hover your mouse pointer over it) for the malware to be executed. Sandboxie would not protect you here I don't think (but a classical HIPS probably would). Also, this begs the question of whether DefenseWall would protect you in a situation like this. Given that .jpg files automatically become trusted when manually copying them out of an untrusted folder means that DefenseWall is unlikely to protect you in this situation. Right?

Also, by the way, what does opening "calculator" and "notepad" do? How does that actually infect or compromise your system? I know that if "calculator" or "notepad" tried to call out through the internet, I'd get a pop-up from Comodo Firewall about this. Also, if "notepad" or "calculator" or any other executable tried to open an internet-facing application, that application on my setup will be forced to run sandboxed.

 

Yes, it's still sandboxed. Sorry for the quick conclusion, I'm not paying attention. So, even with a default config of sandboxie, the user will still be protected from malwares using exploits of arbitrary or remote code execution and perhaps buffer overflows vulnerabilities.

 

These POCs' payloads are 'notepad' and 'calculator', a realworld malware or exploit-embedded image files or multimedia files or document files would call out just about anything. It could be another instance of Internet explorer with a hidden window to download a trojan(will probably caught by a firewall with application control or hips functionality if configured to prompt) or call out cmd.exe or rundll.exe, etc or shutdown for e.g your firewall as arran pointed out with the pron image file shutting down the comodo firewall.

Excellent approach!

 

Does anyone have any response to this?

 

I think it's every file mate, including .dll. Every file that tries to execute will be denied if it doesn't match the allowed file(s) list.

http://www.sandboxie.com/index.php?RestrictionsSettings#startrun

 

Are you sure about this? Theres nothing in that which specifies that it detects all binary executables. Not to mention script executables. All it says is that it wont allow "programs" to run. You can add a program by typing its "explicit executable name". Sounds to me like it only recognises ".exe". In my personal experience sbie has only ever alerted me if an unauthorised .exe tried to run.

 

The classic exploit is the conficker worm which uses rundll32.exe to load a malicious DLL with a spoofed file extension. Many people tested conficker, and for those who didn't want to let conficker run, I created a test using MSWord and an AutoOpen macro to load a non-White Listed DLL. Here is how it works:

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

and you can download the files if you want to try:

http://www.urs2.net/rsj/computing/tests/hmmapiTestXP.zip

Current versions of MSOffice have macro protection, so you will have to disable that to let the macro run; and you should let IE run since you want to see how your security handles executable files other than .exe.

----
rich