[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