4 ms·
Ask HN: Do I have a Linux bootkit?
Lately I noticed my laptop has been acting weirdly, and have been looking for causes. By using nethogs I noticed that my system makes connections to hosting companies, mainly in Germany, from a root account. These entries typically look like this:
? root 10.138.153.2:53498-68.235.39.11:80 tzulo, inc
? root 10.138.153.2:53156-104.26.5.15:443 Cloudflare
? root 10.132.193.74:35374-184.105.99.43:443 Civilized Discourse Construction Kit Inc
? root 10.132.193.74:42738-172.67.70.33:443 Cloudflare
? root 10.132.193.74:56512-199.232.53.91:443 Fastly, Inc
It goes both ways, once sending, once receiving. For example when I woken it up from sleep, I had a dozen hosts making connection to my laptop and sending some data. I don't know what, because I'm not knowledgable enough to investigate.
But the weirdest part is, I upgraded and downgraded the BIOS, reinstalled the system, and even created live bootable usb stick from a fresh sha verified ISO, and this persists. Both my laptop and desktop are affected. I had only tried Linux Mint and PopOS. I have no access to another computer to create live usb stick on it to see if it still be affected, but I have suspicion this is UEFI based rootkit. What the hell is that?
- dchest 3y agoThere are plenty of explanations that don't involve malware. If you open 68.235.39.11, you end up on Linux Mint's Repositories website. Similarly, others connections may be caused by: - autoupdater - internet detection when connecting to wi-fi - some kind of analytics backed into the distro - some other software
- WTHISGO 3y agoNo, normal entries state PID and binary path like so: 1128 root /usr/sbin/NetworkManager But these I'm concerned about look like below, no PID, no binary, just ip pairs. Here you can see various ips making connection to my machine in this very moment: ? root 184.104.179.141:443-172.20.13.34:35542 ? root 104.18.21.226:80-172.20.13.34:39954 ? root 142.250.186.66:443-172.20.13.34:46432 ? root 142.250.186.104:443-172.20.13.34:44694 ? root 172.217.16.195:443-172.20.13.34:53760 ? root 104.17.24.14:443-172.20.13.34:57900 ? root 172.20.13.34:54150-151.101.193.91:443 ? root 172.20.13.34:54140-151.101.193.91:443 ? root 172.217.16.130:443-172.20.13.34:49666 ? root 151.101.193.91:443-172.20.13.34:54136 ? root 142.250.186.138:443-172.20.13.34:53846 ? root 104.16.57.101:443-172.20.13.34:47984 ? root 172.20.13.34:51666-104.26.4.15:443 ? root 104.26.4.15:443-172.20.13.34:51650 ? root 34.120.115.102:443-172.20.13.34:40004 ? root 34.120.208.123:443-172.20.13.34:46076 ? root 104.16.219.84:443-172.20.13.34:44896 ? root 142.250.184.196:443-172.20.13.34:37102 Also, normal services I can control with opensnitch, but these don't trigger prompt and go in the background. If you have a linux machine and a moment, install nethogs and see for yourself.
- LinuxBender 3y agoThere are many directions one could go with this but as a starting point: Are these hidden in lsof -n, ss -emoainp and in /proc/net/tcp ? Are you able to see the associated inodes in ss or lsof? If you boot up on a live / diskless / ram-only / rescue ISO do you see the same things? I would also suggest downloading the ISO and creating the thumb drive on a different machine if that is an option and don't insert thumb drive into suspect machine until it is powered off. Some distributions have a package command that can validate signatures and checksums of all the binaries. Mount the suspect disk read-only and chroot to it to run this command and save output to ram. Dont validate packages from the live running suspect image as GPG keys can be inserted by an attacker. [1] may be a starting point Before you nuke whatever is doing this, can you capture the output of this to a thumb drive assuming tcpdump is not patched? I'm 30% into my first coffee so please forgive me if I miss something obvious. Don't have any applications open when capturing this. Close the browser. # cooked (all) interfaces, no resolution, epoch, verbose, full packet, 4000 packets, write to shared mem tcpdump -i any -NNnnttvv -s0 -c4000 -w /dev/shm/cap.cap cp /dev/shm/cap.cap /wherever/you/mounted/thumbdrive/ It may be worth validating the path of tcpdump and saving all your current live variables and saving that to a thumb drive. Use objdump -p on any suspect binaries. env > /dev/shm/env.txt # esp look for any LD_ anything which -a tcpdump objdump -p $(which tcpdump) > /dev/shm/tcpdump_objdump.txt Most important probably would be to sanitize anything sensitive prior to sharing with anyone on the internet via a paste site or github or whatever is easiest. Feel free to push files into sftp share@ohblog.net in /pub/ (no pw) [1] - https://help.ubuntu.com/community/SecureApt https://help.ubuntu.com/community/SecureApt [should apply to mint, I think]
- LinuxBender 3y agoAdding to this, the IP's mentioned are mostly Youtube, OpenStreetMap and maybe Netflix. 1e100 can be in front of user contributed content for repositories but it would help to see what inodes are opening that connection. Malware is often boot-strapped on public repositories these days. 102.115.120.34.bc.googleusercontent.com. 123.208.120.34.bc.googleusercontent.com. 141.128-27.179.104.184.in-addr.arpa. fra15s46-in-f2.1e100.net. fra24s05-in-f2.1e100.net. fra24s06-in-f8.1e100.net. fra24s07-in-f10.1e100.net. fra24s11-in-f4.1e100.net. spike-08.openstreetmap.org. zrh04s06-in-f130.1e100.net. The only two not entirely clear are the googleusercontent unless that is just Youtube. Only 1 IP is in a blocklist. voipbl.netset:34.120.208.123
- verdverm 3y agoyou could try running clamav on linux not sure if it'll catch a root|boot-kit, but if it's a ddos bot or similar, it can catch those, I know from experience :]
- WTHISGO 3y agoMy machine freezes, including the cursor, and reboots itself when I run clamav.