Unix administration - MAC Address spoofing on Unix

Author

MAC Address spoofing on Unix

SMAC

2006-06-14, 1:28 am

After you change MAC Address in Unix via
"ifconfig eth[x] hw ether 00:40:8C:6E:11:FF"

I heard that there will be an indicator bit in the network packet which
allows the receiver of the packet to know that they got a spoofed MAC
Address.

However, can someone confirm this and tell me which bit is changed?

Thank you,
/la

Creator of SMAC - MAC Address Spoofer for Windows 2000, XP, 2003
http://www.klcconsulting.net

Moe Trin

2006-06-14, 7:22 pm

On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
<qYNjg.907$YZ3.666@fe07.lga>, SMAC wrote:

>After you change MAC Address in Unix via
>"ifconfig eth[x] hw ether 00:40:8C:6E:11:FF"

That is Linux, not UNIX. Did you bother to try that, and if so, sniff
the wire to see what the packet looks like?

>I heard that there will be an indicator bit in the network packet which
>allows the receiver of the packet to know that they got a spoofed MAC
>Address.

Did you review the IEEE documents?

>However, can someone confirm this and tell me which bit is changed?

Is your access to google blocked? A search term is "Locally administered
address". Did you think to try news://comp.dcom.lans.ethernet ?

>Creator of SMAC - MAC Address Spoofer for Windows 2000, XP, 2003

Color me really NOT impressed. "Look at me, supplier to the stars", and
you don't know WTF is in a fourteen _byte_ header with just three lousy
parameters???

Old guy

Barry Margolin

2006-06-15, 1:28 am

In article <slrne919mo.179.ibuprofin@compton.phx.az.us>,
ibuprofin@painkiller.example.tld (Moe Trin) wrote:

> On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
> <qYNjg.907$YZ3.666@fe07.lga>, SMAC wrote:
>
>
> That is Linux, not UNIX. Did you bother to try that, and if so, sniff
> the wire to see what the packet looks like?

I recall being able to do something like that on Solaris years ago. The
syntax might not have been precisely the same, but it was similar. And
I just checked my Mac OS X man page, and it also has a similar syntax.

>
>
> Did you review the IEEE documents?
>
>
> Is your access to google blocked? A search term is "Locally administered
> address". Did you think to try news://comp.dcom.lans.ethernet ?

But since he's selecting the address, nothing forces him to use one with
the Locally Administered bit set?

Which is basically the answer to his question. There's a bit in the
address that indicates whether it's one that IEEE assigns uniquely
versus one that may be assigned locally (analogous to RFC 1918 IP
addresses). If you assign an address manually you're *supposed* to use
one of the latter type, to avoid potential conflicts with devices that
use IEEE-assigned address blocks. But there's nothing that forces this,
so there's no foolproof way to detect use of a spoofed address.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Dave Hinz

2006-06-15, 1:28 am

On Wed, 14 Jun 2006 19:16:34 -0500, Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
><qYNjg.907$YZ3.666@fe07.lga>, SMAC wrote:
>
>
> That is Linux, not UNIX. Did you bother to try that, and if so, sniff
> the wire to see what the packet looks like?

You seem quite don-like today. Rough day at work or something?

Rafael Almeida

2006-06-15, 1:28 am

On Wed, 14 Jun 2006 19:16:34 -0500
ibuprofin@painkiller.example.tld (Moe Trin) wrote:

> On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
> <qYNjg.907$YZ3.666@fe07.lga>, SMAC wrote:
>
>
> That is Linux, not UNIX.
And here comes the old linux is not unix talk again...

Moe Trin

2006-06-15, 1:28 am

On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
<barmar-8C1945.21155514062006@comcast.dca.giganews.com>, Barry Margolin wrote:
>ibuprofin@painkiller.example.tld (Moe Trin) wrote:

