ePMP private management interface accessible via public IP

There is an “undisclosed” vulnerability with ePMP radios. I was FURIOUS that cambium knew and didn’t privately contact the vendors to notify us. We caught it pretty quick but holding this zero day to their chest this long really ticks me off.

Not allowing us to disable SNMP write access has been one of my major concerns for a while.

This isn’t just “default accounts”. Don’t try and blame the users for this one. This is a big deal.

Having a NATTED radio accessible by its public IP to manage is unheard of. Why would you even have its management IP for in the first place?

Why was this “Patched” after 4.4.3?

2 Likes

Hi @Steven_Kenney,

do you have really seen any station that can be reachable for configuration via IP on NAT interface?
Do you have a stable reproduce of this issue? I’ve already heard about such issue. But the reproduce is random. Please PM me if you have some setup where can we observe it.

Im part of the team here at WaveDirect with @Steven_Kenney and after scanning a few subnets I’ve found at least 13sms, Im working through things with the Cambium Support Engineers.

To clarify: those SM’s are accessible trought their public IP? And they have a separate management vlan?

Yes each of them has a private 10. IP assigned for management and they are reachable over both the private and public IPs

1 Like

Wow, I just found three. Two of them have some port forwarding enabled (NOT port 80).
@aka

Maybe its just me but IMO, I don’t see how making the SM a router on a public network is a good idea. Again, maybe thats just me.

1 Like

Depends. Home routers are practically identical to most of these radios in terms of software. These tend to be a little more heavily loaded toward the wireless side but fundamentally the operating systems would be similar. (Variation on some Linux operating system). There obviously will be a lot of proprietary functionality.

Taking that into account, when radios started to become capable of being run with NAT we tested them extensively for security. We found they operated much like a home router with “Remote Management” disabled. They were not accessible via the internet.

After giving it a try for years Cambium was pretty rock solid. When ePMP came along we did similar testing and found it just as good. Though clearly less effort was put into it than the FSK’s and 450 operating systems.

It was our fault assuming that ePMP was completely secure and not testing each firmware release before deploying them to our network. So we do take responsibility for not catching their mistakes. It is our job to protect our network. Bugs happen and we need to work as a team with our manufacturer.

I was just highly upset because we found out Cambium KNEW about this exploit and didn’t send word out or release private communication to the WISPS to patch.

I was doing some security audits trying to find the source/method of the vulnerability when I discovered some radios were accessible by public IP. We’ve since patched many of them. But I ran tests again several thousand radios so I’ll need to do another batch to see if I can find one that is “still open” and Branden will let Cambium know in private.

2 Likes

Hopefully this leads to a security review on software and defaults.I’m hoping to see an soft account lock function that we also now see on even the most basic of netgears these days.
When I saw those default accounts in the lab way back I could see the train wreck coming a mile away.

1 Like

we use cnMaestro to upgrade and push our default config to newly onboarded radios.
If a tech needs to just get a radio back on from a factory default, he just needs to get eap-ttls back working and the radius server sends the configs via AVpairs.

I wish Cambium would give us a method for the radios to request their config file from tftp and check that the config matches or update the local config with the downloaded copy. Like Voip phone stations do.

1 Like

Another issue I find with the radios is if you assign a private network and enable nat, that the private ip’s are exiting the nat natively.

For example to assign (172.16.1.x/24) for the radio LAN. Customer gets 172.16.1.2, and tries to go to google. I can watch through my upstream routers 172.16.1.2 trying to access public ip’s.

I’ve had many such instances of this and are a pain to track down. They don’t get routed out but I’m seeing the attempts.

disable upnp and LLDP on the SMs, these seem to cause customer network ips to be carried to the wisp side.
Also, I am sure your following best practices and have an outbound ACL that blocks RFC1918 addresses? Since we run a per tower router setup, we block these at the tower…

They are blocked. I can still detect them though. Yes we do not enable UPNP etc. These are actual private ip’s trying to contact public ip’s on the internet.

I realize that your clients internal IP addresses are trying to directly contact public IPs on the internet. These features cause IP leaking across nat:
uPNP
NAT PMP (PCP)
Spanning tree protocol
LLDP
These should be disabled unless you are specifically using them and on a client SM they should be disabled period.

This issue is more prevalent on e1k and force 200 series SMs but I have seen it on Force300 radios too.

Exactly. Those other functions are disabled. This has to be a NAT leak somehow. Yes it does seem to happen on the units with the lesser processors. Either way it needs to be fixed in software.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.