How to disable DefaultWEBVPNGroup in ASA 5512-X?

[Scryden2]

Hi all,

We are running an ASA 5512-X firewall running firmware version 9.12.4(62) from September 2023. It is end-of-life and will be replaced in the next few months. Until then I have to make do with this firewall.

We are using AnyConnect, or in this case Secure Client version 5.1 for office staff to VPN in remotely. This VPN profile is setup with RADIUS to a DUO proxy for MFA. Authentication takes place based on Active Directory. So we got our MFA all setup and going for VPN.

However, there is this default DefaultWEBVPNGroup in the firewall that uses the LOCAL user database that I really want to get rid of. When I look in the logs of the firewall, I see a whole bunch of hooligans trying to make a WebVPN session on this profile and trying to brute-force their way in: 6 113015 AAA user authentication Rejected : reason = User was not found : local database : user = ***** : user IP = x.x.x.x.

There was another error that specifically showed me the DefaultWEBVPNGroup but I can't find that now. When I look at the AAA statistics in my ASA, I see about 1000 login attempts of which 99% of them were rejected due to invalid credentials. The 1% permitted was myself logging into the firewall. There is only one username in the LOCAL database which is impossible to guess (50 character long username with 50+ character long password) so I don't foresee any problems here. However, since we are using MFA for our VPN login, I don't want these shenanigans happen on my firewall in the first place. VPN authentication should go through the RADIUS MFA proxy exclusively.

How do I stop these bots from hitting the DefaultWEBVPNGroup and trying to authenticate against the firewall's LOCAL user database? I never set this profile up. It was there by default. And if its accessible from the internet then that poses an astronomical risk, especially for those of us that use something simple like admin/admin for a LOCAL login. So I really want to boot this out so nobody can ever hit this using WebVPN anymore.

[Scryden2]

Hi Rob,

Yes I had already shutdown that portal with an "Unavailable" message when CVE-2023-20269 emerged. But somehow they still manage to get to the WEBVPNGroup profile.

[Rob Ingram]

@Scryden2 is it working? can you replicate this by attempting to login to the DefaultWEBVPNGroup via the web browser or even anyconnect?

[Scryden2]

@Rob Ingram no, on the webportal I see my "Unavailable" message and in the anyconnect profile drop down menu I only see my MFA profile as an option. So I don't know how these bots are able to access the WEBVPNGroup and try authenticating against the LOCAL user database. Those failed login numbers are still incrementing so they are still hitting it as of now. Question is how and where.

[tvotna]

@Scryden2, you're frightening us. We don't see your entire config, so everything is possible, but from the description of the problem it appears that CVE-2023-20269 wasn't fixed properly by Cisco, so I'd recommend opening a TAC case. I guess that in the vulnerability fix Cisco blocked client/clientless WebVPN access to hidden DefaultADMINGroup and DefaultL2LGroup, but they didn't change the protocol itself and it still allows spoofing of tunnel-group in the Aggregate Authentication Protocol. This means that you can connect to tunnel-group A (e.g. if you know group-url), but authenticate to tunnel-group B, e.g. DefaultWEBVPNGroup. In this case it doesn't matter that you restricted "vpn-tunnel-protocol" to IKEv1 or L2TP in the "tunnel-group DefaultWEBVPNGroup".

Below is what we use:

tunnel-group {DefaultWEBVPNGroup | DefaultRAGroup} webvpn-attributes
 authentication certificate

group-policy DfltGrpPolicy attributes
 vpn-simultaneous-logins 0
 vpn-tunnel-protocol ikev1

group-policy <others> attributes
 vpn-simultaneous-logins <n>
 vpn-tunnel-protocol ssl-client

keepout "Not allowed"

"Authentication certificate" should protect you from password guessing attacks. Please try this out and let us know.

[Scryden2]

@tvotna I have configured authentication certificate on those 2 tunnel groups and see how it goes. What exactly does this command do? I understand it changes it from password to certificate based authentication but how would a client obtain a certificate to successfully login? Just want to make sure an attacker can't simply generate a certificate and use that to login. I've never used this feature before so I'm not sure if I would have to manually authorize certificates in the firewall that are accepted for logins.

[tvotna]

@Scryden2, in order for the client to be able to login with certificate your ASA needs to have a trustpoint configured, the trustpoint must have a CA certificate and the client must somehow get a certificate signed by this CA. This is not possible if you don't have trustpoints at all or only have trustpoints with a self-signed ASA certificate for ASDM access. This is also unlikely if you have private CA and strictly control to whom this CA issues certificates.

You can check what you have with:

show crypto ca trustpoint
show crypto ca cert

[Scryden2]

@tvotna I do have a third-party certificate installed on the Anyconnect VPN in ASDM_TrustPoint1. I censored the names in them below:

# show crypto ca trustpoints

Trustpoint ASDM_TrustPoint0:
Configured for self-signed certificate generation.

Trustpoint ASDM_TrustPoint1:
Not authenticated.

FW01# show cry ca cert
Certificate
Status: Available
Certificate Serial Number: 7ce1d0f1c1b7e7dad2630caa2f37d0c5
Certificate Usage: General Purpose
Public Key Type: RSA (4096 bits)
Signature Algorithm: SHA256 with RSA Encryption
Issuer Name:
cn=Sectigo RSA Domain Validation Secure Server CA
o=Sectigo Limited
l=Salford
st=Greater Manchester
c=GB
Subject Name:
cn=vpn.company.com
Validity Date:
start date: 17:00:00 MST Dec 7 2023
end date: 16:59:59 MST Dec 8 2024
Storage: config
Associated Trustpoints: ASDM_TrustPoint1

Certificate
Status: Available
Certificate Serial Number: ae986d5c
Certificate Usage: General Purpose
Public Key Type: RSA (2048 bits)
Signature Algorithm: SHA1 with RSA Encryption
Issuer Name:
hostname=FW01.domain.local
cn=FW01
Subject Name:
hostname=FW01.domain.local
cn=FW01
Validity Date:
start date: 11:29:01 MST Feb 20 2019
end date: 11:29:01 MST Feb 17 2029
Storage: config
Associated Trustpoints: ASDM_TrustPoint0

If all of this looks good then I'll leave the authentication on certificate.

[tvotna]

@Scryden2, ASDM_TrustPoint1 doesn't have CA certificate installed, so configuration is ok.

Should it have a CA certificate you'd need to configure "no validation-usage" in the trustpoint to be on the safe side. This way it wouldn't be used to validate client certificates, but ASA would still be able to use it to represent itself to the outside world. (Might be unnecessary due to "vpn-simultaneous-logins 0", but this vulnerability add so much complexity and so poorly documented that who knows...).

[Scryden2]

@tvotna Gotcha. Thanks a lot! To confirm, I no longer see authentication rejects on the LOCAL database, so that all seems to work. I was just worried if the "authentication certificate" would open up other security holes. But yes like you said, its not a CA certificate. Its just a regular third-party one I use so end-users are not presented with a certificate security warning when they connect to Anyconnect.