RE: HTML email and external embedded links.

["Jim Harrison (SPG)" <jmharr () microsoft com>]

Actually, this issue assumes a wide-open NAT device, like you might find
in a "default-configured" RRAS server with IP-IP paths defined for
internal hosts.

If a real firewall (ISA, BigIP, Checkpoint, whathaveyou) is in place,
the traffic between 
hosts is limited to the definition of the traffic (HTTP, SMTP, etc.)
profile requested by the caller (internal or external) and the rules in
place for that traffic definition.

Assume a properly-configured firewall/proxy:
If I receive an email from BadGuy and I'm dumb enough to open the mail,
thus executing the link from the mail client I never patched, what
happens is that I get what I asked for (literally). He can't make a SQL,
SMTP, NetBIOS, anything connection to my box because the rules in effect
for this session don't allow it. All he can do is respond to requests
that I make; he can't initiate anything, even if he dumps a listener on
my internal host (we can discuss firewall client issues separately).  
If he decides that his trojan should make further HTTP requests to his
evil server, they'll be handled according to the rules in effect on the
proxy/firewall.

* Jim Harrison 
MCP(NT4/2K), A+, Network+
Services Platform Division

The burden of proof is not satisfied by a lack of evidence to the
contrary..



-----Original Message-----
From: Ian Lyte [mailto:ilyte () alias666 freeserve co uk] 
Sent: Friday, October 18, 2002 6:58 AM
To: vuln-dev () securityfocus com
Subject: HTML email and external embedded links.


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