Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New In-Memory Rootkit Discovered By German Hoster

Soulskill posted about a year ago | from the malware-arms-race dept.

Security 91

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

cancel ×

91 comments

Sorry! There are no comments related to the filter you selected.

Kinda cool that they found it (2, Interesting)

Anonymous Coward | about a year ago | (#43940839)

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

Re:Kinda cool that they found it (5, Funny)

Anonymous Coward | about a year ago | (#43940897)

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.

Re:Kinda cool that they found it (1)

Anonymous Coward | about a year ago | (#43941031)

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

Re:Kinda cool that they found it (-1)

Anonymous Coward | about a year ago | (#43941445)

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.

Amen

Re:Kinda cool that they found it (1)

gtall (79522) | about a year ago | (#43945163)

I can SEE the light!!!

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43940907)

also what was the attack vector...

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43941013)

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

Re:Kinda cool that they found it (5, Funny)

Anonymous Coward | about a year ago | (#43941101)

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.

Re:Kinda cool that they found it (3, Funny)

zlives (2009072) | about a year ago | (#43941359)

i think you mean XXen

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43944991)

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.

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43943299)

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

Re:Kinda cool that they found it (1, Funny)

Anonymous Coward | about a year ago | (#43941147)

You sound like a blast at parties.

Re:Kinda cool that they found it (1)

K. S. Kyosuke (729550) | about a year ago | (#43941391)

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

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43942625)

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

Re:Kinda cool that they found it (5, Informative)

Guinness Beaumont (2901413) | about a year ago | (#43941201)

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.

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43944141)

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?

Re:Kinda cool that they found it (1)

lightknight (213164) | about a year ago | (#43943421)

Check for strange processes?

Re:Kinda cool that they found it (1)

cheater512 (783349) | about a year ago | (#43944549)

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

Re:Kinda cool that they found it (2)

MasterPatricko (1414887) | about a year ago | (#43945593)

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.

Re:Kinda cool that they found it (1)

cheater512 (783349) | about a year ago | (#43948111)

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.

Re:Kinda cool that they found it (0)

Anonymous Coward | about a year ago | (#43961415)

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

Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43940863)

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

Re:Address space layout randomization? (0, Troll)

Anonymous Coward | about a year ago | (#43940933)

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

ASLR is a joke.

Re:Address space layout randomization? (2)

Heretic2 (117767) | about a year ago | (#43940945)

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.

Re:Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43941187)

Current Linux kernels have ASLR.

Re:Address space layout randomization? (2)

bloodhawk (813939) | about a year ago | (#43940947)

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.

Re:Address space layout randomization? (1)

Nutria (679911) | about a year ago | (#43941251)

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?

Re:Address space layout randomization? (2)

zwarte piet (1023413) | about a year ago | (#43946085)

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

Re:Address space layout randomization? (1)

Nutria (679911) | about a year ago | (#43947267)

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

Re:Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43940991)

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

Re:Address space layout randomization? (2)

K. S. Kyosuke (729550) | about a year ago | (#43941419)

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.

Re:Address space layout randomization? (1)

K. S. Kyosuke (729550) | about a year ago | (#43941433)

(damn, :s/construct//g)

Re:Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43942575)

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?

Re:Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43945497)

:s/construct //g

Re:Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43941953)

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

Re:Address space layout randomization? (0)

Anonymous Coward | about a year ago | (#43943191)

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

Would have got a frosted psot (0)

Anonymous Coward | about a year ago | (#43940887)

But my firefox process was injected with malicious code.

Re:Would have got a frosted psot (1)

oodaloop (1229816) | about a year ago | (#43941063)

How can you tell?

Re:Would have got a frosted psot (1)

Anonymous Coward | about a year ago | (#43942597)

How can you tell?

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

hetzner is a scummy provider... (0)

Anonymous Coward | about a year ago | (#43941037)

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

EvaPharmacy has been doing this for years... (5, Interesting)

AdamD1 (221690) | about a year ago | (#43941061)

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

WARNING - possibly hostile web site (0)

Anonymous Coward | about a year ago | (#43941255)

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 [pharmalert...fyoudareom]

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.

Re:EvaPharmacy has been doing this for years... (1)

Obfuscant (592200) | about a year ago | (#43941367)

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:EvaPharmacy has been doing this for years... (3, Informative)

Anonymous Coward | about a year ago | (#43941493)

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:EvaPharmacy has been doing this for years... (1)

fisted (2295862) | about a year ago | (#43943205)

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

Re:EvaPharmacy has been doing this for years... (0)

Anonymous Coward | about a year ago | (#43943241)

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.

Re:EvaPharmacy has been doing this for years... (1)

cheater512 (783349) | about a year ago | (#43944555)

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

And rookies wouldn't know about that at all.

Re:EvaPharmacy has been doing this for years... (1)

fisted (2295862) | about a year ago | (#43947259)

rookies wouldn't break root anywhere in the first place

Re:EvaPharmacy has been doing this for years... (1)

kasperd (592156) | about a year ago | (#43945161)

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:EvaPharmacy has been doing this for years... (1)

fisted (2295862) | about a year ago | (#43947287)

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:EvaPharmacy has been doing this for years... (1)

kasperd (592156) | about a year ago | (#43948261)

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

Re:EvaPharmacy has been doing this for years... (0)

Anonymous Coward | about a year ago | (#43941389)

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 [spamtrackers.eu]

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.

yank out the sticks (2)

SpaceManFlip (2720507) | about a year ago | (#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 (?).

Re:yank out the sticks (2)

danceswithtrees (968154) | about a year ago | (#43941159)

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.

Re:yank out the sticks (1)

Guinness Beaumont (2901413) | about a year ago | (#43941297)

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:yank out the sticks (1)

Nutria (679911) | about a year ago | (#43941381)

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 (4, Informative)

Guinness Beaumont (2901413) | about a year ago | (#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:yank out the sticks (2)

Nutria (679911) | about a year ago | (#43941695)

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

Re:yank out the sticks (1)

Guinness Beaumont (2901413) | about a year ago | (#43941755)

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

Re:yank out the sticks (1)

danceswithtrees (968154) | about a year ago | (#43942039)

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

Re:yank out the sticks (1)

Guinness Beaumont (2901413) | about a year ago | (#43942095)

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.

Re:yank out the sticks (1)

danceswithtrees (968154) | about a year ago | (#43942295)

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.

Re:yank out the sticks (1)

Guinness Beaumont (2901413) | about a year ago | (#43942495)

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

Re:yank out the sticks (1)

danceswithtrees (968154) | about a year ago | (#43943429)

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

Re:yank out the sticks (1)

maxwell demon (590494) | about a year ago | (#43944559)

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.

Re:yank out the sticks (0)

Anonymous Coward | about a year ago | (#43942143)

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.

Re:yank out the sticks (1)

DigitAl56K (805623) | about a year ago | (#43942343)

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.

Re:yank out the sticks (1)

ygslash (893445) | about a year ago | (#43993745)

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.

Re:yank out the sticks (1)

gl4ss (559668) | about a year ago | (#43941437)

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:yank out the sticks (1)

El Rey (61125) | about a year ago | (#43941411)

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?

Re:yank out the sticks (2)

techno-vampire (666512) | about a year ago | (#43941559)

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.

Re:yank out the sticks (1)

canadiannomad (1745008) | about a year ago | (#43941565)

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.

Re:yank out the sticks (0)

Anonymous Coward | about a year ago | (#43943781)

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.

Do they tell us? (5, Informative)

theduk3 (2598409) | about a year ago | (#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? (5, Interesting)

Seranfall (680430) | about a year ago | (#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? (3, Funny)

K. S. Kyosuke (729550) | about a year ago | (#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... (1)

Anonymous Coward | about a year ago | (#43941491)

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

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

Nathan

Legal requirements for disclosure (0)

Anonymous Coward | about a year ago | (#43942875)

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.

Re:Do they tell us? (0)

Anonymous Coward | about a year ago | (#43943045)

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

Re:Do they tell us? (1)

ssasa (247050) | about a year ago | (#43945167)

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:Do they tell us? (0)

Anonymous Coward | about a year ago | (#43947397)

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

Re:Do they tell us? (2)

Inda (580031) | about a year ago | (#43959429)

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

Time to start re-writing all code in... (1)

Nutria (679911) | about a year ago | (#43941365)

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

Re:Time to start re-writing all code in... (1)

maxwell demon (590494) | about a year ago | (#43944569)

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:Time to start re-writing all code in... (1)

Nutria (679911) | about a year ago | (#43944621)

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 (5, Informative)

datalife (17290) | about a year ago | (#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]

Re:English version of the article (-1)

Anonymous Coward | about a year ago | (#43942665)

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?

Re:English version of the article (0)

Anonymous Coward | about a year ago | (#43942859)

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

Re:English version of the article (0)

Anonymous Coward | about a year ago | (#43942893)

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.

Re:English version of the article (1)

maxwell demon (590494) | about a year ago | (#43944613)

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.

Re:English version of the article (0)

Anonymous Coward | about a year ago | (#43945049)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>