Re: MAC address spoofing - conflict?

From: Christopher 's1n' Durkin (s1n@evilbastards.com)
Date: Wed Aug 23 2006 - 19:23:42 EDT


Hi all,

firstly, please forgive me for the following essay :)

to clear this up:

Switches
--------

Switches have port/MAC mappings in memory.
For dumb switches (with no port 'security' enabled e.g. cisco catalysts port protection), _ALL_ ports which have the associated MAC address mapped to them should receive all Layer 2 (and by design all Layer 3) traffic intended for that MAC address. Some Managed switches support this as a feature; I have seen said "monitor ports" on both HP and Cisco products. Dumb switches have no way of knowing what port should have what MAC so they do not discriminate. Managed switches can sometimes be set to discriminate although this is rarely done in practice.

Layer 3 traffic is handled by the Operating System's respective networking stack (Not including IP-based ACLs/Firewalls). This means that the layer 2 traffic is irrelevant in such a situation. If the IP address does not match, the packet is dropped.

Hubs

----
Hubs have no Port/MAC mappings and instead relay _ALL_ Layer 2 encapsulated data to _ALL_ ports. Traffic matching the Host's IP address will be accepted. All other IP's will be dropped by the network adapter. This does not cause any bizarre Layer 3 networking problems, so we can assume that there are no conflicts from such situation. 
Side Note
---------
To help clear up any misunderstanding, a port stealing attack (MAC flooding) will cause most switches to fall back to hub mode. this also does not cause any bizarre networking problems as all respective hosts are still receiving the correct information; their network stacks will just drop everything which doesn't match their IP address.
All of this also applies to a WLAN. If DHCP is running on the target network, it will not lease you a new IP as it would think that you already had one, so you should set it up manually.
Summary
-------
Duplicate MAC addresses, no problem.
Duplicate IP addresses, problems such as dropped packets, arp floods, etc.
Duplicate MAC addresses, Different IPs, no problem.
Phew, I hope we can now close this subject.
All of this can be tested by setting the same MAC on two cards, putting them both into _non_-promiscuous mode and loading tcpdump or your sniffer of choice. Then simply spoof a few layer 2 and layer 3 packets to the relevant hosts. Netwag is my choice of tool for this.
-----Messaggio originale-----
Da: Lubos Kolouch [mailto:lubos.kolouch@gmail.com] 
Inviato: lunedì 21 agosto 2006 10.23
A: pen-test@securityfocus.com
Oggetto: Re: MAC address spoofing - conflict?
Yes, but what will happen then? Data will be sent to that MAC address.
If it is switched network, I can imagine the switch will maybe send it
to the correct port from which the response came?
If there is a hub though, the packet will be delivered to which network
card?
Lubos Kolouch
Cedric Blancher píše v Čt 17. 08. 2006 v 08:56 +0200:
> Le mercredi 16 août 2006 à 10:26 +0200, Lubos Kolouch a écrit :
> > I think it does matter. Because there will be more than host replying to
> > ARP broadcasts and the question is what will happen.
> 
> Nope it does not matter, because you won't have multiple answers...
> 
> ARP asks for an _IP_ address, not a MAC one. Therefore, if MAC addresses
> are identical, but IP addresses are different, an ARP request for one
> given IP address will get one answer only. In the end, you will end up
> with two entries in ARP cache with the same MAC address, but there's not
> problem out there.
> 
> And if, in case of some wierd and unexplained behaviour (aka awful bug),
> both hosts were replying, they would reply with the same MAC address to
> the same request, so you would not have problem either.
> 
> Le jeudi 17 août 2006 à 01:03 +0000, penetrationtestmail@gmail.com a
> écrit : 
> > And if anyone knows the exact answer, that would be most helpful ;)
> 
> The exact answer is: you can seamless spoof MAC addresses on WLAN as
> long as you use a different IP address than spoofed host, so you don't
> have TCP RST problems and stuff like this. Tested in lab and real life
> for pentests.
> 
> It's a classical technic (among others[1]) for bypassing some cheap, but
> still widespread, WLAN captive portal that only track authenticated
> clients with their MAC address.
> 
> 
> [1] http://sid.rstack.org/pres/0602_ESW_CaptiveBypass.pdf
> 
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php
------------------------------------------------------------------------
-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.3/423 - Release Date: 18/08/2006
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php
------------------------------------------------------------------------
_____________________________________________________________
EVILBASTARDS.COM, the definitive free email service.


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:48 EDT