Security issues with PHP Sandbox

Question

I am working on a PHP sandbox for a Web Application Honeypot. The PHP sandbox will analyze a PHP file that may have been injected as part of an RFI attack. It should run the file in a safe environment and return the result, embedding the output of the PHP script. We hope to fool the attacker into believing that this is a genuine response and thus continue with the next step of his attack.

In order to build the sandbox, we used the Advance PHP Debugger (ADP). Using the rename_function and override_function, vulnerable PHP functions have been rewritten. Some functions such as exec,disk_free_space have been rewritten to send out fake replies. All the others function just return nothing. Here's a complete list of the functions that have been considered.

Also, the input script is run only for a maximum of 10 seconds in the sandbox. After that, the entire sandbox process gets killed.

1. Is this list good enough? Does this make the sandbox secure enough to be made part of the web app honeypot?

2. Beside blocking function calls like this, are there anymore security measures that should be taken?

3. In the end, this is a honeypot. So, we would like our reply to be as close as possible to a real reply. So, by blocking DNS function calls like dns_check_record and gethostbyname are we restricting the scope of execution for the script unnecessarily. (I am not sure why they are present in the first place)

   In short, I would like to know what elements I should add/delete from the list.

4. Any other suggestions/advice on how to go about this will be highly appreciated.

Answer 1

I'm far from being a PHP expert, so my comments are more general rather than specific.

1. Probably not entirely, but it depends. I don't think that any whitelist/blacklist approach can ever be 100% accurate. There will always be a case of false positives or false negatives. So you're always balancing between hits (of a script being able to still penetrate through your defences) and misses (i.e. successfully blocking the script, but in such a way that doesn't allow you further analysis). PHP must have thousands of different calls and permutations, so building a waterproof list is very difficult. That said, the list on a very quick glance looks ok as a starting point. Again, my php experience is limited.

2. I'm not sure what you meant when you said "to be made part of the web app", but I would rather strongly advise against embedding this with anything that is even remotely connected or in proximity to real data or any real production application. If this is a honeypot, it should probably be kept in as much isolation as possible. You should consider things like:

   • Running this on a dedicated hardware machine which gets regularly 'refreshed' (re-imaged, built from scratch)
   • Don't let it connect to anything other than the outside world
   • Don't store any sensitive (or even not so sensitive) data on it
   • Log all access and use an external firewall with verbose logging
   • Use internal OS system logging
   • Monitor anything even remotely strange on any of your logs
   • Consider throttling the speed of the external connection

   If the system is isolated well enough, then the main remaining risk besides to itself, is to other systems. Assuming the attackers went through your php protection layer successfully, your honeypot can be used to launch external attacks onto other systems - spam, denial of service, act as part of a botnet etc. This is why keeping it in isolation, keeping a close eye on it, as well as trashing and starting from scratch is a good idea.

3. Unfortunately I cannot answer that more than I already covered on 1.

4. See 2.

Answer 2

Your approach doesn't make a lot of sense to me.

You say you want to create a honeypot (i.e. a system which appears to be insecure) by disabling common attack vectors.

We hope to fool the attacker into believing that this is a genuine response

That implies you will only be able to substitute responses for attacks you have already characterized. And you'll be running a very different software stack to the system you are trying to model the behaviour of.

At best, this is going to be a huge amount of effort. More likely that you'll have something which is far from representative, which doesn't expose the vulnerabilities of the system you are modelling and which exposes this to any attacker. Your list is very far from being a complete list of things to disable/wrap for a secure PHP installation - but that's not the point.

I'd recommend that you revert to a standard PHP build and think about how you encapsulate and monitor the honeypot as a whole. You certainly want to implement the honeypot in a virtual machine (which you can copy elsewhere to study / take offline quickly / modify the build) and proxy and log all the server traffic to/from, with remote logging and (near) continuous integrity checking. By all means wrap key PHP functions / constructs with logging - but don't disable them.