Omada SDC - potential security issue

Omada SDC - potential security issue

Omada SDC - potential security issue
Omada SDC - potential security issue
2025-06-02 19:17:57 - last edited 2025-06-11 07:34:38
Hardware Version:
Firmware Version: 5.15.20.21

I am posting here because the issue appears to be with the SDC itself .... however, I would need to access my adopted / SDC managed SG2008 switch in stand-alone mode to know for certain.

 

Upon logging onto the SDC, in Global view, I can see my Omada devices and everything looks fine. However, when I change to Site view and look at my Omada devices there is a difference but only with my SG2008 switches device object while in Site view. In Site view, the SG2008 switches device object shows three icons on its extreme right. It's the third icon that I am taking issue with ... the icon looks like an "eye" and provides free and open access to the switches running config which for the most part is presented in plain text. To include MAC Addresses and object memberships but most alarming is the admin account of the SDC / Switch .... granted, the password is salted and hashed (thank god) but all of the other data seems a tad too "available" with no explicitly required security challenge to access. Couldn't this be locked down a little? Or, if you want to provide a semi-public icon for running configs without requiring explicit security maybe hash out some of the more sensitive details when accessed without a security challenge. And if the hashed information is of interest, perhaps satisfying a secuirty challenge could then optionally provide the unhashed version of potentially sensitive data. Really, just a PIN or password or something from the "sane and secure" side of the room .... anything but something. 

 

Again, for me, this only manifests while in Site view on the SDC, Global view does not present the third "running config" icon on the switches device object, just the first two icons.

 

Why does this matter? Afterall, I had to logon to the SDC itself and then drill into the Site view to see the icon. Someone could argue that the interface is secure enough ... I argue that in this regard it isn't.

 

Honestly, No. It really isn't .... and if that's going to be an opposing viewpoint, I can respect it but am still asking for some additional security concession for accessing the running config even if the concession were optional to implement.

 

Thanks

It doesn't really matter whether you think that you can or whether you think that you can't .... either way .... you're always going to be correct.
  0      
  0      
#1
Options
1 Accepted Solution
Re:Omada SDC - potential security issue-Solution
2025-06-06 08:13:54 - last edited 2025-06-11 07:34:38

  @Net-Moose 

 

But the switch isnt exposing its "running config" to anything other than the super-admin account of the controller.  If you disable site SSH, nobody can leven attempt to og into the switch to see its config.  Even more, if you add a port 22 switch ACL block to your management vlan range

Main: ER8411 x1, SG3428X x1, SG3452 x1, SG2428LP x1, SG3210 x1, SG2218P x1, SG2008P x3, ES208G x1, EAP650 x6 Remote: ER7206 v2 x1, ER605 v2 x3, SG2008P x2, EAP650 x2, ES205G x1 Controller: OC300
Recommended Solution
  0  
  0  
#7
Options
6 Reply
Re:Omada SDC - potential security issue
2025-06-03 04:05:22

  @Net-Moose 

 

is it show running config you are thinking of? if you are an administrator then you should almost be able to see the configuration, don't you think, the information is the same as if you use putty and SSH to the switch. also the password is encrypted so you don't see the real password.

 

  0  
  0  
#2
Options
Re:Omada SDC - potential security issue
2025-06-03 07:40:10 - last edited 2025-06-03 07:40:42

  @Net-Moose 

 

I dont see any issue here

 

A controller administrator and super-admin/owner account should have full access to everything, and they do.  Having a obscured password shown in a switch running config is a non-issue, since a controller user of this level already has access to view and edit the site device username and password anyway, and the ability to enable or disable SSH for the site.  So at this point, what is shown in the switch running config is a moot point.

 

I just tested another account i set up as just a "viewer" level access.  No access to device username/password and no access to see running config.

 

Frankly, if someone has gained administrator level access to your controller you have bigger problems than a switch running config.

Main: ER8411 x1, SG3428X x1, SG3452 x1, SG2428LP x1, SG3210 x1, SG2218P x1, SG2008P x3, ES208G x1, EAP650 x6 Remote: ER7206 v2 x1, ER605 v2 x3, SG2008P x2, EAP650 x2, ES205G x1 Controller: OC300
  0  
  0  
#3
Options
Re:Omada SDC - potential security issue
2025-06-03 07:50:07

Hi  @Net-Moose 

 

Thanks for posting here.

