The SSH daemon that was taking over didn’t have an OpenSSL marking or even Debian versioning scheme. My suspicion its that it’s an sshd with a backdoor.
Your script is dodgy because it shows temporary directories which are intentionally obfuscated and references to CC (ie command control server).
Try uploading the script to VirusTotal and see if it gets any hits or searching for a checksum or the file
Although there are some distro checks, including for EL, the script seems to specifically target Debian systems. Note that when it tries to free space it specifically invokes apt-get.
I can but I’m afraid I probably destroyed most of the evidence. Deleted /usr/lib/libu.a/ where it was apparently housing the script and replacement binaries. The sshd replacement has now stopped.
Uploaded the script to VirusTotal but got no hits. Although, the script may have been generated with randomized directory names (e.g. t8489034780, i1935678123) to avoid checksum detection. There is, however, someone’s SSH key embedded. Are there any similar sites that can do a file content search?
There’s apparently a rogue kernel module or something still at large on my system that was kicking this off periodically (and who knows what else was going on), so I do intend to reinstall.
Is it possible you accidentally port forwarded this machine at some point with default credentials?
Can’t rule that out definitively, but to the best of my recollection the first thing I did with this box was configure SSHD as I normally do: root login and password authentication disabled. If I port forwarded for a time it would have been with that configuration.
Could this have come in by way of a Kodi add-on, or would that not have adequate permissions?
Only other avenue I can think of is RetroPie by way of retrOSMCmk2. The setup.sh script runs as root.
Woah. Adding an entry into the authorized_keys (Passwordless login into your device).
That definitely is nasty! And you see in that script also the sshd-restart function
If that is not a nice trojan horse with back-door install capability, I don’t know what it is!
And check the /etc/hosts file - it also changed some things in there
If I were you, make sure to change all passwords After you cleaned that mess. Because the script also shows a password-sniffer being active using the ssh link.
The sshd binary you have there probably had a sniffer implemented (reason they replaced it). and the end of the script also shows it (check the reverse sniffer) in the script.
Point taken. Thankfully this box was just a media center and not something I interacted with much through SSH (aside from figuring this out). The only reason I noticed something was off was because the root kit’s sshd didn’t support ED25519 keys, which is what I prefer. I got lucky.
@sam_nazarko In light of this incident, and a Kodi addon being the most likely attack vector, I wonder if /etc/sudoers.d/osmc-no-sudo-password should be reconsidered as a default policy?
I think some evidence more than a suspected likelihood would be necessary. This is a single incident of unconfirmed origin, of a highly customized system with likely dozens, if not hundreds of additional packages not typical of an OSMC installation, also not confirmed by any additional instances.