LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 05-06-2010, 04:22 PM   #1
bombuzal
LQ Newbie
 
Registered: May 2010
Distribution: Debian,Centos,Ubuntu
Posts: 9

Rep: Reputation: 0
apache and/or php executing arbitrary code


As the subject says, my Apache has been broken into. Someone executed some exploit and gained root. PHP is secured with php-harden, but has
Code:
safe_mode=off (otherwise breaks lots of sites - it is a shared hosting)
register_globals=on
disable_functions = "shell_exec,exec,system,dbmopen,suexec,escapeshellcmd,show_source,escapeshellarg"
My question is: how can I audit through which site (lots of virtual hosts) it has been broken into?
I get something like this

sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 2: /tmp/back: Permission denied
sh: line 1: wget: command not found
sh: line 1: fetch: command not found

but this is in general log. When I grep for that patterns in access logs, nothing comes up. Any suggestions?
Can something be blocked through mod_security? Any quick recipes?
 
Old 05-06-2010, 05:02 PM   #2
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,791
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Don't shut down the machine, but do cut off network access. If you can pull the network plug or put up a firewall so that SSH is the only thing allowed and only from trusted IP addresses.

You'll probably want to start gathering information on what is currently running:

lsof --Pwn
netstat -anpe
ps -axfwwwe

Hopefully those may reveal a bit about who is running what, but if they gained root, tracks may have been covered. Also start looking at the CERT checklist and start developing a picture of what is going on.

Instead of grepping your access logs, you'll probably want to eyeball them and look for odd entries. If you have any idea of when the intrusion happened, that may help. Sometimes if the logs have been erased, the timestamp might be a clue. Also have a look at root's .bash_history.


Other useful information is going to include OS details, versions of Apache and PHP and if you've been keeping up to date with patches.

Last edited by Hangdog42; 05-06-2010 at 05:03 PM.
 
Old 05-07-2010, 06:08 AM   #3
bombuzal
LQ Newbie
 
Registered: May 2010
Distribution: Debian,Centos,Ubuntu
Posts: 9

Original Poster
Rep: Reputation: 0
I don't think there are any rouge processes running on the server, no external nmap scanning reveals anything etc. Anyway, the server is up for a clean reinstall ASAP.

But the main question still remains: if I boot up Apache, even the reinstalled with a freshest and patched version of everything, there is still a chance that some PHP application will execute some code, even if it does no serious harm... it can send spams or erase some 777 files.
 
Old 05-07-2010, 07:59 AM   #4
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,791
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Anyway, the server is up for a clean reinstall ASAP.
Maybe not the best decision at this point.

Quote:
But the main question still remains: if I boot up Apache, even the reinstalled with a freshest and patched version of everything, there is still a chance that some PHP application will execute some code, even if it does no serious harm... it can send spams or erase some 777 files.
And this is why your previous decision may not be a particularly good one. Unless you take the time to do an investigation, you could be setting yourself up for the same headache all over again. The bad guys already know where your server is and how to exploit it. If you just re-install they'll still know where the machine is and how to exploit it AND they'll also know that they have to be more careful next time.

There are a number of people here who have experience in analyzing cracked machines. If you're willing to do the work, you'll get some help.
 
Old 05-08-2010, 01:43 PM   #5
jiml8
Senior Member
 
Registered: Sep 2003
Posts: 3,171

Rep: Reputation: 115Reputation: 115
I presume you have mysql on the server as well?

I am sure that someone like unspawn will show up with some better ideas, but to the best of my knowledge, any PHP exploit has to be based on entering something in a textbox or listbox, and these usually wind up heading for a backend database. If you deploy mod security, this is what it will watch.

You might try checking and filtering your raw HTTP logs, looking for patterns in incoming data that would match known exploits, particularly sql injection attacks. This might let you find the problem.

You also COULD deploy mod security, but that very possibly will break functioning and properly secured websites. Speaking personally, I have switched hosting services in the past when that package was deployed on me without warning, resulting in LOTS of problems for me figuring out why submit strings that USED TO work didn't work, and why a client's email address broke the system, when no other email address broke the system.

Turns out that my submit strings contained a string that matched something in mod security, and the client's email addy also contained such a string. Mod security is very unintelligent about its tests; you match the string, you're gone. No context detection and, for instance, a string like "mycmd=setrequesttoone" will match because of the string "request" in the middle, when in fact the DANGEROUS string would be " request " (note the spaces around the word request).

So, a clean install is clearly warranted, and good luck with finding the problem. Wish I could help more.
 
Old 05-08-2010, 03:22 PM   #6
spampig
Member
 
Registered: Feb 2010
Location: /Earth/UK/England/Hampshire
Distribution: Debian, Ubuntu, CentOS, Slackware
Posts: 262
Blog Entries: 2

Rep: Reputation: 56
People often blame PHP and whilst it is incredibly easy to write incredibly dangerous code, it's not always guilty. Perl/CGI is often overlooked and can runs some devastating stuff and most people overlook just how much system access can be gained with Perl.

Probably stating the obvious, but don't overlook the obvious; don't rule out a weak root || privileged user password. A tool like Hydra or BruteSSH can smash that in no time at all.

The best advice is to fix it before you reinstall it, or you'll be in the same position in no time.
 
  


Reply

Tags
asterisk, exploit, lamp, php, security


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Apache/PHP: Executing 'at' scheduled jobs? bomix Linux - Software 11 01-23-2009 02:02 PM
apache php - executing commands using system(), problems Sambojambo Programming 3 05-29-2008 12:52 PM
executing C++ code from within PHP code vineet7kumar Programming 1 06-03-2007 05:13 PM
I want to count CPU cycles used by arbitrary code JonBrant Programming 4 11-10-2006 05:43 PM
Test php code on Apache backpacker Linux - Newbie 3 12-17-2005 05:14 AM


All times are GMT -5. The time now is 09:26 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration