Discussion:
ip address spoofing
(too old to reply)
George Georgalis
2005-01-19 17:01:39 UTC
Permalink
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)

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Gabriel Sechan
2005-01-19 17:01:39 UTC
Permalink
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from the
highest "Received: from" line in headers?
None.
Post by George Georgalis
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.
It can easily be done, but don't expect data back. Expect a 1 way
conversation. (2 way may be possible, but I know one way works for sure).
Post by George Georgalis
Ideas, resources, links? (note, I do have scruples and this inquiry is
primarily to cover my end when pursuing unauthorized SMTP access)
http://www.google.com/search?q=IP+spoof+download+TCP&sourceid=mozilla-search&start=0&start=0

has some interesting links off it.

Gabe

_________________________________________________________________
Unlimited Internet access for only $21.95/month.  Try MSN!
http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Tracy R Reed
2005-01-19 17:01:39 UTC
Permalink
Post by Gabriel Sechan
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Only if the target has guessable sequence numbers which is rare these
days.
Post by Gabriel Sechan
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from the
highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
Post by Gabriel Sechan
It can easily be done, but don't expect data back. Expect a 1 way
conversation. (2 way may be possible, but I know one way works for sure).
And this is why it is not likely.
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/949db18a/attachment.pgp
Paul G. Allen
2005-01-19 17:01:40 UTC
Permalink
Post by Tracy R Reed
Post by Gabriel Sechan
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Only if the target has guessable sequence numbers which is rare these
days.
Post by Gabriel Sechan
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from the
highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
The only cases I've seen are where the domain name and/or host name did not match the IP of the machine. This falls under what you said about spoofing the rest of the Received: line though.

PGA
--
Paul G. Allen
Owner, Sr. Engineer, Security Specialist
Random Logic/Dream Park
www.randomlogic.com
Paul G. Allen
2005-01-19 18:26:45 UTC
Permalink
Post by Tracy R Reed
Post by Gabriel Sechan
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Only if the target has guessable sequence numbers which is rare these
days.
Post by Gabriel Sechan
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from the
highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
The only cases I've seen are where the domain name and/or host name did not match the IP of the machine. This falls under what you said about spoofing the rest of the Received: line though.

PGA
--
Paul G. Allen
Owner, Sr. Engineer, Security Specialist
Random Logic/Dream Park
www.randomlogic.com
Tracy R Reed
2005-01-19 18:26:44 UTC
Permalink
Post by Gabriel Sechan
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Only if the target has guessable sequence numbers which is rare these
days.
Post by Gabriel Sechan
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from the
highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
Post by Gabriel Sechan
It can easily be done, but don't expect data back. Expect a 1 way
conversation. (2 way may be possible, but I know one way works for sure).
And this is why it is not likely.
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/949db18a/attachment-0001.pgp
Tracy R Reed
2005-01-19 17:01:39 UTC
Permalink
Post by George Georgalis
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?
When you spoof an ip in a tcp connection the reply packets go to the
spoofed ip. But you need to see the reply packets so you know what
sequence number to use next. If the target OS uses guessable sequence
numbers you don't need this but nearly everyone uses relatively hard to
guess sequence numbers now. I think you can have pretty high confidence
that the highest Received: line is correct although be careful you don't
fall for a bogus Received: line inserted into the header by the malicious
sender. You will usually see a discontinuity in the chain if this happens.
Post by George Georgalis
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.
UDP can do it, yes. It has no sequence numbers etc. But you have to find a
service and protocol that don't have any form of challenge-response (even
trivial forms incidental to the protocol having nothing to do with
security) that you cannot guess or you will have problems.
Post by George Georgalis
Ideas, resources, links? (note, I do have scruples and this inquiry is
primarily to cover my end when pursuing unauthorized SMTP access)
Unauthorized SMTP access? How is that possible? Did an authorized user
send unauthorized spam through your server? Surely you don't let
unauthorized users relay...
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/d18b911a/attachment.pgp
George Georgalis
2005-01-19 17:01:39 UTC
Permalink
Post by Tracy R Reed
Unauthorized SMTP access? How is that possible? Did an authorized user
send unauthorized spam through your server? Surely you don't let
unauthorized users relay...
I'm doing this research for a better argument and CYA in situations
like below...

// George




Dear Andy,

It looks okay.

$ cat newtest | /var/qmail/bin/qmail-remote 64.85.4.11 \
h64.85.4.11 does not like recipient.
Remote host said: 550 not local host galis.org, not a gateway
DGiving up on 64.85.4.11.
***@trot:~/ $


Who should I bill for my time?

// George
Post by Tracy R Reed
Can you try doing the test again. EtherJet says they made some security changes.
cat semi-open-relay.txt | /var/qmail/bin/qmail-remote 64.85.4.11 \
http://www.qmail.org/man/man8/qmail-remote.html
plus I changed my /var/qmail/control/me to be "twtc.net"
It's just using the standard protocol, with a particular smtp that
of the junk sent to me with that sender (Return-Path) and whatever
to/from or IP origin.
I'm not in the business of shifting blame, but I suspect I could have
prepended my text file with a received from cox header to tag the origin
to the original ip which would make it look like I relayed the cox mail
just like 64.85.6.5 did.
// George
Would you mind showing me how you did that?
Dear Andy,
I'm sending the message again, but this
time using the relay in question...
and masking my identity. It's an open
service, that normally sends me viruses
and warnings; but could just as well be
spam. You can find my return address in
the signature.
Please don't let the issue be muddled.
The only "Received" header that can be trusted is for the final
delivery, as it is possible for SMTP servers to change them in route.
I have no reason to suspect they have been changed here. The email
probably did come from the cox network.
The user on 68.7.78.118 is infected with klez and is forging domains.
Yes probably. And I'm complaining because your client is relaying them
to me.
THIS IS A LEGITIMATE COMPLAINT. If I have one per week or 1,000,000
inappropriate emails a day coming from a Time Warner IP, the
responsibility is all the same.
from buycastings.com (abyss.activeservers.net [64.85.6.5]) by
from cyberpackets.com (phoenix.activeservers.net [64.85.4.11]) by
Whether or not 64.85.6.5 or 64.85.4.11 is an open relay (for everyone)
is irrelevant, by saying the mail originated on a network you are
not responsible for and delivering that mail, you have functionally
demonstrated an open relay. (Delivered mail you have no affiliation
with, yes.)
The quote below from the Symantic link regarding the virus is entirely
When it performs its email routine. it can use a randomly chosen address
that it finds on an infected computer as the "From:"
There is no question the "From:" address was mine (though the virus
generated it, not I). The virus came from the cox network and spoofed
the from address, however there was no spoofing of the relay IP -- it
This is the source of my complaint. The Time Warner IPs in question are
relaying mail to me or sending messages that my email was quarantined
when I had nothing to do with their invocation; furthermore the owner of
the IPs are declining responsibility after delivering the messages to
me.
// George
George,
The source of the problem goes back to IP 68.7.78.118 which as you know is cox.net
below is a pretty clear give away
Received: from Amgzwww [68.7.78.118] by abyss.activeservers.net
abyss.activeservers.net is on Time Warner IP space, not 68.7.78.118.
Email spoofing
This worm often uses a technique known as "spoofing." When it
performs its email routine. it can use a randomly chosen address
that it finds on an infected computer as the "From:" address,
numerous cases have been reported in which users of uninfected
computers received complaints that they sent an infected message
to someone else.
A clearer understanding can be obtained reading this page.
I reccommend you follow up this issue with cox.net so they can
identify their customer who is more than likely infected.
Cox Enterprises (COX24-DOM)
1400 Lake Hearn Drive
Atlanta
GA,30319
US
Domain Name: COX.NET
Cox Communications
1400 Lake Hearn Drive
Atlanta, GA 30319
US
404-843-5000 fax: 404-847-6335
Record expires on 12-Oct-2003.
Record created on 12-Oct-2001.
Database last updated on 21-Oct-2002 16:32:00 EDT.
NS.COX.NET 68.1.17.237
NS.WEST.COX.NET 68.6.19.237
NS.EAST.COX.NET 68.1.17.5
The user on 68.7.78.118 is infected with klez and is forging domains.
Andy,
I never got a copy of the ticket from Friday. How are things
progressing? I have received several more messages relevant to the ip
blocks as we discussed.
Would you like more info?
// George
Received: from localhost.localdomain
by localhost with POP3 (fetchmail-5.9.0)
Date: Sun, 20 Oct 2002 22:12:29 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: WARNING: YOU WERE SENT A VIRUS
X-Mailer: <IMail v7.07>
X-UIDL: E~a!!l!N"!oX6"!~'D"!
Cyberpackets Filtering & Virus Screening has taken action on
buycastings.com has reported that you were sent an E-mail
843007[1].scr attachment. The subject of the E-mail was "Please try again".
The E-mail containing the virus has been quarantined to prevent any damage.
Received: from Amgzwww [68.7.78.118] by abyss.activeservers.net
(SMTPD32-7.07) id ACB631B300CE; Sun, 20 Oct 2002 22:12:22 -0700
Subject: Please try again
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=T7J125pl8pEWbZkm4S
----- End forwarded message -----
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
File, Print, DB and DNS Servers. http://www.galis.org/george
--
Andrew
Internet Customer Support Specialist II
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
File, Print, DB and DNS Servers. http://www.galis.org/george
--
Andrew
Internet Customer Support Specialist II
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
File, Print, DB and DNS Servers. http://www.galis.org/george
--
Andrew
Internet Customer Support Specialist II
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
George Georgalis
2005-01-19 18:26:44 UTC
Permalink
Post by Tracy R Reed
Unauthorized SMTP access? How is that possible? Did an authorized user
send unauthorized spam through your server? Surely you don't let
unauthorized users relay...
I'm doing this research for a better argument and CYA in situations
like below...

