Is this really a bypass for CFP, OA, GesWall ??

This is how you can reproduce this possible bypass. You must ahve more than one disk or partitions on ur PC.

Download and extract/ install XYplorer portable from here.

http://www.portablefreeware.com/index.php?q=xyplorer&m=Search

Put Defence Plus in Paranoid mode with Proactive Security configuration.

Open Defence Plus Pre-defined Security Policies and make a test policy. Allow only file access and Deny all other actions in this policy( see pic 1).

Now execute the malware b.css exe via cmd.exe and allow first execution pop up, allwoing execution of b.css by cmd.exe( see pic 2).

On second pop up alert choose test policy made by us( Pic 3) for b.css. Now Defence Plus will deny ecery single action by b.css without a pop up except file acess that will produce pop up alerts. Allow all file access( create/ modify/ delete) pop up alerts. Malware will create an autorun.inf file and a TPR.pif file in root directory of each hard disk partition. They will be hidden though, not visible via explorer.exe. Let the malware run and Open xyplorer by executig XYplorerfree.exe.

Navigate to one of your non-OS partitions( D, E, etc), locate TPR.pif file and double click on it to execute it via XYplorer( Pic 4).

Now here ius the point. One would expect here a pop up about TPR.pif being executed by XYplorer.exe. But interestingly instead you will first get two weired alerts about XYplorer.exe:

1- XYplorer.exe trying to access DNS/ RPC client service( Pic 5)
2- XYplorer.exe trying to access internet( Pic 6)

It,s after these two alerts that you get an alert about TPR.pif being executed by XYplorer.exe( Pic 7).

Now my question is how this malware manipulated XYplorer to access internet without any pop up alerts by Defence Plus about XYplorer manipulation or any windows message to xyplorer by the malware. Malware was never allowed to do anything excpet file creation etc. due to the test policy imposed on it?

Hope I have made my point clear. I need your opinions. Thanks

 

Pic no. 6 and 7 are here.

 

OA same problem. No alerts.

 

GesWall bypassed as well.

 

Hi aigle,

I'm probably in way over my head here, but I'd like to question your assertion that GeSWall was bypassed... your own screen captures show bcss.exe being isolated by GeSWall. And isn't it correct that even if a user has Process Termination set to Interactive Ignore, the process is under control and does not do harm to the OS?

Didn't you write essentially that same thing on the GW forum about a month ago...

I emailed Brian Walche about eight months ago, regarding an unpatched bug in Internet Explorer... I asked Brian if GeSWall Pro would protect me from that exploit, the same way it protected me from the DNS vulnerability that Microsoft had to patch back in July (of last year)? Brian wrote back,

Isn't that the same case with this bcss.exe malware? If not, what changed?

 

Hi, b.css is an untrusted process. It,s somehow able to manipulate a TRUSTED process XYplorerfree.exe to go outbound for a malware site. GesWall must not had allowed it.

 

Same with CFP. Question is how the malware is able to manipulate XYplorerfree.exe and xyplorer in turn starts trying to connect to a malwre site.

- through system take over( manipulation) ? probably NOT as our test policy imposed upon malware will block this( debug privileges blocked)

- the manipulation of xyplorer in memory ? NO as our test policy blockes this.

- through a global hook ? NO as our test policy blocks this.

- through a windows messag ? NO as our test policy blocks this.

This is a mystery atleast for me. Why a trusted process XYplorerfree.exe suddenly starts trying to access the internet?

 

Hi, tested MD. Same results. Could not find anything manipulating XYplorer but it tried for outbound.

 

I may be wrong here but if you ran this file manually as a user will that overule the rule you set with your security app ?

 

I just double click it via XYplorer and never allowed it to execute when CFP gave an execution pop up. Infact the XYPlorer outbound acess pop up alert( denied by me) comes before TPR.pif execution alert.

 