[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
>I recall being able to do something like that on Solaris years ago. The
>syntax might not have been precisely the same, but it was similar. And
>I just checked my Mac OS X man page, and it also has a similar syntax.

Correct Barry - and was it the eth[x], or le0, or hme0, or...

>But since he's selecting the address, nothing forces him to use one with
>the Locally Administered bit set?

And in fact, I haven't seen one do so. I believe the original intent of
the Local/Global bit was that it was to be set if the address was changed
and this "supposedly" prevented spoofing Global Administered Addresses.
However this basically defeats the main purpose of the ability to change.

Old guy

Moe Trin

2006-06-15, 1:28 am

On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
<20060614230142.3b645a51.rafaelc@dcc.ufmg.br>, Rafael Almeida wrote:

[vbcol=seagreen]
>And here comes the old linux is not unix talk again...

Sorry to disappoint you dude - but I'm not Don Kool, and I support Linux,
FreeBSD and Solaris boxes. Or, don't you know the difference between
those? It's almost as bad as the difference between BSD and SystemV, so
the subtleties should be obvious.

Old guy

Robert Melson

2006-06-15, 1:28 am

In article <4fbruoF1i2hpdU1@individual.net>,
Dave Hinz <DaveHinz@spamcop.net> writes:
> On Wed, 14 Jun 2006 19:16:34 -0500, Moe Trin <ibuprofin@painkiller.example.tld> wrote:
>
> You seem quite don-like today. Rough day at work or something?

Dave,

Wash your mouth out with soap, NOW! Do NOT utter the name that shall not
be spoken lest it's bearer suddenly reappear.

Superstitious Ol' Bob

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
Under democracy one party always devotes its chief energies to trying to
prove that the other party is unfit to rule---and both commonly succeed,
and are right." ---H. L. Mencken

Dave Hinz

2006-06-15, 7:26 am

On Thu, 15 Jun 2006 03:49:01 GMT, Robert Melson <melsonr@aragorn.rgmhome.net> wrote:
> In article <4fbruoF1i2hpdU1@individual.net>,
> Dave Hinz <DaveHinz@spamcop.net> writes:

[vbcol=seagreen]
> Wash your mouth out with soap, NOW!

I washed it a bit with a nice single-malt Scotch, which is as much
washing as I'll do in this case.

> Do NOT utter the name that shall not
> be spoken lest it's bearer suddenly reappear.

From what I've been told, it is not in a situation which allows
grepping.

Barry Margolin

2006-06-15, 1:25 pm

In article <slrne91k8f.1ju.ibuprofin@compton.phx.az.us>,
ibuprofin@painkiller.example.tld (Moe Trin) wrote:

> On Wed, 14 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
> <barmar-8C1945.21155514062006@comcast.dca.giganews.com>, Barry Margolin wrote:
>
>
>
>
>
> Correct Barry - and was it the eth[x], or le0, or hme0, or...
>
>
> And in fact, I haven't seen one do so. I believe the original intent of
> the Local/Global bit was that it was to be set if the address was changed
> and this "supposedly" prevented spoofing Global Administered Addresses.
> However this basically defeats the main purpose of the ability to change.

I suppose some manufacturers could design the NICs so that they won't
allow you to set the address to a Global address, or automatically turn
on the Local bit whenever the address is set. But one of the original
reasons for allowing settable MAC addresses was to support protocols
like DECnet, where the MAC address is derived from the Layer 3 address;
are DECnet addresses local or global?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Moe Trin

2006-06-15, 7:25 pm

On Thu, 15 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
<barmar-E9AE49.08501815062006@comcast.dca.giganews.com>, Barry Margolin wrote:

>I suppose some manufacturers could design the NICs so that they won't
>allow you to set the address to a Global address, or automatically turn
>on the Local bit whenever the address is set.

I've seen plenty of cards - generally cheap trash based on the NE2000,
that won't accept setting the address. I rarely use the capability,
but I don't ever recall seeing a card turn on the bit itself. Those
that did allow setting the address set it to whatever you told them.

>But one of the original reasons for allowing settable MAC addresses was
>to support protocols like DECnet, where the MAC address is derived from
>the Layer 3 address; are DECnet addresses local or global?

I haven't seen DECnet in decades, but I think that was before this idea
got widely accepted. It certainly wasn't part of the DIX specifications.
Even the V2.0 specs from 1982 only show the multicast bit. Anyway, there
have been OUI assignments that have those bits set.

[compton ~]$ zgrep '^[0-F][0-F]-' MACaddresses.gz | cut -d'-' -f1 | sort
| uniq -c | column
9145 00 2 04 3 10 1 80 5 AA
13 02 145 08 1 11 1 A0 1 AC
[compton ~]$ zgrep -E '^(02|11|AA)-' MACaddresses.gz
02-07-01 (hex) RACAL-DATACOM
02-1C-7C (hex) PERQ SYSTEMS CORPORATION
02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD.
02-60-8C (hex) 3COM CORPORATION
02-70-01 (hex) RACAL-DATACOM
02-70-B0 (hex) M/A-COM INC. COMPANIES
02-70-B3 (hex) DATA RECALL LTD
02-9D-8E (hex) CARDIAC RECORDERS INC.
02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01 (hex) OCTOTHORPE CORP.
02-C0-8C (hex) 3COM CORPORATION
02-CF-1C (hex) COMMUNICATION MACHINERY CORP.
02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION
11-00-AA (hex) PRIVATE
AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-01 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-02 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION
AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION
[compton ~]$

That's a OUI file from late last week. I've had plenty of 02:60:8C
addresses on our wires - they were usually 3C509s, or something for an
old Mac (which I never had to physically touch).

Old guy

ted@loft.tnolan.com (Ted Nolan

2006-06-16, 1:29 am

In article <slrne93u8k.jcc.ibuprofin@compton.phx.az.us>,
Moe Trin <ibuprofin@painkiller.example.tld> wrote:
>
>
>On Thu, 15 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
><barmar-E9AE49.08501815062006@comcast.dca.giganews.com>, Barry Margolin wrote:
>
>
>I've seen plenty of cards - generally cheap trash based on the NE2000,
>that won't accept setting the address. I rarely use the capability,
>but I don't ever recall seeing a card turn on the bit itself. Those
>that did allow setting the address set it to whatever you told them.
>
>
>I haven't seen DECnet in decades, but I think that was before this idea
>got widely accepted. It certainly wasn't part of the DIX specifications.
>Even the V2.0 specs from 1982 only show the multicast bit. Anyway, there
>have been OUI assignments that have those bits set.
>

Sun used to (may still) use this feature to set the MAC address of a
Sun box to 8:0:20..... no matter what ethernet card you had in there.
(In fact, I think even if you had multiple ethernet cards, each one would
report the same 8:0:20... MAC addr, so you had to make darn sure they were
on different subnets.).

The SunOS ifconfig did let you set it to whatever you wanted though. Made
it easy to swap in a Sun box for a cable company router.

Ted

Ted

Rick Jones

2006-06-16, 1:32 pm

In comp.unix.questions Ted Nolan <tednolan> <ted@loft.tnolan.com> wrote:

> Sun used to (may still) use this feature to set the MAC address of a
> Sun box to 8:0:20..... no matter what ethernet card you had in
> there. (In fact, I think even if you had multiple ethernet cards,
> each one would report the same 8:0:20... MAC addr, so you had to
> make darn sure they were on different subnets.).

Indeed, they took the position that the MAC address was a property of
the host rather than the card - ie that an ethernet "station" was the
host.

Strictly speaking I suspect it meant the different NICs needed to be
in different broadcast domains - to say subnet suggests they would
have to be in different IP subnets and I am not certain that was the
case.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...

feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Casper H.S. Dik

2006-06-16, 1:32 pm

Rick Jones <rick.jones2@hp.com> writes:

>Indeed, they took the position that the MAC address was a property of
>the host rather than the card - ie that an ethernet "station" was the
>host.

Didn't DECnet also force that assumption? (DECnet changed the MAC address
on all interfaces)

>Strictly speaking I suspect it meant the different NICs needed to be
>in different broadcast domains - to say subnet suggests they would
>have to be in different IP subnets and I am not certain that was the
>case.

DIfferent broadcast domain; non of Sun's x86 offerings have "per-host"
MACs and all Sun's current NICs have their own onboard MAC address
thoguh it's not always the default to use (a small setting in OBP and
some driver dependencies)

