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.
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:
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
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
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.
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…
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:
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 :)