RADIUS Security

SOLVED
ZedGama3
Comes here often

RADIUS Security

I've set up an MX client VPN to use RADIUS authentication and noticed that Wireshark is able to show the plain-text password when provided with the RADIUS secret.  Is there a way to prevent this?

 

As it stands, anyone with admin access to the server could get the passwords for anyone who uses the VPN.  Interestingly, this doesn't seem to be the case for Wi-Fi authenticating via RADIUS.

1 ACCEPTED SOLUTION
PhilipDAth
Kind of a big deal
Kind of a big deal

NTLMv2 is quite good, but many companies fail to create group policy to make it the only allowed option, allowing NTLMv1 to be used - which is not very good.

 

Microsoft don't do any work on the L2TP client anymore, so I can't see them improving it.  Cisco Meraki continues to work on AnyConnect, which is a much better option.  Once that comes out you'll be able to move onto that and result this issue.

View solution in original post

4 REPLIES 4
Bruce
Kind of a big deal

Not sure there’s an easy solution to this one. RADIUS as a protocol doesn’t include any encryption, other than some password ‘hiding’. When you use it over wireless there is a secure tunnel created all the way to the RADIUS server and credentials are passed through that - hence why you need to ‘accept’ the server certificate if it’s not from a trusted CA. The Meraki MX doesn’t create such a tunnel to the RADIUS server.

 

I’d suggest using a very long RADIUS secret, and restrict administrative access to everyone you can, both to prevent them seeing the secret and to prevent them doing packet captures.

 

Not sure on the practicalities of getting the MX to use a TLS tunnel to the RADIUS server, but probably worth making a wish.

PhilipDAth
Kind of a big deal
Kind of a big deal

Great question.

 

First, if the user has admin access to the server then you don't need to worry about password sniffing.  They could just change the passwords, or extract out the hashes for the existing passwords and use something like hashcat to convert them back to plain text.

Password sniffing only lets you get one password at a time as users connect.  Doing the whole password database gives you everyones password

 

The RADIUS device (MX, AP, whatever) merely passes on the password in whatever form the client presented it in.  Because of this, the entire client authentication scheme in RADIUS is often independent of the devices doing the authentication (client and eventual authentication server).

In the case of client VPN, the client supplies the password using PAP, which is plain text.  This is easy to sniff in Wireshark.

WiFi can use a number of schemes with PEAP being the most popular.  PEAP wraps the authentication exchange in TLS, so the entire conversation is encrypted.  This appears encrypted in Wireshark.

So the short answer is no.

 

TL;DR;

 

The concern I'm trying to address is the ability for someone in a privileged position to impersonate someone else without them realizing it.

 

As for extracting password hashes, I'm surprised that Microsoft hasn't implemented a better hashing algorithm that would require more time to brute force the hash.

 

Regarding Wi-Fi, I see several challenge-response pairs and was assuming the mechanism was using an authentication method that didn't require sending the password.  Example: the server sends a random string, the client then responds with a hash resulting from the combination of the hashed password and the random string - by doing this multiple times the server can be sure that the client knows the password without actually sending the password.

 

Of course, depending on how much access the admin has, they can enable reversible encryption and install key loggers.  No solution is perfect, but I'm trying to limit an attacker's options - regardless of if they are foreign or domestic.  If a password gets changed, it's recognized right away.  The other issue is that most users re-use passwords and could gain access to systems beyond the original scope of the attacker.

PhilipDAth
Kind of a big deal
Kind of a big deal

NTLMv2 is quite good, but many companies fail to create group policy to make it the only allowed option, allowing NTLMv1 to be used - which is not very good.

 

Microsoft don't do any work on the L2TP client anymore, so I can't see them improving it.  Cisco Meraki continues to work on AnyConnect, which is a much better option.  Once that comes out you'll be able to move onto that and result this issue.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels