Hacked? Or Not?

200 isn't an error. It means that Apache found the file it was looking for and returned a result. It doesn't necessarily mean that the exploit worked.

To see for sure if it worked, look in your /tmp directory. If you see a file named gicule, then the exploit worked. There'll also be a process running named gicule. Kill it immediately.

The company that hosts that file seems to have taken action against the person hosting it, since the file it downloads is now not accessible. This is good, but if you have the file it means I can't tell you what it does. Therefore it's probably best to assume the worst until proven otherwise. Typically these scripts run shells that people can use to perhaps root your box.

Keep us posted.

Well I checked /tmp and there is no file named gicule, and no service named that. chkrootkit revealed nothing also. Is awstats secure, or is it just a vulnerability that I should avoid.

I'm thinking that the exploit was unsuccessful, and I hope so, I just got my server working the way I want, I've spent quite some time learning it, but I actually need to start using it very soon, so I am concerned.

Is there any other way of knowing if this was successful?

Cheers.

Since it looks like it's trying to run wget, I'll assume that the exploit attempts to connect to another server… Do you have a firewall setup? If you have one setup to log any outgoing connections, you'd see a related connection attempt in your firewall logs.

Try running "netstat -nptl" as root and see if there are any ports open you don't recognise, or any programs you don't recognise.

Technically, it's possible that the script might delete itself after use or that anybody using the shell might delete the file afterwards. Few are intelligent enough to do this, though. I would take Beek's advice and check your firewall logs if you have them and they log connections. If they don't, then I'm not sure that there's a definitive way to tell if you've been compromised or not.

I would probably assume you're okay. But for next time, paassword-protect AWStats if possible, or move it into another directory. Same for other obviously-named scripts. Either will protect you from that sort of thing again.

Thanks for the advice guys, I have decided to err on the side of caution and go with a fresh install, it won't take that long and I'd rather do that now than put some web sites up for some people and discover that I have been compromised. I can definately count this as a learning experience and will definately put it somewhere else, or if I even use it all, is it an unnecessary risk? Or can it be run securely using a .htaccess setup?

Oh well better get compiling so I can have as little downtime as possible.

Cheers guys.

I am guessing the awstats program does not need to be accessed from everywhere?

If so, I'd use your main apache config or an .htaccess file to limit access to that dir by ip address. I believe this will work with the directive.

Order Deny,Allow

Deny From All

Allow 128.101.101.101

where 128.101.101.101 is the ip you want access it from should work. If you get a new IP on your connection at home, you'll have to change that. Not a big deal considering it renders all attacks like this useless.

Last April my server (at a different ISP) was compromised with a very similar AWStats exploit and the shv5 rootkit was installed. Luckily I noticed it quickly and since Apache was not running as root (very important!) I was able to easily kill it and remove the files.

I removed AWStats since it's an unnecessary risk for the small service it provides, but if you need statistics, you can apply access control like the previous poster suggested. Try this:

 <location cgi-bin="" awstats.pl="">Order Deny,Allow
Deny From All
Allow 1.2.3.4</location> 

to allow by IP address, or use password authentication, like this:

 <location cgi-bin="" awstats.pl="">AuthType Basic
AuthName "AWStats"
AuthUserFile /path/to/passwd_file
require valid-user</location> 

You can use "htpasswd -c /path/to/passwd_file username" to set the password.

You dodged a bullet this time, but you should do something because AWStats will likely have more exploits in the future, and you don't want to turn your LVS into a spambot!