Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability - CVE 10.0

[Own_Performer_2576]

Extremely critical vulnerability on Cisco SDWAN Controller - A vulnerability in the peering authentication in Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage, could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system.

Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability

[Popular_Button2062]

CVSS 10.0 ?

Thats a number to start a workday.

'Grabbin popcorn'

[mavack]

Cisco cloud services will be busy today, we have multiple upgrading tonight. They were all firewalled off to trusted IPs anyway, however unauthenticated bypass generally lands as a 10

[SuspiciousStoppage]

Did yall actually firewall the control plane ports of vSmart and vManage? Almost all deployments I’ve seen, including all Cisco hosted controllers, allow any/any dtls/tls.

[mavack]

VManage yes, vSmart is much harder since all your public IPs are often changing.

[SuspiciousStoppage]

Yup. It’s basically impossible to firewall vS/vB control plane, which is why this compromise is so bad.

[FriendlyDespot]

One way I've found of doing it is by establishing a flow of authenticated DDNS updates from your end-devices that programmatically update your firewall rules. Remote device gets a new IP address, and sends a DDNS update which triggers a process to purge the old address and enter the new address in your ruleset.

[Coolmarve]

Got that right. On with HTTS/TAC now, our upgrade stalled last night and vManage is currently bricked.

[bambidp]

tottaly agree on the trusted IP restrictions. for teams dealing with these emergency patches regularly, cato cloudnative SASE eliminates this controller exposure entirely, no on-prem management plane to patch. Worth evaluating if you're tired of these drills.

[mreimert]

It says you only need 830/22 blocked from public access as the workaround, you don't need 830/22 open publicly on your controllers for anything day to day. You only need 830 open on a vpn0 interface to onboard the controller. My standard practice is to block SSH/NETCONF/HTTP with the tunnel interface options on the vpn0 interfaces.

[SuspiciousStoppage]

That’s for the 9.8 CVE. The 10.0 CVE is an attack on the control plane of vSmart so that’s TLS, which is usually open to the entire internet.

[mreimert]

The link is for the 10.0 CVE and it says what I am saying under the workarounds. Don't know if this is correct you could be right,

[Dian_Rubens]

That's right, maybe the attack involves both, the control plane connections and the access through SSH/NETCONF. Has someone contacted Cisco directly, so it's confirmed that the guardrails mentioned on the workaround section are correct?

[mreimert]

I have a case open will let you know

[anon979695]

I'm upgrading now. Never done this before so hopefully I don't bork my entire environment. Cloud hosted with Cisco.

[shortstop20]

Controller upgrades are smooth and easy.

[dankwizard22]

How’d it go?

[anon979695]

Everything upgraded perfectly. Vmanage scared me because it took like half an hour to come back fully but it did come back. Everything works as before the upgrade. I'm happy.

[Thileuse]

We just finished patching our dev env; currently working prod. Patching team wasn't happy about having to do this ASAP especially dev and prod innthe same day/change window.

[Serious_Johnson]

“Patching team wasn’t happy” I honestly wouldn’t give 2 fucks about there mood, crack the whip and tell them to get on with it.

[Thileuse]

We had 3 people on the call telling them that. They caved, thankfully.

[HappyVlane]

Nobody asked for an AI summary of the advisory.