Here is how we will want our routers set up. The WireGuard PtP IP is the IP addresses used on both ends of the tunnel. The WAN IP is the IP of each Router. Local IP on Host B is setup to distribute DHCP.
WAN IP: 172.16.0.1 WireGuard PtP IP: 10.1.1.1/30
WAN IP: 10.0.0.2 WireGuard PtP IP: 10.1.1.2/30 Local IP: 192.168.0.1/24
We need Host A to be able to access Private IP’s (192.168.0.0/24) behind Host B.
We’ll pretend that the 172.16.0.1 address is a public IP, and Host B, is behind some sort of NAT network.
To create the Point-to-point, or PtP, we will create a WireGuard VPN tunnel, and then add routes from Host A to Host B.
For each Mikrotik we need to create a WireGuard interface, and then a peer. One of the peers needs a keep alive if we are behind a NAT.
Wireguard Setup Overview
Here is an overview screenshot of what our WireGuard settings will look like. Host A is on top, and Host B on the bottom. On the left are the WireGuard interfaces, and the right contains the Peers.
We copy the Public Key from the remote WireGuard interface, to the Public Key on the local Peer. I.e. The Host_B Peer contains Host_A’s Interface Public Key and vice verse
If you want to, you can use the WinBox GUI to setup and configure the router.
*The Allowed Address sets which addresses work on the other side of the tunnel. If we don’t specify 192.168.0.0/24, then we won’t be able to route to those addresses. If we don’t add 10.1.1.0/30, then our tunnel won’t work at all. Since we only need to route to the 192.168.0.0/24 network from the Host A side, we don’t need this IP range on Host B.
Mikrotik Recently patched CVE-2023-37099 which was a way someone with an admin account, could escalate to a “super admin”, or jail break a router.
It appears the technique has been around for about a year.
Affected versions: < 6.49.7
The good news is that someone would already have to have an account to elevate permissions. If your routers have been using strong passwords or SSH public/private keys and have internet management disabled, then you are probably fine.
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.
Quick Summary: Operation Triangulation is an iOS zero-click exploit that will self destruct, looks to have been used since at least 2019, works on iOS 15.7, unsure if it works on iOS 16. Can collect location, mic recordings, photos, and manipulate iMessages. First point of entry is from an iMessage message, that compromises the device, after compromise, the message gets deleted.
The following is a list of C&C domains from the securelist.com article. Did a quick DNS lookup for each domain and they currently have the following records & IP addresses. Note that these can change at any time and some of the IP addresses are/can be shared with other legitimate websites if it is on a shared hosting provider.
If you have installed the hardened Linux Kernel on Fedora, you may have encountered the following error when trying to launch Flatpak applications.
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.
error: Failed to sync with dbus proxy
Opening up the file in a virtual a Kali virtual machine, starts to load what appears to look like a Microsoft Sharepoint site. Notice the URL is the local file. It’s setup to pull the photos from the web. Since the VM had no internet available, the images never loaded.
After spinning around for a second, it loads the “log on page”, already populated with our email address. Note I changed the email address before taking the screenshot.
Typing in a random password and hitting Sign in triggers the sign in page.
Notice the ipinfo.io network connection
Going to https://ipinfo.io/json gives us a good bit of info about our IP address, location etc. It looks like this information is requested and then sent to the hackers.
Since there was not an internet connection, the malicious htm web page never received the IP information and so didn’t continue on to the next stage, it just sat there loading. Should be able to setup a fake local server and feed it the information to continue on to the next stage. Or we can just do some static code analysis
Base64, Base64 and more Base64
Opening up the file in a text editor shows tons of Base64 encoded data. The file is only about 20 lines long, but the individual lines are super long.
This is fairly easy to do, run nodejs from the command line, set the variable, and print it to console
> let b64 = atob(atob(etc...etc...etc...))
If we want to, we can pipe the output into another file with the > operator
nodejs ./Payment.htm > Decoded_Payment.js
Deobfuscating the important stuff
Looking at the decoded code shows that there is still some obfuscated stuff in that last line.
The var _0x8378= array contains a lot of human unreadable text.
Fortunately, this is not hard to decode at all. In a terminal, launch nodejs again, copy the whole array as a variable, and then just print the whole array.
When logged into webmail, the connection can look like the following.
Mar 27 12:31:17 host dovecot: imap(firstname.lastname@example.org)<1234567>: Disconnected: Logged out in=148, out=1166, bytes=148/1166
Mar 29 16:41:30 host dovecot: imap-login: Login: user=<email@example.com>, method=PLAIN, rip=::1, lip=::1, mpid=1234567, secured, session=<1uP1h3vD3as3AAAAAAAAAAAAAAAAAAAAB>
Notice the rip and lip are both ::1, IPv6 localhost. Looks like Webmail is creating a local connection to the server to authenticate and pull the email. This makes tracking down where an actual person signed in from a little harder. The connection still gets logged, it’s just in a different log.
use one of the following two commands to search the session log
tail /usr/local/cpanel/logs/session_log -f
grep "firstname.lastname@example.org" /var/log/maillog
The output should be similar to the following
[2023-03-27 12:31:17 -0500] info [webmaild] 192.168.1.11 NEW email@example.com:A3WnodOlnxn1gq05 address=192.168.1.11,app=webmaild,firstname.lastname@example.org,method=handle_form_login,path=form,possessed=0
Notice it gives us the IP address of where the user signed in from.
You could also look at the “/usr/local/cpanel/logs/access_log” however the @ sign is percent encoded “%40”. That could cause issues if you are trying to grep out the email address.