How to Protect Against the Cable Haunt Vulnerability Using OPNsense

Is your modem vulnerable to Cable Haunt and your ISP has not provided a firmware update? Take matters into your own hands!

How to Protect Against the Cable Haunt Vulnerability Using OPNsense Photo by Cable Haunt from cablehaunt.com

Introduction

Cable Haunt is a recent vulnerability that has been found in over 200 million cable modems in Europe and likely many more in other countries as well. Many modern modems use similar Broadcom chipsets and used the same reference firmware which contained the vulnerability. Because of this, the impact of this vulnerability is much greater than it would have been otherwise. Software running in many (probably nearly all) consumer modems have not implemented best practices for security. I have wondered about the possibility of modem vulnerabilities after hearing about all of the router vulnerabilities. Since access is much more limited in modems than routers, it would very difficult to detect when your device is vulnerable and if it has been hacked.

The vulnerability exists with cable modems which have spectrum analyzers that are typically used for troubleshooting purposes. I knew cable modems usually have web pages which display various cable modem information, but I had no idea they also have a spectrum analyzer running on a different port number which can be accessed via a web browser. The flaw can only be executed from within your network but that can be easily done by getting a user to click on a malicious URL (such as a link in an email or an advertisement in the web browser). The attacker does not need to compromise a machine on your network in order to hack your modem since the attack can be executed through the web browser on any device on your network. That is the scary part. One must always be careful when clicking on random links because they could potentially be malicious.

What Can Be Done?

Unfortunately, your ISP has the exclusive right to update your modem – even if it is a customer owned modem. I believe the reasoning is that they only want approved firmware running on their networks. If that is the true reason (and not simply trying to push users to rent their modems), I can understand why they want that control. They certainly would not want malicious firmware or even terribly implemented firmware from running on their networks for security, reliability, and performance concerns. However, that removes control from the user to patch known vulnerabilities immediately after a new update has been released. The patch for Cable Haunt for some vendors were released in May 2019 but some ISPs are only recently updating the firmware in January 2020 due to increased press on this issue. Lack of ability to update your own firmware is one big reason why modem vulnerabilities are so bad. A device out of your control could be hacked and there is not much you can do besides request another non-vulnerable modem from the ISP or buying a non-vulnerable modem (which could eventually become vulnerable also). That, of course, is not a very practical or economical solution.

Do not worry! In this case, all is not lost!

Mitigating the Vulnerability

There is the possibility that your modem is not accessible from any device on your network and therefore protected from exploit depending on your network configuration. How might that be? The cable modem typically lives at 192.168.100.1 while most consumer routers use 192.168.0.1 or 192.168.1.1. If your router automatically blocks access to other networks such as 192.168.100.0/24, then you may already be protected from the vulnerability. However, I do not think that is the case with many consumer routers since they are designed for the average user to be easy to use with very few restrictions configured by default.

So what if you can access your modem’s spectrum analyzer at 192.168.100.1 on port 8080 (depending on the cable modem model)?

If you have a router that has the ability to add firewall rules such as OPNsense, you can simply block access to the cable modem’s spectrum analyzer port which hosts the web page that contains the Cable Haunt vulnerability! If you are really paranoid, you can block all access to the cable modem on all ports. This is the advantage of using more powerful router/firewall software since you have much greater control of the security of your network (not to mention more frequent software updates).

For the purpose of a simple illustration, I am going to assume that you are using the default configuration in OPNsense: one WAN interface, and one LAN interface with no VLANs assigned to the LAN or other interfaces (see note at the end of this how-to about VLANs). I am also assuming the default “allow all” rule is present on the LAN interface. In this scenario, you should have access to your cable modem’s web interface. To block access to the spectrum analyzer, go to the “Firewall > Rules > [LAN]” page and add the following rule:

Firewall Rule Block

Be sure to choose “Block”. Choose “LAN network” as the “Source” and for the “Destination” enter 192.168.100.1 (depending on your cable modem model). In order to add the specific port, you need to select “TCP/UDP” as the “Protocol”. Selecting only “TCP” may be sufficient, but it does not hurt to be more restrictive and block UDP as well. For “Destination port range”, enter 8080 (or other port such as 6080 depending on the model). You may also leave the port as “any” if you want to block all access to the modem’s web interfaces.

