You can still run the script, you just can't run it directly.
In your example instead of:
./script
run:
/bin/bash script
This will work.
You have to understand that noexec on /tmp isn't going to stop everything.
Someone on your server is running an outdated script. It could be an old phpBB script, it could be an old Wordpress script, it could be anything. But someone has or had an old script installed (probably more than one.. a lot more ... but don't get too alarmed by this, this is common on almost any web server). Hackers or some type of malicious user found this old script. Old scripts are usually old because they had a security hole in them. The hackers or malicious user used this security hole to exploit the script and gain access to your server.
They didn't get a whole lot when they gained access. All they got was the same access level that the user nobody has on the server (which isn't a whole lot, so don't think of this as a severe root compromise). That allowed them to place this file in /tmp and possibly execute it.
A properly configured firewall will prevent the script from making any connections. That may have been what happened here.
A good mod_security ruleset would likely also help prevent the old and outdated script from being exploited.
However, nothing compares to the security of a well up-to-date and maintained script. This is why it is so important that your hosting account users understand that when they install a script on their account, they are not done, they are just getting started. Installing a script on an account is step 1. Step 2 and so on is continuing to keep the script up-to-date whenever a new version is released.
To put this in perspective. If you have a server and it has one account on it. And that one account only runs Wordpress. If the owner of that account upgrades that Wordpress script the second that a new version is released. You basically have no need for mod_security. If all of the scripts on all of your accounts on your server are being kept up-to-date, then this is really the best security model that can happen.
(A gentle note, I wouldn't run a server without mod_security regardless if the above scenario is true. I'm just pointing out that mod_security is less needed in the above scenario. mod_security would still help to protect against 0-day exploits and exploits that reach the wild before the Wordpress developers can patch against it)
If you are not running suPHP when this was exploited, the only way to track the exploit is through comparing timestamps. You take the timestamp of when the exploit was created on the server. Then run through all of your domlogs to find hits that occurred on or around that timestamp. This will get you closer to finding the exploited account. You then just have to filter those results, look for PHP scripts, look for possible warning signs and find your culprit. It gets real fun, when the web script that was responsible for writing this exploit script is also an exploit script and then you have to do this all over again for that script.
Running suPHP allows you to narrow this down to a specific account. Then you can compare timestamps for all of the domlogs under that account, which should be a much smaller sample size and easier to find.
Comparing timestamps doesn't always provide an answer, which again is another good reason to run suphp. If timestamps come up empty, you at least know the account that was responsible for the exploit.
