Scripts on site changed... cause?

[instronics]

gore, I should have stated that more clearly. I can "get in through a back door" by running a PHP script that lets me enter shell commands through a browser. It doesn't let me do anything without entering the proper username and password. Anyone else who wanted to use it would need the Linux credentials, too.

For extra safety I remove this script from the server when I'm not using it. Of course, someone who can get defeat FTP security can put it on the server himself if he wants to. He'll still have to get through Linux security, though.

Ok, let me try to be more specific.

Using DNS arp poisoning, it is possible for someone to sniff unencrypted traffic in a network (a LAN) which is routed through the bad mans computer. Normally a browser would/could complain and warn the user, but most people just ignore warnings and click on OK/NEXT etc... to get their work done fast. That way, it is possible to get a FTP login credential.

After that.. the malicious user is able to upload a BACK-SHELL which is a PHP page with a ton of ready-to-run exploit scripts that make it possible to gain either root access and/or to RUN shell commands and/or to EXPLOIT SERVICES if found to be vulnerable. This INCLUDES modifying/adding lines to code to .htaccess files or any other file for that matter.

Saying that you are certain that these modifications are not done by hand... well with one of those back shells a simple click of the mouse's button will automatically do all that for you.

An example:


Using a back shell like one on the picture, it is 'possible' to execute/install:

- Root kits
- Remote back shell (like you mentioned above)
- Upload/Download files
- Change permissions
- Add/edit users
- Replace system files
- Gain root access
- Modify files
- Exploit the host OS or other services/daemons
- Brute force attacks
- Privilege escalation
- Alter log files
- Remove traces and evidence of any malicious steps taken
- etc etc etc....

The possibilities are pretty much endless, since most of the BACK-SHELLS are home made, so the attacker can basically implement ANYTHING his imagination and skill set will allow, or of course there are a ton of ready-to-download BACK-SHELLS like that with the latest exploits and vulnerabilities already implemented. Any script-kiddie could find one and download it.

Since it is a shared hosting machine... ANY user who has any form of upload rights (ftp) or is running a sql service that can be injected, could be a victim and an entry point to the host machine itself. Once a higher level access has been obtained on the HOST... its basically in the hands of the attacker. That could of course also mean, that any other user who has an account on that host might be the victim/culprit, and from there on the attack might have spread to other accounts like your mentioned clients. Out of interest... you say the modified code redirects you to some suspicious site? What site is that? I could imagine that the attacker is primarily looking for a way to increase his zombie network by infecting users with DoS bots.

My personal thought on the security of that hosting provider is: WTF..... SFTP is turned of by default???? He allows FTP access without encryption??????

Under such circumstances.... a large portion of the blame and security is the hosting provider's fault/issue. There are just too many alternative possibilities of fault here. Just to mention a few:

- Users (A common weak link in a chain of security). An other user on the same shared machine could be sharing his ftp password, or use a weak password.
- Outdated/unpatched services/OS
- Misconfigured services/OS
- No real security measures (IDS/Proper firewalling/encryption/monitoring) in place
- Laziness of the admin to check logfiles/messages/etc.....
- Many companies who have been compromised will NOT mention security breaches in order to maintain their name/image in public.
- <insert a ton of other reasons here>

In any case... you can not solve the issue without having root access to the host machine or the knowledge of securing it. Any service run on the host could be exploitable (mail/web/ftp/sql/this/that/etc...)

One more thing... you mention that you are thinking about going for a dedicated box. Do you have the means of securing & administrating this properly? If not, you could fall into a much deeper hole of security issues.

I may have missed a lot of other examples/info in this post, but I hope it helps you to get a general idea.

Cheers.