The client's MAC address and other information you mentioned can also be easily retrieved from other interfaces in the controller (without requiring additional passwords).

This button allows administrators to quickly access details about the switch and its connected clients, which many find user-friendly and helpful.

May I ask which specific information you believe should not be displayed here?

  0  
  0  
#4
Options
Re:Omada SDC - potential security issue
2025-06-06 00:45:39 - last edited 2025-06-06 00:54:16

  @Net-Moose Ok I see. Well just humor me if you will ...

 

Let me pose this scenario ... 

 

You are an administrator of a network but under constant attack by a nearby known hacker. You have reported them and their activity to the FBI Cybercrimes division via their complaint system twice, you have filed police reports, and even filed a complaint with the FCC for their radios being run at power levels which FAR exceed allowed limits. A month later the attacks have only increased in aggressiveness and frequency and NONE of your reporting has yielded so much as an email reply to say nothing of an actual physical investigation or response. In essence you might as well have written your complaints on some toilet paper, and flushed them all down the toilet. So what do you do?

 

Apart from constructing a faraday cage to enclose your entire footprint or something else equally unrealistic that is ...

 

Exactly ....  Now, your switches are constantly having their ARP caches poisoned, your wireless connected devices nearest the attacker are under constant siege with ceaseless deauth attacks and there is at least one confirmed Pumpkin router blasting out your networks BSSID as if it were your EAP just to gain access to your network but evidence suggests there must be more than one intermittently detected. This alone has you rocking youre EAPs power on all bands at 100% power along with reducing the allowed db for client connections just to try and keep the hacker off of your networks.... however, this is causing your network to become visible over a much larger area than you need to cover your footprint. This exposes you to additional attackers, war drivers, and the like who believe you me will and do take every opportunity to have at your networks security.

 

If you are like me, and be thankful that you are not, you probably would go to 802.1x EAP-TLS with Radius .... the controller has some radius capabilities, though not enough to do all of that. You will need to stand up a Radius server or pay for a service to get it done .... best of luck doing that unless you have experience with successfully implementing RADIUS ... the documentation on how to get one working properly ARE SCANT ... and for the most part completely useless as they are largely out of date referencing deprecated versions and old methods to the point you will start to show signs of baldness from the amount of hair pulling you'll likely have sustained in the process of self learning. If not, then congratulations for being MUCH smarter and knowledgeable than me. That still does not change the fact that this scenario is a reality for some.

 

Now pile on the constant spoofing of learned mac addresses because your network is so loud, an orbiting space station could probably connect ... regardless of MAC-IP bindings, MAC Filtering and ACLs all of which are configured and in use ... and yet, you constantly find your wireless devices showing up as WIRED devices connected to your Gateway and not WIRELESS devices connecting via your EAP like they should be. It goes on and on and on .... 

 

Consider all of this ... and then tell me that an open running config on your switch for anyone to see without a separate security challenge is a good idea.

 

Not every scenario is "Best Case" and not every person on this planet is a decent human being... and as it turns out, more often than not for some people, the exact opposite is the reality, whether they choose to see and acknowledge it or not.

It doesn't really matter whether you think that you can or whether you think that you can't .... either way .... you're always going to be correct.
  0  
  0  
#5
Options
Re:Omada SDC - potential security issue
2025-06-06 00:57:19

  @Net-Moose 

 

On second thought, nevermind. I thought maybe I could articulate a reason for something that would benefit what is likely a small sampling of the larger customer base and therefore not important. Kindly disregard.

 

I'll look elsewhere for a solution that meets my needs.

It doesn't really matter whether you think that you can or whether you think that you can't .... either way .... you're always going to be correct.
  0  
  0  
#6
Options
Re:Omada SDC - potential security issue-Solution
2025-06-06 08:13:54 - last edited 2025-06-11 07:34:38

  @Net-Moose 

 

But the switch isnt exposing its "running config" to anything other than the super-admin account of the controller.  If you disable site SSH, nobody can leven attempt to og into the switch to see its config.  Even more, if you add a port 22 switch ACL block to your management vlan range

Main: ER8411 x1, SG3428X x1, SG3452 x1, SG2428LP x1, SG3210 x1, SG2218P x1, SG2008P x3, ES208G x1, EAP650 x6 Remote: ER7206 v2 x1, ER605 v2 x3, SG2008P x2, EAP650 x2, ES205G x1 Controller: OC300
Recommended Solution
  0  
  0  
#7
Options