Bonjour Sleep Proxy service stealing IP addresses?

Here's an example of one of the incidents.

(IP addresses, MAC addresses, and computer names have been anonymized.)

The "thief" is a Mac OS X 10.6 workstation.
The "thief" has Ethernet hardware address 00:11:11:11:11:11 and Wireless hardware address 00:22:22:22:22:22.
On September 10 it was connected via its wireless interface to our wireless network.
The wireless access point via which it connected operates as a bridge.
The thief's wireless interface used DHCP to obtain a lease on IP address 192.168.2.1.

The "victim" is a Mac worktation, operating system version unknown.
The "victim" has Ethernet hardware address 00:01:02:03:04:05 and Wireless hardware address 00:01:02:03:04:06.
On September 10 it was connected via its wireless interface to our wireless network.
The wireless access point via which it connected operates as a bridge.
It was not the same wireless access point used by the thief.
The thief's wireless interface used DHCP to obtain a lease on IP address 192.168.5.1.

Both the thief and victim's wireless interfaces were on the same IP network.

Although the thief used its assigned IP address 192.168.2.1,
during approximately 1820-1910 September 10, it also stole
IP address 192.168.5.1. (Times are approximate to within ten minutes.)

We were aware of the incident because every ten minutes we take a snapshot of the IP ARP cache from
the IP router. After the day is over, we compare that to that day's log from the DHCP servers.
This showed is that the thief was using an IP address that had not been assigned to it by the DHCP servers.

Our logs show that the thief had not previously been assigned (e.g. via DHCP)
the IP address it stole.

I note that the thief's system.log file
makes a number of references to stolen IP address 192.168.5.1;
whatever the thief thought he was doing with that IP address, he certainly knew about it:

Sep 10 14:52:15 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:17 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:17 jdoes-MacBook-Pro mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:18 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:19 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:19 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:20 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:22 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:23 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:27 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:31 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:35 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:48 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:51 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:53:20 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:53:23 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:54:24 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:54:27 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 15:08:04 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 15:08:07 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 15:08:08 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 18:11:21 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 18:11:23 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 18:32:40 dynamic-oit-vapornet-e-1 mDNSResponder[29]: Waking host at en1 192.168.5.1 H-MAC 00:01:02:03:04:05 I-MAC 00:01:02:03:04:06 for 21 mycomputer. ssh.tcp.local. SRV 0 0 22 mycomputer.local.
Sep 10 19:49:57 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:49:58 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:49:59 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:01 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:01 jdoes-MacBook-Pro mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:02 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:05 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:08 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:13 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:16 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:30 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:33 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:51:02 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:51:05 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:51:46 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:52:09 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.


I note that among the messages above is even one (at Sep 10 18:32:40) that specifically cites the Ethernet and Wireless hardware
addresses of the victim:

Sep 10 18:32:40 dynamic-oit-vapornet-e-1 mDNSResponder[29]: Waking host at en1 192.168.5.1 H-MAC 00:01:02:03:04:05 I-MAC 00:01:02:03:04:06 for 21 mycomputer. ssh.tcp.local. SRV 0 0 22 mycomputer.local.

The "Waking host" text is what first led me to the Bonjour Sleep Proxy service for these incidents.
Data from other incidents also point to the Bonjour Sleep Proxy service.

I understand that a Bonjour Sleep Proxy Server might respond to mDNS queries about the services for which it's been told to proxy.

But I'm surprised that it would be designed so that the server actually used the assigned IP address of the sleeping device as the IP source address of an mDNS response sent by the server, and that the server would send IP ARP Response packets claiming that the owner of the sleeping device's IP address is the Bonjour Sleep Proxy Server's hardware address. I would imagine instead that if the server sends an mDNS response, it would come from the IP address of the Bonjour Sleep Proxy Server, but contain the IP address of the sleeping device inside the payload of the mDNS response. Of course, without documentation of the protocol used by Bonjour Sleep Proxy service, this is speculation.

Where is the protocol used by Bonjour Sleep Proxy documented?
I understand it makes use of mDNS, but I do not see it documented.

The closest I've found is Section 17 of
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
("Multicast DNS"). It provides some information, but it doesn't
say that the Sleep Proxy Server sends IP packets using the IP source
address of the sleeping client, or that the Sleep Proxy Server sends ARP Response
packets claiming that the owner of the sleeping client's IP address
is the Sleep Proxy Server's hardware address.

It says that the full specification of mDNS / DNS-SD Sleep Proxy Service
is to be described in a future document. But I've not been
able to find that published yet.

LittleSaint wrote:
If it didn't use the actual IPs with corresponding ARPs, how else would traffic get to the proxy? Sticking the source address in the payload doesn't work because the original sender is expecting a reply from a real host not a proxy.

Why wouldn't the mDNS response have an IP source address of the Sleep Proxy Server,
but with payload that says that the service you are looking for
is provided by ...(the IP address of the sleeping client)?

I still don't see that mDNS of necessity works this way;
it seems to me that IP source address of an mDNS response packet
is not required to be the same as the IP address that appears inside any A-records
or AAAA-records in the payload. I can imagine an mDNS response packet
sent by a device that is proxying (in the general sense) for another might
have an IP source address of the sender, but contain A-records or AAAA-records
that specify the IP address of another device.

But I do see that the September 10 2009 edition of
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
(draft-cheshire-dnsext-multicastdns-08.txt)
provides additional information about the Sleep Proxy Service in section 17,
compared to the earlier September 10 2008 edition (draft-cheshire-dnsext-multicastdns-07.txt) I had previously seen.

The new edition does indeed make it clear that the intent of that specification is
that the Sleep Proxy Server actually takes ownership of the
sleeping device's IP address(es). That is, the Sleep Proxy Server
will indeed send packets with an IP source address that belongs
to the sleeping client. While it doesn't explicitly say that the mDNS response packets
sent by the Sleep Proxy Server have an IP source address of the sleeping device,
it does describe other packets that the Sleep Proxy Server sends as coming
from the IP source address of the sleeping device. And because it states
that packets destined to the sleeping device's IP address are delivered
to the Sleep Proxy Server, it does indeed imply that the Sleep Proxy Server
will also send ARP Response packets claiming that sleeping device's IP address belongs to the
hardware address of the Sleep Proxy Server.

So the behavior I am seeing from Bonjour Sleep Proxy Servers on our network
(that they are using IP addresses not assigned to them)
is not an implementation bug, but is their intended behavior.

The issues I am left with are:



• If the IP address was assigned to sleeping client via DHCP,
is it really appropriate the sleeping client to temporarily "transfer"
this IP address to another device? Put another way, should a DHCP lease
be transferrable?

I've always viewed a DHCP lease as something a DHCP server awards to
a DHCP client. The DHCP client doesn't get to transfer that lease to
another device.

I'm not sure how well this idea (that the DHCP client can transfer its
IP address to some other device) fits into the DHCP world.



• Wouldn't it be easy to leverage this Sleep Proxy Server behavior (from an attacker
on the same IP subnet as the Sleep Proxy Server) to force it to perform
the Denial of Service I described above?



• I've seen a Mac OS X 10.6 workstation "steal" an IP address
in the way that a Sleep Proxy Server would. (The incident description
I posted above, with the incriminating system.log file.) But Apple's doc
doesn't say that Mac OS X 10.6 acts as a Sleep Proxy Server.



• Shouldn't the Sleep Proxy Server implemenation (e.g. in the Apple Time Capsule,
AirPort Base Station, and anywhere else it's present) have an "on/off" switch?
It seems to me that if I own the device, I should be able to turn on and off
the various (optional) services that the device offers to the network.

