glussier
08-14-2003, 08:46 AM
Seems like, nowadays nothing is safe: Read the article: http://ftp.gnu.org/MISSING-FILES.README
Click to See Complete Forum and Search --> : A root compromise and a Trojan horse were discovered on gnuftp.gnu.org
Chadduss
08-14-2003, 10:00 PM
hmmm I have a question. Now Linux, of course, is more secure than windows but if more people come to linux and more viruses are made, how much safer are we really?
Thanks
Thanks
terribleRobbo
08-14-2003, 10:58 PM
The FTP server they were running was unpatched.
hard candy
08-15-2003, 12:17 AM
The FTP server they were running was unpatched.
Sounds like a Microsoft situation, doesn't it? If you don't download the updates, you are vulnerable. I'm wondering, like Chaddus said, what if the viruses are aimed at Linux- are there more exploitable ports/entrances to be found? And since I don't know much about ptraces, etc, how did that cracker have access to root privleges?
Sounds like a Microsoft situation, doesn't it? If you don't download the updates, you are vulnerable. I'm wondering, like Chaddus said, what if the viruses are aimed at Linux- are there more exploitable ports/entrances to be found? And since I don't know much about ptraces, etc, how did that cracker have access to root privleges?
kam
08-15-2003, 12:51 AM
Originally posted by terribleRobbo
The FTP server they were running was unpatched. But when unpatched Windows servers are hit by a worm, people talk about how horrible Windows is.
The FTP server they were running was unpatched. But when unpatched Windows servers are hit by a worm, people talk about how horrible Windows is.
MkIII_Supra
08-15-2003, 01:01 AM
The system would have to have been compromised locally in order for the attack to occur. If you read about the ptrace vulnerability at kernel.org and securityfocus and CERT, the flaw cannot be remote exploited. The ptrace can only be exploited locally, so the initial break in occured in house, then who ever used the root access they had gained to use the exploit remotely.
Still though, I am somewhat shocked that this happened. Something else I find funny is that nobody else seems to have keyed in on the fact that the ptrace flaw is a local root exploit. All the NBM'rs are screaming "Look! Linux is insecure too!" Yes this is true, any computer that is front of a cracker is not safe! Duh! What people have failed to recognize is that this in NOT a remote exploitable flaw!
At least the 2.5 and of course the 2.6 kernels don't allow this to happen, because this segment of the kernel was completely re-written. I don't have all the details but I remember that part of the article I read on kernel.org.
Still though, I am somewhat shocked that this happened. Something else I find funny is that nobody else seems to have keyed in on the fact that the ptrace flaw is a local root exploit. All the NBM'rs are screaming "Look! Linux is insecure too!" Yes this is true, any computer that is front of a cracker is not safe! Duh! What people have failed to recognize is that this in NOT a remote exploitable flaw!
At least the 2.5 and of course the 2.6 kernels don't allow this to happen, because this segment of the kernel was completely re-written. I don't have all the details but I remember that part of the article I read on kernel.org.
bwkaz
08-15-2003, 07:59 PM
Originally posted by hard candy
And since I don't know much about ptraces, etc, how did that cracker have access to root privleges? They somehow got a local shell open. Whether that was through the FTP server software, or through SSH access to that machine, or some other way, I don't know, but they got a local shell open (this is why the GNU people think that it may have been one of the local users).
This user then used a bug in the kernel. Basically, the bug consisted of the fact that a process could be debugged before doing something that would cause the kernel to run something as root. When the kernel fork()ed (...basically), they debugged the child process, which got root privileges automatically. Since they were debugging the process, they stopped it and changed its code to start up a shell. That was the root shell that they had. The fix was to chagne something about the way the fork worked in this case, or something.
But what I'm wondering about was this:
For the ptrace bug, a root-shell exploit was available on 17 March 2003,
and a working fix was not available on linux-kernel until the following
week. Evidence found on the machine indicates that gnuftp was cracked
during that week. So, err, why didn't they apply that kernel patch? And reboot? That would kill the root shell...
It is possible, though, that the cracker had already installed some backdoors at that point, I suppose. So maybe it's not that bad after all...
And since I don't know much about ptraces, etc, how did that cracker have access to root privleges? They somehow got a local shell open. Whether that was through the FTP server software, or through SSH access to that machine, or some other way, I don't know, but they got a local shell open (this is why the GNU people think that it may have been one of the local users).
This user then used a bug in the kernel. Basically, the bug consisted of the fact that a process could be debugged before doing something that would cause the kernel to run something as root. When the kernel fork()ed (...basically), they debugged the child process, which got root privileges automatically. Since they were debugging the process, they stopped it and changed its code to start up a shell. That was the root shell that they had. The fix was to chagne something about the way the fork worked in this case, or something.
But what I'm wondering about was this:
For the ptrace bug, a root-shell exploit was available on 17 March 2003,
and a working fix was not available on linux-kernel until the following
week. Evidence found on the machine indicates that gnuftp was cracked
during that week. So, err, why didn't they apply that kernel patch? And reboot? That would kill the root shell...
It is possible, though, that the cracker had already installed some backdoors at that point, I suppose. So maybe it's not that bad after all...
hard candy
08-15-2003, 10:46 PM
So theoretically, there could still be an locked entry that the cracker could open with a password, is this cotrrect?
It seems the maintainers would have to examine each line of code and compare it to a model of that code. Which is what the mdsum is doing I imagine, but that must be some tedious work.
And by local user, are we talking about someone physically present on the site? Or with a remote terminal? And wouldn't they be able to compare logs of processes and find out who was logged in when a process was changed?
I'm not a network person but this is getting to be a good mystery. A microsoft spy? A disgruntled volunteer? A jealous rival wanting to mess up someone's work?
It seems the maintainers would have to examine each line of code and compare it to a model of that code. Which is what the mdsum is doing I imagine, but that must be some tedious work.
And by local user, are we talking about someone physically present on the site? Or with a remote terminal? And wouldn't they be able to compare logs of processes and find out who was logged in when a process was changed?
I'm not a network person but this is getting to be a good mystery. A microsoft spy? A disgruntled volunteer? A jealous rival wanting to mess up someone's work?
sharth
08-15-2003, 11:12 PM
Originally posted by bwkaz
But what I'm wondering about was this:
So, err, why didn't they apply that kernel patch? And reboot? That would kill the root shell...
It is possible, though, that the cracker had already installed some backdoors at that point, I suppose. So maybe it's not that bad after all... They had access to the shell since fsf was fairly free to give out shell / ftp accounts to developers. They then used the shell to use the linux ptrace bug. To answer the second half, there was no fix for the exploit for a week, the server was vracked in that week.
But what I'm wondering about was this:
So, err, why didn't they apply that kernel patch? And reboot? That would kill the root shell...
It is possible, though, that the cracker had already installed some backdoors at that point, I suppose. So maybe it's not that bad after all... They had access to the shell since fsf was fairly free to give out shell / ftp accounts to developers. They then used the shell to use the linux ptrace bug. To answer the second half, there was no fix for the exploit for a week, the server was vracked in that week.
serz
08-15-2003, 11:19 PM
That's why.. they couldn't patch it because there was no patch at that time.
carrja99
08-16-2003, 05:18 AM
I think it's just so wrong that someone went and cracked thier ftp and messed it up a bit... it's kinda like breaking into a Red Cross blood bank and dumping or contaminating all the donated blood :(
bwkaz
08-16-2003, 10:00 AM
Originally posted by sharth
To answer the second half, there was no fix for the exploit for a week, the server was vracked in that week. Yeah, I know. But why didn't they apply the patch after that week was over (I know I did...) and reboot?
The answer is, they probably did (...at least, I hope they did... if they didn't, they might just deserve this...), but there was still a backdoor present on their systems. The easiest backdoor that I can think of would be a copy of sshd (or something) running on a high port, with logging disabled and set up to accept root logins with no password. Plus a "modified" version of top, ps, and whatever else, so that those programs don't report the second SSH server.
Originally posted by hard candy
I'm not a network person but this is getting to be a good mystery. A microsoft spy? A disgruntled volunteer? A jealous rival wanting to mess up someone's work? A person (my guess is a script kiddie, but I don't have any idea for sure) posing as a developer (or one who had already obtained a developer's login name and password) that wanted to collect more passwords, is what it looks like to the GNU sysadmins.
To answer the second half, there was no fix for the exploit for a week, the server was vracked in that week. Yeah, I know. But why didn't they apply the patch after that week was over (I know I did...) and reboot?
The answer is, they probably did (...at least, I hope they did... if they didn't, they might just deserve this...), but there was still a backdoor present on their systems. The easiest backdoor that I can think of would be a copy of sshd (or something) running on a high port, with logging disabled and set up to accept root logins with no password. Plus a "modified" version of top, ps, and whatever else, so that those programs don't report the second SSH server.
Originally posted by hard candy
I'm not a network person but this is getting to be a good mystery. A microsoft spy? A disgruntled volunteer? A jealous rival wanting to mess up someone's work? A person (my guess is a script kiddie, but I don't have any idea for sure) posing as a developer (or one who had already obtained a developer's login name and password) that wanted to collect more passwords, is what it looks like to the GNU sysadmins.
sharth
08-16-2003, 01:35 PM
They did apply the patch when it was available. The server has been hacked since march, they just now found out.
On the backups, when your server has been hacked for 5 some months, 5 months of backups are possible to be infected. So they have to go back and go through all of that.
And just to throw out a question, did you check your computer for root-kits when after that patch hit? I personally didn't.
and a modified version of login would work much better, since it would probably work on ftp and ssh, and you could use the normal ports.
Plus, he didn't have to hide his login, he (or she) probably had legit access anywho. It's the root access that needs to be further hidden.
On the backups, when your server has been hacked for 5 some months, 5 months of backups are possible to be infected. So they have to go back and go through all of that.
And just to throw out a question, did you check your computer for root-kits when after that patch hit? I personally didn't.
and a modified version of login would work much better, since it would probably work on ftp and ssh, and you could use the normal ports.
Plus, he didn't have to hide his login, he (or she) probably had legit access anywho. It's the root access that needs to be further hidden.
bwkaz
08-16-2003, 07:22 PM
Originally posted by sharth
And just to throw out a question, did you check your computer for root-kits when after that patch hit? I personally didn't. Not immediately afterward, but I run the latest version of chkrootkit fairly often. I have run it since the last time I rebooted (and that was around ... June perhaps?).
and a modified version of login would work much better, since it would probably work on ftp and ssh, and you could use the normal ports. It might, assuming sshd runs login. But I don't know if it does or not.
And just to throw out a question, did you check your computer for root-kits when after that patch hit? I personally didn't. Not immediately afterward, but I run the latest version of chkrootkit fairly often. I have run it since the last time I rebooted (and that was around ... June perhaps?).
and a modified version of login would work much better, since it would probably work on ftp and ssh, and you could use the normal ports. It might, assuming sshd runs login. But I don't know if it does or not.
justlinux.com
Copyright Internet.com Inc. All Rights Reserved.
Copyright Internet.com Inc. All Rights Reserved.