Posted on 10/09/2002 5:54:22 PM PDT by Bush2000
Hackers send Sendmail a message
Online vandals hacked into the primary download server for Sendmail.org and replaced key software with a Trojan horse, a Sendmail development team member said Wednesday. The apparent attack on Sendmail didn't leave a back door in the popular open-source e-mail software package, as previously believed, but compromised the download software on the Sendmail consortium's primary server so that every tenth request for source code would receive a modified copy in reply.
"The exploited code that we see is not in our (development) tree at all," said Eric Allman, chief technology officer of Sendmail Inc., which sells a version of the open-source e-mail server program, and a member of the Sendmail Consortium, the development group for the software. "It seemed to be going to the (Sendmail) host, but it was delivering a corrupted file that wasn't on our server anywhere."
The problem apparently only affects source code for version 8.12.6 of Sendmail downloaded between Sept. 28 and Oct. 6, according to an advisory posted by the Computer Emergency Response Team (CERT) Coordination Center on Tuesday.
While the Sendmail development group is only just starting its forensic analysis of the computer that hosted the files, Allman said that its current theory is that the FTP (file transfer protocol) server had been hacked. If a user tried to download the latest Sendmail source code from the ftp.sendmail.org server, a compromised copy of the code would be sent instead about 10 percent of the time.
"It was a little bizarre that way," said Allman.
If the evidence confirms the theory, the hack would definitely be a strange way to compromise a downloadable file, said Marc Maiffret, chief hacking officer for security software firm eEye Digital Security.
"I'm not sure why they would want to do that," he said.
A Trojan horse--like the instrument that led to the downfall of the city of Troy--is a program that appears to be a legitimate piece of software but in fact has unwanted functions that allow a company or hacker to access the victim's computer.
The FTP server compromised by this attack apparently provided people who requested downloads not with the Sendmail source file, but with a Trojan-horse copy. This copy included a non-Sendmail test component that, when compiled, started a program that opens a covert channel to another server on the Internet. That server has since been configured to block the covert connection, according to messages posted to the Bugtraq security list.
Taking into account the 1-in-10 ratio, about 200 people may have downloaded the corrupted software over that eight-day period, said Sendmail's Allman. The development group is trying to contact everyone who downloaded the source code.
Both Sendmail and the CERT Coordination Center stressed that any software that is downloaded from the Internet should be verified using common cryptographic tools and the file's signature.
"Anyone that downloaded the code and followed good software practices would have found that this software was bogus," said Marty Linder, team leader for incident handling for CERT Coordination Center.
Linder stressed that, while the open development projects that give open-source its name may seem to invite problems like those of Sendmail, companies working on proprietary software have also run into problems.
In October 2000, Microsoft's source code may have been compromised by a hacker that penetrated the company's network allegedly with the help of a malicious program known as the Qaz Trojan.
"The same thing can happen if an intruder compromises the source tree of a private company," Linder said. "It's just another method for injecting badness into software."
But the same thing happened to a Microsoft service pack, so this has little to do with open/closed source code.
The other open source project with atrocious security was the old BIND. BIND 9 was totally rewritten, and has been much better in that regard. Sometimes, it does make sense to go back to the drawing board and throw out old, outdated code.
There are shadowy figures out there, though, who can do amazing things to even relatively well-maintained servers running whatever OS you choose.
http://www.viacorp.com/auditing.html
Friday, our Japanese participants discover that a computer on their company network has been cracked into, one very secure Linux box running only SSH and Apache 1.3.4. Now this would definitely send a chill up your spine if you knew just how fanatic our friends are when it comes to network security. Furthermore, they only detected the intrusion three days after the fact, which is unbelievable when you consider the insane monitoring levels they've been keeping since they agreed to participate in the scan. They would have noticed any funny stuff, and in fact, they did, lots of it, but none of which came close enough to a security breach to raise any alarms.Readers should also note how although a key binary in the cracked machine had been modified, tripwire and an assortment of other booby traps failed to detect this had happened. Even a close-up manual inspection (comparing file contents with a trusted backup, playing with it's name) could not detect any odd behavior. This trick, and others equally spooky were achieved by clever manipulation of the OS's kernel code (dynamicly, through a module).
...
How the NT box was cracked into in the first place is still a mystery. The logs weren't helpful (surprise! surprise!) and the only way we were even able to confirm this had happened was by putting a sniff on the NT's traffic (following a hunch) and catching those sneaky packets redhanded, transmitting our SSH identification down under.
We never liked NT before, being generally suspicious of propriety blackbox OS, from a company with a long history of poor quality bloatware. But realizing just how helpless we were against an attacker that obviously knew the ins and outs of this can-of-worms OS, the company recognized that NT was a serious security hazard and changed it's security policies to keep it as far away from it's systems as possible, and this included restricting employees from using it from at home to log into the company network (even with SSH).
2) The attacker is using a custom built software penetration agent.
This is only an hypothesis, but is strongly supported by the fact that the entire attack only lasted an incredible 8 seconds! During which the attacker manages to log on (over an employee's SSH account, no less), gain root privileges, backdoor the system, remove any (standard) traces of it's activity and log off.
And they probably would have gotten away with it too, if it wasn't for those meddling kids!
Who thoughtfully installed a crude old tty surveillance-camera hack that trapped IO calls to and from isatty(3) file descriptors, in realtime, saving them on file along with a timestamp for neato it's-almost-as-if-you-were-there playback qualities.
Scary stuff, that.
Someone replaced the original sendmail source code distribution archive file with a bogus copy which included malicious code that opens a TCP connection to an outside server on port 6667 and waits for input from parties unknown.
This code runs as part of the build process, it does not affect the sendmail program, ancillary utility programs or support/configuration files.
The intruder replaced the file on the ftp server, but not the copy kept on the http server.
The MD5 checksum files were not altered. The PGP/GPG signatures were not altered (nor is it likely that they could have been). Anyone bothering to validate the checksums or check the cryptographic signatures would have discovered that the file was not genuine.
What can we infer from these facts? Someone gained unauthorized access to the sendmail.org ftp server and replaced the source distribution tarball with a bogus copy containing malicious code. Do you know which ftp server was in use at the time of the compromise and which platform it was running on? If not, then to claim that the fault lies with open source software is ill-informed, at best. Based on past experience I would attribute it to willful ignorance on your part. If you tried a little harder to get the facts straight and draw credible conclusions instead of acting like someone who's determined to spin every incident into a repudiation of something he hates, your words might hold more weight with those of us who actually know the subject and you might even find yourself involved in constructive dialogs. Your habit of starting and engaging in flamewars does not serve your purported cause very well. It takes real effort to constantly remind oneself that your behavior is not typical of all advocates of Microsoft software and culture. The average reader is not willing to make that distinction and will either agree with you or not based upon purely subjective criteria (and the choir says "Amen!"). Are you comfortable knowing that those who agree with you do so only because they're members of your camp? I certainly wouldn't be.
I'm troubled by the recent spate of compromised source tarball incidents (OpenSSH, BitchX IRC client, etc.) and all the more determined to make sure that none of my systems fall victim. I recently enabled GPG signature validation on the package management system on a couple of my systems but I'm not pleased with the results: several of the packages I've tried to install are not signed. This particular system does the right thing and refuses to install the unsigned packages (even though the MD5 checksums are valid) but why aren't the packages signed in the first place? While the MD5 checksums are checked against pre-existing local copies of the MD5 sums, reducing the likelihood that the MD5 sums could be falsified, I'm not comfortable relying only on this method of validation and would prefer the GPG cryptographic signatures.
There is a problem here, and users of open source and Free (libre) software (including Microsoft) should be concerned about the authenticity of the source code they use. A strong signature-validating package management system like RPM adds some protection, assuming the builder of the packages has taken due care to validate the source code used to create the package in the first place, but this isn't good enough, and a better system will have to be devised. Given my past experience with open source I'm optimistic that these issues will be addressed in the near future. Perhaps it's time to consider adding MD5 checksum and GPG signature validation directly to the BSD and GNU implementations of the ubiquitous tar(1) archive utility (the sectar project aims to be a "secure tar").
The problem of ensuring the authenticity of source code distributions is only the tip of the iceberg. What are we to do about this problem? Is Palladium (or something like it) the answer? I don't know. Sooner or later someone is going to figure out how to make Ken Thompson's nightmare scenario a reality (if it hasn't happened already) and I doubt anyone is equipped to detect such a compromise and deal with it effectively.
As far as not liking Bush2000 posts, I have a simple suggestion. Just don't read them and post on them. Kind of like if a tree falls in a forest and no one is there to hear it...does it make a sound?
If you aren't doing that you are taking for granted that the code is good. I'm not talking about making sure it's authentic, but rather is it sound code (no bugs and such).
If you rely on others to do that, the argument of "I can review the code myself and make sure it's safe is bogus". My point is that you always rely on others. Open-source has many more people looking at the code than MS does. That has advantages and disadvantages. Black hats just as much as white hats can use that code to hack systems. According to the post (a couple of this one) it mentions Linux/Apache being hacked even though the admins were anal about security. And then it mentions NT had a similiar hack (not sure if they meant win2k or NT4), and the person is quoted as saying he does't trust MS products because it can be attacked like this. But wait, what about the apache/linux box that was hacked, which was probably acheived because of the open source code.
So it's back full circle. And the question is, which software can patch their software reliably and quickly? Can the open source community produce a patch fast enough and distribute it effectively to millions of users when a bug is found. Can MS or ther large software houses do the same?
(a couple of this one) = (a couple ABOVE this one)
Hey their both prepositions, so it was close enough
Mail is what you make of it, I get 100’s of emails everyday and I am cautious as to what I open. I keep security patches and virus update current religiously. People need to take personal responsibility, but I would guess that the average user would not be verifying check sums of programs they download from a source they know.
Nope. As I have posted before, we ran across Linus in 1991 and have been using Linux for years. From those early hacked out kernels or the early distributions that took 50+ floppies to the current stuff like RH 8.0. I have developers that do java work and .NET. Started an eval. project considering ASP.NET as a solution just last night.
This sendmail "event" is not so significant that it warrants a big red banner from Bush2000 and another thread for him to use this site to bash what is not Microsoft. It's like calling the cops about a broken barn door that was fixed last week because you are not sure if one cow is still walking around outside.
As far as your "simple suggestion? You are welcome to consider the suggestion yourself regarding my posts back to Bush2000. Which won't cease as long as he uses this forum to "troll" for people to start fights with. Not discussions, but fights among Freepers. That's why he does these posts. He has indicated that to me in freepmail. He thinks it's funny. I don't.
They're actively trying to turn the bulk of the thread into a flame war because they know that 80% of the people who see the flames will just turn and leave the thread, and not read the substance of the thread.
There are 2 basic methods:
His entire point with this thread is, clearly, to try and make the claim, "See, MS is no worse than anyone else -- everyone has security problems".
Then when people with knowledge come in to point out the flaws with that reasoning, he tries to answer with posts that will drive away the casual observer.
It's "FUD" standard operating procedure. It is on purpose, and it achieves the desired goal.
Security should be everyone's interest! I can't think of one problem I have had in my years and years of use of UNIX that someone else or the author hasn't encountered. With so many varients on various processors, someone is bound to have stumbled on it.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.