Or: How to Make your Apple quiet
Many security professionals gravitate towards grey laptops milled from a solid block of alumin(i)um. Apple computers are actually not the safest systems to plug into sensitive control networks. The biggest reason for this is part of what makes them lovely: Rendezvous (aka zeroconf networking or Bonjour).
When a stock Macintosh is connected to a network, it immediately starts issuing multicast UDP/IP packets which announce the services running on the computer. This is how, for example, a Macintosh automatically builds a list of other computers on a network, allows for iTunes library sharing, automatic filesharing discovery, etc.
Quite a few vendors use multicast addresses for fairly important functionality — for example, IEC-61850 uses multicast traffic for peer discovery and at least one vendor uses a multicast protocol for determining the live link on their redundant Ethernets. Some embedded control systems products are poorly-written enough that an Apple’s unexpected messages could cause trouble. I have yet to see something die from the multicast announcements that a Mac makes, but I really don’t want to — especially not on a client’s live network. I thought that a writeup on how to get around Apple’s cute protocol is in order. Friends don’t let friends trash live control systems, after all.
I use three primary methods of defeating Apple, depending on what test I am running and how paranoid I feel about equipment on the target network.
Method 1: Disable multicast announcements
The first is to disable Zeroconf itself. I recommend doing this in addition to the other methods listed here, because it also makes you a bit more secure when using untrusted networks and can prevent accidents when using other methods.
mDNSResponder is the OS X process responsible for zeroconf. Apple changed the way their mDNSResponder application works starting with Snow Leopard. In Snow Leopard and Lion, it is responsible for normal DNS resolution as well as zeroconf, so the service can no longer just be disabled as it could in Leopard and prior versions of OS X.
To disable multicast announcements from mDNSResponder, follow Apple’s instructions. To verify that the instructions worked, check the mDNSResponder process using ‘ps -auxw|grep mDNSResponder’ from a command-line. The process should have the “-NoMulticastAdvertisements” option passed to it. Verify that it worked (because software that you don’t write yourself never works right) with Wireshark by searching for packets destined for 188.8.131.52.
Frustratingly, this will not keep your computer from spitting out all mDNS requests. In particular, if your Mac has ever been associated with an OS X Server at any time in its existence (user authentication seems to be the issue, not Time Machine), your computer will probably issue mDNS name queries, forever searching for that OS X Server. Apple is working on a fix, but it may be a while.
Method 2: VMs to the Rescue
A second method is to use an alternate network card to share directly with a Virtual Machine. This is probably the safest thing to do, and it is my default choice for active tests unless I am working with a crummy virtual operating system. When doing this, I highly highly recommend also disabling zeroconf as described above. Why? Because if your virtual machine crashes, or the network device somehow disconnects from the guest OS, OS X will take back control of the USB Ethernet device and will begin transmitting multicast packets.
I use a nice Gigabit USB dongle from Plugable, generally connected to BackTrack 5 or another stripped Linux VM. This adapter uses an ASIX ethernet chipset and is almost identical electronically to the adapter sold by Apple. It is well-supported by Linux and Windows. The Plugable-supplied driver must be installed to use the adapter natively on a Mac — OS X will recognize it as Apple’s USB-Ethernet adapter, but the standard Apple driver does not work quite right.
I connect the USB device to the virtual machine using USB passthrough. This gives the guest OS exclusive access to it, and OS X can’t even try to put weird packets on the wire. This works wonderfully in VMWare Fusion.
Method 3: Hardware Hacks
There are other methods to achieve some of these goals, of course, all of which have their pros and cons. For completely passive scanning, you can always use a dedicated tap. For 10/100 networks, you can use an inexpensive “throwing star” LAN tap. These don’t work on gigabit-only networks, where TX and RX lines use the same physical wires. A company called DualComm makes a nice gigabit ethernet tap. You can special order models DCGS-2005LE and DCGS2005E which disable ingress traffic on the tap port (the standard model taps and switches on the tap port, so you could accidentally inject to the network). I have not yet used one, but they look nice and the Dual-Comm staff are competent computer hackers. The downside to these is that these units are almost as expensive as a managed gigabit switch, which could itself be configured with port mirroring. Of course, the Dual-Comm unit is a lot smaller for travel.
Whatever you do, do something to keep your Mac quiet. It would be ugly to be the person that discovers a vulnerability or “feature” in 61850 or a multicast failover protocol the hard way.
photo by Katie Tegtmeyer