ePMP private management interface accessible via public IP

Products ePMP
1

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
2

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.

3

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.

4

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

5

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
6

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

7

After years of wanting to know why I could not forward a port for the customers if the “Separate” management interface using an ENTIRELY DIFFERENT SUBNET (a 10.#.#.#) happened to be using the same port. I guess it’s because apparently ePMP doesn’t really mean “Separate” when they say “Separate”. Kind of like how forever when ePMP said Fire “Wall” they meant Fire “Colander” .

Until not long ago you couldn’t forward port 22 because ePMP “separate” management interface used port 22.

With only a couple of exceptions every single customer radio on our network is set as NAT / PPPoE and does NAT/DHCP to the customer with a “Separate” Management Interface / IP . So radio gets a public IP via PPPoE , then does NAT/DHCP on the 192.168.#.# to the customer and the “Separate” management interface is 10.10.#.# all radios 4.6.1

Scanned four /24 subnets so far and about a dozen radios so far that can be accessed/logged into using the public IP address… I’ve checked a few of them and so far all have the expected settings , nothing appears to have been changed and nothing in the settings is different from any of the other radios so no explanation for why these are accessible via the public interface/IP.

Luckily we do not use default passwords/strings but still… W T F ePMP !?

The ePMP interface is an absolute raging trash fire…

Edit:
So 17 radios so far who’s “separate” management interface can be access via the public Interface IP.

All but one are 5Ghz 1000 series radios running 4.6.1
One is a 2.4Ghz elevated Ubiquiti Nanostation running 3.5.6

Have more subnets to scan but for now a firewall rule will stop the outside world from touching any management ports. Firewall rule on our actual firewall not on the stupid ePMP radios where a firewall rule may or may not work as expected…

Anyone not sure how to track these down, you can download a program called Angry IP Scanner https://angryip.org/

By default it scans for ports 80, 443 and 8080 but you you use non-standard ports you can go to Tools > Preferences and the “Ports” tab and ad/remove whatever ports you want it to check.

Once it scans you can sort by the “Ports” column and if you highlight an IP and CTRL+2 will open the IP in a web browser (or right click and go to “Open” for other options).

EDIT: Warning! just in case anyone decides to make a firewall rule on the radios to prevent/control access to the management interface… I would test it on a bench radio first. I experimented with the firewall on an ePMP radio a while back, blocked access to port used by the management interface on the wireless interface and found I could not access the radio via the wireless nor lan interfaces. Had to default it to get back into it.

2 Likes
8

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
10

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
11

I’m seeing 2.4Ghz radios running v3.5.6 showing up in scans… so how long have they known this was a thing I wonder.

I guess we got lucky and only had a couple of dozen radios that had slipped through the cracks and were using standard ports and only a few that the installer account had not been disabled… I don’t know why that account is enabled by default in the first place.

2 Likes
12

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
13

Since the beginning we put a basic config on every new radio when it comes in (while doing the firmware updates on them) and I really don’t even remember / know what is or isn’t on/off by default these days. But the idea was to make sure these accounts/settings were what we wanted them to be from as default as we could make it.

The hole in my system however was not taking into account customer radios either defaulting on their own or being defaulted by a tech and then the tech changing only the settings required to get the radio connecting so someone at the office could log in and configure the rest. Only the person at the office either didn’t know, forgot, was in a hurry, etc, and did not disable / change those accounts/settings.

Isn’t MAC Telnet on by default also ? I seem to remember discovering that new feature after a firmware update and having to go through alllllll the radios one at a time to turn it off and then making new templates making sure it was turned off.

1 Like
14

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
15

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.

16

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…

17

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.

18

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.

19

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
20

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