24 ms·
Malware installed by Cron job
- Yver 13y agoThe attacker obfuscated "base64_decode" part but not "eval". It's not the first time I see base64_decode() being more the focus of attention than eval, I don't know where it originates from. Also, if cron infected the PHP files I wonder what infected the crontab. :\
- eponeponepon 13y agoPresumably PHP itself, no? Assuming it was running with a few too many permissions, or even under root...
- lmz 13y agoIt's the web user's own crontab judging by the lack of username in the file.
- Shish2k 13y agoI'd expect the old insecure joomla install was the original source of the infection, the cron was just there to automatically re-infect it without the attacker needing to run the same remote exploit repeatedly
- iwwr 13y agoWhat happened to "A compromised machine can never be trusted again"?
- blueskin_ 13y agoCompanies like the linked one make their money in cleaning up compromised servers rather than nuking and reinstalling them. Not saying it's impossible to do a full clean, but I would certainly not trust a server once compromised.
- dergachev 13y agoSeriously. If this company was surprised to discover the use of cron for the malware, imagine what kind of stuff they might have missed. Here's a particularly creative technique I recently came across: https://gist.github.com/dergachev/7916152 https://gist.github.com/dergachev/7916152
- alexkus 13y agoIt's probably a typo (or copy-and-paste-o) but if your ls -l of the binary with setuid is showing "-rwxr-xr-x" then you're more than likely running a rootkit version of ls that hides setuid info. From your gist:- ls -al /bin/nano # -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano chmod u+s /bin/nano # installs the backdoor ls -al /bin/nano # -rwxr-xr-x 1 root root 191976 2010-02-01 20:30 /bin/nano What you should see is:- # whoami root # ls -l /tmp/sh -rwxr-xr-x 1 root root 109736 2014-01-16 16:20 /tmp/sh # chmod u+s /tmp/sh # ls -l /tmp/sh -rwsr-xr-x 1 root root 109736 2014-01-16 16:20 /tmp/sh # chmod u-s /tmp/sh # ls -l /tmp/sh -rwxr-xr-x 1 root root 109736 2014-01-16 16:20 /tmp/sh If you've got 'ls --color' then you'll see the filename is different when setuid (white text on red background rather than light green on default background - if colours are the default).
- blueskin_ 13y agoThey have a link scanner which I've actually used before which is good, but I doubt I'm the target audience in terms of paying someone for a cleanup. Perhaps different parts of the company are at a different level.
- AlexanderDhoore 13y agoThe number of times I've wanted to scream that in my "security" classes is uncountable.
- mhurron 13y agoThat's too hard to deal with and requires good backups.
- jlgaddis 13y agoAnd so you end up with the same machine being compromised again and again.
- minimax 13y agoDo you consider the machine compromised if the attacker has only managed to gain access to a non-privileged account? It isn't clear the bad guys got root access here. It's a genuine question (I'm not a security person).
- drdaeman 13y agoIf you aren't certain that attacker did not managed to gain root access you should assume the worst. So, power down, boot from a clean medium and do a full check, validating (debsums, tripwire, rdiff with a copy of backup, etc) every configuration and executable file out there. Or, to save time, just wipe everything out and quickly redeploy the services.
- deleted 13y ago[deleted]
- srd 13y agoMisleading title. I was assuming that the article would be about backdoors to crond, not that an exploit script gets reinstalled via regular user cronjobs.
- deleted 13y ago[deleted]
- darkr 13y agoSetting up /etc/cron.allow with only specified users (I.E _not_ your webserver user) is a good thing to do on servers generally. If you have cronjobs that need to run as a webserver user, setup another user specifically for the task, then in sudoers configuration explicitly allow that user to run the required command in the context of the webserver user.
- bbwharris 13y agoYes, this kind of simple fix can save many headaches.
- kolodny 13y agoI always wondered why people aren't grepping unreviewed code for `eval` or `call_user_*`