FTP sniffing trojan - how do you handle it?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Pedja
    Senior Member
    • Mar 2004
    • 329

    FTP sniffing trojan - how do you handle it?

    For some time trojans that sniff FTP login parameters are making me big headdaches.
    Have you met them? How do you handle them?

    It works like this:

    - you access compromised site, which contains iframe that loads malicious script. Until recently your antivirus did not react on such code.

    - malicious code attacks your browser (IE, Firefox, Opera, PDF reader, Flash... all are vurnelable) and installs itself on your computer.

    - you now have trojan installed. Each time you access any FTP account, username and password are sniffed and sent to trojan owner. Some trojans also know how to read saved passwords from some well known FTP aplications, so saving passwords in no more an option, even if you maintain number of sites. There are even suspects that some trojans sniff keyboard to get passwords.

    - after some time, bots start accessing all FTP accounts they know about and alter index*, main*, and default* files inserting iframe that loads malicious code.

    - visitors of the sited als get infected and if they also maintain some sites, their ftp accounts are also compromised.

    - there is no antivirus, anti mallware or anti rootkit that detects these trojans. The only way to find out that you have it is to see that your sites are altered.


    Recently, antivirus software started to recognize malicious <iframe> in web pages, but only if they scan http. Also Google started to block sites where it crawled malicious <iframes>. This helps limiting trojan spreading but it is far from successful.

    I have lots of problems with this. My clients are asking for my help and I do not know what to say, except that they should format hard disks and reinstall system.

    My idea was to limit FTP access by IP address, but cpanel does not support that. It can only limit specific address, not limit everything but known addresses.

    This pest makes FTP service unusable. If there is no option to control access by FTP, then there is only solution to stop FTP service in whole.

    Good thing is that trojan is not able to sniff SFTP connections so, using SFTP (check WinSCP) is good alternative (Dathorn supports it). If you are attacked, change FTP passwords and DO NOT USE FTP ANY MORE.

    If you met this pest share your experience and knowledge. Do you think we should ask Dathorn to provide some measures to help about this?
  • Frank Hagan
    Senior Member
    • Mar 2004
    • 724

    #2
    The most recent version of FileZilla also supports SFTP.

    I have had one customer get hacked with "Gumbler" that sounds similar to this. We cleaned it up quickly enough, but it was a hassle. I found one "site scanner" that checks for the obfuscated javascript (it actually checks all pages and links on the site). It is at http://unmaskparasites.com

    Comment

    • Pedja
      Senior Member
      • Mar 2004
      • 329

      #3
      I have no problem finding hacked documents on site. Problem is computer that is used for stealing password. I even managed to isolate single computer that is surely sniffed, but I was unable to find anything suspicious on it, nor any other computer I suspected as compromised.

      I tried with number of antivirus, antimallware, antirootkit ant similar scanners. Nothing found anything suspicious. Regardless, when computer is used for FTP access, after password is changed, new password is sniffed and account is hacked.

      Comment

      • AndrewT
        Administrator
        • Mar 2004
        • 3653

        #4
        The only real solution is to clean up the computers, keep them clean, and stop using regular (unsecured) FTP. Anything else would just be a band-aid that doesn't fix the actual problem, which is the compromised computer or network.

        Comment

        • ZYV
          Senior Member
          • Sep 2005
          • 315

          #5
          We've already discussed this issue somehow over here: http://forums.dathorn.com/showthread.php?t=3539 ...

          Actually I don't think that SFTP will be of help, unless you use certificates, because if you save the password in your FTP client it will stored in encrypted form, but this encryption is reversible anyway, so that the client itself can send it to the server even in the SSL-encrypted form.

          So on top of what Andrew's just said, I would actually recommend not storing the password on the hard drive...

          But anyway, once your computer has been compromised you are not safe anymore. It's like when you've lost your keychain will all your keys. It might never cause any harm if you dropped it into the deep river, but you might be very well robbed next day.

          Comment

          • Pedja
            Senior Member
            • Mar 2004
            • 329

            #6
            Guys, what you've saying is all I already said in the first post. It is not an issue.

            I am speaking from the angle of host. There sia problem, number of sites are hacked, pest is wide spread and clients are not to blame, as trojan is sophisticated and undetectable. My point is how to protect server from being hacked.

            Thats how Andrew thinks when someone abuses server, he simply uses his power to prevent abuse. This is the same situation.

            For instance, Dathorn closes SSH connections that stay to long by they opinion, and even banse SSH for client stat frequently use long SSH connections. Why? Because that is suspicious. Also, Dathorn bans IPs which from unsuccessful login attempts come. They are very rigid, so even valid IP will be banned because of few password errors. That is also prevented as suspicious.

            Now we have a pest, that obviously abuses server, and it does not ring bells?!?!?!

            It is clear that clients should clean their computers but that is not an easy task as trojan is not detectable. Until means for detecting and cleaning are found, something should be done to minimize damage - not just to the attacked sites, but from further spreading of the pest. This is not just suspectful behaviour, this is the real threat.

            So, now, it seems like banning SSH connections just because they last longer, or banning IP just because of unsuccessful login are not band aids, and they need rigid measures, but real FTP attacks are not? I see no logic in that.

            I would like to see for instance that FTP access is blocked somehow, by preventing all IP's except approved ones (this is currently impossible on Dathorn), or simply by preventing all FTP access and instructing clients to use SFTP (I do instruct them do use SFTP, but I cannot prevent them from using FTP).

            Of course, I would like to see any other kind of measure that would help preventing damage. Also, I would like to hear some good advices how to detect and clean the pest. Advices as "one should clean his computer" are not helpful at all. Everyone knows that. Problem is that these new beasts are hard to detect and clean.

            Comment

            • ZYV
              Senior Member
              • Sep 2005
              • 315

              #7
              It is clear that clients should clean their computers but that is not an easy task as trojan is not detectable.
              OK, how come it's not detectable? I use the latest licensed Kaspersky with today's bases on a machine which runs Windows Vista and it easily detects this kind of trojans. Have you actually tried this?

              By the way, mind you that it might not be possible at all to detect a rootkit on a machine, when it already as ring0 access and the antivirus software was installed afterwards, because it can actually intercept any interrupt before the software was installed and trick it into thinking that the machine is clean, rendering the detection mechanisms useless. If you want to clean a machine with minimal effort, then disconnect its hard drive and plug it into a cleaning workstation, BUT the proper solution, of course, would be a clean install.

              Why? Because, as I have said earlier, when you've lost your keychain, you're out of luck. You can't trust this machine anymore. You can't trust the data it carries. You can't trust ANYTHING.

              In the Unix world what we do is just to reinstall the system on a clean drive and then install the packages that were installed on the system, restore the configuration from the latest trusted backup and then restore the data from the last trusted backup.

              This is a quick and easy task if you have your backups, because the configuration is stored centrally in text format, all software is packaged, so the installation is automated and the data resides in a separate directory tree.

              Of course, this might be much for difficult for Windows users, but if you use Windows, you're quite used to pain and maybe you even appreciate it, so anyway, it's doable and it's the only proper way around it.

              Of course, I would like to see any other kind of measure that would help preventing damage.
              I think that allowing resellers to disable FTP and forcing users to use SSH with key-based authentication is the way to go, but mind you that you can pretty much exclude anything which requires manual WHM/cPanel modifications, so frankly speaking I don't believe you're ever going to get anything like this...

              Comment

              • AndrewT
                Administrator
                • Mar 2004
                • 3653

                #8
                I would love to disable regular FTP server wide but that is so obviously not feasible. Many, many customers use it without issue. This would create the biggest mess of problems ever.

                As for restricting FTP to certain IP addresses, this isn't particularly useful given the dynamic IP addresses that most are using. It would once again just create more of a hassle for those that are using FTP without any problems. There is no way that this could be setup on a per domain basis as it would require server wide firewall rules and exceptions for it to be effective at all.

                Like I (and you) have said, the problem is with the end users. We've had this happen to numerous customers and most times they were able to find the infection that caused it. I don't have specific cleaning recommendations as I have personally never had to deal with.

                Smart web browsing goes a long way. IMO, everyone should be using Firefox with NoScript or similar. You just can't trust anything any more as malware javascript is making it into advertisements on mainstream websites.

                Comment

                • Pedja
                  Senior Member
                  • Mar 2004
                  • 329

                  #9
                  Ok, Andrew, then you should remove prohibitions of unsuccessful login attempts and long SSH connections, and any other policy that prohibits us and our clients do do things that are perfectly valid but may be used to make damage. Otherwise you are playing with double standards.

                  Now, I even have more serious problem: only cpanel user can use SFTP. It there are other FTP accounts for one cpanel account they cannot use SFTP - so recomendation for using SFTP is out of question - my clients must use FTP as they need several FTP accounts on single Cpanel account.

                  That means they are going to be sitting ducks as we are all because of Dathorn policies that allows someone with bad intentions to shut down any account on Dathorn if he knows what to do to trigger Dathorn watchdogs.

                  Unfortunately, this is not the first time that we, as Dathorn clients are suffering this.

                  What we actually can expect is that Dathorn starts suspending sites which are attacked, as they are spreading malicious code, which is forbiden by Dathorn policies - story that we've seen before.

                  Comment

                  • AndrewT
                    Administrator
                    • Mar 2004
                    • 3653

                    #10
                    You are comparing completely different and unrelated things. Blocking brute force attempts is far from blocking regular FTP access entirely. The latter would easily cause mass havoc. The comparison is completely meaningless and does not help. What started as an informative discussion has now turned in to a completely unwarranted attack towards us.

                    We are not the problem here. You are looking for a server side fix to a problem that is purely on the client side. The bottom line is that these users are getting their login information compromised through infected computers. Of course the server is going to allow a login with valid login information. It may be FTP now but it could easily be any other protocol down the road. Would you want us disabling email, SSH, cpanel, etc. as well?

                    Comment

                    • ZYV
                      Senior Member
                      • Sep 2005
                      • 315

                      #11
                      Pedja, you keep confusing responsibilities. Limiting the number of people who can try to open the door with the key that doesn't fit is not the same that limiting the number of people with valid keys by letting in only those who come from New York.

                      Stupid users with valid login credentials are *your* problem, because as I've said earlier, once you have installed a trojan on your machine it can't be trusted anymore. They might very well capture your saved SSH password and use this for SCP, FTP is what they're using right now because it's simple and it works.

                      Why wouldn't you try passphrase-protected SSH keys for SCP? You can have many of these if you want. The only downside is that you can't limit different users to their folders, but other than that it works quite nicely and it's impossible to sniff. Even if you have a trojan installed, it would need to

                      1) capture your key
                      2) capture your passphrase from keyboard

                      and the latter is much more difficult, than just decoding the FTP password, because many SSH clients have protection against keystroke logging etc.

                      You didn't mention whether Kaspersky did the trick, by the way.

                      Comment

                      Working...