Starting nmap V. 2.54BETA37 ( www.insecure.org/nmap/ ) The 1 scanned port on snsonline.net (203.62.158.32) is: closed
Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds
I fail to see what's the use of this "trojan". It doesn't make sense for a script kiddie to try to connect to a closed port on a legitimate looking machine.
by Anonymous Coward writes:
on Thursday August 01, 2002 @08:47AM (#3991299)
The machine was rebuilt from source and rebooted within an hour of finding out. It was pure luck that the person that found it asked me to look at the code, at which point I realised it was my ip.
The person who found out, MavEtJu, asked on some irc channel [slashdot.org] if anybody had a problem installing openssh, too. And just because a random mood of the universe, the (only?) person who answered was you because you had a checksum error, too, when you installed it.
Now, as it turnes out, the ip number this program contacts during build time happens to be your machine.
Do you have any explantation for this coincidence? It just sounds so unlikely. I mean, you might have been the first person who installed the trojan which phoned home to some other ip and then the package might have been modified again so it contacts your host... but how comes you have been on the same irc channel, #sage-au, at that moment?!?!
This is not meant to flame or suspect you, I'm just curious.
Well he's part of the OpenSSH team and it was ftp.openbsd.org that was comprimised. Chances are the attacker sniffed his password for ftp.openbsd.org after rooting the box.
Well since we don't have any details of the comprimise and ^Sarge^ chose to wipe the drive without any investigation first (that we know of) we prolly won't know.
But there'd be other ways besides sniffing. A rootkit with a trojaned login for instance. Maybe his pwd for that box was the same on openbsd? Maybe he did use sftp but sftp was trojaned as well.
Once the attacker rooted the box, anything became possible.
another more likely possability would be that he was using passwordless authentication. so by rooting a box he has access to, the cracker could ssh to any other computer/user with his public key in the authorized_keys file. they could also scp the trojaned file in the same manner. this is not very unlikely.
Who is saying "Sarge"'s system was compromised ? The guy who put the troyan. Why should we believe him ?
If the goal was to crack into systems, the guy could have done a much better job of it. TCP out is useful, but why not open a port to the outside too? Make a little worm, a little network controlled by the first socket to try? Hell, controlled by the guy who has the private key . . . It's not as if the troyan had restraints in size, or that it had to be difficult to find!
At the *very* least, the IP should have been some unadministered korean server that would have taken weeks to track down. Round-robin several of them, too.
No, the IP belongs to someone on the OpenSSH team, guaranteed to be one of the very first people alerted.
Who is taking bets that port 6667 on his machine never was open at all, and that this is just a(nother) move to make OpenBSD look bad?
And, umm, who'll take a bet that OpenBSD.org FAQ number 8.18 (Why does www.openbsd.org run on Solaris?) will change radically:-)
You should be checking _all_ your other machines and alerting those who have accounts that their passwords for their systems may have been compromised if they connected from your machine. You also need to revise your security policy and services you offer the world. It's a pity you wiped the machine, as it may have contained evidence that could help track down who compromised your machine in the first place.
Did you verify that the source you built from was clean and did not contain similar problems ?
Building and rebooting is not enough. Next time, back up the entire machine so you can examine it for traces of those who compromised it, and then perform a clean reinstall from verified media.
Hello, McFly?!? Rebuilding from source and rebooting *DOES NOT* guarantee expulsion of the hacker. Any binary on a compromised system can be compromised - including gcc, ld, and other tools used during the make build process. You need a fresh install with known good binaries, pf everything, cvsup/anoncvs up to date, and then rebuild your world, rebuild all installed ports *from scratch, not packages*, and any other third-party software needs to be rebuilt from source or if unavailable, redownload the binary from the original site, checking the md5 sums. Then you can say you are safe.
Actually, that's not true. (someone correct me if I'm wrong on this, but I think I'm close). When you compile gcc, it first compiles a version of itself (stage 1) using your current gcc. Then it uses stage 1 to compile itself again, resulting in stage 2. Finally, it compiles itself one more time using stage 2, resulting in stage 3. The build succeeds if and only if stage 2 and stage 3 are identical. This process ensures that your final gcc is free from any defects in the original gcc. Once you have a clean gcc, you can rebuild the rest of your system using it.
Take a look at www.linuxfromscratch.org to see how this works for an entire system.
Recompiling the compiler doesn't do anything to rid you of trojan code/back doors. If you need to ask why, take a look at "Reflections on Trusting Trust" by Ken Thompson [acm.org], and the description of a back door [tuxedo.org] in the jargon file.
The short story is, that the compiler decides what to output. So you have to trust your compiler.
The reason for the recompiling of gcc is something else entirely: It is to allow the source code of gcc to rely on gcc, and to allow an optimized compiler to be created. For additional information consult a good book on compiler writing.
too many people are making assumptions. all we know is that the machine was wiped and reinstalled. he could have backed alot of relivent info before he wiped it. this would allow him to fix the computer, get it back up, and inspect the info later at his leisure.
i would wait until more information is available before jumping to what i would consider to be a silly conclusion.
who said he is hiding anything? because he doesnt state something explicitly doesnt mean he is hiding. perhaps he is assuming that other people would assume he made backups.
It was rebuilt from source code - source code that he possibly did not verify, and using a toolchain that was possibly backdoored.
another assumption that i dont think you can accurately make, but hey i cannot stop you.
203.62.158.32 (Score:1)
Re:203.62.158.32 (Score:1)
-
[14:20:17] *** Unable to connect (Connection refused)
[root@Server root]# nmap -sS -p 6667 203.62.158.32
Starting nmap V. 2.54BETA37 ( www.insecure.org/nmap/ )
The 1 scanned port on snsonline.net (203.62.158.32) is: closed
Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds
I fail to see what's the use of this "trojan". It doesn't make sense for a script kiddie to try to connect to a closed port on a legitimate looking machine.
Re:203.62.158.32 (Score:2, Insightful)
Re:203.62.158.32 (Score:5, Interesting)
Cheers,
^Sarge^
Re:203.62.158.32 (Score:2, Insightful)
Re:203.62.158.32 (Score:2)
1) sarge installed OpenSSh earlier... assuming he's an australian, he's ahead of you...
and his machine was then the first one to phone home...
Mister BlackHat waltz right back into openbsd hq and updates the archive with his new zombies IP, and gets rid of his old one...
2) another australian decided to install ssh, with what happens to be a binary with some other poor sods IP in it...
logs into security related channel, asks who's had issues with OpenSSH recently...
etc etc
heh... pretty slim odds... but not *THAT* slim
Re:203.62.158.32 (Score:1)
Do we understand this correctly -
The person who found out, MavEtJu, asked on some irc channel [slashdot.org] if anybody had a problem installing openssh, too. And just because a random mood of the universe, the (only?) person who answered was you because you had a checksum error, too, when you installed it.
Now, as it turnes out, the ip number this program contacts during build time happens to be your machine.
Do you have any explantation for this coincidence? It just sounds so unlikely. I mean, you might have been the first person who installed the trojan which phoned home to some other ip and then the package might have been modified again so it contacts your host... but how comes you have been on the same irc channel, #sage-au, at that moment?!?!
This is not meant to flame or suspect you, I'm just curious.
Re:203.62.158.32 (Score:1)
Re:203.62.158.32 (Score:1)
Well since we don't have any details of the comprimise and ^Sarge^ chose to wipe the drive without any investigation first (that we know of) we prolly won't know.
But there'd be other ways besides sniffing. A rootkit with a trojaned login for instance. Maybe his pwd for that box was the same on openbsd? Maybe he did use sftp but sftp was trojaned as well.
Once the attacker rooted the box, anything became possible.
public key authentication (Score:2, Insightful)
Re:203.62.158.32 (Score:1)
nobody
Re:203.62.158.32 (Score:1)
Who is saying "Sarge"'s system was compromised ? The guy who put the troyan. Why should we believe him ?
If the goal was to crack into systems, the guy could have done a much better job of it. TCP out is useful, but why not open a port to the outside too? Make a little worm, a little network controlled by the first socket to try? Hell, controlled by the guy who has the private key . . . It's not as if the troyan had restraints in size, or that it had to be difficult to find!
At the *very* least, the IP should have been some unadministered korean server that would have taken weeks to track down. Round-robin several of them, too.
No, the IP belongs to someone on the OpenSSH team, guaranteed to be one of the very first people alerted.
Who is taking bets that port 6667 on his machine never was open at all, and that this is just a(nother) move to make OpenBSD look bad?
And, umm, who'll take a bet that OpenBSD.org FAQ number 8.18 (Why does www.openbsd.org run on Solaris?) will change radically
Re:203.62.158.32 (Score:1, Informative)
Re:203.62.158.32 (Score:1, Informative)
Building and rebooting is not enough. Next time, back up the entire machine so you can examine it for traces of those who compromised it, and then perform a clean reinstall from verified media.
Re:203.62.158.32 (Score:1)
Re:203.62.158.32 (Score:2, Informative)
Cheers,
Brian
Re:203.62.158.32 (Score:3, Informative)
Take a look at www.linuxfromscratch.org to see how this works for an entire system.
Re:203.62.158.32 (Score:3, Informative)
Recompiling the compiler doesn't do anything to rid you of trojan code/back doors. If you need to ask why, take a look at "Reflections on Trusting Trust" by Ken Thompson [acm.org], and the description of a back door [tuxedo.org] in the jargon file.
The short story is, that the compiler decides what to output. So you have to trust your compiler.
The reason for the recompiling of gcc is something else entirely: It is to allow the source code of gcc to rely on gcc, and to allow an optimized compiler to be created.
For additional information consult a good book on compiler writing.
Re:203.62.158.32 (Score:1)
Rebuilding from source, and paranoia (Score:3, Informative)
http://www.acm.org/classics/sep95/
Step 2: Decide for yourself if you're ready for the tinfoil-helmet brigade.
Step 3: Type 'make world' if you dare.
Re:203.62.158.32 (Score:1)
nobody
Re:203.62.158.32 (Score:1, Funny)
I'm sorry. I shouldn't have inflicted my strange sense of humour on the world.
Re:203.62.158.32 (Score:2)
Actually the odds are 3409878560:1. Go do the math.
Re:203.62.158.32 (Score:1)
Wiped the machine too early? (Score:1)
If the cracker rooted openbsd.org through this box, then any evidence of the attack would have been wiped, wouldn't it?
Or is there still a chance on finding out who was behind this and how it happened? Firewall logs maybe?
too many assumptions.. (Score:2)
i would wait until more information is available before jumping to what i would consider to be a silly conclusion.
Re:too many assumptions.. (Score:1)
It was rebuilt from source code - source code that he possibly did not verify, and using a toolchain that was possibly backdoored.
another assumption that i dont think you can accurately make, but hey i cannot stop you.
Re:203.62.158.32 (Score:2)
As for "rebuilt from source" you _did_ build on a clean machine, did you ??