PHP injected into server root 2

[audiopro]

I recently had a malicious PHP script added to my server root.
I have all the usual input checking in place but it somehow still got through.
This is on a site which is only partially live.
Can anyone suggest somewhere to read up on prevention measures?

Keith

http://www.studiosoft.co.uk

 

[jpadie]

What was the attack vector?
First thing is to make sure you have the perms right. Php should not have write permissions to a directory that can execute code unless you are sure that is really necessary.

 

[audiopro]

No idea about the attack vector, I have a couple of log ins to the outside world but these are protected by content checking. All non essential chars are blanked by default. The same with an image size .php script which has all inputs protected. I am not really sure what other route there could be into the server hence asking for suggestions of possible over sights.
This is on a site which I am currently working on and changing permissions constantly is a real pain.

Keith

http://www.studiosoft.co.uk

 

[ChrisHirst]

cPanel/WHM control panel?

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[audiopro]

Is that a vulnerability Chris?

Keith

http://www.studiosoft.co.uk

 

[ChrisHirst]

Many, mostly with the "Legacy file manager" that still cannot be disabled.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[jpadie]

also crm's like wordpress drupla joomla etc all have plugins which are intrinsically vulnerable and not fully supported. don't use any plugin that you don't understand and have yourself validated.

wordpress itself has vulnerabilities that are detected from time to time. so make sure you update.

bash is vulnerable. ensure you run apt-get update frequently (obviously first on the dev platform before rollout). and of course there was vulnerability in openssl, although this should have been plugged ages ago.

but of all of these it seems that the most likely is a vulnerable webform coupled with perms not being set correctly.

depending on the environment and the flavour of php consider hardening the platform using suphp/suexec. there's plenty of good stuff published by security consortia about how to harden webservers. but if you don't get the underlying file server right, then there's not much you can do about the application layer.

 

[ChrisHirst]

also crm's like wordpress drupla joomla etc all have plugins which are intrinsically vulnerable and not fully supported. don't use any plugin that you don't understand and have yourself validated.

Not only the plugins, some of the 'default themes' have flaws that can be used as an attack vector, even if they are not 'activated'.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[audiopro]

I don't use wordpress drupla joomla or any other automated content creation software so that is not the issue.
Following advice from various sources, I have been beefing up security on the VPS and double checking all form inputs.
I can get my head round sql injection and how that is possible but I am afraid that vulnerabilities in the server software itself are a great mystery to me.

Is it likely that the php script was uploaded to my root dir via ssh, are there other routes which could have been used or is the route unlikely to ever be discovered?



Keith

http://www.studiosoft.co.uk

 

[jpadie]

it won't be a vulnerability in php or apache. it will be most likely that you have a poorly coded form somewhere that has been exploited coupled with poor practice on perms.

there is no way you should architect your solution to allow php to write to your server root. change this and change the perms to secure it properly.

disable ftp too - as that is very insecure.

and if you're on shared hosting, migrate now.

 

[audiopro]

All my forms are custom made and handled by perl scripts. All form input is checked and non essential chars are substituted.
The only php I use is for image resizing and only writes files to internal dir's only.
I have some shared hosting but this problem has been on a VPS.

Keith

http://www.studiosoft.co.uk

 

[ChrisHirst]

If your VPS is a Red Hat variant (RH, CentOS or Fedora) you might want to check if your server is vulnerable to this exploit

https://www.digitalocean.com/commun...ver-against-the-shellshock-bash-vulnerability

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[spamjim]

You might check the date the file appeared with your server logs. The logs may show who was on the site at the time and who may have been kicking the tires to find a vulnerability... and where they settled to apply their attack.

If there is no log trace then you can be somewhat confident that the guy didn't exploit you via HTTP and your own scripting may be fine. In that case, you can narrow your focus to backend exploits, like the host's control panel.

Hang on to those malicious PHP scripts and modify them for your use (turning off any functions that "phone home"). The scripts are most often used to browse and edit files on a system. You can re-use them to determine how easily your site was exploited. I once dealt with a an exploited host that claimed to have patched their security hole. I was able to run the hacker's tool later to realize the host had done nothing to improve security.

 

[ChrisHirst]

And for cPanel logs to see what has been happening.

User Auditing.
/var/cpanel/accounting.log

For user actions and activity
/usr/local/cpanel/logs/access_log


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[audiopro]

One of the other sites on the server has had javascript code added to every index. file.

How is this possible?
What is the route this attack would have taken?

Keith

http://www.studiosoft.co.uk

 

[spamjim]

You can see how it is done by reviewing the PHP file that was dropped on your server.

This is a common effect. The bad guy uploads a PHP script that opens all files on the server, inserts code near a particular token in the file, and then resaves the file.

So this is a shared server, not VPS?

 

[ChrisHirst]

Possibles are;

Compromised FTP accounts;
WebDAV flaws, there are a lot which is why WebDAV should be disabled totally
FrontPage extensions, these are obsolete should be removed completely;
Compromised user account(s).

Is maldetect (maldet) and clamAV on the server and scanning every couple of hours?
If not install them and use a root crontab entry so it can remove anything suspicious.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[jpadie]

On every box I have administered that this has happened to there has been a poorly coded web form or ftp/WebDAV turned on. The high majority has been web form exploits.
Bottom line: even with bad forms this should not happen if your perms are set correctly (which you suggest is not the case)

 

[audiopro]

Thanks

It is a VPS.
I use FTP regularly, what is the alternative?
I have never heard of WebDab so need to do a bit of reading up on that.

Keith

http://www.studiosoft.co.uk

 

[jpadie]

WebDAV. No dab.
Ftp bad. Use sftp.

But you need to get to the bottom of the attack vector. Get the create time of the offending file and then go back and analyse all your Apache and php logs for an hour either side of that time. That should show you whether the exploit is via the webserver. Do likewise for your ftp logs.
Who is the file owned by? Is it the Apache user?
It is also a possibility that you yourself uploaded the file from your development machine and it is that machine that has been compromised.