Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security

New In-Memory Rootkit Discovered By German Hoster 91

Posted by Soulskill from the malware-arms-race dept.
New submitter einar2 writes "German hoster Hetzner informed customers that login data for their admin surface might have been compromised (Google translation of German original). At the end of last week, a backdoor in a monitoring server was found. Closer examination led to the discovery of a rootkit residing in memory. The rootkit does not touch files on storage but patches running processes in memory. Malicious code is directly injected into running processes. According to Hetzner the attack is surprisingly sophisticated."
This discussion has been archived. No new comments can be posted.

New In-Memory Rootkit Discovered By German Hoster More

New In-Memory Rootkit Discovered By German Hoster

Comments Filter:

  • Kinda cool that they found it (Score:2, Interesting)

    by Anonymous Coward

    Even if you notice strange traffic, how do you actually find something that is only in memory?

  • This has actually been around since at least 2006.

    Russian spam operation EvaPharamacy have been using this approach to turn public servers they don't own into free hosting for all of their rogue pharmacy sites.

    You can read a pretty detailed description of this here:

    http://pharmalert.zoomshare.com/1.html [zoomshare.com]

    The people who run EvaPharmacy (criminals, in my opinion, but also in others' opinion) do a lot of destructive things to your server while installing their proxy hosting / DNS software on your server, and they leave no trace of any files at all.

    ad

    • http://pharmalert.zoomshare.com/1.html

      A fascinating description, but since it is wrong on a very simple point I have to doubt the whole thing.

      They modify your shadow file so that it is unwritable (read only.) This stops you from being able to modify your root password, and all others.

      The shadow file on one of my servers is, right now:

      ----------. 1 root root 1125 Jun 7 18:13 /etc/shadow

      And I can change passwords just fine. Funny thing about setuid root programs, they can change permissions on anything.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        I believe they mean with chattr, not with permissions:


        $ sudo -s
        # touch file
        # chmod 000 file
        # ls -l file
        ---------- 1 root root 0 Jun 7 15:28 file
        # cat > file
        asdf
        # cat file
        asdf
        # chattr +i file
        # cat > file
        bash: file: Permission denied

        • Re: (Score:2)

          by fisted ( 2295862 )
          as root you can just chattr -i the file. Pity lunix doesn't have a feature like FreeBSD's securelevel [freebsd.org].

          • It does leave you scratching your head for awhile first however.

            And rookies wouldn't know about that at all.

          • Re: (Score:2)

            by kasperd ( 592156 )

            Pity lunix doesn't have a feature like FreeBSD's securelevel.

            You can't expect to have that sort of features on a 16 bit architecture. Managing to produce a unix system with just the basic features and capable of running on only 64KB of RAM is quite a feat.

            • Re: (Score:2)

              by fisted ( 2295862 )
              16 bit? What are you even talking about? Embedded? Anyway, i doubt it would be hard to implement securelevel, since it is essentially just one integer and a couple comparisons of it against constants.

              • Re: (Score:2)

                by kasperd ( 592156 )

                16 bit? What are you even talking about?

                My bad. I just checked what Wikipedia had to say. And it turns out the 6502 [wikipedia.org] is actually an 8 bit CPU (even though it has 16 bit addresses).

  • yank out the sticks (Score:3)

    by SpaceManFlip ( 2720507 ) on Friday June 07, 2013 @05:41PM (#43941081)
    Quick! Pull all the RAM sticks from the servers!

    Throw them in the fire! Then piss into the fire with a frosty Heineken pee pee....

    Cauterize the germs!

    My main question is how the rootkit process made its way into the RAM of the afflicted machines (?).

    • Joking aside, wouldn't you expect a restart to eradicate a RAM resident rootkit? Granted the vulnerability still exists and it is possible to be reinfected/rerooted, a simple reboot should get rid of this.

      • The rootkit itself was most likely not in RAM only, but the way it exploited daemon processes was. Restarting would just have the rootkit re-infect your daemons at launch.

        • Re: (Score:2)

          by Nutria ( 679911 )

          Restarting would just have the rootkit re-infect your daemons at launch.

          But then it's not RAM-only. Am I misunderstanding you?

          • Re:yank out the sticks (Score:5, Informative)

            by Guinness Beaumont ( 2901413 ) on Friday June 07, 2013 @06:40PM (#43941587)

            No, you're misreading the article.

            "The rootkit does not touch files on storage but patches running processes in memory."

            The rootkit isn't in RAM only. The way that it attacks the daemon processes is done entirely in RAM.

            • Re: (Score:3)

              by Nutria ( 679911 )

              So the statement rootkit does not touch files on storage but patches running processes in memory is wrong (or at the very least, misleading?

              • "The man doesn't touch x, but rather y." vs. "The man doesn't exist in x."

                No. It's not misleading. English is just a really shitty language to convey specific information. This is a common problem.

                • FTA

                  ...they used a previously unknown rootkit that doesn't touch any hard disk files.

                  The quote appears rather unambiguous and I am tending to disagree with your interpretation of the summary. Do you have specific knowledge that others are not privy to? Or are you biasing your interpretation to fit what you think to be true?

                  As for English being a shitty language, I think you can write ambiguously in just about any language. You can also certainly write unambiguously and and concisely in English (I would think this to be true for most languages, but I don't want to state that as a matter

                  • I was comparing English as a language to exact (programming) languages, not to other spoken languages; but to answer your question, no. I don't have any information that you don't. I see touch as a verb, as used above in the example with the man. The rootkit didn't 'touch' the files on the disk. That doesn't speak to the rootkit's location, only to its actions.

                    • The rootkit didn't 'touch' the files on the disk. That doesn't speak to the rootkit's location, only to its actions.

                      If in fact the rootkit is located on the hard drive, how did it get there? Any process/program that wrote the necessary file(s) to the hard drive could rightly be considered part of the rootkit. Unless you are invoking another program/process writing the necessary files to the hard drive, I don't think you can square (1) not touching files on the hard drive with (2) this being called an "in-memory" root kit and (3) the root kit being located on the hard drive.

                      Granted, the writers could be writing deceptivel

                    • "...no reasonable person..." -- Well, that escalated quickly.

                      It's entirely possible that the exploit occurred entirely in RAM and your original post would be true. I'm merely looking at the choice of words here, and making an educated guess. I've worked on exploits before that used process editing in RAM to defeat the exact kind of checksum noted here.

                      Here's my train of thought, based on this quote from the article:

                      According to Hetzner, the attackers displayed an unusually high level of sophistication: apparently, they used a previously unknown rootkit that doesn't touch any hard disk files. "Instead, it patches processes that are already running on the system and injects its malicious code directly into the target process image", explained Martin Hetzner. The executive said that the rootkit seamlessly manipulated the OpenSSH daemon and Apache in RAM, apparently without the need to restart the services. According to Hetzner, the rootkit is probably also able to manipulate ProFTPD. The number of reported incidents during which attackers manipulated the daemons of important programs is currently increasing. What appears to be a new approach is that the manipulation was carried out exclusively in RAM.

                      They mention that the exploit attacked sshd / apache (httpd?), and rewrote parts to intr

                    • "...no reasonable person..." -- Well, that escalated quickly.

                      That's a bit rich. Your replies have been brusque bordering on arrogant. Things like:

                      No, you're misreading the article.... The rootkit isn't in RAM only.

                      English is just a really shitty language to convey specific information. This is a common problem.

                      Your replies are inconsistent with the summary and article without supporting information-- and can easily be interpreted as condescending. Perhaps the summary/article are incorrect-- it has happened before. I like to give people the benefit of doubt on Slashdot because there are a lot of really smart people with specialized knowledge-- perhaps they really have an insight that 99% of people don't have. If you have worked on

                    • If in fact the rootkit is located on the hard drive, how did it get there?

                      A virus might have installed it. Or a worm. Or a trojan. Or some automated process remotely looking for vulnerabilities and exploiting them. Or a hacker, manually. In none of the cases it was the rootkit itself.

            • No, you're misreading the article.

              "The rootkit does not touch files on storage but patches running processes in memory."

              The rootkit isn't in RAM only. The way that it attacks the daemon processes is done entirely in RAM.

              I think you are misreading the article. It's very possible the attacker used an exploit in a running daemon to execute code in that process, which then went on to modify other running processes. The article says they haven't found the original entry point. Nothing need be written to disk. If you restart you will blow away the kit, at which point the attacker loses communication with the system through their backdoor, so they just hit it again because you haven't patched the original exploit, because you hav

            • Re: (Score:2)

              by ygslash ( 893445 )

              My understanding of Hetzner's report is that it works like this: there is a backdoor on a Nagios server (not clear whether that means a backdoor in Nagios itself, or some other kind of backdoor on a server whose purpose is Nagios monitoring). The attackers are able to use this backdoor to gain root on other servers within Hetzner, which they use to modify key daemons on those servers. The daemons are modified in memory as they run, and I'm sure the attackers are careful not to generate any logging events.

        • Re: (Score:2)

          by gl4ss ( 559668 )

          The rootkit itself was most likely not in RAM only, but the way it exploited daemon processes was. Restarting would just have the rootkit re-infect your daemons at launch.

          the way I read the summary was the whole point that absolutely nothing was left on disk and not even a funny process, but the code was patched to run in the processes already in memory.

      • Re: (Score:2)

        by El Rey ( 61125 )

        Exactly what I was thinking. If it, "never touches the disk", how does it reload if you turn the machine off and turn it back on? Saving itself to the BIOS?

        • I was thinking that too. However, I can see it calling home every few minutes to let the control machine know it's still there and running. (No response needed.) If it misses a scheduled call, the control machine launches a new attack and re-infects it. Don't know how well it would work in practice, but it sounds reasonable.

        • Don't know about you, but my laptop stays on a very long time between reboots... Goes to sleep often, but reboots? Only on certain types of updates/problems.
          If my computer somehow got infected and was not detected, it could do a lot of watching/logging/calling home/ddosing/etc while never touching the HD...
          If you can get enough random people to get infected on a regular basis, who cares if a few of them shutdown periodically.

  • Do they tell us? (Score:5, Informative)

    by theduk3 ( 2598409 ) on Friday June 07, 2013 @05:44PM (#43941113)

    I have a root server from Hetzner and got the disclosure mail, which was very detailed.
    Customer data was compromised, including the hashed/salted passwords and the last 3 digits of credit card numbers (which should not really be an issue).

    This is not the first major breach at Hetzner, in 2011 managed server account passwords were compromised as well.
    Back then they advised customers to reset the passwords for all accounts for the admin panel.

    The interesting question... is Hetzner sloppy about security, more so than it's competitors, or are they actually more vigilant and/or more forthcoming about breaches?
    I have the uncomfortable hunch that we do not hear about a lot of breaches at all the cloud sevices/hosters out there.

    • Re:Do they tell us? (Score:5, Interesting)

      by Seranfall ( 680430 ) on Friday June 07, 2013 @05:56PM (#43941179)

      The interesting question... is Hetzner sloppy about security, more so than it's competitors, or are they actually more vigilant and/or more forthcoming about breaches? I have the uncomfortable hunch that we do not hear about a lot of breaches at all the cloud sevices/hosters out there.

      My real fear is that it's not because of willful lack of reporting of the breeches, but that the breeches are going on completely undetected that we aren't hearing more about them.

      • Re:Do they tell us? (Score:4, Funny)

        by K. S. Kyosuke ( 729550 ) on Friday June 07, 2013 @06:30PM (#43941489)

        My real fear is that it's not because of willful lack of reporting of the breeches, but that the breeches are going on completely undetected that we aren't hearing more about them.

        Bah, I can usually detect breeches by means of a quick visual scan, so I don't think that they can go undetected. I suspect that breeches are seldom reported these days because of the declining horse population.

      • www.trommer-bau.de has been hacked too... (Score:1)

        by Anonymous Coward

        http://www.trommer-bau.de/chimera.html

        I tried contacting them via email and my email gets bounced.

        Nathan

    • Re: (Score:1)

      by ssasa ( 247050 )

      50% of all spam that receive we in Eastern Europe comes from Hetzner hosted servers. There were numerous complaints to Hetzner that their users are spamming around but they NEVER did anything to resolve this. Shame on them and their sloppiness.

    • Re: (Score:3)

      by Inda ( 580031 )
      >>and the last 3 digits of credit card numbers (which should not really be an issue).

      It is an issue. With those three numbers, I can possibly gain authetication from another company for another account owned by the credit card holder. "Can you just confirm the last three digits of your credit card please?"

      It's all about gaining one little piece of information at a time until the full picture is seen.

  • B&D languages like Ada. (I wonder if there are any ESPOL or NEWP compilers for x86-64...)

    • Even the most sophisticated programming language doesn't protect you against manipulation of the generated machine code in memory during execution. The only thing that can provide protection is the operating system together with the processor's memory access permission system (by denying access to the in-memory image of the process).

      • Re: (Score:2)

        by Nutria ( 679911 )

        But they'd do a better job of not allowing privilege escalation bugs.

        Also, ESPOL and NEWP are system languages.

  • English version of the article (Score:5, Informative)

    by datalife ( 17290 ) on Friday June 07, 2013 @07:04PM (#43941769)

    There is an english version of the article, so there is no need to Googletranslate the thing

    http://www.h-online.com/news/item/Hetzner-web-hosting-service-hacked-customer-data-copied-1884574.html [h-online.com]

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close