On October 31, 2018, Cisco released a security advisory for its ASA and Firepower threat defense software regarding a Denial of Service (DoS) vulnerability. The full security advisory can be found here. The summary (below) notes that the Session Initiation Protocol (SIP) inspection engine could allow a remote attacker to trigger high CPU usage resulting in a DoS condition.
A bug with no fix?
Even more unsettling, the advisory notes that there is no software update available for this vulnerability, nor are mitigation options available. That’s basically technical jargon for, “if you have Cisco firewalls, you could be screwed, and we can’t help you”.
Are you impacted? Are you particularly vulnerable to external traffic from potential attackers? How extensive is your vulnerability? How can you quickly identify all the affected devices and prioritize remediation based on where traffic could be coming from? How quickly can you test a possible fix and verify that it will work?
In this blog post, we’ll show a new way to answer all these questions and identify all points of vulnerability - in only minutes. We’ll employ Forward Enterprise, an intent-based verification platform that can quickly identify all paths through your enterprise network that conform to certain high-level criteria. It can also verify if proposed changes affect desired policies or address known issues (like outside traffic reaching Cisco firewalls using SIP protocol).
Where can the traffic go?
Let’s take a look at how you can check a network in Forward Enterprise. First, you might want to quickly query your network design to see which sections of the network are affected by Cisco ASA traffic. In our system, and as shown below, we would build a modular query that asks where any traffic using SIP protocol enters an ASA device:
The results of this query show the portion of the network where traffic can flow through a pair of Cisco ASA appliances, along with all edge destinations that can be reached. The unaffected portion of the network is shown in lighter gray. From this result, we know that the immediate problem is restricted to one data center only, and such traffic can’t reach the MPLS backbone or other sites. Reasonably good news at first glance.
Unfortunately, this portion of the network is behind an internet gateway. Our next issue is to determine if external traffic can reach our suspect devices and if so, how to design a fix. A slightly more specific query will ask if traffic from the internet gateway can reach any of our ASA appliances. Notice that we have essentially changed “from anywhere” in our query to “from atl-internet”, which is the name of our gateway.
The result now shows that, indeed, external traffic can reach one of the two ASA edge firewalls, and also reveals that external SIP protocol traffic will be dropped at that point. We know this because no paths are shown southbound from this device, as well as the dashboard showing that all paths result in drops. But knowing that all SIP traffic is dropped at the ASA device does not necessarily solve our problem. This is a DoS attack, which could take down the device and affect legitimate traffic from reaching destination servers.
Determining a fix...
Fortunately, we see an excellent solution from our Forward Enterprise analysis. We can reconfigure the atl-isp-edge01 router to block SIP traffic, since that is the only viable route to our vulnerable device. The firewall edge-fw02 is a back-up, currently unaffected for external traffic. Dropping SIP traffic at edge01 would be a priority to circumvent the DoS attack immediately, but the back-up firewall should be addressed as well for when it came online.
But, it gets better still. We could actually evaluate a potential configuration change in our system and verify that: 1) it prevents SIP traffic reaching the ASA appliances, and 2) no other policies would be violated as a result of this quick change. In fact, we can even ensure that if any future change breaks this policy, we’ll be notified immediately.
Forward Networks provides an ideal platform to quickly query and search large enterprise networks to view possible paths that conform to certain criteria or policies, such as in this scenario, going through any vulnerable Cisco ASA appliance. We provide a way to refine queries around specific policies or scenarios, such as isolating traffic from a particular source, like the external gateway. Or we can identify which applications and subnets could be subsequently affected. Finally, we have a way to quickly determine and prioritize points of remediation and verify how those changes would affect overall network policies.
Want to learn more? Contact us for a quick demo and we can show you how we can quickly determine your level of vulnerability to this new security advisory and a whole lot more! Or, check out some of our latest demo videos on our YouTube channel:
