Keep in mind FTP sends your password in CLEAR TEXT. So the potential for compromise is definitely there.
Another thing to consider, is your FTP password UNIQUE to your hosting? Are you sure you're not using it ANYWHERE else? No other accounts, websites, etc?
How secure is your EMAIL password? I've been involved in cases where the "weak link" was actually the EMAIL password and the culprit was just sending "forgot passwords" to the email and deleting the evidence from the email box while everyone was too busy focusing on the compromised server to notice.
Just a few things that came to mind... some other things of course would be a social engineering approach with your ISP or some software vulnerability on your server or one of the packages your hosting.
There's more (obviously) but those are typically the "usual suspects".
UPDATE:
Based on this new information (that the hacker is not using FTP to change your files) I can only assume that the most likely cause is probably an unsecured web app.
That's not the ONLY thing it can be but in cases like this is the most likely.
Another thing to consider (and check for) is if he left himself some sort of "back door" to your app. I seem to recall you mentioning before that your ISP said he came in via FTP. Is it possible he came in via FTP the first time and left himself a back door?
Also, its a shot in the dark, but I have personally witnessed compromised boxes where a hacker only came in ONE time but left a cron job that kept changing files and other various evil. Is it possible that the hacker DIDN'T come back and you're dealing with an automated script? Just something to check if you feel you've exhausted all other possibilities.
Finally, do you have access to your web logs, system logs, etc? If so, what do they say? Do they reveal any clues?
I strongly disagree with Chris S's claim that all files/directories should be owned by root. There is a reason for the Unix permissions system.
There are two basic ways to run Apache/PHP. One is to run it as the www-data user, and have the files owned by a non-root username. Apache runs as a low-privilege account and must be granted access to particular directories/files in order to write to them. This is why Joomla has the ftp layer, to compensate for this. However, in a shared server environment, the fact that all files need to be world readable makes config files for other sites on that machine easily read.
The other way is to run Apache with PHP running suPHP, which is what CPanel prefers. In this case, Apache runs as a low privilege user, but, all PHP requests are handed to a script that changes the ownership to the username that owns the files. While you can now use Unix permissions to prevent other rogue scripts on the machine to browse your directories, any compromised PHP script is able to be run as your username and as a consequence, modify/deface any of the files owned by your username.
Since you're not well versed in server security, finding well hidden rootkits, etc on the machine would not be a fun task. First, you'd have to know whether the kernel was exploitable (unless you're running a very recent kernel, the answer here is yes), and whether anything had been affected. This particular hack usually occurs through a compromised FTP account at which point they are able to execute scripts. Since you found that code, it also suggests that the 'hacker' using it wasn't very sophisticated. There are many ways that he could have hidden that code and prevented your logs from seeing what he was doing.
mojah is correct. Once they get in, they try to run a script from /dev/shm/.something or /tmp that connects to their IRC network, or, acts as a takeover bot on undernet or another competing network. You'll likely find one or two scripts running, perhaps a cron entry to restart it, and, other remote shells hidden throughout your Joomla installation. Look for files in the /uploads or /images directory named similar to existing files. i.e. img_1034.jpg.php. They will usually hide their irc bot in multiple places that aren't web accessible so that you won't stumble across them when you log in, but, will have stashed their remote shells in places so that they can get back in and rerun their script and have it reconnect to their network.
In any case, the task you're faced with is somewhat tricky. You've got a site that you need to stay online, you lack some of the experience with these situations, and, you just want your site to work.
Take a dump of your database through Joomla's export function, make sure it is a complete dump. Create a second site and import the dump to verify it. Once you are sure you have a good, importable dump, make a backup of the site. Delete all files, reinstall Joomla, basic installation, use the existing MySQL connection information - it might believe you are upgrading, in which case allow it to upgrade. If you are on a VPS somewhere, perhaps have them hand you a fresh image and reinstall.
Best Answer
Restore from known-good backups. Otherwise, you may have to wipe and reinstall. A good rule of thumb is to NEVER trust a system once it's been compromised. There's too much chance that binaries have been replaced to hide a payload or backdoor.
As for the how, it may have been an SQL injection attack. Or some other way in. You were running everything with the latest patches?
This link is from a cache of an apparent hack into twit.tv (I think it's This Week In Tech). If you google the phrase you'll get a bunch of hits. Any time there's a scripted mass attack out there you're going to find chatter on different forums discussing it.
Again...DON'T TRUST THE SYSTEM. You probably should wipe and reinstall then restore database information from a previous backup...that's the safest route.