Tuesday, March 1, 2011

Changing Your MAC Address In Window XP/Vista, Linux And Mac OS X : MAC spoofing


First let me explain a few things about MAC addresses. MAC stands for Media Access Control and in a sense the MAC address is a computer's true name on a LAN. An Ethernet MAC address is a six byte number, usually expressed as a twelve digit hexadecimal number (Example: 1AB4C234AB1F).

IPs are translated to MAC address by a protocol called ARP (Address Resolution Protocol). Let's say a computer with and IP of 192.168.1.1 wants to send information to another computer on the LAN that has an IP of 192.168.1.2 . First 192.168.1.1 will send out a broadcast to all stations on the LAN asking who has the IP 192.168.1.2. Then the box that has 192.168.1.2 will respond to 192.168.1.1 with it's MAC address which is cached in 192.168.1.1's ARP table for later use. To put this in Socratic Dialog form (with just a touch of Stallone):

Host 1 (192.168.1.1): Yo everyone on the LAN (FF:FF:FF:FF:FF:FF), who has the IP 192.168.1.2? My MAC is DE:AD:BE:EF:CA:FE so you can respond back to me.
Host 2 (192.168.1.2): Hello DE:AD:BE:EF:CA:FE, I have IP 192.168.1.2 and my MAC address is 12:34:56:78:90:12 so you can send your IP packets to me.

 You can see the ARP table of a box by dropping out to a command prompt and typing "arp –a" in Windows or just "arp" in Linux. ARP can also work the other way by a host on the LAN sending its MAC address to another machine on the LAN for preemptive caching unless the host is configured to not accept un-requested ARP replies.

 A person might want to change the MAC address of a NIC for many reasons:

  1. To get past MAC address filtering on a router. Valid MAC addresses can be found by sniffing them and then the deviant user could assume the MAC of a valid host. Having two hosts on the same network can cause some network stability problems, but much of the time it's workable. This is one of the reasons why MIC Address filtering on a wireless router is pointless. An attacker can just sniff the MAC address out of the air while in monitor mode and set his WiFi NIC to use it. Interestingly, a lot of hotels use MAC filtering in their "pay to surf" schemes, so this method can be an instant in for cheap skate road warriors. 
  2. Sniffing other connections on the network. By assuming another host's MAC as their own they may receive packets not meant for them. However, ARP poisoning is generally a better method than MAC spoofing to accomplish this task.
  3. So as to keep their burned in MAC address out of IDS and security logs, thus keeping deviant behavior from being connected to their hardware. For example, two of the main things a DHCP server logs when it leases an IP to a client is the MAC address and host name. If you have a wireless router look around on it's web interface for where it logs this info. Luckily there are tools to randomize this information (MadMACs).
  4. To pull off a denial of service attack, for instance assuming the MAC of the gateway to a sub net might cause traffic problems. Also, a lot of WiFi routers will lock up if a client tries to connect with the same MAC as the router's BSSID.


BSD

1) Bring down the interface: "ifconfig xl0 down"
2) Enter new MAC address: "ifconfig xl0 link 00:00:00:AA:AA:AA"
3) Bring up the interface: "ifconfig xl0 up"

Linux

1) Bring down the interface: "ifconfig eth0 down"
2) Enter new MAC address: "ifconfig eth0 hw ether 00:00:00:AA:AA:AA"
3) Bring up the interface: "ifconfig eth0 up"

Windows 2000/XP
Method 1:

This is depending on the type of Network Interface Card (NIC) you have. If you have a card that doesn't support Clone MAC address, then you have to go to second method.

a) Go to Start->Settings->Control Panel and double click on Network and Dial-up Connections.
b) Right click on the NIC you want to change the MAC address and click on properties.
c) Under "General" tab, click on the "Configure" button
d) Click on "Advanced" tab
e) Under "Property section", you should see an item called "Network Address" or "Locally Administered Address", click on it.
f) On the right side, under "Value", type in the New MAC address you want to assign to your NIC. Usually this value is entered without the "-" between the MAC address numbers.
g) Goto command prompt and type in "ipconfig /all" or "net config rdr" to verify the changes. If the changes are not materialized, then use the second method.
h) If successful, reboot your system.

Method 2:

This should work on all Windows 2000/XP systems
a) Go to Start -> Run, type "regedt32" to start registry editor. Do not use "Regedit".
b) Go to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}". Double click on it to expand the tree. The subkeys are 4-digit numbers, which represent particular network adapters. You should see it starts with 0000, then 0001, 0002, 0003 and so on.
c) Find the interface you want by searching for the proper "DriverDesc" key.
d) Edit, or add, the string key "NetworkAddress" (has the data type "REG_SZ") to contain the new MAC address.
e) Disable then re-enable the network interface that you changed (or reboot the system).

