hack on directadmin server

W

WizardX

Verified User
Joined
Aug 1, 2006
Messages
20
Recently I found out that we're sending out excessive amount of spam, but not trough exim. When I did an lsof I saw a process connecting directly to smtp servers to send out spam. I figured out this process was initiated from the crontab which strangely bein initiated the same time the datask cron:

Aug 26 14:30:01 ha04 /USR/SBIN/CRON[30626]: (root) CMD (/usr/local/directadmin/dataskq)
Aug 26 14:30:01 ha04 /USR/SBIN/CRON[30627]: (apache) CMD (/var/tmp/mxXtkKKqOl >/dev/null 2>&1)

Can anyone tell me where dataskq retrieves its commands to run from? all user crons are empty including /etc/crontab /etc/cron.d and subdirs.
 
Lots of commands which run through dataskq can be initiated from the DirectAdmin login interface, and I'm guessing through the API as well, so the first place to look would be at users, especially recently signed up users.

Did you find the spam program(s) on disk, or only in memory? If only in memory, as which user were they running? If on disk, in which directory, and owned by whom?

Jeff
 
The dataskq runs every minute. I don't believe it's related.
The suspicious script is being called by cron.
We can see the cron is run by the "apache" user, I'm guessing a bad php script was used to add a cron.. (setup is likely mod_php without mod_ruid2)

Run this command to check:
Code: 
crontab -u apache -l
to get the list of apache crons.
Note that DA does add apache to the /etc/cron.deny list, so make sure you see apache there.
If not, run:
Code: 
cd /usr/local/directadmin/scripts
./cron_deny.sh
which should be run at both the install time and for each DA update.. so not sure why it would be empty.

If the crontab output is empty, check the following
Code: 
cd /etc
grep [COLOR=#333333]mxXtkKKqOl crontab
grep [/COLOR]mxXtkKKqOl cron*/*
as.. those are the only places it should be.


Note, if they were able to add info to any of the above /etc/cron* areas.. they likely already have root access... which is bad.
A given user (aka: apache) should only have access to crontab... and only if they're not in the cron.deny list.


Preventative measures:

1) Ensure the cron.deny is filled (it already should be)

2) Secure php to prevent those calls. http://help.directadmin.com/item.php?id=247]Tip #2

3) Mount /tmp as noexec/nosuid, and then use a symbolic link for /var/tmp to /tmp.

4) If they were able to add an apache cron, that would mean you're running apache as mod_php, without mod_ruid2.
Use any other php type so that php scripts run as the User:
- suphp
- mod_php with mod_ruid2 (ruid2 is why it runs as the user). This is the CustomBuild 2.0 default.
- php-fpm
- fastcgi

5) If you're running a very old version of DA (which may explain the empty cron.deny list), update.

John
 
The apache user crontab cannot be accessed directly using the -u flag (because of the cron.deny) but I found out that /var/tmp/mxXtkKKqOl was being initiated. /var/spool/crontab/apache showed the cron I was looking for. How it came over there is a complete mystery. The owner and group of that spool file wasn't modified by a user. Parallel to these findings I found a user with a php shell backdoor in their homedirectory. I also found using lsof that the following process is running the spamruns:

/sbin/ude 32405 apache 22u IPv4 20861599 0t0 TCP ha04.deepmedia.nl:35746->smtp-in.orange.fr:smtp (ESTABLISHED)
/sbin/ude 32405 apache 23u IPv4 20861600 0t0 TCP ha04.deepmedia.nl:60107->smtp-in.orange.fr:smtp (ESTABLISHED)
/sbin/ude 32405 apache 26u IPv4 20861605 0t0 TCP ha04.deepmedia.nl:35556->mx1.mail.icloud.com:smtp (ESTABLISHED)
/sbin/ude 32405 apache 31u IPv4 20861520 0t0 TCP ha04.deepmedia.nl:56989->mta-v1.sbc.mail.vip.ne1.yahoo.com:smtp (ESTABLISHED)

ha04:~# ps aux | grep 32405
root 3334 0.0 0.0 6304 600 pts/1 S+ 12:33 0:00 grep 32405
apache 32405 8.8 0.0 33140 7316 ? Ss 12:00 2:56 /sbin/udevd

Killing the process will stop the run, but I'm still curious who created the cronjob and who started this pid. Next to these findings I also found using rkhunter the following 'strange' perl files:
-rwxr-xr-x 1 root root 8635 Feb 19 2012 /usr/bin/lwp-download
-rwxr-xr-x 1 root root 2798 Feb 19 2012 /usr/bin/lwp-dump
-rwxr-xr-x 1 root root 2477 Feb 19 2012 /usr/bin/lwp-mirror
-rwxr-xr-x 1 root root 15059 Feb 19 2012 /usr/bin/lwp-request

Anyways, I concluded my loss and am now migrating all content to a clean new server and shut the old one. Off course with checking the userdirs for rootkits or viruses.
 
/var/spool/crontab/apache showed the cron I was looking for. How it came over there is a complete mystery. The owner and group of that spool file wasn't modified by a user.
Click to expand...

Was it owned by root? If so, then you might need to format your HDDs, and install a new server.
 
are you running maldet?
seems like it would have picked up on this?
 
rkhunter and clamav, but they both didn't. Anyways, the server is offair and so this adventure is over :)
 
You must log in or register to reply here.
Back
Top