New AnycConnect Vulnerability

[Otanx]

See below. Basically if you have both Auto Update, and Enable Scripting turned on in your anyconnect profiles someone can get code execution on the client. By default auto update is enabled, scripting is disabled. No patch released yet.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-anyconnect-ipc-KfQO9QhK

-Otanx

[deanwebb]

Well, at least the default install is OK.

[Dieselboy]

Note: To successfully exploit this vulnerability, an attacker would need all of the following:

Valid user credentials on the system on which the AnyConnect client is being run by the targeted user.
To be able to log in to that system while the targeted user either has an active AnyConnect session established or establishes a new AnyConnect session.
To be able to execute code on that system.

The one that gets me is "To be able to execute code on that system.". I think powershell remoting is covered by this. Given my recent research on windows 10 builds the reddit community love this as well as pdq software which can also remotely install software. So I anticipate a high impact with this one.

Powrshell remoting starts a service on the endpoint and creates a listener / socket. It also edits the firewall rules to allow this to be contacted. To be able to remotely install software any time, this service needs to be enabled and then not closed. I don't particularly like it or feel safe with this. 

[icecream-guy]

If people are running as regular local user account instead of administrator on their PC,  and password protecting local accounts ...
to exploit seem highly unlikely.  Those that run admin accounts with no password, they probable deserve what comes next.

Note: To successfully exploit this vulnerability, an attacker would need all of the following:

o Valid user credentials on the system on which the AnyConnect client is being run by the targeted user.

o To be able to log in to that system while the targeted user either has an active AnyConnect session established or establishes a new AnyConnect session.

o To be able to execute code on that system.

[Dieselboy]

If people are running as regular local user account instead of administrator on their PC,  and password protecting local accounts ...
to exploit seem highly unlikely.  Those that run admin accounts with no password, they probable deserve what comes next.

Note: To successfully exploit this vulnerability, an attacker would need all of the following:

o Valid user credentials on the system on which the AnyConnect client is being run by the targeted user.

o To be able to log in to that system while the targeted user either has an active AnyConnect session established or establishes a new AnyConnect session.

o To be able to execute code on that system.

Right now, we currently have users assigned local admin privilege so they can set up their dev environment. I will be working on this soon to reverse this and manage software for them but we're not there yet.

So here's my thoughts on this with regard to "To successfully exploit this vulnerability, an attacker would need all of the following:"

Valid user credentials on the system on which the AnyConnect client is being run by the targeted user.

This equates to any local admin configured and I mean either the logged in domain admin or a locally created admin account. Also domain admin that has never logged in before. OR a previously logged in and cached admin / domain admin account. The scope is pretty high with Windows. For example if a domain admin account had been used on the system previously, the password is cached. If later on, say 6 months later the account had been breached and the password updated on the server then it would still be possible to use the old and breached cached password on this system.

Regarding unix/mac, the scope is larger because it's a bit more tricky to cover off the above windows points using policy (like GPO). The devs here when using CentOS need user accounts created for services. Because they're admins they can do whatever they like and it becomes tricky from a security perspective.

So basically any account that will work is "valid user credentials" point so it's not that difficult to achieve this one - the scope is larger if the above points are not covered by GPO. To mitigate these I've enforced GPOs which do the following:
- only cache the most recent login (this means only the active user of the computer since we issue users laptops.
- locally created admin user has a password that is rotated by AD LAPS and it is very long and secure, also managed by GPO
- other GPOs implemented to prevent caching of account credentials in an insecure manner
- GPO to implement secure credential entry (I think this runs in a VM)

You can get the GPO details from here: https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-microsoft-windows-10-version-1909-workstations

To be able to log in to that system while the targeted user either has an active AnyConnect session established or establishes a new AnyConnect session.

OK so the scenario 1 is a user is working from home and is connected to the corp. network via anyconnect:
- computer will be reachable on the home network (unless tunnel-all is used with prevent local LAN access)
- computer will be reachable on the corp network also

scenario 2 is a user is working from a hotel and is connected to the corp. network via anyconnect:
- same as above but also accessible on the hotel network

I also have a GPO to prevents a laptop from establishing both LAN and WIFI connections simultaneously to help mitigate issues there. In some situations we cannot use tunnel-all. We have cloud-based webex calls/meetings so it can seriously impact calls if tunnel-all is used.

To be able to execute code on that system.

I think a better way to look at this one would be to understand when would it NOT be possible to execute code. If linux then all you need is a shell. Same in Windows really. At first I thought that this was some option that you needed to turn on in anyconnect but that's not the case.


Not having local admin is a huge security advantage.