ANOTHER ONE FROM A TOP SECUIRTY EXPERT...
A local firewall (As opposed to gateway or hardware) sits either as low in the TCP/IP protocol stack as possible (and nievely hopes the OS makes apps behave) ... or it sits as low as it can in the OSI model generaly by wrapping the interface functionality.

The first is ridiculous and the second is highly questionable

First ...

The first can be got around by tapping the Layered Service Provider's Transport Provider Interface for example... which is essentialy one half of the protocol stack (The other being the Namespace Provider Interface) .. this is done by simple inclusion of a .DLL exporting an SPI (Service Provider Interface) at both its upper and lower edges and thus sitting in the middle. By aggressively holding the lowest position in the stack by claiming to all above it to be the base layer etc ... this DLL can not only use ports parasiticaly but can generate phantom ports that dont show up on netstat and other socket enumeration ... it can also fake in both directions presenting non-network data to applications as though it were regular traffic - and presenting traffic as though it were formed in an application.

This on its own can present significant problems exploiting inherrent trust in a process-based-firewall environment ... and can even be used to promiscuously listen for quoted commands on ANY port or protocol (And strip such sections before presenting up the stack to the app) ... similarlt messages can be quoted into a legitimate stream and passed OUT through the converse method, at least as trusted as the application who apparently generated the traffic.


The second is FAR nastier ...

Not only will it NOT show up on any local firewall (Process based or not) due to being on the OTHER side of the firewalls hooking and thus already from OUTSIDE of the machine (In a TCP/IP context) ... it also is running INSIDE the machine in a code context ... The best of both worlds !

Not only this ... but external firewalls and gateways can be fooled by the same quote/dequte scheme as before. And traced back to ... the legitimate app.

This makes every port on your system a trojan, and any log that shows a LEGITIMATELY FORMED transaction could be a trojan command that was stripped prior to the firewall seeing the packets.


Not only this ... from the VxD layer we can intercept any API call, any registry call, and any Disk access (Even sector reads/writes) ... and filter them and/or remap them and/or return a lie. We've even beaten IDS into submission with this and managed to propagate holes into several layers of backup.

Anyway ... This means that our VxD based trojan is transparent, socketless, promiscuous and has no window/task/thread ID's ... It also may (depending on coding) be impossible to see in a memory scan, drive scan and its registry storage may be invisible to all ... or even different depending on the process doing the asking.

DaVinci Group wrote The MiniBaug LSP trojan in 1999 and several variations of VxD wrapper based trojans for concept over recent years.

Combine these low level tools with some pretty basic exploits and you have a reason not to trust AV/FW solutions as far as you can comfortably spit a horse.

Linux *spit* *spit* is not above this either ... in fact, it can often be easier to install this type of code into the abstract machine representation in a linux based environment that even the windows systems depending on the specific configuration... certainly, IDS systems like Tripwire have never been much of a problem on either system.

Personaly, I believe the much hyped Magic Lantern software probably uses such techniques with the added advantage of good co-operative relations with the governments bedpartner, microsoft... And, if it doesn't ... well, theres no excuse.

Luckily LSP and VxD development are not so openly documented that the lamer can easily exploit these techniques. And DaVinci are a members only non-publishing organisation ... both with code and exploits, by a strictly enforced disolvement policy. However, anyone with coding experience and a copy of the MSDN DDK (VxD) or the MSDN SDK Subscription (LSP) should find their way given a little determination.