There appears to be a bug on the UDM Pro that you can encounter while trying to update your WAN IP addresses. The error was similar to “Can’t change IP Address “PublicIP” used in Default Network”
It appears that the issue stems from the Internet Source IP being used in the LAN Network settings.
The way to work around this is to disable the Internet Source IP. However, this is greyed out which keeps us from making any changes. We can however use the Chrome Developer tools to get around this restriction.
Enable the Legacy Interface. UniFi Network Settings -> System -> Legacy Interface
Go to Settings -> Networks -> Edit (Select Default Network)
Open up the Dev tools with Ctrl + Shift + i and select Console
Paste the following in and hit enter
$$('[disabled]').forEach( a => a.disabled=false )
Enable Internet Source IP on UDM Pro
Find “Internet Source IP”, Disable and Save!
Swap back to the new user interface and go change the WAN IP address.
Included in the FAQ is a section on “How to Disable Wireless Security on airMAX AC Devices?”
The default security configuration for AC devices since firmware version 8.5.11 was changed to WPA2 AES with a pre-shared key 0000:0000.
Ubiquiti Default AC device WPA2 Preshared key
On Ubiquiti AC radios, you can not disable WPA 2 security through the web interface. This is not necessarily bad, however, what happens if you have a client that is reset and will only connect to the default ubnt SSID?
Fortunately there is a way to disable the WPA2 Preshared key.
Log into the device over ssh.
Run the following command to disable WPA2 in the config sed -i s/aaa.1.wpa.mode=2/aaa.1.wpa.mode=0/g /tmp/system.cfg
Save the config file with /usr/etc/rc.d/rc.softrestart save
Login to the client device and configure the SSID.
After you are done, you can click the enable button to re-enable Wireless Security.
Note: aaa.1.wpa.mode=2 doesn’t appear to be on all devices. If not, change “wpasupplicant.status=enabled” to “wpasupplicant.status=disabled”
Screenshot from UI help page on Wireless Security on airMAX AC devices
Getting around applications that strip directory traversal sequences
Using a null byte
Directory Traversal
What exactly is directory traversal anyway? Well, it is pretty much exactly what it sounds like. We traverse directories by manipulate the file path, for something like an image, to get something more valuable like the passwd file.
In it’s most basic form, we can add ../../../../../etc/passwd to a file path and instead of pulling an image, we get the passwd file.
For instance, if we load an image on a website, it’s file path on the server may be something like /var/www/html/image.png. If we right click on an image and open in a new tab and inspect the URL, we can see this path. “Note: Web servers have a root directory for all the website files. Generally web files’ root starts there not / root of the machine.”
Now if we remove image.png and replace it with ../ (../ on Linux/macOS or ..\ on Windows) we’ll go backwards one directory. String them together and we can go back to the root of the drive. Then we can add /etc/passwd (Or replace with whatever file we want) and load the contents of that file.
Most web applications should have some sort of protections in place to guard against directory traversal. Let’s go over a few ways to get around it.
URL Encoding
URL encoding sometimes can work and is simple to do. In Burp, select the file path, right click, Convert selection -> URL -> URL-encode all characters.
You can also try double encoding. Encode once, select the encoded text and encode again.
In the above screenshots, ../../etc/passwd becomes “%25%32%65%25%32%65%25%32%66%25%32%65%25%32%65%25%32%66%25%36%35%25%37%34%25%36%33%25%32%66%25%37%30%25%36%31%25%37%33%25%37%33%25%37%37%25%36%34”
Getting around applications that strip directory traversal sequences
Sometimes the web app can strip out text that it knows is directory traversal characters/sequences. For instance, it sees ../ in the requested url and just strips it out.
We can do something like the following sequence to get around it.
....//....//etc/passwd
That is 4 periods, followed by 2 slashes. What happens is the web app reads the URL, goes hey ../ is not allowed, bye bye! Removes the two instances of ../ and forwards the URL on. Which ends up being
../../etc/passwd
Which is just perfect for our use case.
Using a Null Byte
If the application is using the file extension to validate that an image or other file is loaded, instead of say passwd, we can try using a null byte. A null byte is used to terminate a string.
../../etc/passwd%00.png
What can end up happening is the web application sees the .png or .jpg at the end and goes “oh that is a valid extension, carry on” and then the system reads the line and sees the null byte and says “Oh null byte! end of file path, here is your file.”
Most of the heavy lifting is done by the ubntmod.sh script. All you need is the IP addresses for the access points. The script will figure out the connected devices, reboot them first, then reboot the AP.
Here is a quick run down of the steps we need to perform.
Create list of AP’s and put them into an ap.lst file
Install ubntmod.sh script
Configure usernames and passwords to use with ubntmod.sh
Setup crontab to automatically run
Create list of AP’s and put them into an ap.lst file
This is really as simple as creating the ap.lst file and filling it with the access point IP addresses. One per line. The script uses wstalist to discover connected devices.
nano ap.lst
Install ubntmod.sh script
Installing the script is really hard. 2 lines to get setup.
Setup usernames and passwords to use with ubntmod.shd
When you first run ubntmod.sh without the -y option, it should prompt you to setup usernames and passwords to use. After this is setup, the script automatically reads from the config file for future use.
You can manually modify the ubntmod.conf file update any usernames or passwords.
Note that the 192.168.1.2/32 is important. If you have multiple clients connected and one of them is setup with a /24 instead of a /32, it will cause issues. I think this is because WireGuard tries to route the whole /24 over that peer.
Also note that you can not use DHCP with WireGuard. Each client will have a static IP address assigned in the config. In this example, 192.168.1.2.
You should now be all set up and able to connect from your device.
Troubleshooting
Some issues you may run into.
Unable to have two devices connected at the same time.
First, you’ll need to have one Peer per Client connection. Either that, or do not connect at the same time.
Second, check and verify that each peer has the ClientIP/32 in the Allowed Address.
For example, if the WireGuard interface is using 192.168.1.0/24, and one of the peers has 192.168.1.4/24 in the Allowed Address option, then only one client will work. It appears that the MikroTik will attempt to route all 192.168.1.0/24 request to 192.168.1.4.
It can be common for older devices to throw errors like the following when trying to ssh into them.
Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
or
Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa
The issue is that your version of SSH does not support those older, and most likely insecure, Key Exchange and Host Key algorithms types. The errors do give us enough info to add the right options to connect to the device.
No Matching Key Exchange Method Found
For the “no matching key exchange method found.” we need to manually add the KexAlgorithms option. KexAlgorithms means Key Exchange Algorithm.
It looks like some 3D printers can not read GPT microSD cards. Or SD cards formatted as exFat. You can fix the problem by converting the SD card to MBR and create a FAT32 partition on it.
