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