The mystery of the lost Motorola controller password

Introduction

In this article, i will describe the way I managed to get back access to a WLAN Motorola controller whose password has been lost for two years. I am only sharing this because this story contains tips and tricks that might interest you in case you are dealing with a similar situation.

The network device in question was a RFS-6010-1000-WR wireless controller from Motorola, I asked around to former colleagues that were there when it was setup 8 years ago, some of them gave me a bunch of local accounts passwords to try, others told me that it is actually using radius to authenticate over ssh. None of the passwords I tried worked and neither did my own Active Directory account.

Local or Radius ?

The first interesting question was if the authentication is based on a local account setup within the Motorola controller or if it is using Radius/Tacacs authentication. That is not always obvious but in my case, I got lucky.

I noticed that every time I entered a password, it would take around 10 seconds before the device claims that the password I entered was incorrect. This is not something that would happen with a local account, this was more like the controller tried to reach a radius server but timed out after some time and gave up.

The radius server on site

After asking around to the local IT team, a radius server on site was identified, let’s call it VM_RADIUS_01 and pretend its IP address is 192.168.3.39.

I logged into that Windows server VM hosting a NPS Radius, and checked if the Motorola controller was part of the Radius clients. It was !

I then tried to login to the motorola again using ssh and then checked the Radius Events Viewer… But nothing related to my connection attempt ever appeared. While the Event Viewer contained logs from the Motorola controller, they were only related to clients authenticating on the Motorola WLAN Access point and definitely not on users trying to login on the Motorola SSH Management service. Back to square one.

Capturing traffic on the Cisco switch

At that point, i was convinced that a radius server was used, but I did not know which one. Here is a network map containing the information I had back then, I will update it multiple times later on this article.

blog_motorola_1

You probably guessed it, the next step if to capture traffic between the switch and the Motorola WLAN Controller, since the switch is a C9300-48P from Cisco, it was really easy to setup a capture remotely :

SWITCH_10# monitor capture apm interface GigabitEthernet1/0/28 BOTH
SWITCH_10# monitor capture apm match any
SWITCH_10# monitor capture apm buffer size 100
SWITCH_10# monitor capture apm limit pps 1000
SWITCH_10# 
SWITCH_10# monitor capture apm start

I then tried to login to the Motorola controller over SSH again, then stopped and exported the capture right away to a SFTP server outside the site, where i would be able to retrieve the file on my laptop and inspect it with Wireshark.

SWITCH_10# monitor capture apm export location flash:/apm.pcap
Export Started Successfully
SWITCH_10# 
SWITCH_10# copy flash:/apm.pcap scp://193.168.101.202
Address or name of remote host [193.168.101.202]?
Destination username [admin]? fabien
Destination filename [apm.pcap]?
Writing apm.pcap
Password:
 Sink: C0644 779836 apm.pcap
!!!!
779836 bytes copied in 3.771 secs (206798 bytes/sec)
SWITCH_10#

Wireshark analysis

I am going to jump right in, this is what Wireshark displayed:

blog_motorola_2_wshark

Two things are important to notice:

We have a new unknown device (192.168.10.84) that appears to be the radius server that the Motorola controller is trying to reach. This device is outside the site.
This device (192.168.10.84) is sending back ICMP packets, which means the service udp/1812 (usually a radius service) is not running on this device

You can also notice the 5 seconds delay between two attempts, that is explaining the 10 seconds delay I experienced while trying to login over SSH.

Investigating on 192.168.10.84

blog_motorola_3

This investigation lead to absolutely nothing, after a couple of minutes trying to login with all the passwords I was able to think of, I was really disappointed seeing I just logged in to a very old Aruba650 mobility controller running a firmware from 2010 and rebooting every two years because of a memory leak. This device is abandoned and not managed anymore by anyone.

I checked if this Aruba controller would be actually able to be a radius server and if so, how can I restored this service, but to no avail. If think whoever set this device as the radius server for the Motorola controller did a mistake, or may be I missed the point.

No matter what, it was a dead end and it was time for another strategy.

Mounting a fake radius server

Now it was time for action, but with minimal configuration changes on the network/system infrastructure to avoid messing with the production.

The idea was to use an OpenBSD VM on site to create a rogue radius server and force the Motorola controller to reach it instead of the actual IP address.

Redirecting the Motorola controller request

That part was not hard. Only a more accurate route (higher netmask) than the default route to setup on the coreswitch :

CORESWITCH# ip route 192.168.10.84 255.255.255.255 192.168.12.179

And then assigning the IP address 192.168.10.84 to one of the interface of the OpenBSD VM:

OpenBSD$ doas ifconfig vic0 inet 192.168.10.84/25
OpenBSD$ 
OpenBSD$ ifconfig
[...]
vic0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
[...]
        inet 192.168.10.84 netmask 0xffffff80 broadcast 192.168.10.127
[...]

vlan80: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
[...]
        inet 192.168.12.179 netmask 0xfffffff0 broadcast 192.168.12.1
[...]
OpenBSD$

No need for NAT (yet) !

Mounting a radius server on OpenBSD

I was about the download freeradius when I remembered that OpenBSD comes with a very simple radius server called “radiusd”. And when I say really simple, I really mean it, see for yourself, this is all the configuration the server required to run a radius service that will authenticate based on the user “fabien” defined as user of the OpenBSD vm:

OpenBSD$ doas cat /etc/radiusd.conf

listen on 0.0.0.0

client 192.168.2.103/32 {
        secret "########"
        msgauth-required no
}

module load bsdauth "/usr/libexec/radiusd/radiusd_bsdauth"

authenticate fabien {
        authenticate-by bsdauth
}

You might be wondering how did i got the radius pre-shared key, since I had no access to the Motorola controller configuration. Well I got really lucky on that one, I went back on the radius server on site (VM_RADIUS_01) and whoever configured the Motorola controller as client on that NPS server, saved the PSK template by naming it…

… With the actual key content. ¯\(ツ)/¯

Quick tip: If you wonder if the PSK you found is the right one and you have a capture file of the radius communication (you need both the radius request AND the reply), you can use Wireshark to verify it.

By default, the “Authenticator” field is not checked by Wireshark. You need to enable it from the Radius protocol preferences:

Edit > Peferences… > Protocols > Radius

blog_motorola_8_ws_protocol_radius

Anyway, it was time to test.

Almost there, but with read-only privilege

As a reminder, this was the situation:

The radiusd authentication went just fine

OpenBSD# radiusd -d
2024-05-23 23:55:10:DEBUG: Loaded module `bsdauth' successfully.  pid=87272
2024-05-23 23:55:10:INFO: Start listening on 0.0.0.0:1812/udp
2024-05-23 23:55:10:DEBUG: Module `bsdauth' started successfully

2024-05-23 23:55:33:INFO: Received Access-Request(code=1) from 192.168.2.103:32893 id=8 username=fabien q=1: `bsdauth' authentication is starting
2024-05-23 23:55:33:INFO: Sending Access-Accept(code=2) to 192.168.2.103:32893 id=8 q=1

And I had access over ssh to the motorola WiFi controller, but something was off… I was unable to configure anything and I eventually realized that I was logged in with a role allowing only read privileges.

MotorolaWLC>show sessions
INDEX   COOKIE  NAME            START TIME              FROM                  ROLE
1       6       snmp            2023-04-16 00:38:29     127.0.0.1             superuser
2       7       snmp2           2023-04-16 00:38:29     127.0.0.1             superuser
3       313     fabien          2023-12-29 14:01:06     192.168.12.179       monitor

On the road to full privilege

I made the assumption that the radius reply must contain a special strings as Vendor-Specific Attributes (VSA). Like when you want to authenticate a user on a Cisco device using radius, you have to return “shell:priv-lvl=15” as VSA on the radius reply. Otherwise the user will not have full privilege.

I found the reference guide of the model of this WLAN motorola controller and the VSA to send were specified.

blog_motorola_5b_doc

Unfortunatly, radiusd is not able to send such VSA messages, so I had to find another radius service that can. I thought of freeradius first, but then I remembered that I had a Windows NPS radius server at my disposal (VM_RADIUS_01) that fully support that VSA feature. The only minor downside being that this server was (and still is) in production…

blog_motorola_7_NPS

So the last problem to solve, was to trick the Motorola into sending the radius request to that VM_RADIUS_01 server instead. While I probably could have added an interface with the IP address 192.168.10.84 the way I did on the OpenBSD server, I wanted to avoid modifying production servers too much.

So the other idea, was to use a Destination NAT on the OpenBSD VM, to replace the destination of the radius request packet from 192.168.10.84 to 10.69.53.39. That would give us that:

blog_motorola_5_vsa

Here is the PF firewall configuration to achieve this:

#Motorola radius DNAT
pass in on vlan80 inet from 192.168.2.103 to 192.168.10.84 rdr-to 192.168.3.39

And you can find below a tcpdump capture on the OpenBSD VM when the DNAT happened.

OpenBSD$ doas tcpdump -nn -i vlan80 port 1812

tcpdump: listening on vlan80, link-type EN10MB

23:35:49.353006 192.168.2.103.32893 > 192.168.10.84.1812: Axs? id:5 [129] Name = u123456, Caller = 5C-0E-8X-XX-XX-X7, NAS-Pt = 0, 61, F-MTU = 1400, USvc = Framed, [|radius] (DF) [tos 0xb8]

23:35:49.353060 192.168.2.103.32893 > 192.168.3.39: Axs? id:5 [129] Name = u123456, Caller = 5C-0E-8X-XX-XX-X7, NAS-Pt = 0, 61, F-MTU = 1400, USvc = Framed, [|radius] (DF) [tos 0xb8]

If you are wondering how the obvious asymmetrical routing is not preventing the OpenBSD VM to accept all the packets, the reason is that this VM was designed to work more like a router than a firewall (all traffic was allowed to be forwarded, no block rule).

At the end, i gained full access to the Motorola WLAN controller, and I was able to modify the configuration.

FRAMDMCT003#show sessions
INDEX   COOKIE  NAME            START TIME              FROM                  ROLE
1       6       snmp            2023-04-16 00:38:29     127.0.0.1             superuser
2       7       snmp2           2023-04-16 00:38:29     127.0.0.1             superuser
3       315     fabien        2023-12-29 15:24:50     192.168.12.179       superuser

Conclusion

Not much to say, it was actually fun to do and very rewarding.

To those who might ask why I did not use the existing firewall to do the DNAT instead of the OpenBSD VM, please remember that one of the objective was to modify as few network devices in production as possible. The firewall was used in production while the OpenBSD VM was not.

But yes, that would have worked as well.

Thanks a lot to Maxime and Craig for the proofreading :)