DoD CAC Authentication to routers/switches

NetworkGroover · April 21, 2015, 09:33:45 PM

Ok, so this is driving me nuts and I'll just own up and say I don't have a clue how this is supposed to work. As a route/switch guy I never came across this in my studies, and I have yet to work a job where I interfaced with this other than overhearing conversations where it was supposedly a requirement but it was either not supported or didn't work properly.

So, what I don't get, is if you log into AD with a CAC, and your AAA account that you use to manage the switch is tied to your AD account, how is that not two-factor auth using CAC?

Please, if someone with federal/DoD experience could break this down to me retard-style, I'd greatly appreciate it. Searches on the web turn up results that I don't even understand fully how to translate - I'm just not from that security world.

Otanx · April 22, 2015, 09:42:22 AM

So first you need to remember that one you are dealing with DoD some of the most paranoid people in the world. Two remember that this is rumour on my part as well. I no longer work with DoD, and have not seen the official requirements document. Now with those two things in your mind the way I understand it is that the problem is with the TACACS and RADIUS protocols. You are relying on a shared secret to pass the information back and forth which is just a password. Now as an attacker if I can get that shared secret I can MITM the auth request, and accept any login given. The device does not validate in any way, besides the shared secret, that the authentication response is valid.

-Otanx

NetworkGroover · April 22, 2015, 10:18:49 AM

Quote from: Otanx on April 22, 2015, 09:42:22 AM
So first you need to remember that one you are dealing with DoD some of the most paranoid people in the world. Two remember that this is rumour on my part as well. I no longer work with DoD, and have not seen the official requirements document. Now with those two things in your mind the way I understand it is that the problem is with the TACACS and RADIUS protocols. You are relying on a shared secret to pass the information back and forth which is just a password. Now as an attacker if I can get that shared secret I can MITM the auth request, and accept any login given. The device does not validate in any way, besides the shared secret, that the authentication response is valid.

-Otanx

That helps, thanks, but if your TACACS/RADIUS account is tied to AD, doesn't it enforce you to authenticate against AD, which in turn would require a CAC and password/PIN? Or can you simply bring in a home laptop, plug it into the switch, and authenticate to it via your AAA account without having to auth to AD with the CAC?

Otanx · April 22, 2015, 01:44:22 PM

The problem is with validating the authentication server to the router. How does the router know it is talking to a valid authentication server? This is done using a shared secret (TACACS or RADIUS key). So all of your two factor authentication is dependent on that single password. If I compromise that password (type 7 for the win) I can impersonate/MITM the real auth server, and reply with an ACCEPT messages to any login the router sends.

Lets say that I am an attacker, and I want to login to your router. I compromise a host on the same vlan as your TACACS server. I then ARP poison the default gateway and the TACACS server to get in the traffic flow. I now login to the router. The router sends a SYN packet to the TACACS server to begin the authentication. My compromised host responds to the router with SYN/ACK. The router ACKs back finishing the three-way handshake. It then sends the auth request. I ignore what is in the packet, and just reply with ACCEPT. The router lets me login, and I can do whatever I want. The router is assuming I am a valid auth server because I used the same shared key to encrypt the ACCEPT message. The entire two factor CAC authentication broke because one password was compromised. I don't even really need to MITM the auth server as long as I can see the traffic, and send the ACCEPT message to the router before the real server sends the REJECT message.

My understanding is the requirement is basically certificate based authentication for the entire chain. So the router and authentication servers both need certificates, and certificate chains to validate each other, and the client you are logging in from, and the router you are logging into need to authenticate each other. As far as I know currently there is no good way to do this.

-Otanx

NetworkGroover · April 22, 2015, 02:53:34 PM

Quote from: Otanx on April 22, 2015, 01:44:22 PM
The problem is with validating the authentication server to the router. How does the router know it is talking to a valid authentication server? This is done using a shared secret (TACACS or RADIUS key). So all of your two factor authentication is dependent on that single password. If I compromise that password (type 7 for the win) I can impersonate/MITM the real auth server, and reply with an ACCEPT messages to any login the router sends.

Lets say that I am an attacker, and I want to login to your router. I compromise a host on the same vlan as your TACACS server. I then ARP poison the default gateway and the TACACS server to get in the traffic flow. I now login to the router. The router sends a SYN packet to the TACACS server to begin the authentication. My compromised host responds to the router with SYN/ACK. The router ACKs back finishing the three-way handshake. It then sends the auth request. I ignore what is in the packet, and just reply with ACCEPT. The router lets me login, and I can do whatever I want. The router is assuming I am a valid auth server because I used the same shared key to encrypt the ACCEPT message. The entire two factor CAC authentication broke because one password was compromised. I don't even really need to MITM the auth server as long as I can see the traffic, and send the ACCEPT message to the router before the real server sends the REJECT message.

My understanding is the requirement is basically certificate based authentication for the entire chain. So the router and authentication servers both need certificates, and certificate chains to validate each other, and the client you are logging in from, and the router you are logging into need to authenticate each other. As far as I know currently there is no good way to do this.

-Otanx

Ahhhh thank you. That helps shed some light. So would CAC auth at the AD level, plus mutual authentication via certificates between the switch and the AAA server satisfy it? I'm sure I'm oversimplifying it. Or are they looking to use their CAC to complete the entire chain? Sounds complex...

NetworkGroover · April 22, 2015, 03:17:25 PM

Also, what if you have role-based command authorization deployed on the switch? How would the attacker know what account to use?

EDIT - I should say, even if you could bypass the auth server, you'd need to know what roles are configured on the switch and appropriate attribute-value pairs that the AAA server passes in order to do anything locally on the switch.

EDIT 2 - Does having mutual auth prevent a denial-of-service attack on the switch though? Even if you couldn't technically do anything on the switch, could you induce a condition where maybe others couldn't log in?

Otanx · April 22, 2015, 05:40:22 PM

For AV pairs I don't know. I have not worked with them enough to know how they work in detail. If I have the key, and I have access to the traffic path I can look at previous traffic, and replay the values. Mutual auth will not prevent a DoS, it only really prevents MITM. No mater what you are using for auth if I can see the traffic I can just forge TCP RST packets at both the router, and auth server all day to reset the authentication requests. Then it will depend on how your router handles that condition. It can either fail all auth, or it could fall back to local auth, or do something else entirely.

-Otanx

NetworkGroover · April 22, 2015, 07:07:18 PM

Quote from: Otanx on April 22, 2015, 05:40:22 PM
For AV pairs I don't know. I have not worked with them enough to know how they work in detail. If I have the key, and I have access to the traffic path I can look at previous traffic, and replay the values. Mutual auth will not prevent a DoS, it only really prevents MITM. No mater what you are using for auth if I can see the traffic I can just forge TCP RST packets at both the router, and auth server all day to reset the authentication requests. Then it will depend on how your router handles that condition. It can either fail all auth, or it could fall back to local auth, or do something else entirely.

-Otanx

Yeah I suspect the auth mechanism would fail so depending on configuration you'd either fail back to local auth or if you're hardcore, require a specific local emergency account only accessible via console...