Re: Natted IP

From: winged (winged_at_nofollow.com)
Date: 02/24/05 

Date: 24 Feb 2005 00:30:37 EST

Jim Nugent wrote:
> "winged" <winged@nofollow.com> wrote in message
> news:cvgkhi$a0i@dispatch.concentric.net...
>
>
>> While it is not desirable to advertise the local IP (if one knows the
>>local IP and can guess other protocols that might be allowed through the
>>firewall, knowing the natted IP (even if the IP is un-routable)is very
>>useful if one trys to tunnel an exploit of one protocol inside a second
>>protocol.
>
>
> Just how would that work? How would you guess? Lots of protocols are
> "allowed though the router" if the connection is initiated from the inside,
> but the router "firewall" will block all unsolicited packets unles they are
> addressed to a port that you have forwarded to a machine inside. And then,
> there has to be a program (server) listening on the socket connected to that
> port or the port will appear closed (return "Connection Refused"). If all
> these conditions are met, you can try to start a converstation with a server
> WITHOUT knowing or caring about the LAN address.
>
> The only way to reach an IP on the inside if if the router forwards it, and
> that's transparent. The remote end has to address the packet to
> <WAN_IP>:<Port#>. The remote doesn't know which LAN IP it's forwarded to,
> and can't find out unless (e.g. with auditmypc.com) mobile code is
> downloaded and allowed to retreive it.
>
> If you send some kind of tunneled packet wrapped inside, what's going to be
> there on the other end to unwrap it? Remember, a packet is not on the LAN
> until the router forwards it, and it forwards it to a SPECIFIC IP.
>
>
>>Knowing the internal IP assists in the footprinting effort
>>against a target and required for firewall protocol tunneling exploits.
>
>
> Again I asked, where is the tunnel endpoint? What knows how to "unwrap" it?
>
>
>> Firewalls (especially stateful ones) are very rude when one tries to
>>guess the internal address with multiple attempts often shunning the
>>attacker for a preset time before another attack can be attempted.
>
>
> My router's WAN side would never see a packet addressed to, say
> 192.168.1.20, because it can't get there over the internet. If it's wrapped
> in another packet addressed to my WAN address, how does it magically get
> unwrapped so the router can decide to "be rude" to it.
>
>
>>Part
>>of the footprinting process should determine how many attempts can be
>>made before the firewall shuns the attacker and how long the trigger
>>lasts. Firewalls do impede attacks but should only be considered the
>>first line of defense not the only line of defense. They are devices
>>with their own peculiarities, but can not be relied on to keep all the
>>bad guys out.
>
>
> I'd be curious to see an explanation (or a reference to one) that describes
> how such an attack is carried out. The only thing I can guess is VPN, and I
> have to set that up on my end as well as the remote end before it will work.
>
>
>>When Java (applets) are enabled and JS enabled site does what is
>>described. When either is disabled the function breaks. Typically I
>>run only with JS enabled with Java applets disabled. Java applets can
>>break out of the sandbox. I have found Java script to be far less
>>dangerous to the local machine. I try to restrict Java applets or
>>programs from trusted sources like any other executable program.
>
>
> I could be wrong but i don't think an applet has to break out of the Sandbox
> to get the machine's IP. I've never seen a vulnerability related to this.
>
>
>>While I have seen issues with the MS implementation of Java, Sun's
>>flavor has overall been much more respectful of my computer space. Sun
>>has had a few vulnerabilities, but I have had few problems from their
>>implementation. But I am sure some one else's mileage may vary.
>
>
> FWIW I'm running Sun Java 1.5.
>
> BTW my questions are genuine. I'm willing to learn.
When I referred to Java breaking out of the sandbox, I was not referring
specifically to this application. Knowing the internal IP, in the grand
scheme of things, is only a piece of data. It is an important piece of
data of data when reverse tunneling. No Firewalls are not suppose to do
this, but they do. When trying to exploit the goldmine (asset A)in a
network, direct access to the goldmine is usually prohibited (sometimes
on both the internal and external interfaces) by the firewall, in most
large organizations, you may have several firewalls to navigate. Many
times however you may find asset B that exists behind the firewall that
has access to the goldmine but the firewall only allows X protocol from
the outside to asset B. Sometimes you have to thread through a number
of assets to get to Asset A. Many times there are multiple restrictions
you must navigate to get to the goal. Before one attempts such activity
it is best to gather all the information you can legally acquire before
attempting the intrusion. This process is called footprinting. The
footprinting process uses all information one can gather "legally"
before the attempt is made. Learning and mapping all of the exposures
and all of the network information you can gather such as exposures,
operating systems, versions, hardware makes assists in knowing before an
attempt is even made, what stratagems may work for access. This is not
a script kiddie running a scan over an IP range and all protocols.
Probes are made but always low enough key to stay under the radar scope.
  Most major networks have IDS tools running and one prefers not raising
the alarms before one even attempts the penetration. Large networks,
especially at the boundary usually have any number of hosts and
protocols exposed. If it can be managed getting to a perimeter router
to monitor communications for connections is useful, if one can pull it
off. When one is doing this it is best to be cascaded through several
country boundaries to obscure the trail. Bear in mind in some countries
attempting to penetrate a firewall can get you the death penalty, in
most countries it will get one jailed, so it is usually desirable to
obscure ones source location across country borders using several
cascade methods to erase the footprints as much as possible.

Reverse tunneling can be accomplished using several attack methods.
E-mail is one of the easiest methods especially if the company is MS
centric. Outlook historically (not talking outlook 2003, still
studying) has had a number of methods to open ports to outside hosts and
has had the potential exploits available of the IE browser. (NOTE:
There are still over 11 known and open exploits in IE that have been
published even after this months IE patch releases). Sometimes one must
tunnel through a firewall using blind protocols such as an exposed UDP
service. One can use UDP to tunnel TCP data to cause certain
activities. I don't want to go into great detail however there is a
basic article on this "kind" of behavior at
http://www.inside-security.de/fw1_rdp.html though this by no means is
the only methodology. Additionally one can utilize exploits below the
IP layer given the right situation. A number of oddities can, for
example, be done at frame relay to tcp/ip boundaries. Just because a
winbox doesn't allow certain activities on the tcp/ip protocol doesn't
mean there are tools that allow you to break all of the TCP/IP rules.
There are some Linux flavors that have some remarkable TCP/IP
manipulations with built-in tools. A stateful inspection firewall will
stop most of this kind of horseplay however other firewall solutions
that simply rely on NAT do not.

But in a nutshell, without getting myself or someone else in trouble,
firewalls are only the first layer of properly implementing security.
It is far harder to peel onion layered security. They should not be
relied on as the only security mechanism used to secure your nuggets.

Winged

Relevant Pages

  • [Full-Disclosure] YABBT [1] - Re: Zone Alarm
    ... >>network blocking when dealing with like protocols. ... > "There is one big benefit, which no hardware router can bring you. ... "A HW firewall can only block a whole machine but can't denied access ...
    (Full-Disclosure)
  • Re: [fw-wiz] Firewall Primitives
    ... >to the sheer number of protocols in common use today? ... checkpoint more easily than through a proxy firewall. ... we did app logic on HTTP as well. ... As William Hugh Murray says "Connectivity trumps security ...
    (Firewall-Wizards)
  • Re: Wich protocol numbers?
    ... I believe that he is referring to other networking protocols such as IPX, ... Banyan VINES etc. Normally a firewall is not needed for these ...
    (microsoft.public.win2000.security)
  • Re: INCOMING CONNECTION ON PROTOCOL 50
    ... >> take dial up networking which uses GRE. ... >> my firewall will not even notice this traffic passing through. ... >> its as though the Firewall doesnt see GRE packets. ... >ability to filter protocols other than the common ARP, ICMP, ...
    (alt.computer.security)
  • Re: Firewall Useless Today :better security product ?
    ... > Compounding the situation is that attack mechanisms use popular ... > Versioning) are designed to skirt firewall configurations, ... > protocols billed as "firewall friendly" actually circumvent them, ... > rely on them to block the onslaught of tainted packets, ...
    (comp.security.firewalls)