[prev in list] [next in list] [prev in thread] [next in thread] 

List:       best-of-security
Subject:    Re: IP Spoofing
From:       Julian Assange <proff () suburbia ! net>
Date:       1995-08-24 17:22:15
[Download RAW message or body]

Forwarded message:
>From firewalls-owner@GreatCircle.COM Thu Aug 24 17:36:29 1995
Date: Wed, 23 Aug 1995 18:00:08 +0200
Message-Id: <199508231600.SAA04320@utopia.hacktic.nl>
Subject: Re: IP Spoofing
To: Firewalls@GreatCircle.COM
From: nobody@REPLAY.COM (Anonymous)
Organization: RePLaY aND CoMPaNY UnLimited
XComm: Replay may or may not approve of the content of this posting
XComm: Report misuse of this automated service to <postmaster@REPLAY.COM>
Sender: firewalls-owner@GreatCircle.COM
Precedence: bulk


> Subject: IP spoofing ?
> Forgive my total lack of understanding of any of the lower level IP
> stuff, but I was wondering about the threat caused by IP spoofing.  It
> seems to me that if a server only allowed local clients to access it,
> and if there was a gateway to the rest of the world, that IP spoofing
> wouldn't help the potential hacker much because the IP packets wouldn't
> ever make it out of the local network.

  Correct- they won't make it out of the local network.

> (I would think that they'd be routed to the local network rather than
> through the gateway.) (Needless to say that meens that our local network
> is trusted and I don't expect any of our local machines to need to spoof
> any others.)

  The danger is that the packets don't have to leave the network to be
  useful in hacking.  Think of this--

  NORMAL:
    - System A tries to open a connection to system B.  System B accepts
      the connection (or not) and sends back a response- the connection
      gets established and they talk all normal-like and stuff.
    - Requires trust between A and B.

  SOURCE-ROUTE:
    - System A wants to 'fake' one of your systems addresses to talk w/
      system B (the address to be 'faked' is assumed trusted to B).  The
      exact same thing happens as above except the first-hop gateway from
      system A has been set up to route YOUR netmask to system A and system
      A has been set up w/ the trusted address on your net.  The other diff
      is that system A is 'source routing' (LSR if distant) to your net w/
      the first-hop's address in the route, so when system B answers its
      buddy the trusted system, the packets are actually going to system A's
      first-hop and getting routed to system A.  Complex, ugly.  The fix
      is to disallow source-routing o'course.
    - Requires control of first-hop routing from A and that system B's net
      allows source-routing.

  SPOOF (DNS spoofing)
    - System A finds r* programs on system B and modifies the reverse DNS
      entries for system A to look like a system that B trusts.  System A
      connects to system B, B looks up the DNS entry and gets back a host
      that B trusts.  Easy, ugly.  Fix is tcp-wrappers or replace r*'s.
    - Requires control of reverse DNS tables w/ system A's address and the
      default/stupid r* command daemons on system B.

  SPOOF (DNS spoofing w/ cache poison)
    - As above but system A 'volunteers' an IP address in an MX record to
      system B's DNS cache so that if tcp-wrappers are running the second
      lookup and compare w/ also succeed.  Harder, ugly.  The fix is to
      stop allowing r* services.
    - Requires control of DNS tables w/ system A's address and that system B
      be using r* daemons (various other related attacks are possible)

  SPOOF (IP level 'blind' spoofing):
    - System A shuts down the trusted host on your network via quirks in the
      implementations of TCP/IP (or waits for it to go down or whatever).
      System A sends a non-source-routed connect packet to system B using
      the trusted hosts's network address, just like the trusted host would
      have done if it were initiating a connection.  System B sends out the
      response to it's buddy and it stays on the local subnet (why would it
      have any desire to leave ?).  System A never gets the response, but
      the seq# guessing code doesn't care, it just guesses the next seq# in
      the chain of packets that system B would expect and pretends it has an
      open connection (which to system B it does, but system A has no way of
      really knowing that- thus, it (system A) is acting 'blind').  The point
      of the exercise is to send system B something that gives system A some
      kind of access/feedback.  The fix, don't allow external packets into
      your network that have internal addresses.  Easy, ugly.
    - Requires system B's net to allow external packets w/ internal addresses.

> I attempted to ask this question of a local consultant who gave me "I
> won't tell, 'cause then you'll hack into people's computers" B.S.  I
> would hope that people would try to understand what a consultant was
> proposing to solve their computer problems, especially when you're
> considering security.  (i.e:  my consultant is not "trusted")

  Find a new consultant- you're paying him/her for expertise not BS.

> P.S.  Are there any GREAT books out there on internet security issues
> that anyone would recommend?  

  Thought about it, never had the time to write one.

> Thanks for the help,
> - shawn
> 
> Shawn Steele
> Information Systems Administrator
> Association of Brewers                (303) 447-0816 x 118   (voice)
> 736 Pearl Street                      (303) 447-2825         (fax)
> PO Box 1679                           shawn@aob.org          (e-mail)
> Boulder, CO  80306-1679               info@aob.org           (aob info)
> U.S.A.                                http://www.aob.org/aob (web)
> 
> Note:  When replying to my messages, please include enough of my
> message so that I know what you're replying to! :-)

  A followup message said:

> Forgive my total lack of understanding of any of the lower level IP
> stuff, but I was wondering about the threat caused by IP spoofing.  It
> seems to me that if a server only allowed local clients to access it,
> and if there was a gateway to the rest of the world, that IP spoofing
> wouldn't help the potential hacker much because the IP packets wouldn't
> ever make it out of the local network.  (I would think that they'd be
> 
> The thing about IP spoofing is that it overrides the
> routing tables in your routers. You specify the path
> the packets will take in the little used options field
> in the IP header. There are other TCP/IP attacks where
> you can hijack a connection between one machine that
> trusts another but this is much more difficult.
>         
> Lyndon

  See above, that's a source-routing attack.  Using RIP or another routing
  protocol to modify the behavior of a between-hop router has the same or
  similar effect if done properly.

  If the only tool you have is a hammer,
  every problem looks like a nail.

  Anon.




-- 
+----------------------------------+-----------------------------------------+
|          Julian Assange          | "if you think the United  States has    |
|                                  |  has stood still, who built the largest |
|        proff@suburbia.net        |  shopping centre in the world?" - Nixon |
+----------------------------------+-----------------------------------------+

[prev in list] [next in list] [prev in thread] [next in thread]