From: Dario Ciccarone (dciccaro) (dciccaro@cisco.com)
Date: Sun Dec 04 2005 - 16:43:36 EST
> -----Original Message-----
> From: kuisma [mailto:kuisma@ping.se]
> Sent: Sunday, December 04, 2005 1:25 PM
> To: Roni Bachar; pen-test@securityfocus.com
> Subject: Re: Ping a mac address
>
> Tricky;
>
> a) The MAC address may no have an IP address at all
> b) The MAC address may send IP frames for many IP addresses (a router
> for example)
I prefer to rephrase this as 'could you see L2 frames from the same
source MAC address, and belonging to different L3 networks'. But those
address do not belong to the device (router) itself - so it would not
reply to an ARP request for those addresses with its MAC addres - UNLESS
it has something akin to 'proxy-arp' configured.
Also: firewalls do a lot of proxy ARP - and are not routers. L2 load
balancers could also reply to an ARP request with its MAC address.
Routers in HSRP/GLBP/VRRP groups. Some examples only :)
>
> You can do a few tricks;
>
> 1) Broadcast Reverse ARP for that MAC address, but it's likely not to
> give any response at all.
Let's try to be a little more thorough in our examples here. Are you
talking about mixing a RARP reply, using as destination a broadcast MAC
address, or issuing an ARP reply, using a broadcast MAC address?
The trick of issuing an ARP request (or an ARP reply, send as
broadcast/unicast to the device in question MAC address) *could* work -
if the device has any measures in place to 'defend' his MAC address
agains spoofing attacks/misconfig. Say the device MAC address is A, IP
address is 1. Sending a broadcast/unicast (with destination MAC A) ARP
request might work - device would see his own IP, but being 'advertised'
by other device - and *could* send an ARP reply of its own. Similar idea
applies to sending an ARP reply - again, device *might* try to defend
his MAC address.
>
> 2) Send that MAC address a packet with YOUR OWN IP as target,
> and see if
> you get it back in return. You then know that the MAC address
> exists, it
> can speak IP and have IP forwarding capabilities.
How is this supposed to work? The device in question would probably pick
the packet from the wire (as the L2 address match), but drop it at L3
(address not belonging to him). It's nonetheless interesting - I shoul
check RFC-1812 to see how a router is supposed to process this packet.
Might send back an ICMP redirect to the host sending the packet, dunno.
Will see if I can try it on the lab ;)
>
> 3) Send that MAC address an ICMP Echo on IP broadcast
> address(es). You
> MAY get a reply, and the reply may give away the primary (or
> closest) IP
> address, or it may return the broadcast address as source.
> But remember,
> an ICMP Echo Request destined to an IP broadcast or IP
> multicast address
> MAY be silently discarded according to rfc792.
Depends on the host IP stack implementation. Most devices today should
drop L2/L3 broadcasts they shouldn't process (ie: ICMP requests - should
process DHCP, if a DHCP server). But in that case, source IP would be
0.0.0.0, and proto = UDP. And no 'primary' or 'closest' - the host has
to reply with the IP address belonging to the same network as the source
IP on the received packet - or ignore it if he doesn't have an assigned
IP address on that network.
>
> Good luck,
> -- Mikael Kuisma, Ping Research
>
>
> Roni Bachar wrote:
>
> >Hi again
> >
> >I guess I didn't explain my self good.
> >What I want is tool that i can do:
> >Ping 00:0F:EA:8C:FC:5A
> >
> >
> >And in return get the ip of this mac
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >-------------------------------------------------------------
> -----------------
> >Audit your website security with Acunetix Web Vulnerability Scanner:
> >
> >Hackers are concentrating their efforts on attacking
> applications on your
> >website. Up to 75% of cyber attacks are launched on shopping
> carts, forms,
> >login pages, dynamic content etc. Firewalls, SSL and
> locked-down servers are
> >futile against web application hacking. Check your website
> for vulnerabilities
> >to SQL injection, Cross site scripting and other web attacks
> before hackers do!
> >Download Trial at:
> >
> >http://www.securityfocus.com/sponsor/pen-test_050831
> >-------------------------------------------------------------
> ------------------
> >
> >
> >
> >
> >
>
>
------------------------------------------------------------------------------
Audit your website security with Acunetix Web Vulnerability Scanner:
Hackers are concentrating their efforts on attacking applications on your
website. Up to 75% of cyber attacks are launched on shopping carts, forms,
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are
futile against web application hacking. Check your website for vulnerabilities
to SQL injection, Cross site scripting and other web attacks before hackers do!
Download Trial at:
http://www.securityfocus.com/sponsor/pen-test_050831
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:14 EDT