Method 3:

Use the program Etherchange from http://ntsecurity.nu/toolbox/etherchange/
Windows 9x
Use the same method as Windows 2000/XP except for the registry key location is "HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\Class\Net" and you must reboot your system.

Locking down Windows Vista and Windows 7 against Malicious USB devices


 A fair amount has been written already about locking down a Microsoft Windows box to protect it against undesired USB flash drive usage. If system owners want to keep data from leaving their network via removable storage there's a simple registry entry the can be tweaked:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\StorageDevicePolicies\WriteProtect
Or a simple tool I wrote awhile back can be used to manipulate this registry key:
It should be noted that my tool above was meant more for forensics use (though I make no guarantee that it is forensically sound). A security professional may be worried about more than just data leaking out of their systems on removable storage, they may also worry about U3 thumb drives with undesired Autorun payloads. In the case of Autorun/Autoplay concerns, the following Microsoft article has a great amount of detail on disabling Autorun on selected device types:
What the article you are reading will concentrate on is stopping other classes of possibly malicious USB devices, especially the PHUKD (Programmable HID USB Keyboard/Mouse Dongle) from my upcoming Defcon presentation:
One of the advantages of the PHUKD is that human interface devices (HIDs) like mice and keyboards don't require administrative privileges to install and function, at least by default. Another advantage the PHUKD has is that many organizations are beginning to lock down Autorun on their systems to prevent malware like Conficker from spreading via that particular vector, and to keep tools like the Hak5 U3 Hacksaw from functioning. However, since a PHUKD is a USB HID, turning off Autorun has no effect on it. There are however other Windows 7/Vista setting that can be tweaked to disable arbitrary USB devices.
While I did most of my testing of the following Windows Vista/7 security options using a PHUKD device, they should also prove useful in blocking U3 thumb drives, WiFi dongles (think inadvertent rogue access points), non-passive keyloggers and other devices that could be attached to a system. Also, these security options can be applied to restrict other types of hardware, not just USB, though USB peripherals are what I will concentrate on in this article.
Shortly I will be covering Windows 7/Vista Group Policy/Registry tweaks that you can apply to block the automatic install of USB devices, but first there is a tool you may want to download to easy your experimentation. Nirsoft's USBDeview was of great use to me during this research.
USBDeview is quite useful, especially as compared to Device Manager. A few of the more useful features of USBDeview include:
1.    View Vendor ID, Product ID, Device Class, Serial Number and etc. all from one line of output.
2.    Uninstall devices, even if they are not currently connected to the system.
3.    Jump straight to the registry keys related to the USB devices.
4.    Export list of installed USB devices to a text file.
Along with USBDeview it may be useful for you to be able to go straight to the MMC plugins we will be using in this article: Device Manager and Local Group Policy Editor. To jump directly to these MMC plugins: Enter the command "devmgmt.msc" to bring up the Device Manager, or "gpedit.msc" to bring up the Local Group Policy Editor. These commands may be entered via the "Search programs and files" bar, the Run bar or via the command console (cmd.exe/ powershell.exe). Putting shortcuts to them on your Desktop is also an option of course.
Now that we have the needed tools, I'll cover the Device Installation Restriction options available in Windows 7/Vista. For each entry the following information will be given:
1.    The setting's name.
2.    A quote of Microsoft's description of the setting as seen in the Group Policy Editor.
3.    My notes from testing where I will try to clarify the use of the settings and certain "gotchas" you may encounter while using them.
4.    The registry keys and values that are changed when the option is enabled. This should make it easy for administrators to create their own scripts and interfaces for manipulating these security options.
Now let's take a look at some of the GPO options Windows 7/Vista provides for restricting hardware installation. To bring up the list of Device Installation Restriction options, use the command "gpedit.msc" as covered earlier, and navigate to:
Computer Configuration->Administrative Templates->System->Device Installation->Device Installation Restrictions

If at any point you have problems getting hardware to work because of changing these setting, set all of these GPO options to "Not Configured" then go into Device Manager and do an "Action->Scan for Hardware Changes" from the menu bar.


Background on I2P

