Re: Interesting webserver intrusion (apache 1.3.31, mod_ssl 2.8.18, php 4.3.7)

[Tim Greer <chatmaster () charter net>]

On Fri, 2004-07-09 at 11:15, nathan c. dickerson wrote:
> Greetings,
>
> A few weeks ago, a webserver at my location was broken into. I caught 
> the attacker in progress before any damage was done, but the attack 
> itself was quite stealthy and surprising.
...

> We are now running Apache 1.3.31 with mod_ssl 2.8.18, which I thought 
> was secure. However; a few days ago, I noticed another successful 
> intrusion via Apache. Same callback scripts to get around the firewall, 
> same people.
>
> This annoyed me greatly, since they managed to execute commands via Apache.
>
> The standard error of their exploited httpd process would show up in the 
> error log. I believe the execution is done blindly.
>
> sh: line 1: /usr/sbin/apachectl: No such file or directory
> sh: line 1: cd: /var/tmp/...: No such file or directory
> sh: line 1: cd: /var/tmp/...: No such file or directory
> cat: /tmp/cmdtemp: No such file or directory
> rm: cannot remove `/tmp/cmdtemp': No such file or directory
>
> During the first attack, they uploaded binaries and a perl script in 
> /var/tmp/.../ , but since then,  with the addition of non executable 
> temporary directories, they have been simply using a perl script which 
> connects back to spawn a shell on efnet IRC (uploaded in /dev/shm !) -- 
> fairly clever.  The IRC callback shell leads me to believe the access is 
> blind. Again, they didn't have time to get root, as a combination of 
> spotting the activity quickly and running the latest kernel.
>
> I have obtained decently accurate time ranges of intrusion from the temp 
> files left around. After searching through alot of logs around those 
> time ranges, the only strangeness in the logs seemed to be (ips somewhat 
> hidden): 
>
> 64.110.x3x.217 - - [02/Jul/2004:12:04:17 -0700] "\x80L\x01\x03" 501 -

...

> This occurred several times from several different IPs at different 
> times, and 30 minutes before one of the scripts was uploaded. However, 
> it makes me wonder if it is a worm. I hope it is a worm, because if its 
> not, they are using a non disclosed apache hole, which is disturbing.
>
> If it is a hole in PHP, or one of the scripts on one of the 120+ sites, 
> it is very difficult to detect. It also wouldn't generate anything in 
> the error_logs (unless they do something silly), and the useful 
> variables GET and POST get tructuated in the access log, making my job 
> more difficult.


Sounds like one of the many PHP scripts is exploitable.  You could run
PHP as CGI w/ the suexec wrapper (and even tweak the source or use an
existing patch so PHP scripts don't need to be modified at all (other
than the ownership of some files/dirs PHP scripts need to use/write to).

Of course, this means that the exploit would allow the attacker to run
as the user and that might open a more serious hole if the user has
shell access or the exploit allows the attacker to do things the global
web server wouldn't allow (which is more likely).

You can check out mod_security or similar type of modules to log and
filter/block certain variables/requests, and so forth.  This sounds like
a standard PHP script exploit, and it doesn't sound like the attacker
knew much at all, which is usually the case--I'd not worry.  Hire a
qualified systems administrator to get your secure more secure and don't
sweat it.  It's unlikely to be an exploit in Apache or PHP itself
(though anything's possible--start worrying if you see more serious
signs).