// George




Dear Andy,

It looks okay.

$ cat newtest | /var/qmail/bin/qmail-remote 64.85.4.11 \
h64.85.4.11 does not like recipient.
Remote host said: 550 not local host galis.org, not a gateway
DGiving up on 64.85.4.11.
***@trot:~/ $


Who should I bill for my time?

// George
Post by Tracy R Reed
Can you try doing the test again. EtherJet says they made some security changes.
cat semi-open-relay.txt | /var/qmail/bin/qmail-remote 64.85.4.11 \
http://www.qmail.org/man/man8/qmail-remote.html
plus I changed my /var/qmail/control/me to be "twtc.net"
It's just using the standard protocol, with a particular smtp that
of the junk sent to me with that sender (Return-Path) and whatever
to/from or IP origin.
I'm not in the business of shifting blame, but I suspect I could have
prepended my text file with a received from cox header to tag the origin
to the original ip which would make it look like I relayed the cox mail
just like 64.85.6.5 did.
// George
Would you mind showing me how you did that?
Post by George Georgalis
Dear Andy,
I'm sending the message again, but this
time using the relay in question...
and masking my identity. It's an open
service, that normally sends me viruses
and warnings; but could just as well be
spam. You can find my return address in
the signature.
Please don't let the issue be muddled.
The only "Received" header that can be trusted is for the final
delivery, as it is possible for SMTP servers to change them in route.
I have no reason to suspect they have been changed here. The email
probably did come from the cox network.
The user on 68.7.78.118 is infected with klez and is forging domains.
Yes probably. And I'm complaining because your client is relaying them
to me.
THIS IS A LEGITIMATE COMPLAINT. If I have one per week or 1,000,000
inappropriate emails a day coming from a Time Warner IP, the
responsibility is all the same.
from buycastings.com (abyss.activeservers.net [64.85.6.5]) by
from cyberpackets.com (phoenix.activeservers.net [64.85.4.11]) by
Whether or not 64.85.6.5 or 64.85.4.11 is an open relay (for everyone)
is irrelevant, by saying the mail originated on a network you are
not responsible for and delivering that mail, you have functionally
demonstrated an open relay. (Delivered mail you have no affiliation
with, yes.)
The quote below from the Symantic link regarding the virus is entirely
When it performs its email routine. it can use a randomly chosen address
that it finds on an infected computer as the "From:"
There is no question the "From:" address was mine (though the virus
generated it, not I). The virus came from the cox network and spoofed
the from address, however there was no spoofing of the relay IP -- it
This is the source of my complaint. The Time Warner IPs in question are
relaying mail to me or sending messages that my email was quarantined
when I had nothing to do with their invocation; furthermore the owner of
the IPs are declining responsibility after delivering the messages to
me.
// George
George,
The source of the problem goes back to IP 68.7.78.118 which as you know is cox.net
below is a pretty clear give away
Received: from Amgzwww [68.7.78.118] by abyss.activeservers.net
abyss.activeservers.net is on Time Warner IP space, not 68.7.78.118.
Email spoofing
This worm often uses a technique known as "spoofing." When it
performs its email routine. it can use a randomly chosen address
that it finds on an infected computer as the "From:" address,
numerous cases have been reported in which users of uninfected
computers received complaints that they sent an infected message
to someone else.
A clearer understanding can be obtained reading this page.
I reccommend you follow up this issue with cox.net so they can
identify their customer who is more than likely infected.
Cox Enterprises (COX24-DOM)
1400 Lake Hearn Drive
Atlanta
GA,30319
US
Domain Name: COX.NET
Cox Communications
1400 Lake Hearn Drive
Atlanta, GA 30319
US
404-843-5000 fax: 404-847-6335
Record expires on 12-Oct-2003.
Record created on 12-Oct-2001.
Database last updated on 21-Oct-2002 16:32:00 EDT.
NS.COX.NET 68.1.17.237
NS.WEST.COX.NET 68.6.19.237
NS.EAST.COX.NET 68.1.17.5
The user on 68.7.78.118 is infected with klez and is forging domains.
Andy,
I never got a copy of the ticket from Friday. How are things
progressing? I have received several more messages relevant to the ip
blocks as we discussed.
Would you like more info?
// George
Received: from localhost.localdomain
by localhost with POP3 (fetchmail-5.9.0)
Date: Sun, 20 Oct 2002 22:12:29 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: WARNING: YOU WERE SENT A VIRUS
X-Mailer: <IMail v7.07>
X-UIDL: E~a!!l!N"!oX6"!~'D"!
Cyberpackets Filtering & Virus Screening has taken action on
buycastings.com has reported that you were sent an E-mail
843007[1].scr attachment. The subject of the E-mail was "Please try again".
The E-mail containing the virus has been quarantined to prevent any damage.
Received: from Amgzwww [68.7.78.118] by abyss.activeservers.net
(SMTPD32-7.07) id ACB631B300CE; Sun, 20 Oct 2002 22:12:22 -0700
Subject: Please try again
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=T7J125pl8pEWbZkm4S
----- End forwarded message -----
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
File, Print, DB and DNS Servers. http://www.galis.org/george
--
Andrew
Internet Customer Support Specialist II
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
File, Print, DB and DNS Servers. http://www.galis.org/george
--
Andrew
Internet Customer Support Specialist II
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
File, Print, DB and DNS Servers. http://www.galis.org/george
--
Andrew
Internet Customer Support Specialist II
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Michael O'Keefe
2005-01-19 17:01:39 UTC
Permalink
Post by George Georgalis
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)
A man in the middle attack is possible, but originating a TCP IP spoof
attack is only possible if you are close enuff to the target that you can
re-route packets intended for the IP that you have spoofed to come to your
attacking machine. Otherwise, the hand-shake will go to the bewildered host
and he will respond with a TCP RST, and the conversation will cease.

I say *only* possible, with my limited knowledge...IANAC of TCP ;)
--
Michael O'Keefe | ***@qualcomm.com_
Live on and Ride a '96 Honda CBR1000F| ***@cox.net / |
I like less more or less less than |Work:+1 858 845 3514 / |
more. UNIX-live it,love it,fork() it |Fax :+1 858 651 1984 /_p_|
My views are MINE ALONE, blah, blah, |Home:+1 858 748 5432 \`O'|
blah, yackety yack - don't come back |Fax :+1 858 _/_\|_,
Gabriel Sechan
2005-01-19 17:01:39 UTC
Permalink
Post by Tracy R Reed
Post by Gabriel Sechan
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Only if the target has guessable sequence numbers which is rare these
days.
Only most versions of Windows :)
Post by Tracy R Reed
Post by Gabriel Sechan
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from
the
Post by Gabriel Sechan
Post by George Georgalis
highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
I have.
Post by Tracy R Reed
Post by Gabriel Sechan
It can easily be done, but don't expect data back. Expect a 1 way
conversation. (2 way may be possible, but I know one way works for
sure).
And this is why it is not likely.
Since TCP is a byte stream, you don't have to respond to packets. If you
know the protocol, you can send all the data in 1 quick series of packets.

This works best if on the same network (so you can look for acks) but does
work otherwise. Just send the data 10 times or so, the recipient will drop
the repeats it gets.

Gabe


_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access.
http://resourcecenter.msn.com/access/plans/default.asp
George Georgalis
2005-01-19 17:01:39 UTC
Permalink
Post by Gabriel Sechan
Post by Tracy R Reed
What level of confidence can be had that SMTP mail truly was
delivered from the highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
I have.
The only time I saw (noticed) bad received headers, they were in the
wrong place and obviously put in with formail or something.

I'm thinking if a received header was in the top of a message piped to
qmail-remote -- that might be hard to catch, but I haven't tried it.

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Tracy R Reed
2005-01-19 17:01:40 UTC
Permalink
Post by Gabriel Sechan
Only most versions of Windows :)
True. Windows 95/98 are poor. But 2000 etc are much better. And any unix
out there is nearly impossible. So it depends on what the target OS would
have been in George's situation. Usually smtp servers are Unix or NT.
Post by Gabriel Sechan
Since TCP is a byte stream, you don't have to respond to packets. If you
know the protocol, you can send all the data in 1 quick series of packets.
Yes, you do have to respond to packets in the form of ack. And the ack
must contain the sequence number of the packet being acked.
Post by Gabriel Sechan
This works best if on the same network (so you can look for acks) but does
work otherwise. Just send the data 10 times or so, the recipient will drop
the repeats it gets.
Yes, if you are spoofing an ip that will be routed back into your subnet
you can sniff and know all of the sequence numbers. I have done tcp
session hijacking by spoofing arp of the gateway on a switched network to
intercept all traffic and then inject funny comments into my coworkers IRC
sessions. :)
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/eb520440/attachment.pgp
Nick Bastin
2005-01-19 17:01:40 UTC
Permalink
Post by Tracy R Reed
Post by Gabriel Sechan
Only most versions of Windows :)
True. Windows 95/98 are poor. But 2000 etc are much better. And any unix
out there is nearly impossible. So it depends on what the target OS would
Oh, REALLY? Along with Win95/98, AIX and HP/UX have 100% attack
feasibility. The only unix with 0% attack feasibility out of the box is
OpenBSD 2.9, and most have a feasibility of greater than 10%.

On top of all of this, there are many other ways to munge the 'Received
By:' header, and I would never trust it's value in an email received by
someone else, and only marginally trust the value in email sent directly to me.

--
Nick
Kevin Partridge
2005-01-19 17:01:40 UTC
Permalink
What makes OpenBSD rate a 0% attack feasibility?

Kevin
Post by Nick Bastin
Post by Tracy R Reed
Post by Gabriel Sechan
Only most versions of Windows :)
True. Windows 95/98 are poor. But 2000 etc are much better. And any unix
out there is nearly impossible. So it depends on what the target OS would
Oh, REALLY? Along with Win95/98, AIX and HP/UX have 100% attack
feasibility. The only unix with 0% attack feasibility out of the box is
OpenBSD 2.9, and most have a feasibility of greater than 10%.
On top of all of this, there are many other ways to munge the 'Received
By:' header, and I would never trust it's value in an email received by
someone else, and only marginally trust the value in email sent directly to me.
--
Nick
--
http://www.kernel-panic.org
list archives http://www.ultraviolet.org
To unsubscribe, send a message to the address shown in the list-unsubscribe
header of this message.
Tracy R Reed
2005-01-19 17:01:40 UTC
Permalink
Post by Kevin Partridge
What makes OpenBSD rate a 0% attack feasibility?
Secure tcp sequence number prediction. A solid algorithm with lots of
entropy.
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/fb2c51e8/attachment.pgp
Kevin Partridge
2005-01-19 17:01:40 UTC
Permalink
Post by Tracy R Reed
Post by Kevin Partridge
What makes OpenBSD rate a 0% attack feasibility?
Secure tcp sequence number prediction. A solid algorithm with lots of
entropy.
how does it differ from any other *nix's generator?

Kevin
Tracy R Reed
2005-01-19 18:26:45 UTC
Permalink
Post by Kevin Partridge
What makes OpenBSD rate a 0% attack feasibility?
Secure tcp sequence number prediction. A solid algorithm with lots of
entropy.
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/fb2c51e8/attachment-0001.pgp
Kevin Partridge
2005-01-19 18:26:45 UTC
Permalink
Post by Tracy R Reed
Post by Kevin Partridge
What makes OpenBSD rate a 0% attack feasibility?
Secure tcp sequence number prediction. A solid algorithm with lots of
entropy.
how does it differ from any other *nix's generator?

Kevin
George Georgalis
2005-01-19 18:26:45 UTC
Permalink
Post by Gabriel Sechan
Post by Tracy R Reed
What level of confidence can be had that SMTP mail truly was
delivered from the highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
I have.
The only time I saw (noticed) bad received headers, they were in the
wrong place and obviously put in with formail or something.

I'm thinking if a received header was in the top of a message piped to
qmail-remote -- that might be hard to catch, but I haven't tried it.

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Tracy R Reed
2005-01-19 18:26:45 UTC
Permalink
Post by Gabriel Sechan
Only most versions of Windows :)
True. Windows 95/98 are poor. But 2000 etc are much better. And any unix
out there is nearly impossible. So it depends on what the target OS would
have been in George's situation. Usually smtp servers are Unix or NT.
Post by Gabriel Sechan
Since TCP is a byte stream, you don't have to respond to packets. If you
know the protocol, you can send all the data in 1 quick series of packets.
Yes, you do have to respond to packets in the form of ack. And the ack
must contain the sequence number of the packet being acked.
Post by Gabriel Sechan
This works best if on the same network (so you can look for acks) but does
work otherwise. Just send the data 10 times or so, the recipient will drop
the repeats it gets.
Yes, if you are spoofing an ip that will be routed back into your subnet
you can sniff and know all of the sequence numbers. I have done tcp
session hijacking by spoofing arp of the gateway on a switched network to
intercept all traffic and then inject funny comments into my coworkers IRC
sessions. :)
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/eb520440/attachment-0001.pgp
Nick Bastin
2005-01-19 18:26:45 UTC
Permalink
Post by Tracy R Reed
Post by Gabriel Sechan
Only most versions of Windows :)
True. Windows 95/98 are poor. But 2000 etc are much better. And any unix
out there is nearly impossible. So it depends on what the target OS would
Oh, REALLY? Along with Win95/98, AIX and HP/UX have 100% attack
feasibility. The only unix with 0% attack feasibility out of the box is
OpenBSD 2.9, and most have a feasibility of greater than 10%.

On top of all of this, there are many other ways to munge the 'Received
By:' header, and I would never trust it's value in an email received by
someone else, and only marginally trust the value in email sent directly to me.

--
Nick
Kevin Partridge
2005-01-19 18:26:45 UTC
Permalink
What makes OpenBSD rate a 0% attack feasibility?

Kevin
Post by Nick Bastin
Post by Tracy R Reed
Post by Gabriel Sechan
Only most versions of Windows :)
True. Windows 95/98 are poor. But 2000 etc are much better. And any unix
out there is nearly impossible. So it depends on what the target OS would
Oh, REALLY? Along with Win95/98, AIX and HP/UX have 100% attack
feasibility. The only unix with 0% attack feasibility out of the box is
OpenBSD 2.9, and most have a feasibility of greater than 10%.
On top of all of this, there are many other ways to munge the 'Received
By:' header, and I would never trust it's value in an email received by
someone else, and only marginally trust the value in email sent directly to me.
--
Nick
--
http://www.kernel-panic.org
list archives http://www.ultraviolet.org
To unsubscribe, send a message to the address shown in the list-unsubscribe
header of this message.
Nick Bastin
2005-01-19 17:01:40 UTC
Permalink
Post by Tracy R Reed
Post by George Georgalis
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?
When you spoof an ip in a tcp connection the reply packets go to the
spoofed ip. But you need to see the reply packets so you know what
sequence number to use next. If the target OS uses guessable sequence
numbers you don't need this but nearly everyone uses relatively hard to
guess sequence numbers now. I think you can have pretty high confidence
that the highest Received: line is correct although be careful you don't
fall for a bogus Received: line inserted into the header by the malicious
sender. You will usually see a discontinuity in the chain if this happens.
First, many systems *still* have guessable sequence numbers, but that's not
even the point here. It's entirely possible to spoof the source IP
address, but still provide a temporary return path so that you can actually
set up the connection without having to deal with the inconvenience of not
getting the return packets.

If you haven't already seen it, a while ago BindView software published a
paper on TCP sequence number prediction with current operating
systems: http://razor.bindview.com/publish/papers/tcpseq.html

--
Nick
George Georgalis
2005-01-19 17:01:40 UTC
Permalink
Post by Nick Bastin
Post by Tracy R Reed
Post by George Georgalis
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?
When you spoof an ip in a tcp connection the reply packets go to the
spoofed ip. But you need to see the reply packets so you know what
sequence number to use next. If the target OS uses guessable sequence
numbers you don't need this but nearly everyone uses relatively hard to
guess sequence numbers now. I think you can have pretty high confidence
that the highest Received: line is correct although be careful you don't
fall for a bogus Received: line inserted into the header by the malicious
sender. You will usually see a discontinuity in the chain if this happens.
First, many systems *still* have guessable sequence numbers, but that's not
even the point here. It's entirely possible to spoof the source IP
address, but still provide a temporary return path so that you can actually
set up the connection without having to deal with the inconvenience of not
getting the return packets.
If you haven't already seen it, a while ago BindView software published a
paper on TCP sequence number prediction with current operating
systems: http://razor.bindview.com/publish/papers/tcpseq.html
Hi Nick -

First off I'm amazed at the amount of response! (my isp wouldn't even
respond to the question.)

The technique you describe seems like it would require a compromise of
the spoofed IP box. Yeah, that could be a problem, but for my needs
it doesn't matter much if a box was used in-route (last hop) or was the
origin.

(ooops there goes my cable tv and isp.... don't think it's gone out before)

It's a very good point though, just because the transaction came from some
host, doesn't mean they know or did it. In the end I guess it really depends
on how they respond to a complaint... Since I heard it at a sdriw talk, I've
always reiterated: demonstrating "reasonable care" that your computers
are updated and aren't compromised is "enough"

The link looks very good, fortunately it's still in my browser :) maybe
my mail queue works too... :-)

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Kevin Partridge
2005-01-19 17:01:40 UTC
Permalink
Post by George Georgalis
Hi Nick -
First off I'm amazed at the amount of response! (my isp wouldn't even
respond to the question.)
The technique you describe seems like it would require a compromise of
the spoofed IP box. Yeah, that could be a problem, but for my needs
it doesn't matter much if a box was used in-route (last hop) or was the
origin.
(ooops there goes my cable tv and isp.... don't think it's gone out before)
funny that your service went out. the technique they were talking about
doesn't require owning the other box but it is facilitated by DoSing the
spoofed address. :)

(the DoS part is true. I'm being funny talking about your service going out.)

Kevin
George Georgalis
2005-01-19 17:01:41 UTC
Permalink
Post by Kevin Partridge
Post by George Georgalis
(ooops there goes my cable tv and isp.... don't think it's gone out before)
funny that your service went out. the technique they were talking about
doesn't require owning the other box but it is facilitated by DoSing the
spoofed address. :)
(the DoS part is true. I'm being funny talking about your service going out.)
Well looking at the latency gradient (plotted by smokeping), a dos
wouldn't surprise me. In about :15, ping times gradually rose until they
doubled the norm, then (12:30 am) the gateway was out for 8 hours.

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
George Georgalis
2005-01-19 18:26:47 UTC
Permalink
Post by Kevin Partridge
Post by George Georgalis
(ooops there goes my cable tv and isp.... don't think it's gone out before)
funny that your service went out. the technique they were talking about
doesn't require owning the other box but it is facilitated by DoSing the
spoofed address. :)
(the DoS part is true. I'm being funny talking about your service going out.)
Well looking at the latency gradient (plotted by smokeping), a dos
wouldn't surprise me. In about :15, ping times gradually rose until they
doubled the norm, then (12:30 am) the gateway was out for 8 hours.

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
George Georgalis
2005-01-19 18:26:46 UTC
Permalink
Post by Nick Bastin
Post by Tracy R Reed
Post by George Georgalis
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?
When you spoof an ip in a tcp connection the reply packets go to the
spoofed ip. But you need to see the reply packets so you know what
sequence number to use next. If the target OS uses guessable sequence
numbers you don't need this but nearly everyone uses relatively hard to
guess sequence numbers now. I think you can have pretty high confidence
that the highest Received: line is correct although be careful you don't
fall for a bogus Received: line inserted into the header by the malicious
sender. You will usually see a discontinuity in the chain if this happens.
First, many systems *still* have guessable sequence numbers, but that's not
even the point here. It's entirely possible to spoof the source IP
address, but still provide a temporary return path so that you can actually
set up the connection without having to deal with the inconvenience of not
getting the return packets.
If you haven't already seen it, a while ago BindView software published a
paper on TCP sequence number prediction with current operating
systems: http://razor.bindview.com/publish/papers/tcpseq.html
Hi Nick -

First off I'm amazed at the amount of response! (my isp wouldn't even
respond to the question.)

The technique you describe seems like it would require a compromise of
the spoofed IP box. Yeah, that could be a problem, but for my needs
it doesn't matter much if a box was used in-route (last hop) or was the
origin.

(ooops there goes my cable tv and isp.... don't think it's gone out before)

It's a very good point though, just because the transaction came from some
host, doesn't mean they know or did it. In the end I guess it really depends
on how they respond to a complaint... Since I heard it at a sdriw talk, I've
always reiterated: demonstrating "reasonable care" that your computers
are updated and aren't compromised is "enough"

The link looks very good, fortunately it's still in my browser :) maybe
my mail queue works too... :-)

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Kevin Partridge
2005-01-19 18:26:46 UTC
Permalink
Post by George Georgalis
Hi Nick -
First off I'm amazed at the amount of response! (my isp wouldn't even
respond to the question.)
The technique you describe seems like it would require a compromise of
the spoofed IP box. Yeah, that could be a problem, but for my needs
it doesn't matter much if a box was used in-route (last hop) or was the
origin.
(ooops there goes my cable tv and isp.... don't think it's gone out before)
funny that your service went out. the technique they were talking about
doesn't require owning the other box but it is facilitated by DoSing the
spoofed address. :)

(the DoS part is true. I'm being funny talking about your service going out.)

Kevin
Gabriel Sechan
2005-01-19 17:01:40 UTC
Permalink
Post by Kevin Partridge
What makes OpenBSD rate a 0% attack feasibility?
Pretty much purely random numbers. There's no clustering of their random
number generator whatsoever. So it would have to be a pure guess- a 1/2^31
or 1/2^32 possibility.

Gabe

_________________________________________________________________
Get faster connections -- switch to MSN Internet Access!
http://resourcecenter.msn.com/access/plans/default.asp
Michael J McCafferty
2005-01-19 17:01:40 UTC
Permalink
That's "probability" not possibility. :o)
guess- a 1/2^31 or 1/2^32 possibility.
Gabe
**************************************************
Michael J. McCafferty
M5 Computer Security
858-576-7325 Voice
PGP Key ID: 0x2206347F
http://www.m5computersecurity.com
**************************************************
--- "If you build it, they will hack !" ---
George Georgalis
2005-01-19 18:26:44 UTC
Permalink
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)

// George
--
GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229
Security Services, Web, Mail, mailto:***@galis.org
File, Print, DB and DNS Servers. http://www.galis.org/george
Gabriel Sechan
2005-01-19 18:26:44 UTC
Permalink
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from the
highest "Received: from" line in headers?
None.
Post by George Georgalis
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.
It can easily be done, but don't expect data back. Expect a 1 way
conversation. (2 way may be possible, but I know one way works for sure).
Post by George Georgalis
Ideas, resources, links? (note, I do have scruples and this inquiry is
primarily to cover my end when pursuing unauthorized SMTP access)
http://www.google.com/search?q=IP+spoof+download+TCP&sourceid=mozilla-search&start=0&start=0

has some interesting links off it.

Gabe

_________________________________________________________________
Unlimited Internet access for only $21.95/month.  Try MSN!
http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Tracy R Reed
2005-01-19 18:26:44 UTC
Permalink
Post by George Georgalis
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?
When you spoof an ip in a tcp connection the reply packets go to the
spoofed ip. But you need to see the reply packets so you know what
sequence number to use next. If the target OS uses guessable sequence
numbers you don't need this but nearly everyone uses relatively hard to
guess sequence numbers now. I think you can have pretty high confidence
that the highest Received: line is correct although be careful you don't
fall for a bogus Received: line inserted into the header by the malicious
sender. You will usually see a discontinuity in the chain if this happens.
Post by George Georgalis
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.
UDP can do it, yes. It has no sequence numbers etc. But you have to find a
service and protocol that don't have any form of challenge-response (even
trivial forms incidental to the protocol having nothing to do with
security) that you cannot guess or you will have problems.
Post by George Georgalis
Ideas, resources, links? (note, I do have scruples and this inquiry is
primarily to cover my end when pursuing unauthorized SMTP access)
Unauthorized SMTP access? How is that possible? Did an authorized user
send unauthorized spam through your server? Surely you don't let
unauthorized users relay...
--
Tracy Reed http://www.ultraviolet.org
"Our products just aren't engineered for security." - Brian Valentine,
senior VP in charge of Microsoft's Windows development 5 Sept 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20021024/d18b911a/attachment-0001.pgp
Michael O'Keefe
2005-01-19 18:26:44 UTC
Permalink
Post by George Georgalis
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)
A man in the middle attack is possible, but originating a TCP IP spoof
attack is only possible if you are close enuff to the target that you can
re-route packets intended for the IP that you have spoofed to come to your
attacking machine. Otherwise, the hand-shake will go to the bewildered host
and he will respond with a TCP RST, and the conversation will cease.

I say *only* possible, with my limited knowledge...IANAC of TCP ;)
--
Michael O'Keefe | ***@qualcomm.com_
Live on and Ride a '96 Honda CBR1000F| ***@cox.net / |
I like less more or less less than |Work:+1 858 845 3514 / |
more. UNIX-live it,love it,fork() it |Fax :+1 858 651 1984 /_p_|
My views are MINE ALONE, blah, blah, |Home:+1 858 748 5432 \`O'|
blah, yackety yack - don't come back |Fax :+1 858 _/_\|_,
Gabriel Sechan
2005-01-19 18:26:44 UTC
Permalink
Post by Tracy R Reed
Post by Gabriel Sechan
Post by George Georgalis
Is there any way to spoof the source IP in a TCP/IP transaction?
Yes, fairly easily.
Only if the target has guessable sequence numbers which is rare these
days.
Only most versions of Windows :)
Post by Tracy R Reed
Post by Gabriel Sechan
Post by George Georgalis
What
level of confidence can be had that SMTP mail truly was delivered from
the
Post by Gabriel Sechan
Post by George Georgalis
highest "Received: from" line in headers?
None.
I have never run into a case where the Received: line was not correct.
I have.
Post by Tracy R Reed
Post by Gabriel Sechan
It can easily be done, but don't expect data back. Expect a 1 way
conversation. (2 way may be possible, but I know one way works for
sure).
And this is why it is not likely.
Since TCP is a byte stream, you don't have to respond to packets. If you
know the protocol, you can send all the data in 1 quick series of packets.

This works best if on the same network (so you can look for acks) but does
work otherwise. Just send the data 10 times or so, the recipient will drop
the repeats it gets.

Gabe


_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access.
http://resourcecenter.msn.com/access/plans/default.asp
Nick Bastin
2005-01-19 18:26:45 UTC
Permalink
Post by Tracy R Reed
Post by George Georgalis
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?
When you spoof an ip in a tcp connection the reply packets go to the
spoofed ip. But you need to see the reply packets so you know what
sequence number to use next. If the target OS uses guessable sequence
numbers you don't need this but nearly everyone uses relatively hard to
guess sequence numbers now. I think you can have pretty high confidence
that the highest Received: line is correct although be careful you don't
fall for a bogus Received: line inserted into the header by the malicious
sender. You will usually see a discontinuity in the chain if this happens.
First, many systems *still* have guessable sequence numbers, but that's not
even the point here. It's entirely possible to spoof the source IP
address, but still provide a temporary return path so that you can actually
set up the connection without having to deal with the inconvenience of not
getting the return packets.

If you haven't already seen it, a while ago BindView software published a
paper on TCP sequence number prediction with current operating
systems: http://razor.bindview.com/publish/papers/tcpseq.html

--
Nick
Gabriel Sechan
2005-01-19 18:26:45 UTC
Permalink
Post by Kevin Partridge
What makes OpenBSD rate a 0% attack feasibility?
Pretty much purely random numbers. There's no clustering of their random
number generator whatsoever. So it would have to be a pure guess- a 1/2^31
or 1/2^32 possibility.

Gabe

_________________________________________________________________
Get faster connections -- switch to MSN Internet Access!
http://resourcecenter.msn.com/access/plans/default.asp
Michael J McCafferty
2005-01-19 18:26:45 UTC
Permalink
That's "probability" not possibility. :o)
guess- a 1/2^31 or 1/2^32 possibility.
Gabe
**************************************************
Michael J. McCafferty
M5 Computer Security
858-576-7325 Voice
PGP Key ID: 0x2206347F
http://www.m5computersecurity.com
**************************************************
--- "If you build it, they will hack !" ---
Continue reading on narkive:
Loading...