Recover a compromised KiwiSDR [fixed]
Hi All,
I have a Beaglebone Green from Seed with a KiWiSDR which purchased and implemented about 3 1/2 years ago and worked fine for about two years on a public IP address, until it was compromised and my ISP threatened to disconnect me unless I shut it down for allegedly sending spam.
Due to various issues (family, work, Covid) I have only just got around to trying to resurrect it. Of course the SD card was lost, so I went to:
and did my variant of it because I was running on another Devuan 4 box (Devuan 4 is like Debian 11 but without systemd)
- I got the flasher script
- I ran the flasher script to fetch the .img file
- I watched the checksums verify
- I ran unxz on the xz image file to obtain KiwiSDR_v1.390_BBB_Debian_8.5.img
- I ran dd if=KiwiSDR_v1.390_BBB_Debian_8.5.img bs=4096 of=/dev/sdb to copy to a 32Gb micro SD card
- I ran fdisk /dev/sdb and verified that there was an sdb1 partition type Linux (83) size 1.4Gb
- I connected the BB Green/KiwiSDR on my "inside" private LAN, inserted the SD card, booted and there was activity
- Blue LEDs flashing, Ethernet flashing and after a period the device shutdown (all lights off)
- Removed SD card
- Re-powered the system, activity, device obtains IP address (192.168.144.122) via DHCP
Device now seems to be stuck in a loop making connections to Amazon cloud via HTTPS and flashing the blue lights lights. I left it overnight and its still doing the same thing this morning.
Watching it on TCP dump shows:
root@xg115:/var/lib/dhcp# tcpdump -vv -i eth1 host 192.168.144.122 tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:58:23.671748 IP (tos 0x0, ttl 64, id 51250, offset 0, flags [DF], proto TCP (6), length 85) dhcp-122.tubby.org.38465 > ec2-3-233-199-89.compute-1.amazonaws.com.https: Flags [P.], cksum 0xaca7 (correct), seq 711252822:711252855, ack 3263345502, win 1456, options [nop,nop,TS val 146628309 ecr 2017735728], length 33 10:58:23.761705 IP (tos 0x0, ttl 236, id 62378, offset 0, flags [none], proto TCP (6), length 83) ec2-3-233-199-89.compute-1.amazonaws.com.https > dhcp-122.tubby.org.38465: Flags [P.], cksum 0x971d (correct), seq 1:32, ack 33, win 132, options [nop,nop,TS val 2017826711 ecr 146628309], length 31 10:58:23.762823 IP (tos 0x0, ttl 64, id 51251, offset 0, flags [DF], proto TCP (6), length 52) dhcp-122.tubby.org.38465 > ec2-3-233-199-89.compute-1.amazonaws.com.https: Flags [.], cksum 0xc948 (correct), seq 33, ack 32, win 1456, options [nop,nop,TS val 146628332 ecr 2017826711], length 0 10:58:28.950303 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dhcp-122.tubby.org tell gate.tubby.org, length 28 10:58:28.951959 ARP, Ethernet (len 6), IPv4 (len 4), Reply dhcp-122.tubby.org is-at 44:d5:cc:49:d5:f1 (oui Unknown), length 46 10:58:42.179436 IP (tos 0x0, ttl 220, id 37007, offset 0, flags [none], proto TCP (6), length 86) 52.95.122.231.https > dhcp-122.tubby.org.40510: Flags [P.], cksum 0xb863 (correct), seq 317337024:317337070, ack 554006657, win 748, length 46 10:58:42.180890 IP (tos 0x0, ttl 64, id 56180, offset 0, flags [DF], proto TCP (6), length 86) dhcp-122.tubby.org.40510 > 52.95.122.231.https: Flags [P.], cksum 0x10da (correct), seq 1:47, ack 46, win 1643, length 46 10:58:42.202894 IP (tos 0x0, ttl 220, id 37008, offset 0, flags [none], proto TCP (6), length 40) 52.95.122.231.https > dhcp-122.tubby.org.40510: Flags [.], cksum 0x31f9 (correct), seq 46, ack 47, win 748, length 0
Here's a video of it going round in circles:
What do do next?
Mike G8TIC
Comments
More info ... if I scan it with nmap it has a couple of ports open but no SSH, no HTTP, no HTTPS and port 8073:
What happens if you reset or power cycle it? (Reset button is the outer one by the blue leds)
(yeah I did just suggest turning it off and turn it back on again)
Seriously though, does it get to the exact same condition?
The ethernet LEDS suggest it is passing some data, what connections does it have open?
OK a quick guess having just port scanned mine (just 22 and 8073 open) the image write perhaps was not successful and it is still running the old install.
I'd concentrate on the board, remove the Kiwi cape. Then get a base Debian install for the Beaglebone Green, see if it installs and runs OK then load KiwiSDR from github. I'll have a go here as I've not done it for a while and am not sure how recent a Debian will work.
I'd bet that 144.122 is not really the Kiwi's ip address. The video shows the standard Kiwi server LED pattern which does contain the ip. Can you decode it using the instructions here? http://kiwisdr.com/quickstart/index.html#id-leds
Ports 1080 and 8888 should not be open which is even more suspicious.
If you enter that MAC address (44:D5:CC:49:D5:F1) into a site like www.whatsmyip.org/mac-address-lookup it comes back "Amazon Technologies Inc." So this device is actually something like an Amazon Alexa 🙄
That makes much more sense.
If you can read the Kiwi serial (2165 ?) could you see if my.kiwisdr.com shows it coming up (if enabled).
Good catch Stu. That Kiwi serial number has a
my.kiwisdr.comlocal ip of192.168.144.125updated Jan 8 11:35 UTC (I can tell this because I'm able to look on the server where themy.kiwisdr.cominfo is stored).Gents,
Thanks for the help ... its my fault!
The KiWiSDR serial is 2165 and it does appear to have re-flashed and recovered as intended.
I had written 192.168.144.125 on one bit of paper, and 192.168.144.122 on another bit of paper for something else to do with a problem with an Alexa device.
It was late last night and I had a bit of a brain fart.
Mike G8TIC
Mike, good to hear.
The SDR is now running on 2m with a 116MHz offset.
This time its behind my firewall, but I've gone one further and implemented an Nginx reverse proxy so that it is accessible over HTTPS on the normal port 443.
You can find it here:
Mike