Hacker Newsnew | comments | show | ask | jobs | submit login
Malware installed by Cron job (sucuri.net)
33 points by cubictwo 494 days ago | 18 comments



What happened to "A compromised machine can never be trusted again"?

-----


Seriously. 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

-----


It'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).

-----


They 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.

-----


Companies 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.

-----


The number of times I've wanted to scream that in my "security" classes is uncountable.

-----


Do 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).

-----


If 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.

-----


That's too hard to deal with and requires good backups.

-----


And so you end up with the same machine being compromised again and again.

-----


Setting 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.

-----


Yes, this kind of simple fix can save many headaches.

-----


The 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. :\

-----


I'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

-----


Presumably PHP itself, no? Assuming it was running with a few too many permissions, or even under root...

-----


It's the web user's own crontab judging by the lack of username in the file.

-----


Misleading title. I was assuming that the article would be about backdoors to crond, not that an exploit script gets reinstalled via regular user cronjobs.

-----


I always wondered why people aren't grepping unreviewed code for `eval` or `call_user_*`

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: