Have a pen tester in and he was able to get on the network in 20 seconds by spoofing the mac address of a Cisco IP phone, which authenticates via MAB. I have conflict triggers on and enabled at the top of the MAB Service to deny spoof attempts, however this one did not catch. After working with TAC I received the following info on Conflicts:
1. Conflicts trigger if the fingerprint from the same source changes over time, resulting in two different device profiles. Example: device is originally profiled as a computer when it first shows up on the network, but after spoofing the MAC of a printer, the endpoint DB will be update as printer and the Conflict True flag is raised.
2. The fingerprinting from different sources resulting in two different device categories. Example: Profiled as a computer from DHCP fingerprinting, but profiled as a SmartDevice from HTTP fingerprinting.
With all of that being said, if a hacker comes on to your network and has never been seen before, and spoofs the address of a peripheral device (phone, printer, etc) from the getgo, it seems there is no way to stop them, based on how conflict triggers work. ClearPass has never fingerprinted the device previously, so when it presents itself to ClearPass with the MAC of the phone it MAC Auths like the phone does.
Am i missing something, or is this a gaping hole in a NAC in general? Taking suggestions for other ways to prevent this. Doing 802.1x on our phones and eliminate MAB is a plan of attack, but then the pen tester migrates to the printer in the next cube and you're back to the same problem.
Any advice anyone has would be most appreciated.
Thanks for the reply, Tim.
With ClearPass as the primary authenticator, if you were to implement UBT would your access and core layer also need to be Aruba? Or could this work with Cisco switches/routers, Aruba wifi and ClearPass?
Thank you for the information Tim. You have confirmed what I was thinking, and unfortunately that's not a good thing. It appears that ClearPass is fantastic for an onboarding solution, as well as a guest wireless solution. But as far as a NAC goes, it has a huge problem detecting mac spoofs, rendering it useless in that capacity. Not sure if Cisco ISE handles this any better (or any other NAC solution), but this is very disheartening.
We've spent a ton of money and many, many day/weeks/months fine tuning this product, only to have a pen tester break in within a matter of moments like it wasn't even installed.
I'm hoping there is a bug at play here, and that detecting conflicts is a working feature within the application. I've seen it work before, however for whatever reason that is no longer the case.
did you find any solution or workaround for this? If so, please share.
Forgot to post a solution to this...worked with TAC over the course of a couple weeks and what we found was the endpoint cache has to be changed from 300 seconds (5 minutes) to a much lesser value (I made ours 10 seconds).
The conflict flag was not triggering when the Linux laptop spoofed the MAC of a Cisco phone because it looks at the endpoint cache first before the endpoints database. If the cache is associating a MAC with a legit endpoint (in this case a Cisco phone), the spoofing device (in this case a Linux laptop) will appear to Clearpass as the phone and let it on. Interesting that when it does that it updates the endpoint database entry of the phone with the hostname of the Linux laptop, yet still keeps it classified as a Cisco voip phone.
At any rate, when the endpoint cache timer was set to 10 seconds, by the time the Linux box was on the network looking to spoof, 10 seconds had elapsed and it went straight to the endpoints database to MAC auth instead of cache. Clearpass recognized the conflict, flagged it and sent the CoA to the Cisco access switch in the background to shut the port. There was one catch however...it took 31 seconds for the switchport to shut off. Clearpass did it's part (conflict flag and send CoA) in 8 or 9 seconds. Now I'm looking through Cisco documentation to see why it takes them 22 more seconds to receive the CoA and act upon it. Not the most ideal situation because a lot can be accomplished by an internal hacker in 31 seconds, but it's meeting an audit item for now.
Here is a screen shot where the change is to be made:
Any update on this? I am preparing for a PENTEST and ran acroos your thread.
I just went through yet another pen test a month or so ago and came across the same issue. I had to ramp down the endpoint cache timer to 7 seconds in order for the spoof/conflict detection to work correctly. That fixed the issue.
Thanks for the info, we had the same problem as you did I'll try reducing the cache time as well, kudos!
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.