Slashdot Mirror

← Back to Stories (view on slashdot.org)

New In-Memory Rootkit Discovered By German Hoster

Posted by Soulskill on 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."

91 comments

  1. Kinda cool that they found it by Anonymous Coward · · Score: 2, Interesting

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

    1. Re:Kinda cool that they found it by Anonymous Coward · · Score: 5, Funny

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

      Through the power of Jesus Christ, our Lord and Savior.

    2. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      also what was the attack vector...

    3. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      On a VMWare server I would create a snapshot and then analyze the contents of the memory

    4. Re:Kinda cool that they found it by Anonymous Coward · · Score: 1

      Seeing that this hasn't been modded up, up, UP after 11 minutes is evidence this site is gone to hell.

    5. Re:Kinda cool that they found it by Anonymous Coward · · Score: 5, Funny

      On a VMWare server I would create a snapshot and then analyze the contents of the memory

      I don't always examine a couple gigs of raw memory with no context on a summer Friday but when I do I prefer Xen.

    6. Re:Kinda cool that they found it by Anonymous Coward · · Score: 1, Funny

      You sound like a blast at parties.

    7. Re:Kinda cool that they found it by centipedes.in.my.vag · · Score: 5, Informative

      You can walk-though and dump a running process' memory to file to analyze it later. Just reference the pid+offset and read. This style of patching a process (CREATE_SUSPENDED flag / Edit / ResumeThread) rather than editing the file itself is really popular when trying to defeat a CRC check, so methods to analyze it shouldn't surprise anyone.

      --
      Only on /. can I lose karma with 2x "5, Funny" posts.
    8. Re:Kinda cool that they found it by zlives · · Score: 3, Funny

      i think you mean XXen

    9. Re:Kinda cool that they found it by K.+S.+Kyosuke · · Score: 1

      Trust me, you don't want to sound like BLAST at parties...unless it's a geeky party, that is.

      --
      Ezekiel 23:20
    10. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      Thats exactly how all the coders used to get their 3M's stolen when they encrypted them. Now no one gets anything unless they pay for it. Suckers...

    11. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      I understand all of that - but what about a winter Wednesday? Wouldn't you prefer VirtualBox then?

    12. Re:Kinda cool that they found it by lightknight · · Score: 1

      Check for strange processes?

      --
      I am John Hurt.
    13. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      Do you expect to get real data from inside the compromised system? I see how the virtualization approach would work, if you assume that the virtualization layer is unaffected. Inside the system, a rootkit could hide everything and give you squeaky clean process images, couldn't it?

    14. Re:Kinda cool that they found it by cheater512 · · Score: 1

      When all the tools used to do that have been patched to not show the strange processes?

    15. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      FTFY:
      I don't always examine a couple gigs of raw memory with no context on a summer Friday but when I do I prefer XXXen.

    16. Re:Kinda cool that they found it by gtall · · Score: 1

      I can SEE the light!!!

    17. Re:Kinda cool that they found it by MasterPatricko · · Score: 2

      If you're serious about computer security you bring the analysis tools with you, from an independent known-good source, not using anything from the possibly-compromised machine.

      --
      I'd tell a UDP joke, but you may not get it. I'd tell a TCP joke, but I'd have to keep repeating it until you got it.
    18. Re:Kinda cool that they found it by cheater512 · · Score: 1

      And what if it patches the binary as soon as it is loaded in to memory?
      So you couldn't copy over a clean version of say ps and run it.

      Remembering that at this point you don't even know your machine is infected, just strange traffic and if you reboot it all evidence is lost.

    19. Re:Kinda cool that they found it by Anonymous Coward · · Score: 0

      With a memory forensics tool, duh. Check out Second Look. In fact, the compromised company has referenced it on their wiki page about the incident.

  2. Address space layout randomization? by Anonymous Coward · · Score: 0

    Forgive my ignorance, but how did ASLR not stop this?

    1. Re:Address space layout randomization? by Anonymous Coward · · Score: 0, Troll

      Forgive my ignorance, but how did ASLR not stop this?

      ASLR is a joke.

    2. Re:Address space layout randomization? by Heretic2 · · Score: 2

      Forgive my ignorance, but how did ASLR not stop this?

      Because it was on Linux and not Windows?

      Anyway, sounds like they weren't running TXT or selinux.

    3. Re:Address space layout randomization? by bloodhawk · · Score: 2

      ASLR is an important part of defence in depth, but it is by no means a guarantee that you can't be exploited through a vulnerability, it makes it that little bit harder.

    4. Re:Address space layout randomization? by Anonymous Coward · · Score: 0

      And combine ASLR with DEP, and you'd think an attack like this would be quite difficult.

    5. Re:Address space layout randomization? by Anonymous Coward · · Score: 0

      Current Linux kernels have ASLR.

    6. Re:Address space layout randomization? by Nutria · · Score: 1

      Wouldn't this be a highly distro-specific attack? Or can the malware crawl through the binaries and figure out where to inject it's code?

      --
      "I don't know, therefore Aliens" Wafflebox1
    7. Re:Address space layout randomization? by K.+S.+Kyosuke · · Score: 2

      Forgive my ignorance, but how did ASLR not stop this?

      I think a much better question is why do we have remotely exploitable systems when we have tons of methodologies for constructing construct provably correct and safe programs.

      --
      Ezekiel 23:20
    8. Re:Address space layout randomization? by K.+S.+Kyosuke · · Score: 1

      (damn, :s/construct//g)

      --
      Ezekiel 23:20
    9. Re:Address space layout randomization? by Anonymous Coward · · Score: 0

      Do we have any methodologies for constructing any *non* *trivial* correct and safe programs?

    10. Re:Address space layout randomization? by Anonymous Coward · · Score: 0

      I think a much better question is why do we have remotely exploitable systems when we have tons of methodologies for ing provably correct and safe programs.

      Try again maybe?

    11. Re:Address space layout randomization? by Anonymous Coward · · Score: 0

      GP AC here, no, we haven't. I was wrong.

    12. Re:Address space layout randomization? by Anonymous Coward · · Score: 0

      :s/construct //g

    13. Re:Address space layout randomization? by zwarte+piet · · Score: 2

      More compiler specific than distro. And linux seems to be GCC always.

    14. Re:Address space layout randomization? by Nutria · · Score: 1

      But doesn't each distro add their own "we know best" patches, so thus slightly different code would be generated?

      --
      "I don't know, therefore Aliens" Wafflebox1
  3. Would have got a frosted psot by Anonymous Coward · · Score: 0

    But my firefox process was injected with malicious code.

    1. Re:Would have got a frosted psot by oodaloop · · Score: 1

      How can you tell?

      --
      Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
    2. Re:Would have got a frosted psot by Anonymous Coward · · Score: 1

      How can you tell?

      Because the memory is leaking all over the floor!!!

  4. hetzner is a scummy provider... by Anonymous Coward · · Score: 0

    All sorts of trash going around at hetzner...they were last in the news when they got the ban hammer on efnet.

  5. EvaPharmacy has been doing this for years... by AdamD1 · · Score: 5, Interesting

    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

    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

    --
    Because I can! [Brainrub.com]
    1. Re:EvaPharmacy has been doing this for years... by Obfuscant · · Score: 1

      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.

    2. Re:EvaPharmacy has been doing this for years... by Anonymous Coward · · Score: 0

      The SpamTrackers wiki has a much lengthier, though still somewhat clueless description of the EvaPharmacy hijack:

      http://www.spamtrackers.eu/wiki/index.php?title=My_Canadian_Pharmacy

      It doesn't look like they run from RAM (the article claims they do, but whoever wrote it clearly doesn't understand UNIX filesystem semantics). What really happens is that they copy the binary in, run it, and delete it (thus they run from a linkless inode, but it's still on disk). It should be possible to get a copy of it from /proc//exe.

    3. Re:EvaPharmacy has been doing this for years... by Anonymous Coward · · Score: 3, Informative

      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

    4. Re:EvaPharmacy has been doing this for years... by fisted · · Score: 1

      as root you can just chattr -i the file. Pity lunix doesn't have a feature like FreeBSD's securelevel.

      --
      CLI paste? paste.pr0.tips!
    5. Re:EvaPharmacy has been doing this for years... by Anonymous Coward · · Score: 0

      Yes, of course. I was just describing to Obfuscant how you can make a file with 000 permissions unwriteable (without changing its attributes back). The link above describing the process said they also deleted the chattr and lsattr tools--though honestly at that point you should really wipe and reinstall.

    6. Re:EvaPharmacy has been doing this for years... by cheater512 · · Score: 1

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

      And rookies wouldn't know about that at all.

    7. Re:EvaPharmacy has been doing this for years... by kasperd · · Score: 1

      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.

      --

      Do you care about the security of your wireless mouse?
    8. Re:EvaPharmacy has been doing this for years... by fisted · · Score: 1

      rookies wouldn't break root anywhere in the first place

      --
      CLI paste? paste.pr0.tips!
    9. Re:EvaPharmacy has been doing this for years... by fisted · · Score: 1

      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.

      --
      CLI paste? paste.pr0.tips!
    10. Re:EvaPharmacy has been doing this for years... by kasperd · · Score: 1

      16 bit? What are you even talking about?

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

      --

      Do you care about the security of your wireless mouse?
  6. yank out the sticks by SpaceManFlip · · Score: 2
    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 (?).

    1. Re:yank out the sticks by danceswithtrees · · Score: 2

      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.

    2. Re:yank out the sticks by centipedes.in.my.vag · · Score: 1

      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.

      --
      Only on /. can I lose karma with 2x "5, Funny" posts.
    3. Re:yank out the sticks by Nutria · · Score: 1

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

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

      --
      "I don't know, therefore Aliens" Wafflebox1
    4. Re:yank out the sticks by El+Rey · · Score: 1

      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?

    5. Re:yank out the sticks by gl4ss · · Score: 1

      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.

      --
      world was created 5 seconds before this post as it is.
    6. Re:yank out the sticks by techno-vampire · · Score: 2

      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.

      --
      Good, inexpensive web hosting
    7. Re:yank out the sticks by canadiannomad · · Score: 1

      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.

      --
      Hmm, the humour and sarcasm seem to have been be lost on you.
    8. Re:yank out the sticks by centipedes.in.my.vag · · Score: 4, Informative

      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.

      --
      Only on /. can I lose karma with 2x "5, Funny" posts.
    9. Re:yank out the sticks by Nutria · · Score: 2

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

      --
      "I don't know, therefore Aliens" Wafflebox1
    10. Re:yank out the sticks by centipedes.in.my.vag · · Score: 1

      "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.

      --
      Only on /. can I lose karma with 2x "5, Funny" posts.
    11. Re:yank out the sticks by danceswithtrees · · Score: 1

      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 of fact because that would be conjecture).

    12. Re:yank out the sticks by centipedes.in.my.vag · · Score: 1

      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.

      --
      Only on /. can I lose karma with 2x "5, Funny" posts.
    13. Re:yank out the sticks by Anonymous Coward · · Score: 0

      the article does not mention the exploit or payload deployment. It would make sense that either its just in memory and is wiped on reboot to be later exploited again or its touching the file system so on reboot it infects the system again.
      the third option of-course is, the ghost package in the ether.

    14. Re:yank out the sticks by danceswithtrees · · Score: 1

      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 deceptively and ambiguously to hype their findings (or the translation from German might be introducing biases-- I can't read German) but I think you are also parsing the summary (and possibly article) in ways that no reasonable person would. I have this suspicion that you find yourself in a logical hole and can't stop digging.

    15. Re:yank out the sticks by DigitAl56K · · Score: 1

      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 haven't figured out what it is.

    16. Re:yank out the sticks by centipedes.in.my.vag · · Score: 1

      "...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 introduce a backdoor. This requires a local process running to edit the memory of those daemons. The introduction of a foreign process requires that it first be transferred to the local machine, and then run. This leads me to believe that the rootkit process itself isn't the "RAM only" portion of this hack, but that the rootkit's injection happens to the process that's already running.

      I could be totally off, but that's how it makes sense to me. There's really no need to be hostile about it though.

      --
      Only on /. can I lose karma with 2x "5, Funny" posts.
    17. Re:yank out the sticks by danceswithtrees · · Score: 1

      "...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 exploits, perhaps you have special insights as well. But the novelty of this rootkit that was __stressed__ in the title, summary, and the article was that it was only in RAM and "didn't touch files on the disk." I think you have to have discussions assuming this is correct or at the very least give supporting evidence for why it is not possible.

      You do neither-- you give replies that are at odds with the article, apparently without special insight into THIS memory only rootkit or give a rational argument for why this is not possible. You can't argue that you have never seen this before-- that is what makes this novel and worthy of discussion.

      I am open minded but at the same time, I don't believe that all interpretations are equivalent-- your reading just doesn't make sense, i.e. is not reasonable. That is what I meant by "no reasonable person." No hostility was intended.

    18. Re:yank out the sticks by Anonymous Coward · · Score: 0

      Don't know about you, but my laptop stays on a very long time between reboots...

      Is the right answer! Plus, we're talking about servers here that don't expect to be rebooted barring catastrophic failure or kernel reload. Even the most heavily used of my systems have gone a year without a restart.

    19. Re:yank out the sticks by maxwell+demon · · Score: 1

      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.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    20. Re:yank out the sticks by ygslash · · Score: 1

      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. So nothing at all is touched on disk for the servers being attacked. Nothing.

      The backdoor on the Nagios server probably does persist across reboots. However, that also may be something that is remote in origin. For example, perhaps the backdoor is hidden in the Perl code of some Nagios module which is regularly updated by Hetzner (and probably plenty of other data centers) from some remote repository which the attackers have compomised. There doesn't even need to be any trace of the backdoor on the Nagios server most of the time. It only needs to be present for a few seconds every once in a while, say, once every few weeks, because the daemons it attacks are long-running processes.

  7. Do they tell us? by theduk3 · · Score: 5, Informative

    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.

    1. Re:Do they tell us? by Seranfall · · Score: 5, Interesting

      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.

    2. Re:Do they tell us? by K.+S.+Kyosuke · · Score: 3, Funny

      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.

      --
      Ezekiel 23:20
    3. Re:Do they tell us? by Anonymous Coward · · Score: 0

      "I have the uncomfortable hunch that we do not hear about a lot of breaches at all the cloud sevices/hosters out there."

      Probably a lot out there that we hear nothing about, and even more that the admins of the servers don't know about, yet...

    4. Re:Do they tell us? by ssasa · · Score: 1

      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.

    5. Re:Do they tell us? by Anonymous Coward · · Score: 0

      Just look at their IP range and see how much abuse is coming from there (spam, botnets, hosting mailware, ...).

    6. Re:Do they tell us? by Inda · · Score: 2

      >>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.

      --
      This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
  8. WARNING - possibly hostile web site by Anonymous Coward · · Score: 0

    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.c_removethisifyoudare_om/1.html

    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.

    The site listed above was blocked by my security software, probably for good reason.

  9. Time to start re-writing all code in... by Nutria · · Score: 1

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

    --
    "I don't know, therefore Aliens" Wafflebox1
    1. Re:Time to start re-writing all code in... by maxwell+demon · · Score: 1

      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).

      --
      The Tao of math: The numbers you can count are not the real numbers.
    2. Re:Time to start re-writing all code in... by Nutria · · Score: 1

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

      Also, ESPOL and NEWP are system languages.

      --
      "I don't know, therefore Aliens" Wafflebox1
  10. www.trommer-bau.de has been hacked too... by Anonymous Coward · · Score: 1

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

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

    Nathan

  11. English version of the article by datalife · · Score: 5, Informative

    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

    --
    There are only 10 types of people in the world: Those who understand binary and those who don't.
    1. Re:English version of the article by Anonymous Coward · · Score: 0

      Yes, that's where I learned English. What's your point?

    2. Re:English version of the article by Anonymous Coward · · Score: 0

      As someone from the Netherlands I'm surprised there was a Google translation link in the summary at all. Don't they teach you guys languages in school?

      Please, they barely teach us English in school. And any second language will only be worse than our English.

    3. Re:English version of the article by maxwell+demon · · Score: 1

      I don't think German is considered one of the most important languages in the world to learn. Imagine you're e.g. an Indian deciding to learn languages. Your first choice of course would be English. Now imagine you're thinking about what to learn as second language. You'll probably consider Chinese (given that China gets quite important economically, also, it's a neighbour country to India), or Spanish (given that it's spoken in many parts of the world, too). You also might consider French (the language of diplomacy). But unless you're planning to go to Germany or have another specific interest in German, you'll probably not choose German.

      Of course, for you in the Netherlands, it makes much more sense to learn German. Germany is just across the border, and you're likely to make good use of your German skill, and be it just by watching German TV broadcasts. Moreover your language is already somewhat similar to German, so it's probably much easier to learn for you. So yes, in the Netherlands, it makes sense to learn German. But somewhere across the world? There German is just one of many languages. There's no more reason to learn German than there is to learn Russian, Japanese or Italian.

      And I say this as a German.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    4. Re:English version of the article by Anonymous Coward · · Score: 0

      As someone from the Netherlands I'm surprised there was a Google translation link in the summary at all. Don't they teach you guys languages in school?

      No. Most countries skip this important language. Also while I had German at school and did well compared to the other kids I didn't really learn German until I went there. German schoolbooks are about crackwhores, graffiti painters and so on. This meant I had a crash course in normal spoken German when I arrived and had to communicate with non-English speakers on a daily basis. The difference were like learning English from rappers and then having to speak with the Queen or something.
      I did adapt within a week or two, but it caused some... incidents until I did. Nothing major as people realized it was the language barrier. However if a native German speaker had said it, then I assume hostility would appear, which tells a lot about schoolbooks with that kind of language.

      Also you have to remember that the bigger the country, the less likely it is that people learn foreign languages. Specially people in English speaking countries assume they can travel the world without knowing foreign languages. Assuming people to know any language other than English on an English webpage is a seriously flawed idea.

  12. Legal requirements for disclosure by Anonymous Coward · · Score: 0

    vary between countries. Possibly in USA and UK and many EU countries disclosure is a legal requirement, but not in my country (AU).

    Was told a hilarious story about some turkish hackers changing an eCommerce site, adding an islamic tithe field (the correct word escapes me) to all transactions. Disclosure to customers was not performed as far as i know, despite all passwords being compromised.