What to do in response to a source code and/or database leak by a third party hosting provider?

Question

My PHP sourcecode and database (PHPMyAdmin Dump) has been leaked publicly and I believe that the web host I have used for this service are responsible for the leak.

On first appearances, the web host appeared to be very professional, although they were not a well known, large company. I have not had any issues with any other web host I have used.

I believe on my part I used a very secure password for my account. However, I have found data dumps of my application code and database dated 10 minutes after my upload.

Is there anything I can do? What steps can I, or others in my position, take to ensure the safety of our intellectual property and our users' data? What preventative steps can be taken and what measures should I take now I find myself in this position?

Answer 1

I believe that the web host ... are responsible for the leak.

Is there anything I can do? What steps can I, or others in my position, take to ensure the safety of our intellectual property and our users' data?

Inform your users.

Let everyone know about the leak especially if their passwords were exposed. Be honest and sincere. Do not blame your provider until you have positivly indentified them as the source of the leak (see next section). People often use the same passwords on multiple sites, so a delay in informing a user may put them at additional risk on other sites.

Identify the source of the leak.

You suspect your host provider, but it may not have been them. If you distribute your source code to your host by ftp or other encrypted methods it may have been intercepted in transit. The computer used to write the code may have been compromised. If you are not the sole developer then one of the other developers may have leaked the code. Review all the places that the leaked information has been, who had access to it, and how it was transmitted to the next location.

That said, it may have been your hosting provider. Have you asked them? Unless your provider is very small they have a number of employees and clients and may not have noticed your leak. Inform them of the problem . The hosting provider should be interested in helping you even if they made mistakes which lead to you leak. Typically the hosting provider will have a lot more traffic information and logs then you have and will be esential in finding the source.

Finding the source of the leak is important. If you do not know what happened you wont know if you fixed it.

Unfortunatly at this point, if the data is public there is not much you can do. If you see your data or code on another site, politely inform them and nicely ask them to take it down. Threatening another site is not usually helpful, and depending on how wide spread your data it, one site out of many makes little difference.

What preventative steps can be taken and what measures should I take now I find myself in this position?

I assume you mean for next time since at this point you are way past prevention. A lot will depend on what the source of the leak was. If it was your provider you will need to consider whether you want to stay with them or change. Changing providers will not necessarily prevent future incidents unless the provider includes more robust security then your current provider. Make sure that transmission of sensative data is always encrypted with a secure protocol like HTTPS or TSL. Make sure that your sorce code repository is secure. Add an Intrusion Detection System to your server. Read your log files. Unfortunatly almost nothing works as well as regularly reading your log files and learning the typical patterns.

Answer 2

There is very little information in your question, so it is difficult to give a concrete answer.

Before your blame the hosting company or even sue them, you should review your own program code, including all libraries and web applications you have installed.

You should especially look for SQL injection, shell code injection, various ways of remote code execution. A common vulnerability in old versions of many common PHP applications is the writing of files with configuration settings or user uploaded files that can be executed as .php files by visiting the appropriate url in the webbrowser.

The OWASP Top 10 and especially the PHP Top 5 of the Open Web Application Security Project are a good starting point.

Furthermore check that the php files are not world readable on the server.

There are two things you could test on your hosting provider. But depending on the legislation, you are in, this may not be a good idea:

• Can you look into other peoples folder by going up in the directory tree in the ftp/sftp/ftps/scp program?
• Can your PHP programs read files of other people?