Security

Reply
Frequent Contributor II

ClearPass - Preventing MAC Spoofing

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. 

Guru Elite

Re: ClearPass - Preventing MAC Spoofing

MAC Auth is an authorization only. Anything that can’t present a strong credential should never be treated the same as a device that does. For example, a VoIP phone that can’t do 802.1X should only have access to the call server and that’s it.

Anything that can do 802.1X, should be doing 802.1X. Phones, printers, APs, whatever it may be.

UBT should always be used when possible as mobility controllers can provide additional context to ClearPass when DHCP fingerprinting is not available.

| Tim Cappalli | Aruba Security | @timcappalli | timcappalli.me |

NOTE: Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba or Hewlett Packard Enterprise.
Frequent Contributor II

Re: ClearPass - Preventing MAC Spoofing

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?

Guru Elite

Re: ClearPass - Preventing MAC Spoofing

You would need Aruba switches, controllers and ClearPass. The plumbing between the access and controllers doesn’t matter.

tim

| Tim Cappalli | Aruba Security | @timcappalli | timcappalli.me |

NOTE: Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba or Hewlett Packard Enterprise.
Frequent Contributor II

Re: ClearPass - Preventing MAC Spoofing

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. 

Occasional Contributor II

Re: ClearPass - Preventing MAC Spoofing

Hey Ryan,

 

did you find any solution or workaround for this? If so, please share.

Highlighted
Frequent Contributor II

Re: ClearPass - Preventing MAC Spoofing

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:Capture.JPG

 

 

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: