Malware installed by Cron job | Hacker News Reader

Malware installed by Cron job

blog.sucuri.net

33 pointscubictwo18 comments

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

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.

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.

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

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.

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.

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

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.

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

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_*`

Reply on news.ycombinator.com