To find the immediate culprit is most likely a minor forensics exercise.
Check your access log and look at the queries that were active at 11:00 on Aug 20 (assuming that no diddling was done on the file after it was placed there).
If your logs are Apache and you have the 'time to execute' in your logs, you can subtract the time to execute from the log time to find your start time, otherwise you could probably get a pretty good bound by starting at 11:00 and expanding the search around that time. Also check your error logs for warnings or errors around that time.
Now, if your scripts directory can be written to by any other web server running on that box (why would 'nobody' be able to write to your scripts directory?), then you have much larger problems. Check your scripts directory to see if it is open for writing. The web server should never (there is an absolute...) be able to write to a directory containing trusted content (including scripts and html pages) unless you are very certain that this is the correct way to implement some solution (... and there is the hedging statement). There is major risk allowing the web server to have write access to anything except the most distrusted areas in your environment (as you have found).
If you have configured your directory to be writable by the web server, fix it. Now. If your vendor has set it up that way, or even worse, requires it to be set up that way, move to a new vendor, quickly. chmod and chown may help in this regard.
Security is a mindset, not just a checklist that one goes through to be able to say "Yep, secure". Vigilance in monitoring your logs, distrust of anything from outside (and sometimes even inside) of your program, knowing your environment, and considering the attacker's point of view in each and every block of code are just a start to good security.
--MidLifeXis
In reply to Re: Phishing question
by MidLifeXis
in thread Phishing question
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |