yikes! MAC address changed ??

[James Smallacombe]

On Thu, 11 Feb 2010, Matthew Seaman wrote:

> On 11/02/2010 11:00, James Smallacombe wrote:
>> Sorry for replying to myself (AND top-posting!) twice in a row, but this
>> is become a huge concern.  My first thought is that my provider changed
>> routers or router Ethernet ports, hence the MAC address change.  They
>> deny this, plus I find the two MAC addresses:
>>
>> 00:17:e0:4f:b9:c0 to 00:13:e0:4f:b9:c0
>>
>> too close to each other for comfort.  My obvious concern here is that
>> the recent php compromises somehow allowed an attacker to alter the ARP
>> table entry of the default gateway.  Specific questions are as follows:
>
> They're not just close: it's a single bit change between the two MACs
>
>> 1) If this were done via a perl or php script, presumably executing
>>    an 'arp -s' command, would it show up in the log like that?  I've
>>    never changed an ARP entry (except to delete it using 'arp -d'), so
>>    I've only seen log entries like that due to external changes, like
>>    somebody changing IPs on the LAN from one Ether to another.
>
> You'ld need root level access to change something like that, no matter
> if it was from the shell or via some scripting language.  If an attacker
> has the capability to do that to you, then it's *game* *over* -- wipe
> the box and start again.  Of course, that's a pretty bizarre thing for
> an attacker to do.  It draws attention to itself by disrupting your
> network communications and there isn't any obvious advantage to be
> gained by doing that.  [There might be if the MAC was changed to
> collide with another one on the same network segment but I believe that
> is not the case here.]

I figure root at some point is needed, but wondered if there was another 
POA I had to worry about.  In effect, I already "wiped out" this server a 
few days ago...new drives with new / FS from 7.2-RELEASE.  However, I did 
copy over /usr/local and /home file systems from the old server's drive, 
and parts of /var.  Everything in / (including /usr) is fresh.

> It's not 'arp -s' that is used to change the MAC address on an
> interface, but ifconfig(8) -- something like this:
>
>    # ifconfig re0 ether 00:17:e0:4f:b9:c0

See my second post.  I screwed up in my first post.  It wasn't the MAC 
address of my NIC that changed, it's the MAC address of the DEFAULT 
GATEWAY that changed.  I believe that would use 'arp', not 'ifconfig', 
right?

>> 2) Could an Ethernet card defect or re0 driver problem cause anything
>>    like this?  Other bug?
>
> Yes -- this is the most likely cause.  Hardware problems.  The MAC
> address is built into the network card using an EEPROM or such like,
> and those can conceivably go bad.  Replace the NIC and see if the
> problems go away.

Ok, longer shot here...could a hardware problem on my box screw up the MAC 
address of the default gateway?  It should be noted that when I did and 
ifconfig -a during this down time, the Ether showed "no carrier".  Could 
messed up ARP tables even do that?  I would think that the carrier just 
needs a cable plugged from the NIC into a switch?

>> 3) If this was an attacker using a local script, how the hell does he
>>    get a php or perl script owned by UID 80 (or worst case, a user),
>>    to do this?
>
> You don't.  You need root access to change the MAC on a network
> interface.  Same as for changing the IP number on the interface.
> Check /etc/rc.conf -- if there aren't ifconfig commands in there
> to modify the ether or link address, and if the modified MAC survives
> a system reboot, then it's almost certainly hardware going kaput.
> Even if the MAC does recover on reboot, it still might be flakey
> hardware.

Still had no carrier after reboot.  Only after swapping the NIC.  Does a 
reboot wipe out the ARP tables?

James Smallacombe		      PlantageNet, Inc. CEO and Janitor
up at 3.am							    http://3.am
=========================================================================