Note that non of Sun's earlier NICs actually had their own MAC address;
only the system had one.

Casper

Doug Freyburger

2006-06-16, 7:20 pm

Rick Jones wrote:
> In comp.unix.questions Ted Nolan wrote:
>
>
> Indeed, they took the position that the MAC address was a property of
> the host rather than the card - ie that an ethernet "station" was the
> host.
>
> Strictly speaking I suspect it meant the different NICs needed to be
> in different broadcast domains - to say subnet suggests they would
> have to be in different IP subnets and I am not certain that was the
> case.

Note that back when Sun started doing this there were no switches
that did VLANs. There weren't even switches. There were hubs and
there were 2-port bridges. Some of the bridges mapped MAC
addresses some didn't. So at the time a broadcast domain was a
subnet.

At the time it made sense to put the short name in /etc/ethers
so a host could be known by its MAC address. Long since
absolete so it's no longer done that way.

Lots of cards support setting MAC address; lots don't.

Once I encounted a duplicate MAC address on a LAN without any
cards that supported it. Sure enough someone in the building had
the ultraviolet set-up to change PROMs. He was experimenting
with drivers on cards with an embedded workstation ...

Casper H.S. Dik

2006-06-16, 7:20 pm

"Doug Freyburger" <dfreybur@yahoo.com> writes:

>Lots of cards support setting MAC address; lots don't.

I've never seen one which didn't; certainly because some protocols
required it early on.

>Once I encounted a duplicate MAC address on a LAN without any
>cards that supported it. Sure enough someone in the building had
>the ultraviolet set-up to change PROMs. He was experimenting
>with drivers on cards with an embedded workstation ...

Interesting.

Well, we once had a batch of 3com PCMCIA cards with the MAC addresses
all ending in :22:44:66 and the same prefix. Someone had forgotten
to program them (they did have an individual MAC marked on them)

Casper

ted@loft.tnolan.com (Ted Nolan

2006-06-16, 7:20 pm

In article <1150485511.402809.311120@h76g2000cwa.googlegroups.com>,
Doug Freyburger <dfreybur@yahoo.com> wrote:
>
>
>Rick Jones wrote:
>
>Note that back when Sun started doing this there were no switches
>that did VLANs. There weren't even switches. There were hubs and
>there were 2-port bridges. Some of the bridges mapped MAC
>addresses some didn't. So at the time a broadcast domain was a
>subnet.
>

There weren't even hubs at the time. The first Suns I encountered were
Sun1 & Sun2 boxes with 68010s, and the cabling was a thick yellow backbone,
which you had to _cut_ for each new station (unless you had a "vampire"
tranceiver). Although all the ethernet cards were set to the 8:0:20
addr of whatever box you plugged the multibus card into, some were definitely
better than others. The ones that identified as "ie" on boot were
significantly faster iirc.

Ted

Rick Jones

2006-06-16, 7:20 pm

In comp.unix.questions Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> Rick Jones <rick.jones2@hp.com> writes:

[vbcol=seagreen]
> Didn't DECnet also force that assumption? (DECnet changed the MAC
> address on all interfaces)

I know that DECnet would override the MAC on the NIC, but I am not
sure if it would put the same MAC on all NICs in the host.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...

feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Barry Margolin

2006-06-17, 1:29 pm

In article <1150485511.402809.311120@h76g2000cwa.googlegroups.com>,
"Doug Freyburger" <dfreybur@yahoo.com> wrote:

> Once I encounted a duplicate MAC address on a LAN without any
> cards that supported it. Sure enough someone in the building had
> the ultraviolet set-up to change PROMs. He was experimenting
> with drivers on cards with an embedded workstation ...

I once encountered it because the vendor (does anyone remember Symbolics
Lisp Machines?) inadvertently assigned the same addresses to different
cards. They derived the MAC address from the serial number of the I/O
board, but didn't take the model number into account, so ended up with
duplication across different models, and we ended up with a conflicting
pair in our shop. We worked around it by manually configuring the MAC
address on one of the machines.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Moe Trin

2006-06-18, 1:25 am

On 16 Jun 2006, in the Usenet newsgroup comp.unix.admin, in article
<1150485511.402809.311120@h76g2000cwa.googlegroups.com>, Doug Freyburger wrote:

>Once I encounted a duplicate MAC address on a LAN without any
>cards that supported it. Sure enough someone in the building had
>the ultraviolet set-up to change PROMs. He was experimenting
>with drivers on cards with an embedded workstation ...

That has happened more than people like to admit. We had a development
engineer working on single-board systems, and he was going nuts trying
to figure out why networking was so terribly broken. Usual answer - he
had burnt new EPROMs and forgotten to change the MAC address. Each time
he'd burn a new one, he missed the same step, and was tearing his hair
out trying to find his coding error. The logic analyzer wasn't giving
any clue but three of the five systems on the (thankfully isolated)
subnet had the same address, and his code didn't handle the situation
gracefully. He couldn't go back to the "working" PROMs, because he'd
already erased them. He had backed out his change in the code, but it
was still barfing. Someone else who had a sniffer on the wire finally
noticed that the source and destination MAC addresses in a packet were
the same - maybe two or three days after the problems started.

Old guy

Timothy J. Bogart

2006-06-23, 1:22 pm

Barry Margolin wrote:
<snip>
> I once encountered it because the vendor (does anyone remember Symbolics
> Lisp Machines?) inadvertently assigned the same addresses to different
> cards. They derived the MAC address from the serial number of the I/O
> board, but didn't take the model number into account, so ended up with
> duplication across different models, and we ended up with a conflicting
> pair in our shop. We worked around it by manually configuring the MAC
> address on one of the machines.
>

Eeek! I was girding my loins on my first VMS box (with Ada!) and the
contractors I has assigned to me were dealing with Symbolics. We used
to have contests - we would swap visits and see if we could get each
other's machines to lock up - and on good days we could do it with just
walking in the door, no touching of machines!

Yup. and when I installed tcp/ip on my Mac and ftped a file to the
VAXstation, the guys in charge of monitoring the network called me and
asked what I was doing. You see, their goal was to keep utilization
under 10% to avoid problems.

....Which sort of explains how I got into admin. As a manager/user, I
would run into such things, and sorta kinda scream at the top of my
lungs why these folks were, well, not quite up to evolutionary standards
- and others would hear this, and start coming to me with questions.

Ah, to be young and naive! (As opposed to the current situation of old,
feeble and naive of course)