

Malware installed by Cron job - cubictwo
http://blog.sucuri.net/2014/01/the-hidden-backdoors-to-the-city-of-cron.html

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

~~~
dergachev
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](https://gist.github.com/dergachev/7916152)

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

------
darkr
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
Yes, this kind of simple fix can save many headaches.

------
Yver
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
Presumably PHP itself, no? Assuming it was running with a few too many
permissions, or even under root...

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

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

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

