This will copy the backups into ./uisp-backups directory.
On an Ubuntu system, docker needs sudo permissions. If you copy the backups with the above command, the backup files will be assigned to the root user and you will not be able to use your normal user to manipulate the files.
Here are some links and notes on archiving a UniFi Protect’s footage.
Apparently, the .ubv files just need to be remuxed to .mp4 so they are easily playable. On the UniFi Protect appliances, they have a ubnt_ubvexport and ubnt_ubvinfo binary that can do the remux. You can copy the binary off and run it with QEMU on x86 hardware.
We can setup rsync to copy the raw footage off the Unifi Protect appliance. Once we have it locally, we can use the remux tool to convert the files to .mp4 so we can easily view them.
A cool thing about using rsync, is if our copy gets interrupted, we can just rerun the command and it will pick up where it left off without duplicating anything.
The following command is a mouthful. It searches for all the recorded video files for cameras with the MAC addresses specified. (MAC addresses can be found from the web interface), There are only a couple things to change or tweak for the command to work for you.
MAC1 should be the MAC address of camera 1 while MAC2 is the MAC address of the next camera we want to archive. Change the dst_directory to the archive directory or drive. And of course we need to change the IP address (10.0.0.1) to the UniFi Protect IP address.
Who is this mcuser on ubiquiti devices? Nothing shows up in the radio config file about it, but the user shows up in /etc/passwd
mcuser is used for AirControl2. If we look what is in the passwd file, we’ll notice that there is a ! at the beginning of the hash. Meaning that this password is disabled as the hash is not a proper hash. It’s only 10 characters long instead of the normal 13 for Unix DES hashes.
The username was the MAC address of the device and the password field is a DES(Unix) hash of what appears to be an 8 character randomly generated upper and lower case password.
Older AirOS versions only let a user select a password up to 8 characters long. You could create a longer one and log in via SSH, but you wouldn’t be able to log into the web interface.
So how did these get on here in the first place?
I am guessing that the users were created at some point while trying to adopt them to UNMS/UISP before there was firmware that supported it. The user name is the actual MAC address of the device and the passwords do seem to be randomly generated. There do not appear to be any major differences between the support files from a normal AirGateway and a suspicious AirGateway.
Also appears to only affects AirGateways which were the only devices that had issues in the past connecting to UNMS/UISP. The rest of the AirMax equipment uses very similar firmware so if there was a security issue, it should have affected all the devices.
The hashing type “DES(Unix)” does not appear to be used anymore, being replaced with MD5 Crypt. So this does appear to have happened awhile ago.
the -1?l?u let’s us specify a custom character list made up of -l and -u. Lower and Upper case letters. –session airgateway will record a checkpoint ever so often. So if our run gets interrupted, we can restore the session with
./hashcat.bin --session airgateway --restore
Fortunately, remediation is fairly simple.
SSH into the affected device and open up the config file
Find the lines that start with “users.3.”, delete them, and save the file
Run the following command to save the changes.
If you are not comfortable with the command line, then you can, through the web gui, download a backup, edit the backup file in a text editor, then upload/restore the backup.
Something else you may run across is a mcuser that shows up in /etc/passwd. This is typically a user used for AirControl, so if you have used AirControl in the past that is most likely why it is there. Check out the following article to remove the user.
Ubiquiti Airmax gear has tcpdump included. We can easily use it to capture packets to a file and then use SCP from the device to copy the file for analysis.
SSH to the device
Start tcpdump with the following command. Change ath0 and file.cap to the appropriate interface and file name.
tcpdump -i ath0 -w file.cap
After we are done collecting, we can quit with ctrl + c
Now we can use scp or sftp to copy the files off. There is an issue using scp or sftp from a normal Linux machine to the radio, fails with a “sh: /usr/libexec/sftp-server: not found”. It works fine if you initiate scp from the radio.