Our website has been hacked...

[SuburbanNinja]

Well.. Thank you for your help. As to your comment about not having logs etc... the problem here was that I was just tossed in to try and fix the website after it was hacked, since the last webmaster seems to have jumped ship. I was just asking if you knew about any probable exploits that they may have used and their limitations. And yes, it was brazilians. I've seen their work before

So thanks guys. I don't have to worry about the site anymore, I think waterman's getting one of his old webmasters to clean up his sloppy php mess :P

[XTC46]

You still may want to make sure it wasnt the server itself that was exploited, rather then the webpage. That webpage could be as secure as you want but if you have a gaping hole in your OS they can walk right in and do as they please.

[zencoder]

Hi Ninja,
sounds like many of our heavy hitters have weighed in on this for you, but I have one point to mention. I haven't been able to tell with my quick reading of this thread, but it sounds like waterman is hosting with a service...is he on a shared/managed hosting option, or does he own the server and have responsibility for admin? If its the latter, I would definitely consider moving it to a shared service. There are quite a few good ones, and it's a competitive industry so you can usually find decent pricing.
If he is paying for hosting, he (you?) should be actively working with the hosting company on this as well.
Just my $0.02. Best of luck.

[Donkey Punch]

I am thinking from reading this thread it is a disgruntled poster. They could so easily BS you into thinking they are some "1337" group from Brazil, and maybe so, but there are some things to check:

Canned (or custom) scripts paid or not can have exploits, and CGI vulnerabilities, SQL injections, cross site scripting exploits are common. I am suspecting the sploit came from either a known exploit in your software I see you are using Movable Type 3.121 the newest is 3.15. It clearly says it is a bug fix release. Perhaps getting the update would have helped. Or poor file permissions.

Here is an article on CGI vulnerabilities: http://www.net-security.org/article.php?id=91

Naturally, malicious CGI's exist, and can be set up, but I will not disscuss them, instead I will focus on the damage that can be done via your CGI's on your own host, not on the user surfing your web.

In order for an attacker to find an vulnerable CGI, all he has to do is to connect to port 80 and repeatedly send a GET request to CGI's on the server or suspecting they are on the server. Simply by checking your logs for repeated GET requests from a single remote host resulting in a 404, the 'file not found' error can give you an idea that something wicked is going on. As time passes, that same attacker may come up with an unsecure CGI on your system. If that is the case, he'll most probably try to exploit the vulnerability.

and if you plan to use CGI:

If you're planning on creating some CGI's of your own, bear in mind these few things: in perl and bash scripts, don't use the 'eval' statement used for creating strings which will be executed, be careful with popen() and system() calls, and turn off the server side includes. Also, don't leave any means for a client to manipulate with input of your scripts, don't rely on the fact that it will escape any special characters for they will be used by an attacker. It would be smart to check the 'suexec' documentation, for apache web server and use it on your server.

and further, the now defunct phrack has an article about CGI: http://www.phrack.org/phrack/49/P49-08

and is summarized in the following:

2. Vulnerabilities

The vulnerabilities caused by the use of CGI scripts are not
weaknesses in CGI itself, but are weaknesses inherent in the HTTP
specification and in various system programs. CGI simply allows access to
those vulnerabilities. There are other ways to exploit the system security.
For example, insecure file permissions can be exploited using FTP or telnet.
CGI simply provides more opportunities to exploit these and other security
flaws.

The CGI specification provides opportunities to read files, acquire
shell access, and corrupt file systems on server machines and their attached
hosts. Means of gaining access include: exploiting assumptions of the
script, exploiting weaknesses in the server environment, and exploiting
weaknesses in other programs and system calls. The primary weakness in
CGI scripts is insufficient input validation.

Some of the best ways to see how things are exploited is to see what the kiddies are doing. Look around and see what canned exploits are out there and see if there is a work around. There are also advisories for known products such as

http://secunia.com/

I wish you the best of luck