Malware installed by Cron job

http://blog.sucuri.net/2014/01/the-hidden-backdoors-to-the-city-of-cron.html

by cubictwo • 13 years ago

33 18 13 years ago

blog.sucuri.net

Yver• 13 years ago

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

eponeponepon• 13 years ago

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

lmz• 13 years ago

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

Shish2k• 13 years ago

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

iwwr• 13 years ago

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

blueskin_2• 13 years ago

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.

dergachev• 13 years ago

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

alexkus• 13 years ago

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

blueskin_2• 13 years ago

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.

AlexanderDhoore• 13 years ago

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

mhurron• 13 years ago

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

jlgaddis• 13 years ago

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

minimax• 13 years ago

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

drdaeman• 13 years ago

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.

srd• 13 years ago

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.

darkr• 13 years ago

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.

bbwharris• 13 years ago

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

kolodny• 13 years ago

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

Malware installed by Cron job

Related Stories