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

https://www.wilderssecurity.com/showpost.php?p=1539728&postcount=68

 

Update: I had done a quick retest and did some very tight configuration of the HIPS to even ask or prompt for any dll loading. I blocked the loading of dll or of the library file, which was created by the malware and was located in the C:\TEMP folder. After doing that, the malware wouldn't be able to interact with either windows explorer or xyplorer in order to phone home unlike my initial testing where the HIPS was bypassed. The library file if loaded seems to be the one responsible in doing some calls to either explorer.exe or xyplorerfree.exe which HIPS failed to intercept. The calls could be probably happening deep enough that HIPS failed to intercept (if some HIPS monitor only in certain areas under usermode level only and not at kernel level) or do some actions on areas not covered by the HIPS (not all areas in the kernel level are covered by HIPS).

 

Good work!

Can you give me the anme of this/ these dll? and location? Also screenshot of pop up alerts for these dll loading. I am asking as I am very much doubtfull as GesWall, DefenceWall, and SBIE etc will not allow such dll loading into a trusted process.

 

The Dll names are arbitrary and are found in temp folder and are ending in .tmp file extension for e.g. dll1A.tmp . It seems that those sandboxing and HIPS sol'ns have simply allowed the loading of dll on temporary folder since those have .tmp file extension name.(Just a speculation). There's no breach in that the malware inside the sandbox will not be able to use a trusted process outside of the sandbox. All processes' activities are happening and are confined to the sandbox and isolated from the system. The malware may phone home but all actions are confined to the sandbox environment. Privacy breach, maybe, but, Security breach, no.

Sample logs below when b.exe or b.css was ran under Sandboxie with default config i.e allow internet access to all, no start-run restriction. You can see below that the malware had used Sandboxie's start.exe to access the internet...

 

So, is this a bypass of GesWall due to software bug or improper configuration by the user? Im confused.

 

If it downloads an exe from the internet , is that exe also sandboxed ?

 

I highly doubt that GesWall will aloow loading of an untrusted dll.

 

What do u mean by this?

Any untrusted application, if downloads something that will be automatically untrusted too.

 

So, how was geswall bypassed? I have tested sandboxie and it contained this malware and, therefore, no security breach. Then, how can you explain this malware was able to use a trusted process under geswall to phone home, whereas in sandboxie, the malware wasn't able to use a trusted process outside of the sandbox. As the other poster said, is this a bug of geswall? Any other geswall experts or users could care to try out this malware?

 

Well if we are taking about it bypassing Geswall then maybe this aspect is bypassed too ..

I know how it should work !

 

Actually I got same results with SBIE, DW and GW. All of them contained the malware, excpet, that XYplorer tried to connect to internet with all three.

I can,t find the reason for this weired outbound connection by XYplorer and I can reproduce it consistently.

 

But in your case, XYplorer was running inside the sandbox, right? In my testing with sandboxie, the malware wasn't able to use a trusted process outside of the sandbox.
If xyplorer is also running inside the sandbox, I am not surprised at all if that malware will be able to interact with xyplorer.

Edit: I ran within the default sandbox of Sandboxie both XYplorer and b.css. The malware wasn't able to use XYplorer to phone home but did so directly by itself(via start.exe) which was easily catched by any firewall or can be blocked by a simple tweak on the Sandboxie's settings. So, the HIPS(with a default permissive config: dll loading- allowed globally) was able to prevent interprocess communications between the two. Even without the help of any HIPS, Sandboxie has prevented this malware from using a trusted process outside of the sandbox to phone home. Then, I ran the malware through Xyplorer within the sandbox, that's when the malware was able to use Xyplorer to connect to the internet which is not surprising to me. But the point is, there's no security breach whatsoever even with the default settings of sandboxie, on which there's no start-run restriction and with allowed internet access for all processes. You can achieve even more bullet-proof protections as well as some privacy protections by doing simple tweaks on the settings.

 

Super Sandboxie do what needs to do.Allow almost all but just inside box.Network leak via svchost form inside box is really just a little thing...

btw.O.K. the malware test is very good,but in the real world i think user of some HIPS+firewall would notice that is going something unusual and would block that.....''possible malware behavior''...

 

You can block all unwarranted network leaks with just a little tweak on Sandbox settings specifically on "Restrictions-Network access"

Then a tweak on Start/Run Access can stop all malwares from drive by downloads and leave them dropped cold.

A tweak on "Resource Access" can isolate any privacy leaks.

What more can you ask for from a little nifty freeware.

Agree.

 

in all my testing xyplorer was running outside the sandbox. Pls read my first post to understand it fully. I tried to make it clear but it might still be confusing.

 

in my brief testing, it was contained with no bypass.

 

Yes, I understand. Geswall, as you have said was bypassed. Because you ran the malware with xyplorer outside of Geswall's sandbox?

Now, it is clear to me.

Oh, you got to be kidding if you say Sandboxie was bypassed for the mere fact that you run the malware outside of the sandbox. Ofcourse, Sandboxie will not be able to save you on everything running outside. Ha ha

With my testing with Sandboxie, the malware b.css wasn't able to call out Xyplorer or any other trusted process outside of the sandbox. If you'd say that Xyplorer which was running outside of the sandbox and you ran the malware inside of the sandbox and was able to call out Xyplorer to connect to the internet. Then, there must be something wrong in your system? I observed that XYplorer on its own without the malware tend to phone home a lot.

Yes, I understand, you are still baffled on how the malware was able to use a trusted process despite running CFP, OA, Geswall etc.

Perhaps, experts like Prevxhelp, Windchild, Rmus, Sully or even SSJ100 or the developers would chip in.

 

I did not say that.

 

I thought you are implying that. Because your statements are confusing and not clear. Anyways good to know those sandboxing solutions are not bypassed because the confusion stems from a few of your posts.

While here below, you seemed to imply that you actually ran the malware inside the sandbox because you said all of those sandboxing solutions 'contained the malware' and yet as you have said all the time XYplorer was running outside of the sandboxes but was able to connect to the internet with all three...

I visited also the comodo forums. They are baffled also with our findings or are in a state of denial. Judging from the muddy responses, there will be no clear resolution to your problem.

 

Sorry for some confusion. I will try to clear some points.

1- I never run the malware out of sandbox as that will be not a test for sandbox in any way.

2- Malware was contained well by all sandboxes.

3- Only problem is that trsuted XYplorer tried to connect to internet when I tried to run an isolated/ untrusted malware file( .pif file) via trusted xyplorer. I am not sure whether it was something related to xyplorer. windows OS or some manipulation by malware.

 

If the malware phones home , downloads an exe , is that exe sandboxed/untrusted ?

Have you been able to test that ?

 

I see that you are using sandboxie and yet you haven't realized or don't fully trust its full potential, capability and design.
Obviously, everything running within the sandbox will remain isolated in the sandbox. Whether that malware which one gets easily by drive by downloads will download other malwares, those will never break out of the sandbox. Franklin and Peter2150 are the experts here and have tested sandboxie with a barrage of malwares and nothing has bypassed Sandboxie. Even this malware in question wasn't able to bypass Sandboxie.

The confusion stems from the methodology of testing Aigle implemented on which a deliberate bypass was done by user interaction. In this case, XYplorer which was running outside of the sandbox was used to run tpr.pif contained in the sandbox. That's tantamount to running tpr.pif unsandboxed. It's no surprise to me if tpr.piff was able to interact to XYplorer. It's like using unsandboxed windows explorer and double clicking on Sandbox contents and that's dangerous in terms of security because those contents could contain live malwares.

Now the tweak on Start/Run Access acts like a default deny policy or AntiExecutable type of protections. That malware will not even run and if for e.g. that malware was given a clearance to run and given leeway to download more nasty stuffs, those malwares that were downloaded will not be able to run or simply dropped down cold dead.

 

In point no.1, you said you never ran the malware out of sandbox, but, you deliberately run tpr.pif by using XYplorer which was running outside of the sandbox. That's the contradiction. Remember that tpr.pif is carbon copy of b.css or b.exe. So basically you are running the malware outside of the sandbox by double clicking tpr.pif from XYplorer.
It's no surprise to me if tpr.piff was able to interact to XYplorer. It's like using unsandboxed windows explorer and double clicking on Sandbox contents and that's dangerous in terms of security because those contents could contain live malwares.

 

.pif file was marked untrusted by GesWall/ DefenceWall, so even I tried to launch it via XYplorer, it will be launched isolated( with or without a pop up alert from GesWall).

 

I don't use DefenceWall and GesWall. Obviously those are policy based HIPS and have different implementation from Sandboxie.
Those untrusted and sandbox terminologies have gotten us confused because we are talking about different softwares with different designs and implementations with the use of the same malware b.css with its carbon copy tpr.pif.
So, basically there's a bug with both defensewall or geswall, which caused the bypass. You must report this to Ilya and to the geswall author.