Results 1 to 22 of 22
  1. #1
    Join Date
    Apr 2003
    Posts
    187

    Problem with spammer getting into the tmp dir

    So ive got a spammer getting perl scripts into the /tmp/ dir.

    The directory is secured, however he is still getting it in.

    im running commands like

    cd /usr/local/apache/domlogs/
    grep "enviador.txt" ./* | more

    to search for what script has the vulnerability, but searches are comming up empty.

    Any idea where I should search next to see which script hes getting into tmp via?

  2. #2
    You can check the ownership of the uploaded file to know about the user and also check where the last root logins to the server came

  3. #3
    Join Date
    Apr 2003
    Posts
    187
    Only our account is on the server, so its not being uploaded by a system user.

    Its owned by "nobody"

    it must be coming form a php script hole or something of the like.

    anyone have any other ideas on how to trace the origin of the script that uploaded it?

  4. #4
    Join Date
    Aug 2001
    Location
    Canada
    Posts
    2,123
    If it's still running check /proc/processid. Cat the environ file in it.
    www.idologic.com - Reseller, VPS and dedicated hosting - Friendly Customer Service - DirectAdmin - cPanel - InterWorx

  5. #5
    Join Date
    Apr 2002
    Posts
    930
    This is one reason that phpsuexec or PHP as CGI is a good idea. This will cause any PHP script to run as the account owner, and if an account creates a file in /tmp such as this, you will atleast know the owner of the script.

    Another solution is to find the date and time that the file was created in the /tmp directory and then search the domlogs for scripts that corresponded to that time.

    For example, if the file was uploaded on October 17 at 7:32AM, you might run a search in the domlogs directory like:

    Code:
    grep "17/Oct/2005:07:32" * >times.txt
    This also depends on how your domlogs are formatted. I think the above line is the default for CPanel servers, but yours could be different. This will output any thing it finds into the times.txt. I usually do this just because then I will have a complete list of files that were accessed at 7:32AM on October, 17.

    Then from that list, look for any PHP scripts that were accessed:

    Code:
    grep .php times.txt
    I would look for any suspicious script, such as a PHP Shell script or perhaps an xmlrpc.php file that is outdated and vulnerable.

    If you get a long list of php files that were accessed during this time, then you can further filter them by searching for POSTs, as I really figure this is where the exploit will show up.

    Code:
    grep .php times.txt | grep POST
    This might help you to find the problem file.

  6. #6
    Join Date
    Oct 2004
    Location
    India
    Posts
    491
    Make a good mod_sec rule set that will effectively prevent this kind of attack.
    ESC :wq!

  7. #7
    Join Date
    Apr 2003
    Posts
    187
    ran the above greps. not a single entry looked bad.

    its like none of this is registering in the domlogs.

    any other logs i should cehck against?

  8. #8
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,290
    there are ways to hide in in the domlogs.. for example it could be

    happy.php being run

    but really its some hard coded commands.. Its just to much to investigate with just a couple of simple grep commands.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  9. #9
    Join Date
    Apr 2002
    Posts
    930
    Originally posted by Steven
    there are ways to hide in in the domlogs.. for example it could be

    happy.php being run

    but really its some hard coded commands.. Its just to much to investigate with just a couple of simple grep commands.
    This is true, it could also be a PHP shell script that might not have a very distinguishable filename. The grep commands should give you a fairly decent idea.

    Also another thing to consider is your log rotation schedule. I'm not sure if this is a CPanel server, but I know there is an option in that suite to delete logs once the statistics have been generated. I'm not all that sure about other control panels, but if you have something like this in place, then it likely will not be reported.

    Another thing to check is the nobody cron. Check to see if you have anything in nobody's cron:

    Code:
    crontab -l -u nobody
    If you haven't already done so, I suggest that you add nobody to the cron deny list:

    Code:
    echo nobody >>/etc/cron.deny

  10. #10
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,290
    This is true, it could also be a PHP shell script that might not have a very distinguishable filename. The grep commands should give you a fairly decent idea.
    As of late I have found that "generic" methods of investigating do not work as much as they did in the past the same way people are doing

    http://www.domain.com/index.php?page....com/files.txt

    for example and not including anything like

    cmd=wget at the end. Its all hardcoded.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  11. #11
    Join Date
    Sep 2000
    Location
    Alberta, Canada
    Posts
    3,109

    Re: Problem with spammer getting into the tmp dir

    Originally posted by recko11
    So ive got a spammer getting perl scripts into the /tmp/ dir.

    The directory is secured, however he is still getting it in.

    im running commands like

    cd /usr/local/apache/domlogs/
    grep "enviador.txt" ./* | more

    to search for what script has the vulnerability, but searches are comming up empty.

    Any idea where I should search next to see which script hes getting into tmp via?
    In your domlogs dir. you need to grep for; wget or curl

    I agree with Steven, in that some Spammers/Hackers are getting more advanced kiddie-scripts and starting to use 'curl' instead of 'wget'. Still gotta look for both though.

    Perhaps you should hire someone to setup mod_security (with some very tight rules) and/or other areas as well. If you are using WHM/Cpanel for example, there are lots of scripts provided which are garbage and need to be locked down.


    Edit: just thought I'd mention that in order to save time, and your eyeballs once in your domlogs dir. you should grep for:

    grep "cmd=curl" *
    grep "cmd=wget" *
    Last edited by Website Rob; 10-18-2005 at 12:59 AM.
    PotentProducts.com - for all your Hosting needs
    Helping people Host, Create and Maintain their Web Site
    ServerAdmin Services also available

  12. #12
    Join Date
    Dec 2002
    Location
    Quad Cities, Iowa
    Posts
    1,597
    What scripts are you running on your website? Forum software... Blog software... ect.. ect..

    It may be time to find out the versions of everything you use, and check with the provider of the scripts to see if their is new versions. For example phpBB has jumped in versions quite frequently in the past 6 months, older versions are vulnerable.

    Next thing you need to do is find the script they are using to create that file in your tmp directory. Usually there is a file stored somewhere in your public_html that allows the hacker to keep exploiting you. There is actually one advantage to running apache as nobody, and that is you can locate these files easily.

    Command for ssh:
    find /home -user nobody

    You may need to change the directory if your not on cPanel. Anyhow that will find any files owned by "nobody" in your public_html folder. If you have any .php files that are owned by nobody that is probably an exploit. Just open up the files in question with nano or pico and you can safely view their contents.
    Need a new Web Host?
    Become a Host Refugee and receive TRUE 24/7 Support

    cPanel + Fantastico, PHP4 or PHP5
    HostRefugee.com - See our current promotions

  13. #13
    Join Date
    Oct 2002
    Location
    State of Disbelief
    Posts
    22,948
    Command for ssh:
    find /home -user nobody
    This would bring up every gallery image file and far too many results in general to be of use. Need to narrow the scope.
    Having problems, or maybe questions about WHT? Head over to the help desk!

  14. #14
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,290
    bear,

    he could grep -v .jpg | grep -v .gif for example
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  15. #15
    Join Date
    Oct 2002
    Location
    State of Disbelief
    Posts
    22,948
    Simpler to user this?
    find /home/*/www/*.php -user nobody
    Having problems, or maybe questions about WHT? Head over to the help desk!

  16. #16
    Join Date
    May 2005
    Location
    Bay Area
    Posts
    1,211
    Why not just utilize php suexec?

  17. #17
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,290
    phpsuexec in some cases can cause problems with scripts. Some scripts cannot use php thats loaded as a cgi. Another common problem is the load overhead put on the server when using PHPSUEXEC.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  18. #18
    Join Date
    Sep 2003
    Location
    Washington, USA
    Posts
    3,219

    Re: Problem with spammer getting into the tmp dir

    Originally posted by recko11
    So ive got a spammer getting perl scripts into the /tmp/ dir.

    The directory is secured, however he is still getting it in.

    im running commands like

    cd /usr/local/apache/domlogs/
    grep "enviador.txt" ./* | more

    to search for what script has the vulnerability, but searches are comming up empty.

    Any idea where I should search next to see which script hes getting into tmp via?
    99.9% of the time hackers gain access to the /tmp through PHP vulns. Grep through your httpd logs searching for the filename of the spam script and secure the exploited PHP script accordingly.
    SHAW NETWORKS Simple. Professional. Reliable. Web Hosting Done Right.
    Low Cost & Award-Winning: cPanel Reseller Plans 24/7/365 Live Technical Support
    Website: www.shawnetworks.com Fast Response E-mail: sales @ shawnetworks.com
    Sick of downtime? Fed up with excuses? Drop your host! Switch to Shaw Networks.

  19. #19
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,683
    Originally posted by Steven
    phpsuexec in some cases can cause problems with scripts. Some scripts cannot use php thats loaded as a cgi. Another common problem is the load overhead put on the server when using PHPSUEXEC.
    The main - and I think only - thing that doesn't work with PHPSUEXEC is PHP_AUTH_USER and PHP_AUTH_PW. There's a simple workaround for that here - check out the notes to Chapter 34 "HTTP authentication with PHP", search for "charly" about halfway down in the notes. We really need someone who's prepared to spend a bit of time coding (Apache internals are inscrutable to me, I've looked) to fix PHPSUEXEC so it doesn't have this issue. I understand that with lots of users even a workaround is a bitter pill to swallow, but it's a small price to pay for removing much of your admin work/stress load.

    As for performance, I've noted a number of people saying that the performance as a CGI isn't that bad. If your machine is working near the limit of it's performance I can see it making an impact.

    PHPSUEXEC is really the obvious solution here - it becomes obvious fast who created the script in 99% of cases (I can think of some exclusions, but if the hacker is that smart you're in trouble anyway).

  20. #20
    Join Date
    Apr 2002
    Posts
    930
    phpsuexec and mod_security are both very good solutions. The user should at least look into these two methods to apply to their server. That being said, neither really help the issue that is at hand. The original poster has a vulnerable script on their server. Installing phpsuexec and mod_security will not help find that script, it will only help to prevent another exploit. Like it has been said though, it may just not be possible to find the script, however I would think a thorough search through the domlogs would find something.

  21. #21
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,683
    Actually, PHPSUEXEC and mod_security may help find the script a little, as at least he'll be able to see which user it is running as. And the work to install them should probably be done anyway.

    Cleaning out /tmp and rebooting the server may not be a bad way to go either. Also, check /var/tmp.

    If you have cpanel, you may also be able to turn on the tweak security settings to limit the number of emails per hour per user, and prevent nobody sending emails off-site, and to turn on the firewalling of direct connections to external email.

    Another thing you can do is just keep an eye on the output of the "top" command to see whether there are any long-running PHP scripts, or check the cpanel httpd status page which should list the same.

    Another trick is to go to /home and run a find command like:
    find . -mmin -120 -print | grep -v /mail/
    and look for possible script culprits in the output of that command. Be warned that the really smart ones download the scripts then run them, then delete them straight away so you can't find them.

    Hope this is more helpful.

  22. #22
    Join Date
    Oct 2002
    Location
    State of Disbelief
    Posts
    22,948
    Originally posted by brianoz
    Cleaning out /tmp and rebooting the server may not be a bad way to go either. Also, check /var/tmp.
    As well as /dev/shm and a host of other writable/executable directories.
    Having problems, or maybe questions about WHT? Head over to the help desk!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •