HTML email and external embedded links.

From: Ian Lyte (ilyteat_private)
Date: Fri Oct 18 2002 - 06:58:24 PDT

  • Next message: Michal Zalewski: "Re: Covert Channels"

    b0iler recently said ...
    
    >Personally, I signed up to this list to get vulnerability devolopment
    >disscussion.
    
    So with this in mind I have decided to post early and get the lists
    feedback.
    
    I've been meaning to post this for some time but haven't done enough
    research yet. I'm sure that I'm missing something incredibly obvious here
    but I'm equally sure that there is room for development in this
    vulnerability.
    
    As I understand it, network address translation works like this (very
    simply):
    
    Box A inside the network requests information from host B on the internet.
    The internal IP of BOX A passes through the router and put in a NAT table.
    This then goes out to Host B with the IP address of the router.
    
    When a response from Host B is routed back to Box A it has the routers IP
    address. It arrives at the router, the router looks up in the table and say
    'hey, box A requested information from port xx on Host B, this packet is
    from Host B port xx -> route to Box A'.
    
    Stop me if I'm being stupid yet. I realise that if you have packet content
    monitoring or a more complicated NAT table this all falls to pieces but I
    think that quite a few corporations don't have that!
    
    If I send you an HTML email, with an embedded picture, and that picture is
    stored on www.malware.com/malimage.jpg. When you open the email you will
    automatically make a connection to that server. Assuming that I am
    monitoring this server 24 x 7 and see you access that image I know that for
    a period of time I can send requests to your Box as long as I ensure that
    the connection appears to originate from port 80 on Host B. I could be wrong
    but simpler NAT set-ups just map the requests from Box A and not even the
    originating port.
    
    If you know a box A behind the NAT is running (say) an unsecured SQL server
    could not one assume that the firewall in place would be configured to allow
    traffic on port 1433. How about NETBIOS - whilst these are usually blocked
    at a firewall level just simple NAT may let it pass? I can even imagine
    simple firewalls only blocking incoming 135 when _no_ outgoing attempt has
    been made to contact the source IP.
    
    I really don't know - I'm not an expert in this field - that's your jobs!!
    But I do believe that there must be some way of exploiting the fact that by
    sending an html email, with an external embedded link, you can create a
    connection to the Box that opens that email whilst remaining  very
    inconspicuous. I'm just not sure why it isn't being exploited yet.
    
    Maybe you'll tell me ;)
    
    Cheers
    
    Ian
    



    This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 08:45:36 PDT