FMC/FTD WebVPN password spray?

[jbeach44]

We are, and have been seeing what I am interpreting as password spray attacks when viewing the VPN "Troubleshooting" logs within FMC. We do have webvpn enabled and are using DUO as MFA. We have configured only specific users within one AD group to be able to authenticate. I have tested this multiple times and accounts outside this group cannot get past the first level of AD auth. I have put in a few tickets with TAC and they are telling me this is a known issue and to use the "shun" command in the FTD CLI. To me, that's not acceptable. This is causing an occasional AD lockout of service accounts, which is extremely frustrating and confusing. How are the attackers able to bypass MFA and the AD Group that is allowed to authenticate in the first place? Here is an example of a log:

The 198.54 address is coming from Georgia and yeah I added it to our shun list, but this list is growing. I cannot keep up with it, there has to be a fix out there.

Is anyone else experiencing this?

This vulnerability is related but I don't think it is the same as what we are experiencing:

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ravpn-auth-8LyfCkeC

Anyways, we have applied the 7.2.5.1 hotfix and are still seeing it. 

Thanks

[tvotna]

This has been discussed few times:
https://community.cisco.com/t5/vpn/brute-force-attack-from-vpn/m-p/5037486#M294144
https://community.cisco.com/t5/network-security/block-access-to-remote-access-vpn-by-ip-address/m-p/5024025#M1109426

Probably you need to contact Cisco account managers, complain and show them above posts.

We have configured only specific users within one AD group to be able to authenticate. How are the attackers able to bypass MFA and the AD Group that is allowed to authenticate in the first place?

Is Duo capable of limiting authentication to certain specific AD groups/users or you restrict remote access in AD?

[MHM Cisco World]

I have see solution' but I forget to save it' anyway the solution was add acl control list and use public IP of country in acl' the IP for each country is known.

This prevent you from use shun for each IP try to get access via ftd.

If I found it I will share here for all need solution for this case.

MHM

[BlakeBratu]

We recently released a public document regarding the issue being faced and ways it can be mitigated at this time. Let me know if you have any questions or concerns regarding some of the other solutions offered: https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/221806-password-spray-attacks-impacting-custome.html

[tvotna]

@BlakeBratu, I have three questions.

1. Is PSIRT or BU going to publish another security advisory or a FN to confirm that ASA/FTD software is still vulnerable to password spray attacks despite CVE-2023-20269 fixes, and explain that the only way to fully mitigate such attacks on the firewall at this time is to use certificate authentication in at least default tunnel groups or better in all tunnel-groups.

2. Does BU have plans to fix Aggregate Authentication and disallow tunnel-group spoofing completely? E.g.

Received XML message below from the client
<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="auth-reply" aggregate-auth-version="2">
<version who="vpn">3.1.14018</version>
<device-id device-type="VMware, Inc. VMware Virtual Platform" platform-version="6.1.7601 Service Pack 1" unique-id="0BFAC8B855B2C9822DBFD6CDD69B0164DCAFAE4DA3922340BB42372332A54D5C">win</device-id>
<mac-address-list>
<mac-address>00-50-56-8d-f6-d0</mac-address></mac-address-list>
<session-token></session-token>
<session-id></session-id>
<opaque is-for="sg">

<tunnel-group>DefaultWEBVPNGroup</tunnel-group>
<config-hash>1509440110989</config-hash></opaque>
<auth>
<password>cisco</password>
<username>cisco</username></auth>
</config-auth>

3. Does BU have plans to implement control plane filtering on the firewall, most importantly TLS/JA3 filtering? I believe you already have code ready in EVE to calculate JA3 hashes.

[jbeach44]

So based on document posted by Cisco https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/221806-password-spray-attacks-impacting-custome.html 

I decided to create a sinkhole LDAP server and applied it to the DefaultWEBVPNGroup. That seemed to been a great workaround for us, though we are now seeing ldap sync errors (obviously since it is a fake server) but cannot figure out how to turn off automatic ldap sync for this identity source. Anyone know?

[Marvin Rhoads]

I don't believe there is a current capability to disable realm sync on a per-realm basis.

One other alternative suggested by some is to use a local realm as the identity source for DefaultWEBVPNGroup authentication.

[ltmartswlj]

What would be really nice is to have a way for the firewall to auto shun an address after so many failed attempts for a certain amount of time.  We are getting hit really hard by this and using a sink hole auth for the defaultwebvpngroup didn't do much for us.  Just getting a lot of lockouts on accounts, but ours are unique for VPN so at least not affecting internal systems.  May end up going to complicated user account names to mitigate that.

[jbeach44]

Actually what would be really nice is if CISCO FIXED THIS