Scripts on site changed... cause?

Printable View

January 18th, 2012, 06:23 AM
Orthoducks

Scripts on site changed... cause?

I'm facing a security problem on my client's web sites, and need some advice.

Two sites have suffered a total of three security breaches over the past several months. In each case a PHP script in the site's document space was modified to redirect the user or load content from a suspicious site.

The last time this happened was over the past weekend. The thing that was different about this incident was that it happened despite a very strong password that should have made it essentially impossible for anyone to get access to the FTP account.

I sent the hosting service a support request, asking for a copy of the FTP log and any other assistance or advice they could provide.

I got the log, which showed no FTP access to the modified file during the period when the breach occurred.

With the log I got a form email which said in effect, "We're very concerned for your security, but we aren't responsible for anything that happens to your site. If you can't fix the problem yourself, here are some great security tools and services you can buy..."

They made a list of suggestions, none of which seem to apply to this case. The FTP password is now very strong, as I said. There is no commercial software on the site to be infected. The site does not have any downloadable software that might be infected, and does not allow users to upload anything or post messages.

I'm not expert enough to be certain that the applications I developed for my client are bulletproof, but I don't see how any sort of "front door" attack, like a SQL injection attack, could lead to the problem we've encountered.

I'm pretty sure that when I contact tech support again, they're going to want me to prove that the problem isn't mine before they'll look at it. Which is my reason for seeking help.

Is there any way a vulnerability in my code could enable someone to modify files in my document space?

If so, I'd appreciate pointers on how to correct the vulnerabilities, if there are any, or prove that there aren't, if there aren't.

Once I've done that, I'd appreciate pointers on how to demonstrate to the hosting service that the ball is in their court.
January 18th, 2012, 11:53 AM
instronics

Quote:

The last time this happened was over the past weekend. The thing that was different about this incident was that it happened despite a very strong password that should have made it essentially impossible for anyone to get access to the FTP account.

I sent the hosting service a support request, asking for a copy of the FTP log and any other assistance or advice they could provide.

I got the log, which showed no FTP access to the modified file during the period when the breach occurred.

Apart from ftp access, is there any other way to access that machine? SSH/Telnet/rlogin or the likes?

The ftp password could have been sniffed (man in the middle), so no matter how long the pass is, it gets stolen and ftp is clear text unless you use sftp or the likes. (dns poisoning maybe?).

What other services on that machine are in state listen? (unix/linux: netstat -patune |grep LISTEN) (dont know for windows, but you get the idea).

Maybe an exploit in one of the other services giving a shell or reverse shell access?

Are there any php files anywhere that DO NOT belong to you? (back shells?)

Also it would help to know what OS the machine in question is running, and what services (also versions).

Maybe run some sort of rootkit hunter or the likes to look for suspicious files that might have been altered or replaced.

For future reference, maybe also a host based IDS that keeps an eye on files etc...

Whatever the case, some more info would be nice to get a better picture of the possibilities.
January 18th, 2012, 04:23 PM
Orthoducks

Thanks for the suggestions. I'll respond as well as I can.

First, you're using some terms that I don't know (DNS poisoning, back shells), so not everything you said is clear to me. I can look those up, but I have little time right now, so I have to respond first.

You're assuming I have complete access to the server. Unfortunately, I don't. It's a shared server, and it's locked down pretty tight, at least as far as letting me do things I legitimately want to do is concerned. I don't even have shell access, although I've figured out how to get it through a back door. I certainly don't have root access or superuser status, so a lot of the things you suggested are probably impossible.

