I have a couple of customers that use MAC Binding to a Private Pre-Shared Key (PPSK) on the Aerohive platform, and I wanted to show that Windows and OS X devices could pass that security.
The test revolved around replicating the customer’s network as much as possible — Aerohive Wi-Fi with Windows and OS X clients, using MAC Addresses bound to the PPSK.
I started by creating a WLAN and enabling the MAC Binding security feature. You must check two items in the initial setup to enable the feature. You do have the option of restricting the number of clients per PPSK. I will test that in a bit.
Aerohive also requires that the PSK Management AP have a static IP address.
I created the user group for the WLAN and then a user with a unique PPSK. Once I attached all my settings to the WLAN, I pushed the change to my AP.
I connected with my iPhone and was successful. I was able to surf the web — very simple stuff on the Aerohive platform. What should be just as easy is spoofing the MAC address on a Windows device. We have all done it in the past.
I needed to find my real MAC Address, so I did a CMD command of “netsh wlan show interface,” and it said my MAC Address was 40:a5:ef:46:4e:50.
I then open the Properties on the NIC and click Configure. Then click on the Advanced tab and then go to Network Address. There is no Network Address option on any of my NICs. Since Windows 7, Microsoft has been working toward removing this option.
I installed a program called “Change MAC Address.” It does exactly what it advertises. I changed the MAC address of my USB NIC and then connected to my Aerohive WLAN. But what I did notice was that the program said the second number of the MAC is limited to only 2, 6, A, and E. The second nibble (a half byte) represents whether the address is an individual address or a group address. With 0 being the designator for the individual address and a 1 meaning a group address. Microsoft implemented the limitation of only using 2, 6, A, or E as the second number to stop spoofing legitimate addresses, using wireless adapters.
To get around this, I took the WLAN NIC and assigned a MAC Address of 92:81:2a:07:0e4a. I did a CMD command of “netsh wlan show interface,” and it confirmed that the MAC Address had changed. I repeated the process on the second NIC. Once both NICs showed identical MAC Addresses, it was time to test.
I connected to my test WLAN successfully with the first NIC. With the second NIC still connected to my computer, I tried to connect to the same WLAN. After I was successful, I confirmed that one NIC could surf while the second could not. I moved the second NIC to another computer and confirmed that the MAC Change program only edits the registry. The proved that students wouldn’t be able to sell spoofed NICs.
I used the program on the second computer to change the MAC address to the same as the first computer. Once I successfully connected both computers to the same WLAN with the same MAC Address, I discovered that only one of the clients could surf. Running “show arp” on the Aerohive AP revealed only one entry in the table. This failure makes sense as I am using one MAC address, and both devices are in the same VLAN.
I then tried this test on my Macbook OS X device. But I wanted to use a real MAC Address and not one generated by a program.
I joined my SSID with my iPhone and was able to surf the web. I went to my Client view in Aerohive’s HiveManager and saw that the MAC Address of my phone was listed. I copied that MAC address and went to my Macbook.
In Terminal, I ran, “sudo ifconfig en0 ether F0:C3:71:57:10:48” and changed the MAC on my OS X device to that of the iPhone. I ran “ifconfig en0 | grep ether” to show that my MAC had indeed changed to that of my iPhone.
With my phone connected to the test SSID, I then connected my Macbook. The most interesting part of the test was that my iPhone was more than helpful to my Macbook in joining the WLAN. It offered the PPSK.
I now had both devices connected to WLAN, proving that Aerohive does not protect against MAC spoofing. I now had to devices with the same MAC address connected successfully.
However, in testing, only one device was able to ping Google, the Macbook. The last device to connect gets the port for data. Both devices are on the same VLAN; therefore, the DHCP server only issued one IP address to the authenticated MAC Address. When I disconnected my Macbook, the iPhone began to ping Google successfully. I then connected my Macbook to another SSID, on a different VLAN, successfully. I now had a legitimate MAC Address and a spoofed MAC Address on the company’s Wi-Fi.
But what about that option to limit the number of connections per PPSK that we skipped earlier? I deleted all users from the system for this test. In the WLAN option, I now checked the box to limit the number of connections per PPSK to one. The idea behind this setting is to only allow one connection at a time, for each PPSK. This setting is supposed to stop the scenario we saw earlier of the last device to connect gets the connection.
I again connect my iPhone and then spoof that address to my MacBook. When I tried to connect my MacBook, it failed to connect. The setting worked as expected. To prove this, I deleted the user and created a new. This time my iPhone connected and then my MacBook, repeating the above situation.
These tests show that while MAC spoofing is still a thing, you must make sure that all of your settings are correct.
