yikes! MAC address changed ??
up at 3.am
Thu Feb 11 12:22:24 UTC 2010
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',
>> 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
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
More information about the freebsd-questions