Scripts on site changed... cause?
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Scripts on site changed... cause?

  1. #1
    Junior Member
    Join Date
    Jan 2012
    Location
    California
    Posts
    6

    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.

  2. #2
    Antionline's Security Dude instronics's Avatar
    Join Date
    Dec 2002
    Posts
    901
    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.
    Ubuntu-: Means in African : "Im too dumb to use Slackware"

  3. #3
    Junior Member
    Join Date
    Jan 2012
    Location
    California
    Posts
    6
    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.

  4. #4
    Gonzo District BOFH westin's Avatar
    Join Date
    Jan 2006
    Location
    SW MO
    Posts
    1,188
    Do you have access to the webserver logs? You could look for weird requests during the suspected time of the breach...
    \"Those of us that had been up all night were in no mood for coffee and donuts, we wanted strong drink.\"

    -HST

  5. #5
    Junior Member
    Join Date
    Jan 2012
    Location
    California
    Posts
    6
    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!
    Last edited by Orthoducks; January 19th, 2012 at 02:03 PM.

  6. #6
    HYBR|D
    Guest
    I've just manually approved 2 post's, something farted. Thread looks normal now.

  7. #7
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    Quote Originally Posted by Orthoducks View Post
    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?
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

  8. #8
    Junior Member
    Join Date
    Jan 2012
    Location
    California
    Posts
    6
    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.

  9. #9
    Antionline's Security Dude instronics's Avatar
    Join Date
    Dec 2002
    Posts
    901
    Quote Originally Posted by Orthoducks View Post
    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.
    Last edited by instronics; January 20th, 2012 at 09:36 AM.
    Ubuntu-: Means in African : "Im too dumb to use Slackware"

  10. #10
    AO Guinness Monster MURACU's Avatar
    Join Date
    Jan 2004
    Location
    paris
    Posts
    1,002
    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
    \"America is the only country that went from barbarism to decadence without civilization in between.\"
    \"The reason we are so pleased to find other people\'s secrets is that it distracts public attention from our own.\"
    Oscar Wilde(1854-1900)

Similar Threads

  1. Firefox marketing site hacked
    By intmon in forum Security News
    Replies: 1
    Last Post: July 15th, 2005, 06:52 PM
  2. Is This Really A security Site
    By SwordFish_13 in forum AntiOnline's General Chit Chat
    Replies: 19
    Last Post: April 5th, 2004, 04:40 AM
  3. VeriSign sues ICANN to restore Site Finder
    By SDK in forum AntiOnline's General Chit Chat
    Replies: 0
    Last Post: February 27th, 2004, 02:56 PM
  4. Tcp/ip
    By gore in forum Newbie Security Questions
    Replies: 11
    Last Post: December 29th, 2003, 07:01 AM
  5. Al-Jazeera Web Site Faces Continued Hacker Attacks
    By DigitalSyntax in forum Web Security
    Replies: 0
    Last Post: March 27th, 2003, 07:25 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides