Why Your Firewall Will Kill You
The last few years have been great for attackers exploiting basic web application vulnerabilities. Usually, home and small business products from companies like Linksys, D-Link, and Ubiquity are known to be favorite targets. But over the last couple of years, enterprise products from companies like Ivanti, Fortigate, Sonicwall, and Citrix (among others) have become easy to exploit targets. The high value of the networks protected by these "solutions" has made them favorites for ransomware attackers.
For a long time, we maintained our "Survivaltime" graph. Not exactly my favorite piece of data, but it showed how, over the years, the average time between unsolicited packets hitting perimeter firewalls.
So let's look at the average "survival time" of an enterprise-grade firewall. As "survival time", I will define the time it takes for a scan attempting to probe the firewall. For example, for the PulseSecure/Ivanti products, I will use requests for URLs like "/dana-na/nc/nc_gina_ver.txt" and "/dana-cached/hc/HostCheckerInstaller.osx" as they are specific to these firewalls and can be used to identify vulnerable systems. For this test, I considered all URLs containing "/dana-" to target Ivanti. The survival time of an Ivanti instance is approximately one month.
For Fortigate, we can look at a similar pattern, "/remote," often associated with exploits for Fortigate vulnerabilities and scans to determine the firmware version running on a particular device. Our data suggests a similar one-month survival time.
Citrix is a bit more difficult to pinpoint. But many of the exploit and fingerprinting URLs used for Citrix contain "/vpn/". I see fewer of these scans, so you may have two months before your Citrix instance is targeted.
To compare, I also looked at URLs containing "luci." "Luci" is a popular open-source component found in many routers used by home networks. It is still much more popular, with a "survival time" of about a week.
So what does this mean?
1 - Assume compromise
These times are "upper limits". There are many less specific ways to find vulnerable devices. A simple scan of the index page often identifies the device and even the version number. Attackers will also create lists of possible targets before an exploit is released. These devices hide multiple critical vulnerabilities, and vendors do little but wait for third parties to report them. Any attacker interested in exploiting these devices knows that it is just a matter of time before a new exploit is released, and the race is on for the first one to be able to compromise the devices.
2 - Mitigation beats Patching
You will be unable to patch these devices before exploit attempts are launched. Your best bet is to reduce your attack surface. Remove devices as soon as they are no longer needed. Disable features that you do not need. Limit access to any features or admin consoles.
3 - Know normal
Find out what information the device logs provide, and establish a "baseline" to identify what is normal. How many connections per hour or day? Where do they come from? What features are used, and how will the use of these features be represented in the logs? Understand the log format and enable additional logging if needed.
4 - Your Security Tool Supply Chain
Some security tool vendors often advertise how they protect you from supply chain issues. But remember that they are just as much a part of your supply chain. Monitor your vendor's health. Watch out for acquisitions, layoffs, and changes in business focus. Replacing some of these devices is lengthy, and you must get ahead of it. Re-affirm the company's commitment to the products you rely on and track any "end of support" or "end of life" commitments.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments