"Vince C." <
[email protected]> a écrit dans le message de
[...]
... grc news server. Unfortunately I don't remember who posted and where
Here it is. It was a post from Kevin McAleavey
------
You are quite right. The Internet Lock on ZoneAlarm will only stop the flow
of traffic that it is monitoring through your protocol stack. ZoneAlarm, as
any of the software firewalls, is monitoring your traffic high up on the
protocol stack and will not detect traffic which is flowing low on the
stack.
This came up in discussions on grc.com over a year ago and I'll post two
messages from that discussion thread, in two parts, which may provide
further background as to why ZoneAlarm may not be reacting to internet
traffic and how it is possible to hack past a firewall other than disabling
the firewall.
Part 1 of 2 is the discussion of how firewalls work and how it is possible
to hack past them. It is a re-post from a discussion thread in
http://neworder.box.sk/
Part 2 of 2 is a message from Kevin McAleavey of BOClean who was making
comments on the discussion in Part 1. I couldn't say it any better than
Kevin.
Part 1 of 2
This is the message that started the discussion thread in grc.com
http://neworder.box.sk/wb/index.php3?did=neworderpublic&disp=56869&thread=56869
[Requires registration to get to the link.]
moderated by Sidewinder, QX-Mat, Thran, Cube
The dummies guide to Firewalls, the protocol stack, the LSP and how to hack
past them by 1:72 Newbie? everybody calls you a lamer? read! by Clayman
Posted by 1:72 *.btinternet.com - 2001/Apr/12 15:41
plz NO flames just read
I apologise in advance for the length of this post, and the radical dumb-
down ... if anyone wants to discuss it in the dirty raw let me know,*l*
Winsock aware people may want to start reading from half way down <G> Or
even skip the post entirely : ) But trust me, it DOES break new ground at
the bottom.
Heres the dummies guide to Firewalls, the protocol stack, the LSP and how
to hack past them ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Okay, lets look at how those pretty packets get from 'out there' to your
app ... its kinda like the sperm thing, but amazingly less packets die
along the way. Because this is a general threat I'll dumb it down a little
where I can, and I can then expand on areas of question later.
We should all be familiar with the winsock.dll ... it exports the methods
we use to use windows sockets, its a fairly simple affair and doesn't
include any facility for checking and manipulating packets or watching all
socket activity ... Many apps DO watch all sockets though, but how? Is
there another .DLL? A hook?
Well, the methods you need are within the Winsock DLL but they are not
accessible through the public interface (the DLL Exports) they are buried
deep inside ... now, accessing non-exported functionality would be a bit of
a problem, but for the fact that the winsock DLL interface is not a fixed
entity ... its just a handy entry point holder for the true complexity
below, the wonderful 'Protocol Stack' !
So ....
[App] [App] [App] [App]
[--------------------WinAPI---------------------]
[-Winsock DLL-] [Various other DLLs]
[Protocol Stack]
All your windows applications sit on the WinAPI ... which handles all the
hard stuff like talking to the various device drivers for you, this means
that the app doesn't need to know anything except how to talk 'API'
The winAPI has a special (optional) component which handles networking with
sockets called the winsock DLL, this acts as a secretary, phoning people,
hanging up on people, putting new messages in an applications IN-TRAY, and
sending messages from an applications OUT-TRAY ... and basically handling
things for our app in an orderly manner.
Now, The Protocol Stack, sits between the world as we know it, and the
application - and its job covers quite a lot, but think of it simply as a
Wrapping/Unwrapping room for messages going in and coming out. It checks
that the data packages are wrapped correctly according to their size and
nature (TCP/UDP/Etc...)
Packages coming in are checked and unwrapped, the envelopes are all opened,
and the final item is passed, ready to use, to the winsock DLL which then
informs the application that it has a message waiting, and places the
message in the applications IN-TRAY - the application doesn't have to worry
about how the package got here, how it was addresses, or how many layers of
wrapping paper were removed, it just takes the item from the Winsock DLL
when its ready, and uses it.
Now ... That's quite simple so far ... But, there are many different ways to
wrap different types of message - we call these 'protocols' and the
protocols sometimes (rarely) change - or new ones are added ... to cater
for this the ProtocolStack is broken down still further ....
[--------Protocol Stack----------]
[Transportation][Namespace]
The Transportation side of things deals with wrapping/unwrapping parcels
and taking them to and from the delivery medium (Not a MailVan in this
case, its the internet hardware ... although, sometimes it seems about as
slow as surface mail <G>)
The Namespace side is responsible for checking the addresses ...We can
forget this, but think 'DNS'
Now, like I said, the Transportation layer deals with the wrappings ... and
different packages have to be wrapped differently, rather than have one
lump of code telling us how all things should be wrapped we have a much
more flexible arrangement ... We have a conveyor belt of wrapping/unwrapping
people and the packages pass each of them in turn.
Now, in the winsock there is a .DLL for each of these people we have a DLL
that controls how they behave ... for example, we might have someone that
picks out round objects and wraps them in brown paper - that is one DLL the
message passes through ... then our wrapped ball will be passed to a DLL
for a person that takes square objects and puts them in boxes, he ignores
the package because it doesn't apply ... etc ....
So ... data going out passes through a number of DLL's each manipulating
and wrapping it in some way or just ignoring it till it finally comes out
the other side all ready for shipping over the internet safely.
The reverse is true, and passing a wrapped item up the line in the opposite
direction will cause the DLL's to unwrap it appropriately too, so that it
arrives at the Winsock DLL ready to be passed to the application.
Not so difficult so far !
Now, lets look at that pictorially, The wrap/unwrap DLLs are known as 'LSP's
or 'Layered Service Providers' And they are called this because they
provide suitably standardized TCP and UDP wrapping services that the
internet likes, and they do this in layers ... each checking the data in
turn before passing it to the next LSP layer in the long chain of LSPs ...
Finally it reaches a BASE LAYER which does all the low level processing and
actually implements the protocol.
We can start to see now why they call it a 'stack'
[---------Application--------]
[------Winsock2 API-------]
[------Winsock2 DLL------]
[Transport] [namespace]
[LSP]
[LSP]
[LSP]
[LSP]
[LSP]
[Base Layer] - This is the final layer, it does the low level work
Now, since the LSP chain is a linked-list of DLL's we can insert one ...
Firewalls do this ... And this firewall LSP takes his instructions from a
RuleSet, such as .... any packages from 'Lebanon' throw away quickly.
Whenever it sees a package that fits its rules it behaves accordingly, to
lose the packet it simply doesn't pass it on to the next LSP in the chain
(Who didn't expect it coming anyway) and in this way packages to and from
Lebanon can be suitably lost : )
Below the base layer things get a little too grubby, the data passes
through a device driver for a modem or network card, which sends the data
to a device - This is the zero layer, or the VXD ... each of these drives
is hardware specific, and therefore completely beyond out explanation
<grin> Phew, dontcha love shortcuts?
And below that is your pretty modem or network card with its blinking
flashing lights.
Now, our firewall is throwing away packets it doesn't like, and its doing
it at a very low level ... it stops (Or SHOULD stop) bad packets getting to
or from our applications ... and also, should stop hidden applications we
didn't know about from talking to the outside world (Trojans my dear boy,
Trojans!)
Now, some fun ....Nightmare scenarios for your firewall ....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SCENE 1 ... a DLL Trojan is sitting in the protocol stack at a lower
position that the firewall ...
[LSP]
[LSP]
[FIREWALL LSP]
[LSP]
[TROJAN LSP]
[LSP]
[BASE LAYER]
There is no Application sitting on the WinAPI or using the Winsock DLL ....
Just a DLL inserted into the protocol chain as shown above. This means that
Trojan packets don't have to pass all the way along the protocol chain, up
through the stack ... it only has to get as far as your Trojan DLL ... who
will not pass the packet further (Because its journey is a shorter and its
already reached its destination)
This means there is no Trojan packets for your Firewall to handle, they all
stop short - and therefore your firewall is happily silent. Data going out
from the Trojan is the same, it starts inside the protocol stack and
travels outwards from a point already beyond the firewall.
Do a netstat -a (Lists all open sockets) .... because nothing further up
the chain than your [trojanLSP] is aware of the socket (Why would we tell
them we opened a socket) it doesn't show at all ! Stealth!
See the power of a LSP DLL Trojan ?
But, how can we stay ensure that we stay lower in the chain than the
firewall's LSP ?
SCENE 2 ... a DLL Trojan is sitting under the protocol stack as a baselayer
wrapper
[LSP]
[LSP]
[LSP]
[FIREWALL LSP]
[TROJAN - [BASE LAYER] ]
The Trojan pretends to be the base layer (Replaces it) and whenever asked
says 'I am the base layer and there is nothing below me' and doesn't offer a
pointer to the true base layer, thus the true base layer is disconnected
from the chain and cannot be found ... The Trojan calls it and exports all
of its functions back up the chain, but - it takes out Trojan packets and
inserts Trojan replies ... NO LSP will ever see these, regardless of their
position in the stack.
Of course, these methods only evade firewalls on the local machine ... a
hardware firewall or a firewall on a network gateway WOULD spot the
connections to and from the socket. Is there a way around that ???
Of course there is ... and here's the fun part of Trojan LSP's
SCENE 3 ... Promiscuous mode LSP firewall evasion
Lets say we have a gateway that is running externally to the infected
machine (A gateway firewall or a hardware firewall)
Now, ALL firewalls have holes in them for authorized applications to talk
through in both directions ... if they didn't then why have the internet at
all ? Nothing would get in or out !
So, we can assume that there are sockets in use that have firewall approval
.... how does this help our Trojan ... Well, instead of our LSP looking for
packets directed specifically AT it, it scans ALL traffic for specially
quoted sequences...
When it finds a specially quoted (embedded) sequence it removes that
sequence from the data before passing the data up the chain ...
When the Trojan wants to send a reply, it quotes it and inserts it into the
outgoing data on the same socket that it just received the command from ...
Because it is stripping commands out BEFORE they get to the application
that owns the socket, and its inserting replies AFTER they left them
application, the application is completely unaware that a Trojans commands
and replies are getting a free ride on its socket.
So, out hacker just connects (Or sends UDP) to ANY socket he can see from
the outside, possibly an FTP/HTTP/TELNET/MAIL daemon .... and the Trojan
will act upon it and reply, but the application will see none of that, the
application only sees what is NOT quoted .... so, hey presto - we trojaned
ALL of his ports ...and even remote firewalls will allow some of those
ports access to the world, or it wouldn't have the sockets open.
If our open quote was '<---' and our close quote was '--->' and when the
Trojan replies its open quote is '[--' and its close quote is '--]' we
could connect to, saaaay .... the telnet port if its open, and this is what
we type
lo<---hello--->gin guest[enter]
[---OK---]
The Telnet daemon sees 'login'
The Trojan sees 'hello'
The Trojan replies 'OK'
now, lets say our Trojan always replies with the victims time whenever we
type 'time' ... lets continue that telnet connection from where we left,
password? <---time--->
[---The time is 14:27pm on Monday 12th April--]
<--portlog 23 play-->
[--Playing back log for port 23--]
[--login fred^^topsecret^^ls^^ps x^^kill -9 28374^^--]
[--login guest^^blooper^^ls^^quota^^logi^gout^^--]
--8< snip -------
[--login user^^usermania^^ls^^ps x^^eggdrop egg.conf^^ls^^--]
[--end of log for port 23--]
See that, we asked our Trojan for the log of port 23 and it played back the
first few bytes of each connection it had seen on that port today ...
There's the guest password, lets give it ...
blooper [ENTER]
Welcome Guest, This is a test account with no prive ... blah ....
<--shutdown-->
[--Shutting down now--]
[BYE]
..connection lost..
Now, its unlikely that the windows machine has a telnet port, but bear in
mind that this could be ANY UDP or TCP port we can reach despite the
firewall, possibly a port 80 or some listening ICQ or MSN or mIRC's IDENT
port etc ... even ports 137, 138, 139 (Although the firewall would prolly
block or restrict those last 3) ... all are our Trojan
For a firewall to detect this it would have to be an AI, maybe a user that
happened to be packet logging would spot it ... but, our quoting wouldn't be
so obvious and our command/replies would be simply encrypted.
Imagine, the hex 0x293D3E22 was our open quote, and 0xEE3DF405 was our
close quote, and that all data quoted strings were fiendishly bit-mashed,
looks just like regular binary data now huh ? Send it UDPwise to a socked
we can reach and BOOM, we can reset the box, or have it send back files or
directory contents ...
SUMMARY
~~~~~~~~
Now, you know how firewalls tend to attach to the system and filter data
.... and you know that any LSP can see ALL traffic but normally only deals
with packets that it applies to ...
.... you've seen how the low level LSP Trojan can make a mockery of any
remote firewall provision by using either :
Unauthorized sockets (unknown unenumeratable invisible sockets - only seen
from the outside and only if it likes your IP/remote port)
-or-
Authorized sockets (by sitting on all sockets promiscuously and riding the
authorized ones through any firewalls)
There is one lower point of access which has even greater rewards, the
Layer-0 VXD wrapping Trojan, but that we will save for another time.
If anyone wants to see some actual C++ for LSP Trojans let me know and I'll
put some up, but I don't distribute binaries or complete sources, I'm only
offering the business end of the code : )
If anyone wants the seriously detailed hi-tech version of this article, let
me know and I'll place it as a reply to this thread, but my wrists are
aching and I really don't want to type any more today ... I been typing all
day and this article has just wiped out fingers <G>
plz again no flames just read and tell me what u think
PS I need to go now for real and is their any one from HOLLAND cos I am
going from the 18th to the 25th of this month and looking for some
"good"(that's a joke just in case) places to go to.
1:72 out
END of Part 1 of 2
Continued...
------
Continuation from Part 1 of 2...
Part 2 of 2
[From the discussion thread in grc.com about the article posted in Part 1
of 2.]
This might be a dumb question, but...
If an Intruder tried this, wouldn't it corrupt the TCP/IP stack? And
wouldn't that alone alert the user, if in fact, it "did" corrupt
TCP/IP?
Just wondering and trying to increase my learning curve...
Howdy ... End of a long and nasty shift ... OK, I'm game, I'll take this on
.... If an intruder tried this, depending on how well they wrote their VXD
wrapper code, you'd never know TCP/IP is "corrupted" ... Bear with me here
for I am (as usual at this hour) tired and not the sharpest blade in the
drawer at the moment. What you know as "TCP/IP" in Microsoft parlance is
way above the "NDIS layer" (Network Driver Interface Specification or "the
base layer") ... What the author (aside, NICE article that backs up my own
major point about "software firewalls being a waste of time") is trying to
say here is that by "shimming" a Trojan into the "winsock" (actually deep
below it) just like firewalls "shim" the winsock (a misnomer, but the
accepted view of reality lately) it is possible for such a Trojan to "shim"
itself UNDER the firewall in the stack and thus hide from a firewall. An
error would be generated at a higher layer, not here. Either the Trojan
would be successful or the shimming would result in a constant error that
would only be resolved by reloading windows. By the way, reloading windows
without a format and fdisk operation would probably only end up with the
shim reasserting itself again.
That all said, where the author was going is one I really got a kick out of
- that is, like many Trojans we've already seen (and a large number of
"internet worm viruses" as well) who defeat firewalls by using "authorized
connections" such as Outbreak Express or IE which are already authorized to
pass along nasties, is there's an even nastier way to assert a nasty, by
placing it as a wrapper around the lowest level of the protocol, in the
NDIS portion itself. When THIS is done, there is no way on this earth to
stop it from functioning and virtually no way to detect it at all unless
you HAPPEN to catch the VXD being installed. This is what he referred to
with the "ring 0" trick ... Even an external hardware firewall could miss
this is traffic is interspersed with the "real traffic" and siphoned off
before being detected.
But in all sincerity, you're NOT corrupting the stack, assuming the DLL (at
an upper level like a software firewall) intercepts the traffic and passes
along the ashes up the chain to the firewall ... It WOULD fail if it was
poorly written. If however the author of a nasty were to place it into the
VXD chains, there'd be no warning at all and folks are used to seeing
windows bomb on a boot-up, think nothing of it and reboot again whereupon it
wakes up properly. Raise hands now, how often has this happened to you?
What the person proposes is actually quite frightening. It was something I
envisioned when we were working on (and then abandoned) our "securesock"
software before the "free firewalls" pretty much killed the project (can't
compete with free when you've got bills and salaries to pay) ... But we saw
this coming back when Back Orifice 2000 was released and it went and
tunneled right into EXPLORER.EXE with remote threads and one really lousy
(apologies, DilDog ... Heh) cob job of "hacking the process stack" in the
Tooltips library to hide the remote thread BO2K created ...
Bottom line though, there is NO CURE for where nasties are headed ... A
HARDWARE firewall can up your chances a bit, but what he describes in that
article is not only doable, we've seen many recent Trojans (Sub7 2.2 as
just one example) already headed in that direction. As it is, there are
modules in the core Sub7 code that are completely invisible to "process
view" detection ... And "mobman" is working on a 2.3 version of Sub7 that
looks like it will be released in a few weeks (there's a bogus 2.3 going
around which is actually a 2.2 version that's been repacked - same old
stuff, no news) ... And rumors on IRC claim that Bionet 3.14 will also be
headed for the bottom layer, way beneath where software firewalls kick in
the "stack."
Still, the main trick is getting the nasty *onto* the machine, but people
still insist that it's OK to run scripting with "all the latest patches"
.... Ask the Air Force how that all is working out. <grin> Open acceptance
of scripting and ActiveX is STILL the major infection vector these days and
if any of them slip past, they've got ya. What the author talks about
though is very much for real and no, it's highly unlikely that any warning
will appear other than those scripting warnings that enough people have
ignored already.
Sub7 is QUITE prevalent out there even though the USUAL infection vector
involves embedding a tiny file uploader into script on a site which dumps a
VERY small program (we're now seeing these "Trojan grabbers" down to 7 to
16 k in size lately) which once installed, will then go grab the "fatter
Trojans" from somewhere else once they're on the machine. Won't take much
to get nailed though, the kids have been *very* busy as my absence from
here lately attests to. And nailing the "firewalls" is "job number one" to
most of them. The old solutions are about to fall.
Anyhow, loved the description of the FedEx conveyor belt. One of the more
interesting descriptions of the app layers I've seen. With Microsoft's
changes to their own NDIS to create more and more "promiscuous holes for
multimedia and streaming content," I'd say Windows XP is a goner. It was
bad enough when they introduced "out of band data support" in the NDIS 4.0
release, now with NDIS 5.0, they've made it a whole lot worse with (and I
quote) "New mechanisms for off-loading tasks such as TCP/IP checksum,
IP Security, TCP message segmentation, and Fast Packet Forwarding to
intelligent hardware" (see
http://www.microsoft.com/hwdev/devdes/ndis5.HTM
for more) it's about to become and even more "happy browser/OS integration"
nightmare in the NEXT windows (like Win98 wasn't bad enough)
....
Just in case you wondered why I have a bad attitude about Microsoft doing
the "browser/OS integration" thing in the first place ... Well, I'm off to
bed ... Sorry for the ramblings but what I read in that article wasn't news
to me at least ... But then folks pay me to keep up with this
....
Kevin McAleavey
Kevin's home page:
http://www.nsclean.com/
includes BOClean
**END of Part 2 of 2**
]