[svlug] ip address spoofing

Mark C. Langston mark at bitshift.org
Thu Oct 24 11:43:42 PDT 2002


On Thu, Oct 24, 2002 at 11:24:06AM -0700, Robert Hajime Lanning wrote:
> On Thu, 24 Oct 2002, George Georgalis wrote:
> > Is there any way to spoof the source IP in a TCP/IP transaction? What
> > level of confidence can be had that SMTP mail truly was delivered from the
> > highest "Received: from" line in headers?
> >
> > Note I'm not talking about stealing an IP from an unprotected WAP, see
> > http://www.newarchitectmag.com/documents/s=7555/na0902h/index.html
> >
> > I'm wondering if there is a way to (transverse the internet and) connect
> > to a remote server and preform a transaction (one way if necessary), as if
> > coming from a machine I have no access to. I suspect UDP yes, TCP no.
> >
> > Ideas, resources, links? (note, I do have scruples and this inquiry is
> > primarily to cover my end when pursuing unauthorized SMTP access)
> 
> The only way to spoof a complete TCP session is one of two ways:
> 
> 1) gain control of routing for the spoofed IP address.
> 2) be in the actual path the packet would take to get to the real owner of
>    the spoofed address.
> 


Not entirely accurate.  Cf. "blind TCP spoofing" from any of a number
of sources in the past two years.  I believe Dug Song's penetration
of FW-1's authentication mechanism relied on this technique, but I'd
have to check the videotape.

A TCP packet is nothing more than a message tagged with a sender and
receiver address.  There is no guarantee whatsoever that the 
recipient obtained the packet from the sender unmolested, or at all.
There are myriad programs designed to allow the crafting of TCP
packets, and one does not need to control a TCP session to inject
data into the stream.  One merely needs to be aware of the state of
the transaction at injection, and have the ability to either
modify data en route (as you suggest), or create a race condition
in which your spoofed packet reaches the target before the legitimate
traffic, a la the character-buffered exploit for SecurID authentication.
This latter approach requires nothing other than access to the 
destination system and knowledge of -- but not necessarily access to --
an existing TCP session.


-- 
Mark C. Langston         VP, SAGE Certification       Sr. SysAdmin
mark at bitshift.org        http://www.sagecert.org   Project Phoenix
Systems & Network Admin        By and For           SETI Institute
http://bitshift.org       Systems Administrators     mark at seti.org



More information about the svlug mailing list