So there have been a few posts this week about MAC cloning not working.
The solution seems to be that cloning the MAC is not enough. Companies are using sophisticated software to create profiles per device to prevent MAC spoofing. That said, when cloning the MAC, you will also need to clone the IP address of your device to your router.
The request is, on the MAC cloning page, we also need a input field for the IP address,gateway,DNS.
You would just do a static IP and not DHCP then on your WAN/internet interface. Nothing new needed. Doesnāt help mitigate device profiling techniques. MAC is layer-2, and IP is layer-3. Profiling it taking place on the application layer-7. Based on where/what your device(s) talk to, and traffic patterns leveraging machine intelligence, and packet inspection (Palo Alto Networks, Aruba, Cisco, Zscaler ā all have their own buzz words).
Encrypting/Trafficking all of your connections through a VPN can help remain anonymousā¦ but if the controller or firewalls are unable to identify, they could also build policy that makes VPN more difficult for unidentified users such as a quarantine VLAN. It is getting more difficult; and most enterprise companies are taking the approach of, if itās not identifiable, block it.
Not trying to say thereās not a problem. I have experience deploying this stuff, and if itās done right, itās pretty hard to bypass. Itās also getting easier for lower-budget businesses to implement ā toggle buttons and a couple policies.
I agree, all great points but I still think the next logical step is to also clone the IP address on the WAN side.
Iāll do the honours for you:
Related
Aruba Networks Forum, ClearPass - Preventing MAC Spoofing:
I can add something here. Back in the days when I was dealing with the NAC on the engineering side of things, I remember that all devices were profiled based on the initial information sent to their switches. In addition to that, various security appliances on the network would start bombarding the new clients with all possible requests for information. At the end, the NAC would know things like device type (printer/ipphone/computer/router etc) as well as OS, device vendor and many other things. It looks like the travel router with current abilities does not serve its purpose. There is a need to completely mimic a device like a laptop. For example, once the router is up and running, to enable the repeater function a user needs to go to the router gui and enable something. At that time, there must be an option for the router gui to ask user: do you want this router to completely look like the device you currently are connected to it from? yes/no. That would eliminate the need for the user to do the advanced stuff like do ipconfig, replicate all settings like IP, subnet mask, gateway, DNS IP. I guarantee you an average user would have no idea what all that gibberish means. So the router should be able to collect all of that information from the client using the GUI in the same way any NAC-ish device collects that info from the router.
I was thinking something quite similar. GL already publishes an mobile app for router management; presuming the end user is able to successfully connect to $hotspot, why couldnāt the app read all the necessary details/strings/specs/etc required fr that mobile device & then push via curl to the GL routerās API?
ā¦ after all, much of whatās seen in the GL GUI is using json.
There is not even need for an app. Once the user hits āyes I want to mimic my end deviceā, what happens next:
End device connects to router. Router connects to hotel wifi. NAC on the hotel wifi asks the router some information. Router asks the exact same information the end device and forwards that information to the hotel wifi. No native info/settings are ever transferred to the hotel wifi. Hotel wifi would have no way to differ the router from the end device.
Your logic chain is of course the superiour oneā¦ but what happens when $endUser, already suffering fr jetlag/screaming kids, forgets & first connects $phone to $hotspot? Theyād be kinda fākād, wouldnāt they?
They would still hit that yes button and the router would replicate the same settings as if it was before connecting to the hotel wifi. The only exception would probably be the cookies potentially left by the captive portal
This really does come down to exactly what specific details are required to match the fingerprint, as @Authority rightly raises.
IDK about Apple but on Android devices unsolicited network packets (eg: GL router ā $phone) are always dropped so Iād think itād have to be an app-based solution to push the variables.
From my limited experience dealing with NAC, all attempts to identify the device happen in the first second or so. That could be simply forwarded to the end device from the router.
I may be wrong but to me dropping packets sounds like some kind of built in poor manās firewall/ips capabilities and would not identify the device in the eyes of a nac.
ā¦ which will be dropped.
How dare you, sir! /s
IDK about the most recent versions but Android used to run iptables.
Iād love to get some samples of what these so-called āsolutionsā such as Aruba Networkās use of Clearpass fingerprints. This whole topic takes me back to spoofing my browserās User Agent āback in the day.ā
Dropped in the same manner as if the android was connected directly to the hotel wifi. No difference > mimicking successful.
That is exactly what I am saying. No need to spoof. Just forward to the actual client everything coming from the local IPs or at the lower layers in the first ~second
Yeah, I understand the premise perfectly but itās a question of traffic initiation. If the GL router solicits a stock Android device, itāll be dropped as thereās no port listening on $phone. The key aspect Iām focusing in on is:
So how can the GL device get that Layer 7 data if thereās nothing for it to pull from? Thus, I think the $phone would require an app to push it.
ā¦ but without samples this is all speculation, of course.
I think that is too far away from the point where the NAC gives a go or no go signal. Anything that does not look right at layer 7 will be dropped by rich manās layer 7 firewall on the Aruba/whatever, but the deviceās status of being online will not change. NAC does its job before all of that.
Again, I am no expert and had too many cocktails on my cruise today, celebrating my multiple device Internet access, having paid for one device only. So I will leave this to the experts
Seconded.
Good on you for not getān grifted! Drink three for me.
Thereās a few technologies behind thisā¦ The tried-and-true is 802.1x; traditional NAC which identifies company-owned assets through tools like JAMF, Intune, and other agent-based services to know āThis device is oursā.
The one that I think weāre running into is the newer Machine-Learning techniques, Ciscoās done it for years through their NBAR (Network Based Application Recognition) and enhanced with their 9800 controller device profiling (ref: Demonstrate Client Profiling on 9800 Wireless LAN Controller - Cisco).
Aruba has taken it a bit further, especially with their new cloud offering āAruba Centralā which is similar to Cisco Merakiās cloud controller. ClearPass Device Insight Data Sheet | HPE Aruba Networking (arubanetworks.com).
With device profiling, youāre not leveraging on-device services like JAMF/Intune, and clientās donāt need to āreportā anything; like a traditional NAC/802.1xā¦ It leverages application traffic patterns, DHCP request types, and packet inspection combined with application identification to ābest matchā the client to a profile ā based on that profile, youāre then able to set policy.
The references above to listening and responding based on request (ref $phone) would likely work for traditional 802.1xā¦ But, depending on policy if theyāre also leveraging the device profiling, it may still not work. It is hard to fool the device profiling - in the sense that if traffic patterns change, or donāt match a device profile, itāll classify as unknown rather easily. Hotels, and businesses that are service BYOD will likely lean more towards the newer Device Profiling policies, than traditional 802.1x. Seeing as, no one is going to install software on their personal devices so they can identify them. Device Profiling doesnāt require any software or input from users; and simply looks at their traffic patterns and behavior.
Personally, I donāt know a way around the device profiling (unlike traditional NAC/802.1x ā which doesnāt look at network traffic as much as device reporting/user/agents/MAC). Device profiling is completely device agnostic, and is a bit tricky.
Maybe a small laptop with 2 x wifi and vpn over stunnel or ssh would work?
Let us just start with a MAC / IP / DNS cloning facility and possibly a built-in basic browser before conquering the rest of the world here. I really hope the GL.iNETās team are watching this threadā¦
They better be watching; as @Authority just laid out, this tech. evolution/escalation seems to have a severe risk of torpedoing their entire Travel Router lineā¦ if not their reputation.
As for mere MAC, IP, DNS Cloning, I doubt thatāll be a real challenge for 'em; I can see it being nothing more than another well labelled link to an āAdvancedā modal/screen that consolidates everything into one GUI/modal window instead of scattered across something like GL GUI ā Network ā MAC Address then GL GUI ā Internet ā Etherenet ā Modify ā Ethernet Settings ā Protocol ā Static.
I know youāve voiced issues w/ GL, @Almahadeus, perhaps rightfully deserved but in the case of a ācloning facility/featureā, I canāt see a technical issue as a roadblock, only a lack of will to work on the GUI.