RE: Fw: [sbs list] OT: Description Active IP Spoof attack and Blind IP Spoof attack
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Sun, 26 Sep 2004 16:53:45 -0500
I knew when he said that he had the last word that the last word really
wouldn't happen in our lifetime :-)
Tom
www.isaserver.org/shinder
Get the book!
Tom and Deb Shinder's Configuring ISA Server 2004
http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
-----Original Message-----
From: Jim Harrison [mailto:jim@xxxxxxxxxxxx]
Sent: Sunday, September 26, 2004 4:51 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] Fw: [sbs list] OT: Description Active IP Spoof attack
and Blind IP Spoof attack
http://www.ISAserver.org
<sigh>
We thought we'd won, but the little yappy dog just won't give up...
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
----- Original Message -----
From: "Jim Harrison" <jim@xxxxxxxxxxxx>
To: <sbs2k@xxxxxxxxxxxxxxx>
Sent: Sunday, September 26, 2004 14:48
Subject: Re: [sbs list] OT: Description Active IP Spoof attack and Blind
IP Spoof attack
My God; you're like a Chihuahua with a stinky fish.
The ISN "vulnerability" that you lay so much stock in
IS
LONG
SINCE
FIXED
IN
WINDOWS!!
Compromise all the Cisco devices you want; Win2K and later won't play.
TCP Sequence Numbering was never intended to provide any security
mechanism; it's nothing more than a way for the TCP/IP stack to
reassemble packets that may arrive out of sequence and respond "in
context" to any packet received. ..hence, the term "Sequence
Number".
Again, a 3-second Google search reveals a much better (read: accurate)
description of the three-way handshake:
http://www.freesoft.org/CIE/Course/Section4/9.htm
..you'll notice (assuming you even scan the above article) that at no
time is any form of SN used to provide any form of "security".
In order for the attacker to receive packets destined for an IP not
owned by the attacker machine,
IT
MUST
OWN
ALL
INTERMEDIATE
ROUTERS
This is the one place where you almost reach a sense of accuracy; it's
the sheer scale of the required actions that make this
"issue" far less of a potential, much less real problem than you clearly
believe it to be.
Your description of "stateful" is conveniently limited enough to make
your ramblings sound almost plausible, but as is the case with
all of your ramblings, it falls far short of a logical determination.
You logic can be best summed up as "I think (I think)".
As I and many others have responded to you in numerous private and
public threads (which always seem to "end" and resurface as
different threads in new forums, etc.), until you can provide proof of
concept according to accepted standards, you merely generate
noise and confusion (see Simon Weaver's response to your "final
posting").
Since you are clearly unable to produce more than regurgitated,
unfounded claims, I have no choice but to ask you to please step
away from the keyboard.
Here's one the last reference for you to study (there will be a quiz
later, so give it a really good looking over):
http://www.hosstyle.com/cupof.htm
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
----- Original Message -----
From: "Tony Su" <tonysu@xxxxxxxxxxxxxxxxx>
To: <sbs2k@xxxxxxxxxxxxxxx>
Sent: Sunday, September 26, 2004 13:42
Subject: [sbs list] OT: Description Active IP Spoof attack and Blind IP
Spoof attack
For those who are curious about what a Blind IP Spoof attack is and what
an Active IP Spoof attack so you'd know how to recognize if
something like these are happening...
Here are some thumbnails I'll try to make as non-technical as possible.
First, in both cases a base undererstanding of the "Three way handshake"
is required which is required in all TCP/IP connections.
More extensive descriptions with the actual command can be found but
this is a very brief description
Client machine makes initial connection to Server, inludes a number it
will use for the ISN which is based on a complicated
algorithm. All other packets returned during this session will be
incremented by one starting from the ISN, and this is the
"security." If any packet arrives at the Server with the wrong number,
it will be discarded.
Server returns a packet acknowledging receipt of the "secret" Client
ISN, and sends its own ISN to the Client which the Client will
use for evaluating security exactly as on the Server. This includes the
Client's ISN incremented by one to "prove" identity.
Client sends a packet back to the Server acknowledging receipt of the
Server's ISN and is ready to commence the data exchange
portion of the session.
Active IP Spoofing
After a valid session by a real client is in progress with a Server, a
compromised router "in the middle" can capture, monitor and
maybe even store the traffic.
At some point the Attacker on this compromised router can feel he has
accumulated sufficient information about the session to create
a DoS against one of the two machines (I'll say the Client in this
example) to take it offline and step in impersonating the offline
machine. In this case, the victim (The Server) believes it's still
communicating with the offline machine because the sequence
numbers are still consecutive and the data from the Attacker is
consistent with the overall "conversation."
This is an "Active" IP Spoof because the Attacker is actively carrying
on the conversation with the victim.
This attack is not too difficult to execute but requires compromising an
intermediate router. Also, I do not know of any way that
this attack can be carried out against a Loopback address unless the
Victim is also compromised (ie. redirecting the loopback
address)
Blind IP Spoofing
In this case, the Attacker does not require compromising an intermediate
router, but relies instead on guessing the ISN. The ISN
does not have to be guessed exactly with a single guess, the Cisco
vulnerability earlier this year demonstrated that it's only
necessary to accurately guess a number of likely candidate numbers, that
number of candidate numbers probably varies according to
what kinds of defenses the Victim might employ recognizing an unusual
number of improper ISNs (usually no defense) and available
bandwidth. Also, according to my analysis any ISA or Windows event might
actually be the result of tens, or hundreds of dropped
packets, not a single packet you might expect. Only a NetMon trace is
likely going to provide enough detail if wished.
Although Blind IP Spoofing is thought to be very difficult, there are
numerous recountings how an attacker can probe to discover the
likely "next" ISN, ie. make an initial valid connection and maybe even a
series of connections to attempt to discover a pattern. If
the Attacker can be assured of constructing the next session, then the
ISN algorithm's strength is all important making it difficult
to guess because the Attacker <knows> that the next number will be based
on the last number of the previous session.
I suspect though that it's more likely that when discussing a possible
SMTP Blind Spoof attack for the purpose of massive spamming,
the attack makes most sense being made against broad subnet address
ranges so that a "try" is being made against any number of
machines simultaneously. I have not analyzed this last method too much
but feel it's logical and therefor likely... and is
consistent with spamming attacks because spammers are indiscriminate
looking for vulnerable machines.
So, in a Blind IP Spoof attack, the Attacker needs to guess the victim's
IsN and there are a number of ways to improve the
probability of success. The other thing to note is that an ISN's degree
of vulnerability is entirely based on mathematics, there is
no such thing as impossible, only the degree of difficulty and when
Microsoft last modified the ISN algorithm it injected a TimeDate
stamp parameter which I believe has shortcomings because it's a publicly
available parameter. IMO it would have been better and
maybe the next modification will have a private, machine-specific
parameter which also might be re-cycled/re-calculated periodically
so that like Passwords an Attacker can't assume that <every> Windows
machine will calculate the ISN exactly the same way or be the
same long enough to discover what the proper calculation is.
Note that although the ISN is guessed, in a Blind Spoof Attack, the
victim's responses never are actually passed to the Attacker
because the Attacker hasn't "acquired" the spoofed address which would
enable the packets to be routed to him. In the case of
127.0.0.1, this is why Active Spoofing can't be a possibility but Blind
IP Spoofing is. All outbouund packets from the victim are
routed into a black hole and disappear.
So, let's take a look at what happens.
Attacker constructs a three way handshake with the Victim without any
return packets, ie.
Attacker initiates session sending its IsN
Victim responds acknowledging receipt of Attacker's ISN and sends its
own ISN
Attacker never receives Victim's ISN but has guessed the Server's ISN,
so sends the next packet with the guessed sequence number.
Victim accepts the packet because it has the correct sequence number and
sends a response with the next sequence number.
Attacker continues sending packets with guessed sequence numbers without
receiving any in return anticipating at every step of the
way the response of the victim.
Hence, the "Blind" part of this method... The Attacker is completely
blind but can anticipate and predict completely the responses
of the Victim. and in the case of SMTP, the "conversation" is completely
predictable because in an anonymous exchange of commands
the destination server does little more than say, "I got it, next."
My last comment regarding "Stateful Inspection" is that whether this
will be effective combating any kind of IP Spoofing (and other
situations) will depend on how it's implemented, but AFAIK a minimal
approach based on the IPv4 specification does not provide
sufficient basis to detect what I've described here. When a Blind IP
Spoof victim sends packets to 127.0.0.1(for example which would
be an obvious spoof if it actually originate on the machine), it will
consider the session complying with "statefulness" until the
packet is considered dropped and as long as packets do not carry some
unique parameter (ie. IPSec). And, since the next response is
received as expected from the same spoofed IP address, the previous
packet is considered delivered and statefulness is maintained.
Tony Su
As well you can find more info at http://groups.yahoo.com/group/sbs2k
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/dpFolB/TM
--------------------------------------------------------------------~->
As well you can find more info at http://groups.yahoo.com/group/sbs2k
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/sbs2k/
<*> To unsubscribe from this group, send an email to:
sbs2k-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
World of Windows Networking: http://www.windowsnetworking.com
Leading Network Software Directory: http://www.serverfiles.com
No.1 Exchange Server Resource Site: http://www.msexchange.org
Windows Security Resource Site: http://www.windowsecurity.com/
Network Security Library: http://www.secinf.net/
Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
tshinder@xxxxxxxxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
Other related posts:
