A Linux Botnet That Spreads Using Stolen SSH Keys (zdnet.com) 40
ZDNet is warning that Linux users need to watch out for "a new peer-to-peer (P2P) botnet that spreads between networks using stolen SSH keys and runs its crypto-mining malware in a device's memory."
The Panchan P2P botnet was discovered by researchers at Akamai in March and the company is now warning it could be taking advantage of collaboration between academic institutions to spread by causing previously stolen SSH authentication keys to be shared across networks.
But rather than stealing intellectual property from these educational institutions, the Panchan botnet is using their Linux servers to mine cryptocurrency, according to Akamai... "Instead of just using brute force or dictionary attacks on randomized IP addresses like most botnets do, the malware also reads the id_rsa and known_hosts files to harvest existing credentials and use them to move laterally across the network...." Akamai found 209 peers, but only 40 of them are currently active and they were mostly located in Asia.
And why is the education sector more impacted by Panchan? Akamai guesses this could be because of poor password hygiene, or that the malware moves across the network with stolen SSH keys.
Akamai writes that the malware "catches Linux termination signals (specifically SIGTERM — 0xF and SIGINT — 0x2) that are sent to it, and ignores them.
"This makes it harder to terminate the malware, but not impossible, since SIGKILL isn't handled (because it isn't possible, according to the POSIX standard, page 313)."
But rather than stealing intellectual property from these educational institutions, the Panchan botnet is using their Linux servers to mine cryptocurrency, according to Akamai... "Instead of just using brute force or dictionary attacks on randomized IP addresses like most botnets do, the malware also reads the id_rsa and known_hosts files to harvest existing credentials and use them to move laterally across the network...." Akamai found 209 peers, but only 40 of them are currently active and they were mostly located in Asia.
And why is the education sector more impacted by Panchan? Akamai guesses this could be because of poor password hygiene, or that the malware moves across the network with stolen SSH keys.
Akamai writes that the malware "catches Linux termination signals (specifically SIGTERM — 0xF and SIGINT — 0x2) that are sent to it, and ignores them.
"This makes it harder to terminate the malware, but not impossible, since SIGKILL isn't handled (because it isn't possible, according to the POSIX standard, page 313)."
I feel almost sorry for them (Score:5, Funny)
Imagine developing a really cool trojan, and then realize that the way you want to monetize it just crashed and burned the second you're done.
Re: (Score:2)
Imagine developing a really cool trojan, and then realize that the way you want to monetize it just crashed and burned the second you're done.
It's even worse than that. Even if you manage to cash out, you only get rubbles which can't buy anything made outside of Russian and you are still stuck in Russia!
Re: (Score:2)
Give it time, another lockdown or two and toilet paper may be in short supply again, and then you're king.
Re: (Score:2)
LOL! That is a good one. ;)
Re: (Score:2)
My constant reminder that "professional" only means "doing it for the money".
Why does Linux allow unkillable processes? (Score:1, Insightful)
Re:Why does Linux allow unkillable processes? (Score:5, Informative)
Linux does not allow unkillable user processes - they can trap and respond to the Soft Terminate signal (15) per the POSIX standard, that is all.
A hard kill "kill -9 PID" will immediately kill the process. This is what should be used if you need a process to exit immediately due to being "Bad" and you DONT want the process detecting or handling that signal. A process cannot trap or handle kill -9 SIGKILL (9)
"kill PID" - What they are talking about is Signal 15 (SIGTERM): Kill without specifying the signal number gives that, which is a Soft Terminate/Exit Request. a Terminate signal that the process can trap that signal and handle it in order to Allow clean termination - the process is allowed to Catch the Term signal as an interrupt in order to conduct an orderly exit - typical activities would involve Closing any files properly so that corruption does not result; Removing the PID file; releasing any Locks or exclusive handles, etc, But if the process never finishes up and exits itself, then it doesn't terminate.
Re:Why does Linux allow unkillable processes? (Score:5, Informative)
Yes, though for disambiguation there's 3 other situations where a process will appear to be "unkillable" which have to be handled differently:
1) I/O hang (physical hardware delay, maybe due to failure, maybe due to abnormally high load, maybe just a driver problem) which should still eventually respond to a "kill -9" but you have to be patient
2) annoying daemonization behavior where someone programmed it to automatically relaunch itself even if exited on purpose (*cough* pulseaudio *cough*) - look for a config feature of the program itself to change to stop this, or just delete or move the binary before you kill it
3) very rarely something will actually exit but leave some garbage behind in a directory in /proc/ which will still cause it to show up in the process list even though it's completely exited - just delete said directory in this case
Re: (Score:3)
I'm pretty sure /proc/{pid}/whatnot is all read-only, so you can't delete a directory in there.
(There are a few things under /proc that are writeable, but I don't think any of them are under /proc/{pid}.)
"Zombie" processes could be another case where the process appears to ignore a kill -9 -- though the process is not working anymore and it's just stuck waiting for its parent to reap it.
Either way, there's nothing special about ignoring signals (well, the ones that can be ignored -- which isn't all of them)
Re: (Score:1)
No, the /proc/[pid] directory is no longer read-only in the case described. It's a rare issue these days.
Linux, what a joke. (Score:1)
We all TOLD YOU this would happen. This is what happens when you use a UNIX wannabe cobbled together by weekend hobbyists, instead of using an industrial strength OS like Windows or OSX that is rigorously crafted by professional coders.
Re: (Score:2)
what happens when you use a UNIX wannabe cobbled together by weekend hobbyists, instead of using an industrial strength OS
LOL. That's not true about Linux kernel developers, either. Perhaps it started as a hobby or academic project, but kernel devs are largely professional software engineers, many of them being paid by companies such for their work.
Re: (Score:2)
1) I/O hang
Technically they are not Unkillable.. just "Unable to be fully released and removed from the process list" - Kill -9 still interrupts; Once you kill -9 the pid: user code will not resume inside that PID once you killed it - the Virtual memory and process entry assigned to that task aren't free to be recycled just yet.. The process entry is sticking around because that task made a system call which requires the kernel thread to finish executing - the kernel itself is still using tha
Re:Why does Linux allow unkillable processes? (Score:4, Informative)
You're very much wrong. You cannot trap SIGKILL or SIGSTOP. Please reply with working code that allows you to do so.
From the man page of signal(3):
RETURN VALUES
The previous action is returned on a successful call. Otherwise, SIG_ERR
is returned and the global variable errno is set to indicate the error.
ERRORS
The signal() function will fail and no action will take place if one of
the following occur:
[EINVAL] The sig argument is not a valid signal number.
[EINVAL] An attempt is made to ignore or supply a handler for SIGKILL or SIGSTOP.
Re: (Score:1)
Re: (Score:2)
That's not actually true, sorry.
No.. this is quite correct. kill -9 will Force terminate the process, No matter what.
process won't actually terminate if the main thread is stuck in an infinite loop
Um, No. In fact you can kill tasks stuck in a loop just fine. This is a very easy one to show by experiment:
# echo ' int main() { while(1) { } }' > example.c ; gcc -o example example.c ; ./example & ./example & ./example
# jobs
[1]+ Running
# kill -9 %1
[1]+ Killed: 9
#
or if it's waiting on a d
Re: (Score:2)
They are not unkillable. The normal kill statements send a signal to the process to end. This happens in Windows as well, which is why one uses taskkill, which sends a "polite" command to a task to stop... and if that doesn't work, taskkill /f, which acts on the kernel level, removing the process completely.
The fact that they resist control-C and normal TERM stuff isn't new. I've seen malicious shell scripts which would trap that, so a true -9 was needed.
As for SSH keys, this might be a good reason to ha
Re: (Score:2)
You've misunderstood what is happening with these "stuck" processes. A process that seems stuck in "exiting" is a child thread or process that is (in simplistic terms) waiting for its parent to call wait*() or pthread_join() so it can be collected (note that these are all system calls). A process that is stuck in "U" is stuck in an uninterruptible system call of some kind, so it's waiting on the system. There is NO user function that is completely uninterruptible; all user processes are killable.
Re: (Score:2)
Good thing I never said that.
Re: (Score:2)
I've never understood how an OS that prides itself on security easily allows any process to make itself unkillable.
It does not. The story is misdirecting you to make things appear lot worse than they are. Any process is free to ignore SIGTERM and SIGINT. That is as expected. No process is free to ignore SIGKILL and this malware cannot either. It just behaves like a regular process that has done some simple and minimal things to make killing it a very small bit harder.
Crypto ? (Score:3)
Shut that down for good.
Loses 35% value in a week , people get taken for all they got , exchange halting trading cause they got no money to pay up. Pirates taking advantagbe of servers , it enables drug dealing and crime all over the planet.
I see nothing good , nothing , to it.
Crypto/block chain has done nothing positive. In the long term only caused misery and problems.
Shut that shit down for good.
Re: (Score:1)
Well, not nothing good at all, but nothing the banks shouldn't have already been doing to allow free currency exchange over the internet.
Re: (Score:2)
As I've said before, I almost never ever see a "happy" story about crypto- it's almost always about people getting screwed, rugpulls, insiders ripping people off, Ponzi crypto schemes, stolen wallets, exchange breaches, etc etc etc.
It's like there's an infinite number of ways for shit to go south with crypto no matter how careful or diligent you are.
SSH keys are a security nightmare (Score:2)
Been saying it for years, and it does not help that when you Google how to do it, the top hits all tell you to setup you private SSH keys without passphrases. Simple solution just ban them for login, what we did two years ago after hacking attempts where hoping from HPC to HPC facility using unsecured SSH keys. Also helps to use the scrambled known_hosts file. If you what passwordless SSH use fricking Kerberos for fecks sake. Meanwhile good luck on that hacker from China getting the password on the posting
Re: (Score:3)
Nonsense. Password-less SSH is something you only use in specific cases and usually in protected environments. The typical thing to use is ssh with password and, if you have higher security needs, 2FA.
That people do bad things with good mechanisms does not make the mechanism bad.
Re: (Score:1)
Password-less SSH is something you only use in specific cases and usually in protected environments.
And, even then, you typically configure that password-less ssh login so it can only be used to run one specific command.
(Responding anonymously so as not to undo existing mods)
Re: SSH keys are a security nightmare (Score:2)
Any mechanism that allows you to do silly things like setup your SSH keys without a password is a security nightmare period, and as dumb as hell. We simply cannot control what our users do, so SSH key access is disabled. We even doubled down on this by creating the allowed keys file in every users home directory making it owned by root and then setting it immutable. This worm just goes to prove my point and SSH key access to a system needs to die.
Re: (Score:3)
Bullshit. You seem to be an authoritarian asshole that enjoys torturing all users because some of them are stupid and will do stupid things.
Here are some things that will probably blow your mind: Users can automate SSH password entry! No, seriously, they can script that. And morons like you are forcing those that have a valid use-case for this to do so. And even worse: Users can write down passwords, share them or even post them online! Time to disable those ssh-passwords completely!
To sum up: You are doing
Re: SSH keys are a security nightmare (Score:2)
Nope I am not doing it wrong. Nobody actually needs passwordless access to the HPC system I manage, it is mearly a convenience. Yes a user could script up using there password, and doing so would be a violation of our terms and conditions and repeat offences would likely result in termination of access. Nobody is doing it or they are being very smart about it. I am not going to detail how I know in case any of my users are reading.
Besides you can actually get passwordless SSH access to the system in a secur
Re: (Score:2)
Fascinating. Amateur that thinks he knows how it is done. Quite common in the security space. There is so much wrong with your claims, I cannot even care to start the list.
Re: (Score:2)
A password protected key depends on trusting a host that has already been compromised in this situation.
You can set up ssh to require BOTH a key and a system password. That is the most secure way of dealing with ssh keys. You can even add in another 2 factor thing if you need that too. Just remember that most common 2 factor systems are just another password with some math thrown in.
kill -KILL, you've done it again! (Score:3)
kill -KILL, you've done it again!