Results 1 to 2 of 2

Thread: Firewalls

  1. #1
    Junior Member
    Join Date
    Oct 2002


    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, and I'll follow up with a real nasty c++ oriented hard orientation (This is a true 'Firewalls 101')

    Winsock aware people may want to start reading from half way down 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 doesnt 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 burried 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]
    [-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 doesnt 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 basicaly 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 comming 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 doesnt 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 ... Thats 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----------]

    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 conveyorbelt 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 the package because it doesnt 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 finaly 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 pictoraly, The wrap/unwrap DLLs are known as 'LSP's or 'Layered Service Providers' And they are called this because they provide suitably standardised 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 ... Finaly it reaches a BASE LAYER which does all the low level processing and actualy impliments the protocol.

    We can start to see now why they call it a 'stack'

    [------Winsock2 API-------]
    [------Winsock2 DLL------]
    [Transport] [namespace]
    [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 doesnt pass it on to the next LSP in the chain (Who didnt expect it comming 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 doesnt 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 didnt 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 ...


    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 dont 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 doesnt 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


    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 doesnt 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 heres the fun part of trojan LSP's

    SCENE 3 ... Promiscuous mode LSP firewall evasion

    Lets say we have a gateway that is running externaly to the infected machine (A gateway firewall or a hardware firewall)

    Now, ALL firewalls have holes in them for authorised 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 specificaly AT it, it scans ALL traffic for specialy quoted sequences...

    When it finds a specialy 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 recieved 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 wouldnt 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]

    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 ... Theres the guest password, lets give it ...

    blooper [ENTER]
    Welcome Guest, This is a test account with no prive ... blah ....
    [--Shutting down now--]

    ..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 listenint 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 wouldnt 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 ...


    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 normaly 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 :

    Unauthorised sockets (unknown unenumeratable invisible sockets - only seen from the outside and only if it likes your IP/remote port)


    Authorised sockets (by sitting on all sockets promiscuously and riding the authorised 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.

  2. #2
    Senior Member
    Join Date
    Jul 2002
    Great job 1:72. I'm printing it out for future use, for when I can understand more than the first couple of paragraphs. I know nothing about this sort of thing, and that's partly why I'm here, and I appreciate the time you put into your post. Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts