On Mon, 24 Jan 2011, Jefferson Cowart wrote: > We discovered last Friday that one of our web servers had been breached. > (Specifically we found at least one file had been modified and a few > additional files had been dropped.) The server runs Debian 5.0, and the > Debian supplied security releases are regularly applied. The only thing > we've been able to find that was out of date on the server was a CakePHP > framework. (We have found there was a recent vulnerability in that > framework, so that could have been the source of the issue, but we can't > find any evidence of that.) Based on backup logs we were able to > determine a time window when the new files were dropped. At this point > we believe the breach is limited to the web server process. This leads > us to believe that we have a problem in some script on the server. The > server hosts a mixture of vendor supplied files (a mixture of cgi (We > believe they are written in C, but we don't know as they are closed > source.) and php along with some in house written auxiliary pieces of > the system (php and perl). > > We have spent a while analyzing logs this weekend and unfortunately > haven't been able to find anything that lets us determine the source of > the problem. We did find some suspicious log entries (see > http://pastebin.com/yD3jSAJK). In each case the dropped files were > wrapped in calls to a vendor supplied file (cdm4/about.php). > Additionally all other log entries referencing cdm4/about.php were GET > requests not POST requests. However our analysis of that file didn't > reveal any problems; we confirmed register_globals is off, and we didn't > find any references to $_POST or $_REQUEST in the code. > > Unfortunately this now leaves us in the positions of knowing we have a > problem, but being unable to determine where the problem is. We are > getting pressure to get the service back online, but at the same time we > want to ensure everything is fixed before doing so. Any suggestions on > where we should be looking/going from here?
with my security hat on, the answer is to reimage the system, don't trust anything on the box you can't examine directly (i.e. web content files may be Ok, but binaries should be replaced) If you have some reason why you can't do this, you need to scan the box (nmap or similar) to try and make sure that there aren't any ports listening that you don't expect. but you really should plan on rebuilding the box as soon as you possibly can, ideally before putting it back online. David Lang _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
