Re: MiM Simultaneous close attack

["Paul" <paulbugtraq () 263 net>]

Hi,
Considering the following senario:

                 internet
                    |
                 +--+-----+
                 | gateway|
                 +--+-----+ 
                    |MAC1(gg:gg)ip,gg.gg
                    |
                    |port3 
          port1 +---+---+  port2
       +--------+switch +---------------------+
       |        +-------+                     |
   +---+-----+                            +---+---+
   |  Hub1   +--host c ip cc,cc           |  HUB2 |
   +-+-----+-+  mac cc:cc                 +---+---+
     |                                        | 
   Host A(MAC2 aa:aa)              Host B(mac bb:bb)ip,bb.bb 
  ip:aa.aa           
This is the topology of my Campus Network.I am on Host A.I wanna get the packets between all hosts on hub2 and 

the gateway.I sent icmp echo reply(src ip gg.gg;dst ip cc,cc;src mac is gg.gg;des mac is cc,cc).But I　ｃａｎ

not get any packet outside hub1.I think the reason is :

1.In my Campus Network,the gateway is the default gateway of nearly 200 hosts. 2.If the fake icmp reply updates

port1's port->mac mapping,but because gateway is very busy,Port3's port->mac mapping updates very very frequently.

So the packets(dst mac is gg:gg) will goto port3 correctly.(If the same mac presents in two ports,the packets

heading for the mac will be switched to the port which the mac presents latest.)





By the way,if Anybody has succeed in switching proof above,Please send the detail information.

Regards.
Paul

 



----- Original Message ----- 
From: "big bon" <vulndev () hotmail com>
To: <Malcolm () brandes com>; <kkaya () prioriy1world com>; <vuln-dev () securityfocus com>
Sent: Saturday, August 18, 2001 2:08 AM
Subject: RE: MiM Simultaneous close attack


> switched network is not security.  switches can be forced to dump packets to 
> all ports just like a hub
>
> > From: Malcolm Jack <Malcolm () brandes com>
> > To: 'Korhan Kaya' <kkaya () prioriy1world com>, vuln-dev () securityfocus com
> > Subject: RE: MiM Simultaneous close attack
> > Date: Fri, 17 Aug 2001 09:01:11 -0700
> >
> > Excuse my ignorance, but wouldn't a switched network be a remedy for this
> > attack?  Unless you are using some type of 'port mirroring' functionality
> > (at the switch) the attacking computer sitting in promiscuous mode would
> > only hear broadcast traffic.  Right? Or am I missing something?
> >
> >
> >
> >
> > -----Original Message-----
> > From: Korhan Kaya [mailto:kkaya () prioriy1world com]
> > Sent: Tuesday, August 14, 2001 8:38 AM
> > To: vuln-dev () securityfocus com
> > Subject: MiM Simultaneous close attack
> >
> >
> > MiM simultaneous CLOSE attack
> >
> > Revision 1.1
> >
> > For Public Release 2001 August 07 08:00 (GMT +0200)
> > _________________________________________________________________
> >
> >  Vulnerability :
> >         MiM simultaneous CLOSE attack
> >  Vendor :
> >         N/A
> >  Category :
> >         Man in the middle / Denial of service
> >  Date :
> >         08/07/2001
> > Credits :
> >         Korhan Kaya <kkaya () priority1world com>
> >         Document ID   :  MW-TCPMD-03
> >
> >  Contents
> >
> >  1 Summary
> >  2 Affected systems
> >  3 Details
> >  4 Results
> >  5 Solution
> >  6 Reproducing
> >  7 Vendor status
> >  8 References
> >  9 Disclaimer
> > 10 Contact
> >
> > 1 Summary
> >
> >   A Man in the middle attacker can cause network
> >   flood and denial of the service usage by sending
> >   2 TCP packets per connection.
> >
> > 2 AFFECTED SYSTEMS
> >
> >  This vulnerability is tested against following platforms
> >  and they are vulnerable.
> >
> >  Linux kern-v2.4.x
> >  Microsoft Windows 2000 Server
> >  Microsoft Windows 2000 Workstation
> >  Microsoft Windows ME
> >  Microsoft Windows 98
> >
> > possibly other platforms are vulnerable.
> > Pending platform reports.
> >
> > 3 DETAILS
> >
> >   It is possible for an attacker to open ethernet
> >   at promiscious mode and monitor network activity
> >   to collect SEQ and ACK's numbers of an active TCP
> >   connections.
> >
> >   An attacker can trigger an ACK loop by sending a
> >   'spoofed' TCP packet with enabled ACK + FIN flags
> >   to source host and destination host of an active
> >   connection.
> >
> >   TCP Stacks of client and server will acknowledge
> >   that the opposite side of the connection wants
> >   to close the connection. And hosts will immedately
> >   send ACK packets to complete the sequence.
> >
> >   The vulnerability exploits at this point.
> >
> >   Figure A :
> >
> >     TCP A                MIM           TCP B
> >     1.ESTABLISHED                      ESTABLISHED
> >     2..            <-- [CTL=ACK+FIN]
> >     3.                   [CTL=ACK+FIN] -->
> >     4.CLOSE-WAIT   --> <CTL=ACK>     --> CLOSE-WAIT
> >     5.CLOSE-WAIT   <-- <CTL=ACK>     <-- CLOSE-WAIT
> >     ..
> >     ..
> >   1500.CLOSE-WAIT   --> <CTL=ACK>     --> CLOSE-WAIT
> >   1501.CLOSE-WAIT   <-- <CTL=ACK>     <-- CLOSE-WAIT
> >     ..
> >     ..
> >
> > 4 RESULTS
> >
> >   Result of this attack is continious loop of ACK packet
> >   traffic between client and server.After tranmitting
> >   MANY packets using maximum throughput , target
> >   connection will be lost. At this period client
> >   software and target service may lockup ,freeze or
> >   crash.
> >
> >   Number of transmitted packets and the generated
> >   traffic depends on host locations.
> >
> >   Attack becomes more effective if it is used against
> >   local connections such as local netbios/cifs traffic.
> >
> >   if an attacker applies above scenario on an avarage
> >   network,every connection attempt from any host to
> >   any server will fail , the network transport will
> >   be saturated in a short time , the collusion
> >   rates will raise to extreme levels and the cpu
> >   consuming of computers which is connected to
> >   network are  increased up to %90 due to the
> >   packet traffic.
> >
> > 5 SOLUTION
> >
> >    Workaround
> >
> >    none
> >
> > 6 HOW TO REPRODUCE VULNERABILITY
> >
> >    Vulnerability can be reporduced by using atached win32 binary.
> >    Download the zip file and follow the steps at the readme.txt
> >
> >    http://195.244.37.241/mimsc.zip
> >
> > 7 VENDOR STATUS
> >
> >   Microsoft corp. is Informed at 07/30/2001 , no response received.
> >
> > 8 REFERENCES
> >
> >   RFC 761, Page 35+
> >   RFC 793
> >   ACK Storm http://www.insecure.org/stf/iphijack.txt  (see for Similar
> > results)
> >
> >
> > 9 DISCLAIMER
> >
> >   Korhan Kaya is not responsible for the misuse or illegal use of
> >   any of the information and/or the software listed on this
> >   security advisory.
> >
> >   This text may be redistributed freely after the
> >   release date given at the top of the text, provided that
> >   redistributed copies are complete and unmodified.
> >
> > 10 CONTACT
> >
> >   Please send suggestions, updates, and comments to:
> >   kkaya () priority1world com
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp