Interesting script for cpanel

[Un Area]

When we receive the server logs (logwatch, backups, upcp, etc) sometimes we receive a mail telling about a possible uploaded file that can be use for send out spam and a description of where is the file located.

Seems that there is a process somewhere monitoring ftp activity on cpanel servers, and would be nice to apply this to scan files that contains phpshell, shell_exec or other list of words that could be a kiddie script.

You know what I mean? If it works scanning files that contains mail(), sendmail, formmail words could work for the others I mentioned above. Nice to take a look at those scripts and get rid of them and apply a fix if its needed

Bye!

 

[mctDarren]

It's from your upcp each night, it checks out recently uploaded files using the system log (/ver/log/messages) by running a script called /usr/local/cpanel/bin/scanfornewmail. You could likely make a cron that calls this and emails you the results at certain intervals:

#!/bin/sh
/usr/local/cpanel/bin/scanfornewmail | mail "New Email Check" root
exit 0

Then just set up a cron job to run it every X hours. Don't forget to give the script the right permissions.

 

[Un Area]

I already know this, what Im saying is a similar script that scan Recently Uploaded SHELL/Kiddie Scripts. that would be great.
A useful script where you can custom the scanning words like phpshell, shell_exec, udp.pl, etc and add it to the contact manager alerts.

Unfortunately /usr/local/cpanel/bin/scanfornewmail is a compiled script so we cant dig into the code to make something similar for kiddie scripts, so we have to wait that CPANEL implement this.

Bye!

 

[ramprage]

I already know this, what Im saying is a similar script that scan Recently Uploaded SHELL/Kiddie Scripts. that would be great.
A useful script where you can custom the scanning words like phpshell, shell_exec, udp.pl, etc and add it to the contact manager alerts.

Unfortunately /usr/local/cpanel/bin/scanfornewmail is a compiled script so we cant dig into the code to make something similar for kiddie scripts, so we have to wait that CPANEL implement this.

Bye!

That's a good idea however it won't work very well in a real world solution. This is because hackers/script kiddies usually dont' upload these types of files with FTP. Instead they use PHP based remote include exploits to get files on the server using wget, so there are no logs of the activity in /var/log/messages

Still, it's a good start to something interesting, I might make a program that does what you're saying. I like the idea.

 

[mctDarren]

I already know this

Doh, yes -sorry misunderstood what you were saying. :p

That is an interesting project to consider, and while I see what ramprage is saying about viability of logs - I think you might be on to something. I see the project expanding to check for old versions of popularly exploited software being uploaded as well...

Steven, if/when you start this let me know. Very interested.

 

[Un Area]

Would be useful for those kind of users that upload via FTP "common used kiddie scripts".
For php posting we have to deal with mod_security at a certain point.

As rampage said I´m writting a script for this too, suggestions are welcome :D

Bye

 

[GCIS]

Why not fgrep all php files in client home directories, and diff the output to send reports for only scripts created since the last scan? Yes, this can still be bypassed easily, but should weed out most of the hit-and-run abuse. Ultimately, though, there is no magic bullet to identify all scripts of a malicious nature. Only through customer verification and security hardening can you keep spammers, hackers, and script kiddies from abusing your servers.

 

[freedman]

fgrep would be useful only in detecting already known code, and if someone just adds random whitespace or new lines it complicates the matching.


if you want a list of new files.. use find -cnewer /tmp/LASTCHECKED /home/

if you're running it hourly from cron use: find -cmin 60 /home/

or whatever find option you find most appropriate.. take the list it produces and do what you wish with it.

manually look at them, run them through an fgrep, etc...

at leaast this way, you're only looking for files that have changed recently and not acting on all files all the time.

I suppose if this were something I were really concerned about (I know most of my hosting clients and trust them, but if I were selling open hosting accounts which any spammer could buy, then I would be more concerned) then I would do something like this:

#!/bin/sh
if [ ! -e /tmp/NEWFILECHECK ] ; then touch --date="Jan 1, 1970" /tmp/NEWFILECHECK; fi
touch /tmp/NEWFILECHECK.new
find -cnewer /home -exec /path_to_my_root_scripts/checkfile.sh {};
mv /tmp/NEWFILECHECK.new /tmp/NEWFILECHECK
# the NEWFILECHECK.new file establishes a timestamp right before our find.. since our find might take some time, we want to make sure we catch files changed during it's execution which might have been missed--one side affect is that some files might be reported twice... for example. find has gone through /user/auserstartingwitha and then auserstartingwitha uploads a file via a http upload... if we simply 'touch /tmp/NEWFILECHECK' after the find, then we miss that file next time since it was added before the timestamp. when it comes to security, better to double check than not check at all.


run that from cron on whatever frequency you wish
checkfile.sh:
#!/bin/sh
echo $0 >> /path_to_my_newfile_logfile #just to keep track of new files.. you might want to add a timestamp or something to this list

then, in that file you could do grep for your search patterns against a file with known bad code in it.. or you can check the path, email an administrator, whatever you wanted to do with the file/filename....

if anyone comes up with a good checkfile.sh file, I'd love to see it posted here for everyone.

 

[brianoz]

Why not fgrep all php files in client home directories, and diff the output to send reports for only scripts created since the last scan? Yes, this can still be bypassed easily, but should weed out most of the hit-and-run abuse. Ultimately, though, there is no magic bullet to identify all scripts of a malicious nature. Only through customer verification and security hardening can you keep spammers, hackers, and script kiddies from abusing your servers.

You really, really don't want to do this. If someone installs a reasonable sized package, for instance Joomla or Mambo you could get thousands of lines of installed scripts which makes the email useless. You really need to check the new (or newly modified) scripts against a list of known exploit filenames, and against a list of internal exploit signatures. A regularly updated tool like this would actually be really nice.

 

[GCIS]

You really, really don't want to do this. If someone installs a reasonable sized package, for instance Joomla or Mambo you could get thousands of lines of installed scripts which makes the email useless. You really need to check the new (or newly modified) scripts against a list of known exploit filenames, and against a list of internal exploit signatures. A regularly updated tool like this would actually be really nice.

All uploaded files should be checked for potentially dangerous functions, including mail(), shell_exec() [and its variants, among others].


The size of a package has nothing to do with this; a file either contains potentially hazardous functions, or it doesn't. If it does, it needs to be inspected. To save administrative time, certain accounts can be whitelisted, if the client is known to be benign, and there is little expectation of said client having his or her authentication credentials stolen.


As I said earlier, there is no magic bullet solution to this problem. Novel forms of abuse can bypass a system's safeguards. Security scanners are employed to protect against well known and often replicated forms of abuse, and these methods are designed to produce a boolean result - each file scanned either contains potentially hazardous calls, or it doesn't. For this reason, the size of the package is irrelevant.

 

[brianoz]

The size of a package has nothing to do with this; a file either contains potentially hazardous functions, or it doesn't. If it does, it needs to be inspected.

In this case, it's not the size, but how it's installed (sorry for leaving that rather crucial detail out); if it's installed with Fantastico or cpanel addons it doesn't need to be inspected under a microscope. Of course, one has to make sure evil files can't be hidden inside a fantastico-installed directory or file, so some checksumming may be required.

What you say about inspecting for possible malicious code is important. Just as in the virus world, any scanning here has to evolve as the malware authors will change their code so it doesn't match once they realize it's being scanned for. I don't think that's avoidable.