I still cant see the problem , i assume this PTR.pif is a packed exec , which is in the untrusted zone set by your security app.
Then you have run it with a Trusted app (XYPlorer) , in this case your security apps still disallowed it to run and asked you if you wanted to allow it.

 

you need to read and understand the thread again.

 

Maybe it's a new vulnerability.

Why there are no more opinions about this malware? MD is bypassed too.

 

I gave up on this. It,s a mystery that I can,t solve.

 

it's too strange that all these softwares fail this attack...
a friend tried b.css with RTD e SSM, they failed (BTW they're discontinued )

imo there's something we are not taking present...but what??

 

I don't think the malware is manipulating XYplorer, but rather XYplorer is simply reading the file and deciding how to handle it itself.

I have not used XYplorer, but have used a similar third party Explorer replacement called Opus. They usually use plugin or file handlers to read files, and decide how to pass them to Explorer or display them. For example in Opus if i single click an .exe it's shows as Hex in the preview panel.

To me it appears the trusted XYplorer is reading the untrusted file contents, and acting on it like it's supposed to. So the .pif isn't executing.

Does it happen with other file types?

Information about .pif

 

This is just an intelligent guess or speculation in my part born from my small experience in testing wmf exploits in a vulnerable system.

The file could have used buffer overflows or arbitrary code execution to bypass detections from HIPS just like the wmf exploits but the payload in this case is to use a trusted process to access the internet, which is fortunately intercepted by any HIPS or firewall.

Even hardware DEP or even comodo memory firewall (or equivalent component) couldn't detect every arbitrary remote code executions or buffer overflows. And such actual shellcodes are also undetected by any HIPS but the payloads are surely be intercepted by it.

Now like the wmf exploits taking advantage of wmf vulnerability particularly on the offending vulnerable gdi32.dll, we should now take note if there is an existing vulnerability concerning pif file. Perhaps gdi32plus.dll (he he)? Or is this a zero day exploit taking advantage of a vulnerability?

Edit:
A simple search in the net give me this pif vulnerability on which a worm took advantage of... http://isc.sans.org/diary.html?storyid=1730

 

@Tris, You got me thinking
- I looked up to the top of Aigles posts and I saw that in Comodo there was rules to deny interprocess memory access.
I could be wrong, But I don't think it's a result of BO.

 

Yes it could not be buffer overflow as the wmf exploit is not BO but something similar like remote code execution. I have tested the wmf exploits and out of the 15 or so samples of tif, wmf, jpeg or other image files containing the embedded codes, only 2 instances where Hardware DEP as well as the Comodo Memory firewall had prevented those exploits. But the good thing is, all the payloads where intercepted by the Host Intrusion Prevention System. So, this pif exploit and vulnerability is something similar.

Hardware DEP as well as any buffer overflow protections have high failure rates on these types of exploits like wmf and this pif.

Edit: what a clever piece of malware is this? masquerading as a cascading style sheet which would create a usb autorun file with pif file, which would use a trusted process to phone home or to download more malware.

I'll end with a quote from a poster who's concerened with the weak buffer overflow protections rendered by comodo memory firewall...

 

Good idea indeed.

 

I thought the wmf exploits were buffer overflow. Here is the 2005/06 exploit:

(MS06-001) Microsoft Windows Metafile (WMF) Code Execution
Discovery Date - 12/27/2005
http://vil.nai.com/vil/content/v_137760.htm
http://vil.nai.com/vil/content/v_vul3222.htm

Microsoft Windows XP/2003 Picture and Fax Viewer
14.07.2006
http://securityvulns.com/Fnews578.html

There have been quite a few WMF/EMF vulnerabilities using buffer overflow, as far back as 2004. They were patched. and didn't get the exposure that the one in 2005 did.

Microsoft Security Bulletin MS04-011
April 13, 2004
http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx

WMF Multiple DoS Buffer Overflow Vulnerabilities
http://www.opennet.ru/base/ms/1139852289_2153.txt.html
12 Feb 2006

OpenOffice WMF/EMF Processing Buffer Overflow Vulnerabilities
2007-01-08
http://secunia.com/advisories/23612/

Microsoft GDI Buffer Overflow in Processing EMF and WMF Files Lets Remote Users Execute Arbitrary Code
Apr 8 2008
http://securitytracker.com/alerts/2008/Apr/1019798.html

Like the PDF file which seems to spawn new ways of exploiting the PDF Reader, the WMF file afforded many opportunities for exploitation!


----
rich

 

@rmus: remote or arbitrary code execution vulnerabilities and buffer overflow vulnerabilities, etc. those terms are confusing me. To me they are all the same. But from a conversation with Steve Gibson with a white hat concerning wmf... http://www.grc.com/sn/sn-021.htm

 

To me also. As long as they all do the same thing: launch an executable -- they are dead in the water, as far as I'm concerned.

The reason I picked up on wmf and buffer overflow is that I remember from the 2005 exploit that there were three methods of protection before the Microsoft patch:

1) WMF file Signature -- Black Listing

2) blocking the executable from running - White Listing

3) block the Shell Code in the .wmf file from executing - Buffer Overflow protection.

EDIT: Actually 4 methods, if you include the 3rd-party patch prior to the Microsoft Patch.

This third one was mentioned by only a few companies, one of which was McAfee, which I quoted above. Again:

As far as the conversation/discussion you reference: I am not technically informed enough to know one way or another.

Again, if the end result is a malware executable, and it can be blocked from running/installing, the method used is irrelevant.

-rich

 

Finally, I had some free time and tried out this malware firsthand instead of just speculating on how HIPS were bypassed.

I was wrong to assume that the PIF uses exploit/s to some unknown vulnerability/ies. TPR.Pif and B.css is essentially the same malware executable with the latter renamed as a harmless looking cascading style sheet (perhaps to avoid blacklisting detection) and the former executable, to run as an autorun together with autorun.inf. Just renaming them both to exe and see the properties of each and they have the same size(in kb), file version, product version, special build description, etc. Windchild was right after all.

I did the testing first by renaming b.css into b.exe and running from windows explorer. No need for the command prompt or cli(commandline interface) or using cmd.exe.
I have watched how so many registry entries were created and deleted, dll files created, drivers created and trying to load, created autorun.inf as well as the tpr.pif and finally phoning home to mothership(he he). I have observed some peculiarities on which what Aigle observed was that the malware was trying to use another trusted process to access the internet. There were instances where a trusted process like explorer.exe or windows explorer tried to phone home on behalf of the malware.

Using just windows explorer(no need to use Xyplorer), I double click the hidden tpr.pif in order to run the executable and it made the same actions as b.css. I repeat, the created daughter executable file, tpr.pif is essentially doing the same actions as the mother, b.css.

btw, in order for the windows explorer to see this hidden file, you have to go to tools/folder options and then, untick 'hide extensions for known file types' and 'hide protected operating system files' and of course you have to tick 'show hidden files and folders'.

I did run the file also in Xyplorer and did find the same actions or behaviour. Likewise, I did observe Xyplorer trying to phone home in behalf of the malware.

Edit: Now the question of aigle is how did the executable able to interact to a trusted process. Even if memory modification, windows messaging, dll and driver loading, dll injection, etc are all being covered and monitored by the HIPS. How after deliberately executing the malware, none of the any windows messages, interprocess communications or memory modification etc were not intercepted. What aigle seemed to be concerned of is that HIPS failed to intercept calls by the malware to another trusted process to phone home.

 

Thanks for testing, very interesting. I didn't think it was performing any kind of overflow type vulnerability, i thought it was just the Explorer/XYplorer file handler interpreting the contents of the .pif and carrying out the directions itself.

Where is WildChild's comment, is it in another thread? I'd love to see what he said so i can understand your finding a little better.