Security

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. 

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.

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?

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

tim

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. 

Hey Ryan,

 

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:

 

 

 

Hey Ryan 

 

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 update. It this a government client?


Thomas Porter

Network Engineer

571-330-6495 (c)

202-324-0402 (o)

IMPORTANT NOTICE: This message may contain privileged and confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

Thanks for the info, we had the same problem as you did I'll try reducing the cache time as well, kudos!

Hi Ryan,

Will there be any impact if we made this changes?

------------------------------
Wenjie Teng
------------------------------

Original Message:
Sent: Dec 20, 2018 11:28 AM
From: Ryan Brennan
Subject: 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: