For many of us that conduct penetration testing for clients, we discover bugs on a regular basis. Sometimes they are just quirky things that produce interesting output that, may or may not, be the intended function of the developers.

During a recent client engagement, I ran into such an issue with a Cisco ASA device. Most of the time, testing firewalls is a pretty mundane task, but you still follow your testing methodology. From time to time, it pays off for the good guys.

To me, being a penetration tester isn’t just about popping boxes and owning the network. While this is REALLY fun, there is a lot of critical thinking that goes into your daily work. Being able to think “outside-of-the-box” will get you a lot further.

There are tons of products on the market, both free and commercial, that help testers every day. While automation helps a great deal and helps reduce the amount of time you dedicate to an engagement, it only catches the known issues. This could be from a rule or signature incorporated within the tool. If whatever it is that you are testing is properly updated, most likely it has received something to prevent the attack you are trying to discover. The best way to find the unknown is by manually testing your devices and applications utilizing a solid methodology process..

Discovering the Cisco ASA Critical Denial of Service Bug

While going through my manual testing process, I began looking at all the pages the application reported back to me. To start out, I usually open the links, see what they are and monitor the responses I receive. One particular link stuck out.

When I visited the link, I received the following error page.

It seemed benign at first glance, but I noticed the browser was still trying to load the page. Well not exactly… the address bar icons jumped between Stop and Reload. This wouldn’t stop unless you manually closed the tab that was opened. It appeared something was executing on the back end to establish a connection. All this while I was unauthenticated.

When the link was loaded into any browser, it was observed that a connection was established and tore down. It seemed like that is what it should do, but not infinitely, however. The best way to describe the connection is like an infinite loop scenario within an application.

When more tabs were opened in the browser to the same location, utilization of CPU and RAM on the ASA began to increase significantly (4 open tabs from two IP addresses increased utilization from 9% to 27%+ in a 1-minute timeframe) and continued to grow on its own. Now, that is a big increase for two hosts!

Connection count rose in upwards of 200+ connections by itself, and tear down times began to increase from 1 second to, in some observations, over 30 seconds. The ASA was struggling from this simple test in one minute.

The size of the packet began to increase as well, even though no manipulation was done. The connection had to be forcibly closed in the browser by either closing the tab or by stopping the loading of the page, otherwise it would continue to make the request. Looks like DoS to me.

Since this was a client’s production system, I didn’t want to really do much more testing at this point and inadvertently bring it down.

Disclosing the Issue to Cisco

I began the disclosure process with Cisco’s PSIRT team at the beginning of May 2018. All the findings we had collected at this point were disclosed to them for further testing. An immediate response was received. Within two days, Cisco confirmed the finding. In late August 2018, Cisco contacted me and informed me that they had an anticipated disclosure date for the beginning of October 2018. After some further testing on the Cisco side, the fix was not adequate, but on May 1, 2019 Cisco released an alert and software updates addressing the vulnerability. As of the time of this article, there is no workaround for this vulnerability.