(A word on the shared access thing... it was chosen before I was on board, as was the host. With this host we don't have a choice except to get a dedicated server and take complete responsibility for the system's operation. We're not equipped to do that, and so far changing hosts has been too big a step. This incident has us talking about it, though.)

All I know about the system is what phpinfo tells me: it's Linux. Maybe the rest of the goggledygook will tell you more: "System" is "Linux p3nlh270.shr.prod.phx3.secureserver.net 2.6.18-274.7.1.el5PAE #1 SMP Thu Oct 20 17:03:59 EDT 2011 i686," and "Build Date" is "Aug 26 2010 08:49:13."

I'll try to do more investigation later today. I have very little time during the week, though, so it may take me longer.
January 18th, 2012, 06:36 PM
westin

Do you have access to the webserver logs? You could look for weird requests during the suspected time of the breach...
January 18th, 2012, 07:09 PM
Orthoducks

Some additional notes.

I looked up DNS poisoning, and it's certainly possible, but it's not clear how I'd diagnose it or fix it. I don't even know how to find out what DNS server would be involved. The hosting service is large, and may well operate its own DNS server, which would explain why I'm having problems with two different domains on the same host. Again, though, it's not clear to me how DNS poisoning could lead to modified files in my address space.

I couldn't find any clear references to "back shell," but there were references to "connect-back shell." I gather that's a shell that automatically connects to a user when it's started. I don't think there is such a thing on our server; we're not supposed to have shell access at all, so I'm quite sure there isn't supposed to be!

All of these break-ins look automated to me: a little code was appended or prepended to index.php or .htaccess. There's no indication that a human hacker has ever looked at one of our sites. That's consistent with my belief that nothing like a call-back shell is involved.

Up until now I thought the host simply did not support secure FTP. I just discovered that they do, but it's disabled by default -- you have to request them to turn it on. We'll be doing that, if we stay with the host long enough for it to matter!
January 19th, 2012, 10:09 AM
HYBR|D

I've just manually approved 2 post's, something farted. Thread looks normal now. :)
January 19th, 2012, 08:45 PM
gore

Quote:

Originally Posted by Orthoducks

although I've figured out how to get it through a back door.

Was I the only one who didn't miss that or something? If he can do it anyone else can... He said he isn't root with this account from a "back door" but how hard is it to get there from a normal account I mean seriously?
January 19th, 2012, 08:56 PM
Orthoducks

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.
January 20th, 2012, 10:07 AM
instronics

Quote:

Originally Posted by Orthoducks

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:
http://www.antionline.com/images/ieimages/2012/01/1.jpg

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.
January 20th, 2012, 01:27 PM
MURACU

Not a lot you can add after Instronics post but a few things i would do are:
Firstly change all my passwords to the server.
Activate SFTP.
To investigate the issue check the time stamp on the script to see when it was modified if possiable. Use this to verify the logs on the server and check what was connected at these times. the server may also be able to give you the account which modified the script(this will depend on the way the server is set up).
Lastely if you are not sure of the security provided by the web hosting company check around for a new one.
Cheers
Muracu
January 20th, 2012, 02:50 PM
Orthoducks

Instronics and Muracu, that's a lot of very helpful information. (My only criticism is that there's no real connection between it and my easily misinterpreted comment about a "back door!")

Some specific responses:

Quote:

Saying that you are certain that these modifications are not done by hand...

The lawyer in me says I should point this out: I didn't say that; I only said that they "look automated to me." I detest people who claim to be certain of things that are merely possible or probable, so I'm sensitive to imputations that I have done it myself (and I am mortified when I actually do it myself)!

Quote:

Out of interest... you say the modified code redirects you to some suspicious site? What site is that?

There has actually been a fourth attack since my OP... same domain, same technique, different site. The first one was http://margingradient.ru. The second was http://changedivstyle.ru; the full URL was http://changedivstyle.ru/vis/index.php.

I've set permissions on both .htaccess and index.php to 404, which I hope will stave off further attacks until I can resolve the root (pun intended) problem.

Quote:

He allows FTP access without encryption??????

Not merely allows it... practically requires it. I didn't even know SFTP was available until I stumbled across the fact on another blog while researching this problem. My reaction is about the same as yours, although I confess that I shrugged it off until we started having problems.

Quote:

In any case... you can not solve the issue without having root access to the host machine...

That's pretty much what I wanted to confirm. It sounds like the only thing I can do on my own initiative is demand SFTP access, and I can't even get it without the host's cooperation.

Quote:

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?

No, we most certainly do not. That is what has deterred me from recommending it up to now.

If we do go to a dedicated server, we need to find another host who will provide one while retaining responsibility for system management. I recognize that that implies the host will retain a great degree of control... we can't expect them to be responsible for system management if we have authority to fool around with the HTTP server's configuration and such. That's not a problem for us... lack of security, and lack of ability to control things like php.ini, are problems.

Quote:

...check the time stamp on the script to see when it was modified if possible.

I did that, and found that the break-in was not logged. I infer (but cannot prove) that it was not accomplished through FTP.