Since the academic community seems to be far more aware of Tor than I2P, it may be helpful to compare the two systems and cover some of the basics concerning how I2P works. Both Tor and I2P use layered cryptography so that intermediates cannot decipher the contents of connections beyond what they need to know to forward the connection on to the next hop in the chain. Rather than focusing on anonymous access to the public Internet, I2P's core design goal is to allow the anonymous hosting of services (similar in concept to Tor Hidden Services). It does provide proxied access to the public Internet via what are referred to as "out proxies", as well as various internal services to proxy out onto the Tor and Freenet systems, but that is not its core design goal.
Every I2P node is also generally a router (and you can use the terms somewhat interchangeably when it comes to I2P) so there is not a clear distinction between a server and a mere client like there is with the Tor network. Some I2P nodes do take on more responsibility than others, such as floodfill routers that participate in NetDB to handle routing information. Unlike Tor, I2P does not use centralized directory servers to connect nodes, but instead utilizes a DHT (Distributed Hash Table), based on Kademlia, referred to as NetDB. This distributed system helps to eliminate a single point of failure, and stems off blocking attempts similar to what happened to Tor when China blocked access to the core directory servers on September 25th 2009. I2P's reliance on a peer to peer system for distributing routing information does open up more avenues for Sybil attacks and rogue peers, but steps have been taken to help mitigate this and are covered in the documentation.
Instead of referring to other routers and services by their IP, I2P uses cryptographical identifiers to specify both routers and end point services. For example the identifier for "www.i2p2.i2p", the project's main website internal to the I2P network, is:
-KR6qyfPWXoN~F3UzzYSMIsaRy4udcRkHu2Dx9syXSz
UQXQdi2Af1TV2UMH3PpPuNu-GwrqihwmLSkPFg4fv4y
QQY3E10VeQVuI67dn5vlan3NGMsjqxoXTSHHt7C3nX3
szXK90JSoO~tRMDl1xyqtKm94-RpIyNcLXofd0H6b02
683CQIjb-7JiCpDD0zharm6SU54rhdisIUVXpi1xYgg
2pKVpssL~KCp7RAGzpt2rSgz~RHFsecqGBeFwJdiko-
6CYW~tcBcigM8ea57LK7JjCFVhOoYTqgk95AG04-hfe
hnmBtuAFHWklFyFh88x6mS9sbVPvi-am4La0G0jvUJw
9a3wQ67jMr6KWQ~w~bFe~FDqoZqVXl8t88qHPIvXelv
Ww2Y8EMSF5PJhWw~AZfoWOA5VQVYvcmGzZIEKtFGE7b
gQf3rFtJ2FAtig9XXBsoLisHbJgeVb29Ew5E7bkwxvE
e9NYkIqvrKvUAt1i55we0Nkt6xlEdhBqg6xXOyIAAAA
This is the base64 representation of the destination. Obviously having a user type in this 516 byte chunk of data as an Identifier would be somewhat less than user-friendly, and it would not be valid in some protocols anyway (HTTP for example). I2P provides some workarounds for naming identifiers; one is called "Base 32 Names", similar in many ways to Tor's .onion naming convention. Essential the 516 byte Identifier is decoded (with some character replacements) into its raw value, the value is hashed with SHA256, then this hash is base 32 encoded and ".b32.i2p" is concatenated onto the end. The results for the "www.i2p2.i2p" identifier shown above would be:
rjxwbsw4zjhv4zsplma6jmf5nr24e4ymvvbycd3swgiinbvg7oga.b32.i2p
This form is much easier to work with. For most eepSite users the common naming solution is to just use the local I2P address book that maps a simple name like "www.i2p2.i2p" to its much longer Base 64 identifier. There is no official DNS like service to do this lookup as that would be a single point of failure that the I2P project wishes to avoid. Each I2P node has its own series of text files that contain the name mappings in much the same way that the Internet used to use just HOSTS files to translate names to IPs before DNS was invented. There are however naming subscription services inside of I2P that can be synced to if the user wishes, though this means the user is putting some level of trust in these services not to hijack the name mappings.
A router's ID is not the same as a service's ID, so even if the service happens to be running on a particular router the two identifiers cannot be easily tied together. I2P also uses a few techniques to help mitigate traffic correlation attacks. While the Tor network uses a single changing path for communications, I2P uses the concept of "in" and "out" tunnels so requests and responses are not necessarily using the same paths for exchanging information. I2P also uses an Onion routing variant referred to as Garlic routing, where more than one message is bundled together into a "clove". This mixing of messages using Garlic routing can lead to confusion for attackers attempting to correlate transmission sizes and timings, and if "cloves" are composed of messages from both high latency tolerant applications (e.g. email) and low latency applications (e.g. web traffic) correlation could become even harder. More comparisons between I2P, Tor and other anonymity networks can be found on I2P's "I2P Compared to Other Anonymous Networks" page.
Many services can be hosted inside of the I2P overlay network (IRC, Bittorent, eDonkey, Email, etc.), and the I2P team has provided an API for creating new applications that ride on top of the I2P overlay network. As the developers note on their page, many standard Internet applications are not designed with anonymity in mind, so caution should be taken when adapting an existing application to run on top of I2P. While many applications exist and could be researched for application data leaks, this paper will be concentrating on eepSites which are websites internal to I2P. Some measures are taken by the default I2P install to help filter revealing information at the application level, but service providers do make mistakes that can lead to too much information being revealed.