If you do not know the port number of the spectrum analyzer and there is nothing on the commonly used ports 8080 or 6080, you could try port scanning your cable modem. In Linux (Ubuntu in particular), you can install nmap using the following command and then you can run the nmap command:

sudo apt install nmap
sudo nmap 192.168.100.1

Starting Nmap 7.60 ( https://nmap.org ) at 2020-01-21 09:36 EST
Nmap scan report for 192.168.100.1
Host is up (0.0021s latency).
Not shown: 995 filtered ports
PORT     STATE  SERVICE
22/tcp   closed ssh
80/tcp   open   http
443/tcp  closed https
8080/tcp open   http-proxy
8443/tcp open   https-alt

Nmap done: 1 IP address (1 host up) scanned in 17.71 seconds

It will list the open ports on the cable modem. You can try accessing those ports in the web browser to find the spectrum analyzer. In my case, port 8080 has the spectrum analyzer.

After creating the rule, you will need to move the firewall rule above the “allow all” rule. New rules are added to the bottom of the list, but you will need to insert it above the “allow all” rule for the rule to be corrected applied. Rules are processed in order of the first matching rule so you should put the most restrictive rules higher up in the list. The order of the rules is very important! Once you have applied the new rule, try accessing the spectrum analyzer page to ensure that access has been blocked.

Another mitigation you could implement is to change the default password on your modem’s web interface if your modem has password protection and allows you to change it. My Netgear modem allows this and it prompts for the password when opening the main web interface as well as the spectrum analyzer. Changing the password will add one more layer of protection to your modem.

Congratulations, you should now be protected against the Cable Haunt vulnerability even if your ISP has not patched your modem!

Considerations for VLANs

If you have multiple networks (VLANs) in your network, you need to consider the access of each network. All it takes for a compromise to occur is the attacker discovering one open network which has access to the vulnerable device. Depending on how you have your firewalls configured, there a few ways you can keep all of your VLANs from accessing the vulnerable cable modem spectrum analyzer interface. I will describe two different methods of preventing access – one of which I personally use in my network.

Block Access to All Other Private Networks in Each Network

In my network, I took the basic approach below for creating firewall rules on several of my VLANs:

  1. Allow access to the VLAN interface IP (to prevent rule #3 from blocking access)
  2. Allow specific access to devices/services between VLANs (must be above rule #3)
  3. Block all private IP addresses (isolate all VLANs: current and newly created VLANs)
  4. Allow all other (allow all other traffic to the Internet)

This effectively isolates the VLANs from one another, allows specific exceptions to devices/services, and mitigates the cable modem vulnerability because rule #3 would block access to 192.168.100.1 since it is a private IP address that does not have a specific exception to allow access to the web interface. You could certainly add the exception if you so desire (but not to the spectrum analyzer unless you are sure you are patched!).

If you are using a similar approach for your firewall rules, it would be redundant to create a rule in each VLAN interface to block the IP of the cable modem as described in the basic LAN example above because rule #3 takes care of this issue.

For my VLANs that are more isolated, I am also protected because the access for those networks are more restrictive. As an example, my IP security camera network has something like the following:

  1. Allow access to DNS server on OPNsense (to resolve hostnames)
  2. Allow access to NTP server on OPNsense (for using NTP to automatically keep the clocks synchronized)

Because access is limited to two different ports/services hosted on my OPNsense router, no other network traffic is allowed to leave the IP camera network. This limited access also prevents accessing the vulnerable cable modem web interface.

Create a Floating Rule to Block All Access

Alternatively, you may simply create a floating rule which blocks access to your cable modem’s IP address. Floating rules are evaluated before the individual interface rules. What is nice about this approach is that you only need to create one rule to block access for all networks rather than creating one rule for each network.

One potential downside is that you have to update the rule whenever you create a new VLAN interface because the floating rule requires that you select the interfaces in which the floating rule applies.

Below are the example settings for a floating rule:

Floating Firewall Rule Block