DDE communications

[Gregcox]

The first test here http://hackingspirits.com/vuln-rnd/vuln-rnd.html apparantly works when it is in the buffer zone while the browser isn't.

So the buffer zone does not restrict DDE-IPC (Direct Data Exchange – Interprocess Communications) between trusted and non-trusted.

IS this a limitation in the home edition? I hear the home edition doesn't allow limitation of network connections.

I don't know if not blocking DDE-IPC falls into the citeria of breaking bufferzone in your challenge (I suspect it doesn't), but I thought it would be a good thing to do anywhere since it doesn't enable a untrusted app to affect an untrusted one, somewhat similar to injecting a dll.

[Avital]

Hi Gregcox

First, let's try to understand what this whole DDE-IPC is is all about:

As Tr0y put it in his document (zabypass PoC), the idea is to use APIs like CreateProcess, ShellExecute, WinExec etc… in order to run a script (HTTP request in our case) that is later interpreted by a Trusted Host program (iexplorer.exe or other trusted browser in our case).
In the described demo, the program uses the trusted browser in order to send data to some remote site.

An important thing to understand is what information is really available to a program running inside the BZ: basically, all the information that is WITHIN the BZ is accessible (by design) and hence can be sent directly to a remote site without using any special tricks (the BZ do not block internet access by default).
So assuming the Trojan is running inside the BZ, it shouldn't be able to collect data OUT of the BZ.

Now you might ask "what if a Trojan will create a malicious script and call a trusted host to execute it?"
Well, good question In this case, the AntiMalware program includes a "Contamination" and "Process inheritance" mechanisms: whenever an un-trusted script is ran, the host is first moved to the BZ (temporarily if the Host is trusted) and only then the script is executed. Similar thing happens in creating new processes: the new process is created directly inside the BZ.

For example, you may try the following script example:

Set WshShell = CreateObject("Wscript.Shell")
WshShell.Run("www.google.com")

Create a .vbs file that contains the above lines, put it in BZ and run it. You'll notice that even if your default browser is trusted, it will be opened inside the BufferZone (If you get prompt when you run the script, select "execute in BufferZone").

The zabypass demo is no difference:
1. The information it sends is originate from inside the BZ (which is OK)
2. It "contaminates" the default browser.
The fact that you see the page with the sent information is OK (since this information was collected from inside the BZ).

In order to break the BufferZone security your Trojan will have to either:
1. Collect data from OUT of the BZ (bypassing BZ access restrictions).
2. Open the browser (or any other application) OUT of the BZ (bypassing the contamination mechanism).

Keep up thinking about it

Avtial

[Gregcox2]

Hi Gregcox

An important thing to understand is what information is really available to a program running inside the BZ: basically, all the information that is WITHIN the BZ is accessible (by design) and hence can be sent directly to a remote site without using any special tricks (the BZ do not block internet access by default).
So assuming the Trojan is running inside the BZ, it shouldn't be able to collect data OUT of the BZ.

Thank you for your answer.

I'm a bit confused by what "trusted host" which you mention means. In the context of the demo, trusted app is something that has a default firewall allow rule. While in AM, "trusted" means NOT in buffer zone , while untrusted apps are in the buffer zone. When you say "trusted host" in various parts of your answer, I presume you mean Not in the buffer zone?

Scenario 1: Tthe browser, Internet explorer is in the buffer zone (untrusted) and so is the demo. This is what most people will be doing.

In this scenario, yes the buffer zone is not broken. But there is still some potentinal for damage because the browser is in the buffer zone. Like a demo stealing keylogger stealing information from the browser and then connecting out using the browser.

Correct? Is this something that can be addressed with 2 buffer zones? One for programs that you explictly trust to be not malicious on purpose but you are afraid it can be exploited through the net. The idea is to limit the damge even if they get exploited

Another is for apps that you REALLY don't trust. Say a freeware calender you downloaded. You don't mind if they get information from other equally untrusted apps, but you really don't want them near your browser (which is pretty sensitive).


Scenario 2 is what you I think were discussing

Now the browser is not in the buffer zone and the demo is in the buffer zone.

The zabypass demo is no difference:
1. The information it sends is originate from inside the BZ (which is OK)
2. It "contaminates" the default browser.
The fact that you see the page with the sent information is OK (since this information was collected from inside the BZ).

The bufferzone is still not broken because the demo only still has access to the information inside the bufferzone.

In order to break the BufferZone security your Trojan will have to either:
1. Collect data from OUT of the BZ (bypassing BZ access restrictions).
2. Open the browser (or any other application) OUT of the BZ (bypassing the contamination mechanism).

Avtial

I'm aware that the demo did not collect info from outside the BZ, but I'm was under the impression that AM would somehow protected apps from outside BZ from being affected by anything inside. So I kind of expected the browser not to respond to AM, thank you for clairfying what being in the BZ actually means.

The contamination mechanism is a very cool thing ,and thank you for explaining, but it seems I need to get the corproate edition if I really need network controls.

[Avital]

Gregcox:

1. Trusted Host is a program running OUT of the BufferZone (a trusted program). Note that this is somewhat difference than Firewalls where only "Trusted" programs are allowed to access the Net.
2. In the current BufferZone version, the BufferZone is common for all programs and hence treated as an un-trusted environment. In this un-trusted environment it is possible for Trojan or keyloggers to do their tricks. However, Net Access can be denied entirely for the BZ or for specific program running in the BZ. You are right about the possibilities that multiple BufferZones might provide. We already discussed this issue and I assume that will be introduced in future versions.
3. Please see the Configuration Tab of the AntiMalware Control Panel. You can set the BufferZone to prompt you or even block execution before contamination takes place; hence you have a control of programs running inside the BZ regarding the rest of the system.

Cheers,
Avital

[Gregcox]

Thank you Avital for your patience.