-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/tmp/salt-minions[BUG] #57057
Comments
I have the same. salt-minion -V Dependency Versions: System Versions: lsb_release -a |
Gents, this is an attack. Check your firewalls. We've had all firewalls disabled on more than 20 systems. Still working to find out more about the issue. |
Appears to be related to CVE-2020-11651 and CVE-2020-11652. A backdoor was also installed via the exploit to /var/tmp/salt-store. |
Additional context for those not in the loop can be seen here: F |
Maybe it is CVE-2020-11651 and CVE-2020-11652,Because my salt-master has access across the extranet |
Entire system is being taken down by this can anyone tell us the immediate fix please? |
This did at least something for me |
I've also managed to strace the "salt-minoins" and got some IP, I guess it attackers host clock_gettime(CLOCK_REALTIME, {1588474770, 745058278}) = 0 |
kill -9 $(pgrep salt-minions) |
Russian IP |
A scan revealed over 6,000 instances of this service exposed to the public Internet. Getting all of these installs updated may prove a challenge as we expect that not all have been configured to automatically update the salt software packages. To aid in detecting attacks against vulnerable salt masters, the following information is provided. Exploitation of the authentication vulnerabilities will result in the ASCII strings "_prep_auth_info" or "_send_pub" appearing in data sent to the request server port (default 4506). These strings should not appear in normal, benign, traffic. Published messages to minions are called "jobs" and will be saved on the master (default path /var/cache/salt/master/jobs/). These saved jobs can be audited for malicious content or job ids ("jids") that look out of the ordinary. Lack of suspicious jobs should not be interpreted as absence of exploitation however. |
Seems like it's better to stop salt-masters for a while |
Stopping salt masters does not stop the processes from running. Also, can we expect that the exploiters have had root access to every minion? |
Been affected :( . Done the following: Stopped all Salt Masters, and run the following:
Not sure if this is enough at the moment |
YOU MUST UPDATE YOUR MASTER(S) IMMEDIATELYImportant references:
Disconnect them from the internet ASAP, perform the necessary updates. There are also backports for older versions of Salt:
|
Seems the attack started a couple of hours ago. I would add:
|
We got the same issue and we followed the above which remediated it. Thank you all for giving the solution. |
In our experience, we had one job that was executed that did the following on each server according to the logs:
|
salt-minions -> https://github.com/xmrig/xmrig |
same things in my servers. |
Any compromised minion is toast I'm guessing. /tmp/salt-minions is just compiled xmrig? Anyone have any hints for cleanup? |
[root@xiaopgg_2 ~]# /tmp/salt-minions -h Network: |
We are investigating What we know right now
minions kill -9 $(pgrep salt-minions)
kill -9 $(pgrep salt-store)
rm -f /tmp/salt-minions
rm -f /var/tmp/salt-store
sed -i '/kernel.nmi_watchdog/d' /etc/sysctl.conf
systemctl restart firewalld || /etc/init.d/iptables restart master yum update salt-master
systemctl restart salt-master |
We have the same problem, the program shut down all the services, include nginx 、redis |
It enables hugepages. |
Probably wise to change your passwords if you've been logging into root. |
Here's what my salt-store tried to run:
(The last 2 lines execute in a loop until it can detect the miner is running) Method of detection: spun up a docker container, replaced Dockerfile:
hello.sh:
Build container, spin up, run "mv /hello.sh /bin/sh", run "./salt-store", wait 2 minutes, cat log.txt salt-store also auto-downloads the salt-minions binary to /tmp/salt-minions. Not a shell script, uses golang built-in. |
It also stopped and disabled Docker services. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@taigrr It was in /tmp/.ICEd-unix/ The script had a completely random name. No suffix to indicate file type. |
Putting patches behind some sort of sign-up wall requesting personal information isn't exactly classy. Just seems like a way to further annoy users after a major security issue. |
This comment has been minimized.
This comment has been minimized.
I analysed the malware a little, nothing spectacular. The salt-minions binary really seems to be just a Monero miner. Here is the dropper script from the Cron job: hxxps://pastebin.com/UDykbnpU The other one's much nastier. |
What would be "the other ones"? |
Newer versions if you didn't get to it in time. |
One's, not ones. I meant the salt-store remote shell. I dumped its memory as well, but nothing interesting popped up, since it doesn't have many hardcoded strings and is probably obfuscated. I could find a sorted array of ASCII characters. I did not perform any more detailed analysis of the disassembly, so the information is of limited value, but I posted it anyway just in case. |
#57088 |
There is original |
So, i've found some additional files that appear to be dropped. On the salt-master: It seems that virustotal doesn't detect it as bad. It adds this path to /etc/ld.so.preload On both salt-minions and master i've also found that some of the dropped files can't be deleted due to immutable attribute set. This string helped, script helped to locate them: In addition, i've also found /etc/hosts to be edited with additional entries for Bitbucket. |
In case somebody would need this. I used this commands to do quick fix on affected systems:
I never seem this mentioned before, but I found this file trying to periodicaly run salt:
Also check |
@MartinMystikJonas : please don't try to salvage systems at this point. Start fresh.
Everyone else: that helper script may be enough to help you calm down your CPU cycles enough to pull out data from your boxes (make the Cryptominer calm down for a bit) but please remember all your ssh keys and secrets were probably stolen, and you have no way to know what's lingering. If you have any other questions, please visit saltexploit.com or visit the slack channel (directions also on saltexploit.com) |
Hi @wavded, Can you please share the logs path location as what you mention below? Appreciate it. Thanks. Regards,
|
@suhaimi-cyber4n6 it's on the salt-master. Look in the |
Thank you very much @taigrr . I really appreciate it. :)
|
Sorry for being late to this game. Here is what I've seen on Linux. Your experience may differ. (I've proofread this a couple of times. I believe I've corrected my typos.) I've seen two different processes, salt-minions (Not the "s" at the end) and salt-store. Check your crontabs for two entries, likely the last two lines. These commands run every minute to pull down what I think is the installer and to restart salt-store.
Verify these are NOT YOURS, then remove or comment out as you would with any normal cron job. If you are using systemd, run
Note the d at the end of This command will also list your valid For the experienced Unix/Linux administrators/users out there, this find command will quickly locate and print the extended attributes of the file listed after "-name". If you're not comfortable using find, skip it and look for the files manuall.
If you're comfortable with find, you can change |
Found /usr/bin/salt-store on one server, MD5: 33140982ace71281c40d0dab0e9d69b8 Probably it appear late with updates, because i found it only on one server. |
Also mentioned (published) even on January 2020 ... - CVE-2019-17361 |
@pretorianec-ua That is a different issue than the one being discussed in this thread. |
closing as there likely isn't any new relevant information to be added, here and if there is please see our Community Slack Channel #salt-store-miner-public |
Does status - mile stone approved means we are working on a fix but not yet released? And do we have a fix branch to follow? |
@myloveecho This wasn't actually a bug in saltstack, but rather a report of evidence gathered regarding an exploit that used another bug, which was fixed several releases ago. There are patches available here. You can also just upgrade to Sodium, which has the fixes already included. |
This is actually easy, you can check https://www.netweakhackers.com to learn more. |
Description
My all servers with salt-minion installed,An unknown program suddenly ran today,
He's /tmp/salt-minions
[root@yunwei ~]# top
top - 10:06:44 up 511 days, 18:39, 3 users, load average: 2.01, 2.02, 1.91
Tasks: 193 total, 1 running, 192 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.2%us, 18.3%sy, 0.0%ni, 74.1%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8060948k total, 7502768k used, 558180k free, 76316k buffers
Swap: 4194300k total, 437368k used, 3756932k free, 188012k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2280 root 20 0 56.0g 541m 1588 S 101.1 6.9 345886:48 tp_core
27061 root 20 0 2797m 1848 1000 S 99.1 0.0 36:02.75 salt-minions
[root@yunwei ~]# ps -ef |grep 27061 | grep -v grep
root 27061 1 89 09:26 ? 00:36:37 /tmp/salt-minions
sal-minion version 2018.3.2
sys:CentOS release 6.5 (Final)
The text was updated successfully, but these errors were encountered: