Here is a list of common Multicast addresses.
| LLDP | 01:80:C2:00:00:0E | |
| CDP (Sends messages to) | 01:00:0C:CC:CC:CC | More info |
| OSPF – Neighbor Discovery (All Routers) | 224.0.0.5 | |
| OSPF – DR/BDR | 224.0.0.6 | More info |
| All IPv6 Devices | FF02::1 |
| All IPv6 Routers | FF02::2 |
| OSPF | FF02::5 |
| EIGRP | FF02::A |
| Router Solicitation? | FF01::1? |
These steps are for Windows, but they should be very similar on macOS or Linux.
Prerequisites
Apksigner is part of the Android build tools should be in the SDK directory.
%APPDATA%..\Local\Android\Sdk\build-tools\30.0.0
Lets open up a terminal and navigate to the build-tools. Replace 30.0.0 with the actual SDK version you have installed.
cd .\AppData\Local\Android\Sdk\build-tools\30.0.0
Alternatively use the full path (Replace username and 30.0.0 with actual username and SDK number)
cd C:\User\username\AppData\Local\Android\Sdk\build-tools\30.0.0\
We can now verify the Signal APK with the following. Replace username with your username.
.\apksigner.bat verify --print-certs C:\User\username\Downloads\Signal-Android-website-prod-universal-release-6.0.6.apk
Scroll up to the top part and look for the part that says
Signer #1 certificate SHA-256 digest:
Check the signature against the signature on Signal’s website/
https://signal.org/android/apk/
You may see a bunch of
WARNING: META-INF/xxx.version not protected by signature...
Sounds like this can be expected and is a common thing. The certificate is stored in META-INF which means that other files stored in META-INF are not protected. Most of the files in that directory are only version numbers of libraries the app depends on. There shouldn’t be anything important so shouldn’t be a security concern.
https://stackoverflow.com/questions/52122546/apk-metainfo-warning
Mark manages the Ubiquiti UniFi applications at Incredigeek Inc. and is unable to access the UniFi controller. It starts loading and then stops. The URL bar shows that it is trying to load a null network site.
Thankfully the WiFi is still working, Mark thinks to himself, but how am I supposed to manage the network? I am able to access the UniFi Core application, so maybe I can login using a secure shell and check on the application.
ssh root@192.168.1.1
Once logged in, and after using the google, he finds that unifi-os restart will restart the UniFi applications. But I just need to restart the Network application. Running “unifi-os” –help reveals the following options.
# unifi-os --help Usage: /usr/sbin/unifi-os [stop start restart shell 'update url']
Oh shell!
unifi-os shell
Alternatively, we know that on the UDM’s the UniFi Applications are run inside a Docker container. We could run “docker ps” to show the containers and then “docker exec -it unifi-os bash”
Now we can restart just the UniFi Network application.
systemctl restart unifi
It can take a little bit to restart.
You can find detailed info here. https://wiki.wireshark.org/DHCP
But you should be able to filter out the DHCP request with either
dhcp
or
bootp
ip.addr == 192.168.1.1
eth.dst == 01:00:5e:7f:ff:fa
Wireshark has a robust set of options for filtering items.
From the Packet Details pane you can select any piece of information you want to filter, right click -> Apply As Filter -> Selected
You can also copy it and then past it in the filter bar. Right click -> Copy -> As Filter
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.
$$('[disabled]').forEach( a => a.disabled=false )
Swap back to the new user interface and go change the WAN IP address.
Update: Found this handy dandy FAQs link https://help.ui.com/hc/en-us/articles/115009192828
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.
sed -i s/aaa.1.wpa.mode=2/aaa.1.wpa.mode=0/g /tmp/system.cfg/usr/etc/rc.d/rc.softrestart saveAfter 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”
Here are a couple different ways to do directory traversal.
More detailed information is available at the following site.
https://portswigger.net/web-security/file-path-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 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”
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.
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.
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
Installing the script is really hard. 2 lines to get setup.
wget http://incredigeek.com/home/downloads/ubntmod/ubntmod.sh
chmod +x ./ubntmod.sh
More information can be found here.
https://www.incredigeek.com/home/ubntmod/
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.
Example contents of ubntmod.conf file.
unpw=( "ubnt,ubnt" "ubnt,password" "admin,password" )
Open up crontab with
crontab -e
Configure the time. Refer to here for crontab date syntax
10 1 * * * cd /home/bob/ && ./ubntmod.sh -A
That’s it. Should be good to go.
The following is a very basic guide for setting up Fail2ban for SSH.
Install Fail2ban
sudo dnf install fail2ban
You may need to install the epel repo
sudo yum install epel-release
Configure to run on system boot
sudo systemctl enable fail2ban
Start Fail2ban service
sudo systemctl start fail2ban
Copy config file with
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Modify the config file
nano /etc/fail2ban/jail.local
Uncomment the following line and add any IPs that need to be whitelisted
ignoreip = 127.0.0.1/8 ::1 192.168.1.20
Save the file and restart Fail2Ban
sudo systemctl restart fail2ban
Create a new jail file in /etc/fail2ban/jail.d/ called sshd.local
nano /etc/fail2ban/fail.d/sshd.local
Add the following. Note: if you are using a custom ssh port, change “port = ssh” to “port = portnumber”
[sshd] enabled = true port = ssh action = iptables-multiport logpath = /var/log/secure maxretry = 5 bantime = 300
Restart Fail2ban
sudo systemctl restart Fail2ban
You can list the firewall rules to verify that an IP gets banned.
iptables -S | grep ipaddress
You can unban an IP address with the following command.
sudo fail2ban-client set sshd unbanip 192.168.1.100
You can check out the following link for more information
You may need to upgrade your MikroTik if the WireGuard options are not available.
Quick overview of setting up a MikroTik Router as a VPN appliance.
First we need to create a WireGuard interface to use.
/interface/wireguard add listen-port=51820 mtu=1420 name=wireguard1
We’ll need to copy the public key, shown in the following command, for use in the client config.
/interfaces/wireguard print
Next we’ll configure an IP address/range for the new WireGuard interface.
/ip/address add address=192.168.1.1/24 network=192.168.1.0 interface=wireguard1
Download and install the WireGuard application on your computer or phone.
Create an empty config (Ctrl +N), click edit, add the following.
Address = 192.168.1.2/24 DNS = 9.9.9.9 [Peer] PublicKey = ReplaceWithInterfacePublicKeyFromMikrotik AllowedIPs = 0.0.0.0/0 Endpoint = endpointip:51820
Here is a screenshot as an example. We need to copy the public key. We’ll use that when we create the peer.
Now lets create a peer. Back on the MikroTik, run the following command. Change the allowed address and public key.
/interface/wireguard/peers add allowed-address=192.128.1.2/32 interface=wireguard1 public-key="PublicKeyFromClientCreatedInNextStep"
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.
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.