Crackerjack, the voice of tech on the RedZone forums, delights his readers with this today:
We all know that linden labs has the ability to ban not just by ip address or mac address but also uses the serial of the hard drives it finds on each computer (a serial number that is impossible to spoof btw). If linden labs really want to ban you they can ban by hard drive serial and the only way to get around it is to insert all new hard drives.
I am, of course, glad that crackerjack has been reading this blog and thus now knows this, rather than repeating zFire’s cannard about Linden Labs using IP addresses for bans. Sadly he has not really followed the logic through properly.
As I explained, the SL client code packages up MAC address and volume serial number – hashed with an MD5 sum – into the XML authentication packet used to authenticate with their service. Note it is the hash that is transmitted and not the serial number or MAC address itself. Nevertheless these values are certainly used for client authentication.
But it follows to anyone with the first clue about coding, networks and security that spoofing these data is trivially easy. There are two obvious ways to do it (and countless variations and less obvious ways). The first: because the SL client code is open source, you simply role your own client that makes up a valid looking but spurious serial ID. Hash that and send it to the servers and you are away.
Even if the client were not open source, the authentication can be captured in a proxy. Instead of connecting to the SL server itself, you could connect to a local proxy that rewrites the authentication packet before passing it on to the server. Whilst the proxy brings in a small delay, once authenticated you connect to a sim and at that point you can jetison the proxy.
So yes, you can trivially easily spoof the serial number. However, Linden Lab quite specifically prohibits this. In the third party viewer policy we read under “Prohibited Functionality”:
You must not circumvent any security-related features or measures we may take to limit access to Second Life. For example:
- You must not mask IP or MAC addresses. By “mask,” we mean disguising or concealing the IP or MAC address when including it was possible.
- You must not spoof the viewer identifier or the identity of a Third-Party Viewer connecting to Second Life. Each version of a Third-Party Viewer must have a unique viewer identifier and must not use the same viewer identifier as a Linden Lab viewer or another Third-Party Viewer.
Of course the same agreement bans circumventing SL permissions system. Anyone willing to create a copybot client, or to use the parcel media bug to make illegal spyware would likely also ignore that part of the agreement too.
Even if spoofing were not so easy, changing your hard disk serial number does not require changing your hard disk. The serial number is just more data on the disk. That data can be rewritten given the right tools. It is not necessary to do so, nor particularly a good idea, but if you want to know more then Google is your friend.
I should also add that MAC addresses need not be tied to the interface hardware either. They can be spoofed in just the way I described above in the authentication packet, or you can change your interface MAC address. The MAC address is stored on the interface card itself. If it is in EPROM you can reflash it to a value you like, but that is not necessary on UNIX based machines at least. The reason is that when the device driver starts, the EPROM is read but because the access is slow, the MAC address is copied into a structure in kernel memory associated with the device. This memory can be rewritten using the ifconfig command, and the interface can then be brought up with the new MAC address.
One legitimate use for this is in IPv6 address allocation. As I mentioned, autoconfiguration of IPv6 addresses takes place based on MAC addresses. A systems administrator may choose to reconfigure MAC addresses on a link so that they number starting at 1. This has the effect of hiding hardware information that would otherwise be revealed in the IPv6 addresses. When doing this, the systems administrator is supposed to set the universal/local bit to show that these are local and not universal MAC addresses. That is why that bit in the MAC addresses is toggled when creating an EUI-64 from a MAC-48. In this way, the IP address number 1 does indeed look like a 1 (in the hostid part).
Anyway, it is a good thing crackerjack does not think he knows anything about network security.
Oh wait! He does! Look, he just wrote this:
by crackerjack » Sat Feb 19, 2011 7:02 am
[…] my particular expertise is in network security […]
/me shakes his head.