>>> If you're here, chances are you're already compromised.<p>WTF does that mean? Our salt implementation is on an entirely private network, so why would I be more likely than not to be compromised already?<p>----<p>Edit: Re-downvotes -- This is a sincere question. Is there some evidence that the majority of salt implementations are compromised, or some mechanism by which this hits private networks? Or is that line just for dramatic effect?
SaltStack has a long history of home brew protocols, internally written encryption, security issues, and bugs. I'm not surprised they would end up being used as a vector for attacks.
We all got lucky on this one. The outcome could of been much worse, like secret leaking and rm -rf. We record everything that saltstack does and the scripts didn’t even upload anything from the infected servers.
Our server were affected. They added a cronjob which ran every minute wgetting a .sh file and executing it. Most of the time the server which the file was in was either offline or returned 404, but every once in a while it returned the malicious script. When this script got executed, it killed our nginx server, which is how we noticed something odd was happening. If it wasn't for nginx dying, we might have not even noticed we were infected.<p>Here's the contents of the sh script for the curious. <a href="https://pastebin.com/CbupwQMG" rel="nofollow">https://pastebin.com/CbupwQMG</a>
This hit RamNode too.<p>> This message is to customers with VPSs on our legacy SolusVM system.<p>> At approximately 20:34 eastern (GMT -4) on May 2, recently published SaltStack vulnerabilities (CVE-2020-11651, CVE-2020-11652) were used to launch cryptocurrency miners on our SolusVM host nodes. The attack disrupted various services in order to allocate as much CPU as possible to the miners. SSH and QEMU processes were killed on some of our CentOS 6 KVM hosts, causing extended downtime in certain cases.<p>> Upon detecting the disruption, we quickly began to re-enable SSH, disable and remove Salt, kill related processes, and boot shutdown KVM guests. After careful analysis of the exploit used, we do not believe any data was compromised.<p>> RamNode was not specifically targeted, but rather anyone running SaltStack versions prior to the one released a few days ago (April 29).
Algolia got impacted too, apparently their Salt masters were opened to the whole internet: <a href="https://blog.algolia.com/salt-incident-may-3rd-2020-retrospective-and-update/" rel="nofollow">https://blog.algolia.com/salt-incident-may-3rd-2020-retrospe...</a>
This impacted ghost.org hosting really bad <a href="https://status.ghost.org/" rel="nofollow">https://status.ghost.org/</a>
Debian hasn't fixed this yet in their packaging so you might want to work around that if you are using that as a salt-master server.<p><a href="https://security-tracker.debian.org/tracker/CVE-2020-11651" rel="nofollow">https://security-tracker.debian.org/tracker/CVE-2020-11651</a>
I'm so grateful this happened over the weekend, when I had time to respond. My girlfriend woke me up and told me the CPU-fan was going crazy in the living room. I realize this isn't the case for everyone. I extend my deepest consolations to those affected.
Former SaltStack user here. If you're using it, just stop. Switch to Ansible, a Kubernetes/Helm/Flux solution or experiment with Chef Habitat if you're feeling futuristic. SaltStack is just bad. It's buggy, clunky and has really bad error messages. Its only saving grace is that it came before Ansible, but that's only relevant in a historical context. Just no.
How does things like these affect Monero's reputation?<p>I saw Monero mining in JS libraries, now it is in virus form.<p>Thus, why Monero? Does Monero somehow discourage these "practices"?