New In-Memory Rootkit Discovered By German Hoster 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."
Kinda cool that they found it (Score:2, Interesting)
Even if you notice strange traffic, how do you actually find something that is only in memory?
Re:Kinda cool that they found it (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.
Re: (Score:1)
Seeing that this hasn't been modded up, up, UP after 11 minutes is evidence this site is gone to hell.
Re: (Score:2)
I can SEE the light!!!
Re:Kinda cool that they found it (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.
Re:Kinda cool that they found it (Score:4, Funny)
i think you mean XXen
Re: (Score:1, Funny)
Re: (Score:2)
Re:Kinda cool that they found it (Score:5, Informative)
Re: (Score:2)
Check for strange processes?
Re: (Score:2)
When all the tools used to do that have been patched to not show the strange processes?
Re: (Score:3)
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: (Score:2)
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: (Score:3)
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: (Score:3)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
But doesn't each distro add their own "we know best" patches, so thus slightly different code would be generated?
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
Re: (Score:1)
How can you tell?
Because the memory is leaking all over the floor!!!
EvaPharmacy has been doing this for years... (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 [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
Re: (Score:2)
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)
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)
Re: (Score:2)
It does leave you scratching your head for awhile first however.
And rookies wouldn't know about that at all.
Re: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
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)
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: (Score:3)
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: (Score:2)
Re: (Score:2)
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)
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)
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: (Score:2)
"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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
"...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
Re: (Score:2)
"...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
Re: (Score:1)
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: (Score:2)
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)
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)
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)
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: (Score:3)
Re: (Score:2)
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)
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)
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)
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)
http://www.trommer-bau.de/chimera.html
I tried contacting them via email and my email gets bounced.
Nathan
Re: (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.
Re: (Score:3)
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... (Score:2)
B&D languages like Ada. (I wonder if there are any ESPOL or NEWP compilers for x86-64...)
Re: (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).
Re: (Score:2)
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)
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: (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