https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-smi2
Check your gear and make sure this service is off or that you're blocking the hell out of TCP/4786.
BTW, the service is *on* by default. Just talked to some guys that were able to pop a switch with this vuln pretty easily.
:rage:
EDIT:
[vendor mode="on"]ForeScout has a security policy template that checks for this. If you're running ForeScout, get that SPT update and check your gear.[vendor mode="off"]
More information and source code are posted on the Embedi site. We're checking now with Cisco if "no vstack" counts as a valid workaround.
After some testing with our cyber guys the no vstack works. We also scanned for any open tcp/4786. Smart Install should have been off a long time ago because of this one - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170214-smi
-Otanx
Indeed, Cisco also confirmed it. They should at least mention it in the advisory nonetheless...
I will check on my homelab switch...
USDAL-3750e-CDA-01(config)#do sh vstack config
Role: Client
Vstack Director IP address: 0.0.0.0
*** Following configurations will be effective only on director ***
Vstack default management vlan: 1
Vstack management Vlans: none
USDAL-3750e-CDA-01(config)#do sh tcp br all | inc 4786
044300E0 *.4786 *.* LISTEN
Oh my... I need to turn that stuff off!
USDAL-3750e-CDA-01(config)#no vstack
% Incomplete command.
USDAL-3750e-CDA-01(config)#
/me then reads later in the tech note that not all switches support turning off vstack...
:rage:
If you have a Netflow monitor in place, check it for TCP 4786 traffic. You may have something evil inside your network... or something evil that found a way around the firewalls...
We set our IDS to alert to any TCP/4786 packet with a ACK flag set. This way I don't get alerts on scanning, but will get alerted if any of my gear responds.
-Otanx
New advisory is up.
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180409-smi
This one includes the 'no vstack' workaround, merely 14 days after the exploit was published.
There another critical one out yesterday, affects IOS and IOS/XE - QoS for DMVPN UDP port 18999
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-qos
Quote from: Otanx on April 12, 2018, 03:07:51 PM
We set our IDS to alert to any TCP/4786 packet with a ACK flag set. This way I don't get alerts on scanning, but will get alerted if any of my gear responds.
-Otanx
You'll want an alert if the scan is from outside your network, I can guarantee that.
Quote from: ristau5741 on April 13, 2018, 06:13:57 AM
There another critical one out yesterday, affects IOS and IOS/XE - QoS for DMVPN UDP port 18999
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-qos
So, add another line to that ACL that blocks 4786...
Quote from: deanwebb on April 13, 2018, 07:08:16 AM
Quote from: Otanx on April 12, 2018, 03:07:51 PM
We set our IDS to alert to any TCP/4786 packet with a ACK flag set. This way I don't get alerts on scanning, but will get alerted if any of my gear responds.
-Otanx
You'll want an alert if the scan is from outside your network, I can guarantee that.
I really don't care if the scan is from outside my network. I just checked our flow, and I have thousands of entries for TCP/4786 with one packet, and the SYN flag set. Those are just random attackers trying every IP to see what responds. If I respond to one of those attackers then I care. My response will have SYN and ACK flags set (normal TCP handshake), and my IDS will alert me.
Now for the UDP/18999 one I can't do that as there is no handshake. The Cisco alert makes it sound like it is a one packet attack. This means I can't tell if the attack is successful or not from monitoring the network. The only saving grace on that is it was found internally by Cisco so it isn't a 0 day. However, it will not take long for someone to figure it out from the details given so patch your gear, and double check you patched everything.
-Otanx
If the scan is from outside the network and hitting the firewall, I agree, meh.
If the scan is from outside the network and hitting internal hosts, that would warrant further serious investigation.