Just as my Mac has an on/off switch for whether or not it acts as a file server
to the network, I would think that if my device is capable of acting as a
Sleep Proxy Server for the network, I should be able to turn that on or off.

And I also think that the feature's on/off switch should
by default be turned off; my device shouldn't start offering
a service to the network without my explicitly telling it to do so.
(Except perhaps if my device were some sort of dedicated Sleep Proxy Server;
if that's the only thing my device is intended to do, then presumably I want
that behavior turned on by default.)

Time Capsules and AirPort Base Stations are also purchased by students, faculty, and staff. And they attach them to an institution's network. (Why shouldn't a student want to attach a Time Capsule to the network, to function as a networked storage device for her personal use?) It seems reasonable to me that the owner of the device shouldn't be forced to also have the device operate as a Sleep Proxy Server.


I didn't say "alarm: an attack is possible!". I asked (given what information is currently published about how the Sleep Proxy Server works) whether it would be easy to leverage it to construct an attack. It's the sort of thing anyone who maintains a large network with lots of these devices attached is likely to ponder.

While our institution discourages our customers from attaching devices operating as wireless access points to the campus network, and indeed forbid it in certain buildings, there are many buildings where it is permitted, although not encouraged. Our university, like many others, does not enforce network use policies as strict as might be found in a corporate network.

But that's besides the point. WAP-related concerns, for example, would not apply to a Time Capsule that is configured to not operate as a Wireless Access Point. And the Time Capsule is among those devices that operates as a Bonjour Sleep Proxy.

I've begun looking at the mDNS responder source at http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-212.1/mDNSMac OSX/
I see that it includes a Sleep Proxy Server implementation. Perhaps Mac OS X 10.6 does indeed act as a Sleep Proxy Server under some circumstances, regardless of what http://support.apple.com/kb/HT3774 says.

The proxy server should not be running from workstations. That would be my only concern if you are truly seeing such behavior.

I've glanced at the mDNSResponder code at http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-212.1/
It contains support for acting as a Sleep Proxy Server; it can do so under some circumstances.
It's not apparent to me if that support is included in the version of the daemon
distributed in Mac OS X 10.6, and if so, whether Mac OS X 10.6. runs the daemon
in such a way as to tell it that it may offer a Sleep Proxy Server.

However, my experience is that some Mac OS X 10.6 systems here are indeed
acting as Sleep Proxy Servers.

Is it possible those syslog messages are mDNS messages from the access point and not internal to the workstation?

It doesn't appear that the syslog messages are coming from another device on the network.
It appears to me that they are being generated locally by the workstation.

Are you sure it is the MAC address of the workstation that you see with multiple IP addresses in your ARP snapshots?

Yes, no question.


I've now had a number of additional incidents; it's clear to me that (whether this is
something Apple intended or not) Mac OS X 10.6 workstations (at least under some circumstances)
will act as Sleep Proxy Servers.

If the proxy assumes IP addresses of sleeping workstations for mDNS, it doesn't really affect regular communication because those workstations > wouldn't reply to anything but a wake packet anyway, and the proxy will facilitate that. Turning off Wake-On-Network mitigates this entirely > as that also disables any registration with the proxy service.

To my way of thinking, mitigating the behavior of Sleep Proxy Servers by requiring
every user of Mac OS X (and in the future, any other platforms that include a Sleep Proxy client implementation)
to turn off "Wake on Network" is not practical. It makes more sense to me to mitigate this at
the devices acting as Sleep Proxy Servers.

Proper use of DHCP snooping and ARP inspection on your routers mitigates things from an enterprise perspective.

In what way?

I agree that the use of DHCP Snooping and Dynamic ARP inspection of that
sort might be used to stop a Sleep Proxy Server from taking over
the IP address of a client.

It's not an approach we can use here, both because many of our clients are
attached via switch ports that don't support this, we permit clients
(on most networks) to use manual configuration instead of DHCP, but indeed this
approach might be a possibility in other environments. Thank you for
pointing this out.