BitchX 1.0c19 IRC Client Backdoored 338
JRAC writes "A recent Bugtraq submission has indicated that the popular IRC client, BitchX, contains a backdoor. So far, only certain 1.0c19 files, downloaded from ftp.bitchx.com are reported to contain the malicious code. The BitchX developers have been notified, so hopefully a fix will be issued soon. Looks like irssi wasn't the only one ;)"
In other news ... (Score:4, Funny)
Re:In other news ... (Score:3, Insightful)
The name.... (Score:3, Interesting)
BitchX - "I 0NZ0R J00, B1TCH!"
Re:The name.... (Score:3, Informative)
Re:The name.... (Score:3, Insightful)
Open source only? (Score:2, Interesting)
The popular emulator Dos/Windows "Nesticle" comes to mind.
It's not the only issue (Score:2)
This is only an issue with OSS because they are often the product of one person, unfettered by marketing departments and financial considerations. Sometimes this is good (honest disclosure of a programs bugs and limitations, and realistic schedules for new versions such as "when it's done"), and sometimes this is not so good (you get juvenalia like BitchX, which aside from its bad habits seems to be a full-featured, powerful IRC client).
Re:The name.... (Score:3, Informative)
It's not really that much of an issue. It would be trivial to go into the BitchX source code, edit the PROGNAME definition, or whatever the equivilent, and make yourself a nice new IRC client named whatever you want.
Yes it is. Unless they've made major changes to the code recently. I tried to patching the code base about a year ago and make a censored version, but the program name is hardcoded in a million places. And once you do find and replace everything, you still have the problem of creating a new patch everytime a new version is released.
-Brent
Re:The name.... (Score:3, Interesting)
I'd think any average user could cut and paste that.
* Of course, you shouldn't let them on IRC or any other chat without supervision, but y'all knew that.
Re:The name.... (Score:2, Interesting)
It's difficult to find a name that doesn't have negative connotations in some language spoken around the world, as many product managers have unwittingly discovered [snopes2.com]. Big businesses employ branding agencies to help them find good brand and product names, Open Source advocates can't afford the exhorbitant fees they demand (and then they come up with names like "Opteron", gack).
Regarding "mingetty": in Swiss German (at least in the dialects spoken in the eastern parts of Switzerland) it's understood as "My godfather" if pronounced the right way.
Re:The name.... (Score:2)
BitchX backdoored
Most interesting... (Score:5, Interesting)
Sad that the developers didn't notice sooner, and it makes you wonder how many boxes have now additionally been 0wned because of this.
Who's this? (Score:5, Informative)
Re:Who's this? (Score:2)
Re:Who's this? (Score:2)
Re:Who's this? (Score:4, Informative)
netname DATACOM
descr Datacom
descr Warszawa Bemowo
country PL
admin-c AW7760-RIPE
tech-c RW7118-RIPE
status ASSIGNED PA
mnt-by AS5617-MNT
changed tkielb@cst.tpsa.pl 20000915
source RIPE
(stupidly formatted because of lamefilter)
Re:Who's this? (Score:2)
Hey. That's interesting.
I've been getting SSH scans from a Polish ISP right this week. I don't run BitchX (I use X-Chat), but a backdoor discovered with a Polish IP hardcoded in, and an increase in script kiddie activity from Poland in the same week doesn't sound like a coincidence to me.
MartRe:Who's this? (Score:5, Informative)
Yes, someone has most likely compromised the box and is using it for the backdoor. However, the owners of the box are still responsible for the lack of security that allowed their box to be compromised.
Re:Who's this? (Score:2)
Registrar:domaininfo.com
Domain Name: dtcomsa.com
[Owner of domain]
"dataCOM" S.A
Dworcowa 15
Plock, 09-402
PL
Nameserver: wenus.dtcomsa.com (213.77.115.17)
Nameserver: ns5.ports.se (193.12.211.20)
(emphasis mine)
But wenus.dtcomsa.com is also in the mx record for dtcomsa.com and dtcomsa.com itself does not have an DNS record nor does www.dtcomsa.com...
Re:Who's this? (Score:3, Insightful)
I see your point. Still, would you say the same for all the Windows users that did not patch there IIS code when Red Code hit?
Anyone who has a box attached to the internet has a responsibilty to others. They have to be held accountable for something. It is true that nothing is crack proof and you can't expect people to have perfect security. However, they have to take reasonable steps to protect themselves and others. But, what are reasonable steps? Who can judge?
If someone breaks into a house and steals a handgun, that was not locked up securly, and then uses it to commit armed robbery; should the home owner be responsible for the robbery? Of course not. However, the home owner should be responsible for improperly storying his handgun. This is the kind of responsiblity I'd like to see. Did someone take reasonable steps to secure their server?
As for the IP in question at the beginning of this thread. At this time, I don't know any details so I'm not casting any blame.
Re:Who's this? (Score:2, Insightful)
That is how I would see the house if it were an operating system with unpatched vulnerabilities in it.
Are you responsible if it burns down your neighborhood?
No answers here.. just an interesting question to mull over.
Jeremy
Re:Who's this? (Score:3, Insightful)
Re:Who's this? (Score:2)
Ignorance is not an excuse... (Score:2)
Bottom line, if you're not tech-savvy enough to secure your own computer, either get tech-savvy enough or hire someone trustworthy to do it (you'd be amazed how many broke nerd college students will secure your computer and check it on a regular basis for a pizza every time they work on it--my husband would have starved in college otherwise)...but I'm guessing I'm preaching to the choir here...
Re:Who's this? (Score:2)
That wasn't so hard. but if you want, you can find out more [netsol.com].
Geesh, these tools are just stitting there waiting to be used...
Re:Who's this? (Score:2)
Re:Who's this? (Score:2)
The reason I was asking was that it appears that they got most things right.
- they're using BSD. Good choice for security. ... ummmm ... using sendmail. There
are better options out there, like QMail, but
at least the version they're using is reasonably late - 8.11.6
- they're using QPOP for POP3. Reasonably ok.
- They're
- They've turned off all unnecessary ports. Most distros don't do that out of the box.
- They're obviously using ssh.
My point is that they're taking *reasonable* precautions but still obviously got r00t3d. I'm just wondering how ...
It's Odd (Score:3, Interesting)
From the post, "There is something very strange going on with the FTP server on ftp.bitchx.org. In some cases, it serves up the trojaned version; in others, the original, safe version. It seems to be client / client-behavior based (we're not sure exactly what)."
The post continues, "To add a little more to this; we've confirmed that if you come off of what appears to be a cablemodem/dsl IP you are likely to get a trojan'd copy. If you come off of a more static link, you are likely to get a clean copy."
Very strange.
Re:It's Odd (Score:2)
Moral of the story: *always* check md5sums, or use a packaging system that always checks it for you. Doesn't rpm automatically do this? Gentoo's portage does.
Re:It's Odd (Score:2)
Re:It's Odd (Score:3, Insightful)
Perhaps it's actually a DNS issues, and it's directing some people to a dummy server.
Re:It's Odd (Score:2)
Re:It's Odd (Score:2)
Why sign the checksum of a file when you can just sign the file itself?
Re:It's Odd (Score:3, Informative)
This makes one wonder a question that would be best posed to the community; the purpose of MD5/SHA/etc is to provide unequivocal evidence as to the validity of a piece of data. More often than not, such files are kept in the same, vulnerable, location as the actual data. Clearly one can see the downfall of such a system.
(source [google.com])
Re:It's Odd (Score:2)
So long as there are a concentrated, trusted, experienced few through which things are distributed, then gnupg could be employed to sign files and have those distribution masters public keys distributed with a distro. Problem here is that source files come from soooo many different maintainers that there would be as many public keys as packages. Of course with gentoo, instead of the 'portage masters' running md5sums, they could run this sort of signature, so that more permament public key would be around to verify files rather than a single vulnerable md5sum.... At that point there would then be three increasingly difficult levels to compromise to fool the system...
Re:It's Odd (Score:2)
If you were planning a DDOS attack, you'd want to make sure that people on fast but dynamic links (ie home users on cable/dsl who might not have good security) would be the ones to report into the 'home' ip..
that way, the person who trojaned bitchx would have access to a number of perfect, 'safe', but nice and high-speed clients for doing whatever they want to anyone, with reduced chances of the victims (the backdoored people at least) noticing.
only serving the trojaned versions to people who fit that description might have been a way to try and keep the backdoor 'low profile'
anyway, tiz just an idea.
Re:It's Odd (Score:2)
A software? Like BIND maybe?
The DNS explanation makes the most sense (of why sometimes you get a good copy and sometimes not). Seems like modifying the ftpd running to spit out different files for different people would be more trouble than it's worth... A simple DNS exploit would get the same job done.
It's a shame that the detailed analysis on security focus, which includes using different useragents and IP's, doesn't include a simple "host ftp.bitchx.org" for each... Thats most likely where the money's at.
Currently:
$ host www.bitchx.com
Host not found.
$ host www.bitchx.org
Host not found.
$ host ftp.bitchx.org
Host not found.
$ host ftp.bitchx.com
ftp.bitchx.com is a nickname for ftp.cyberpunkz.org
ftp.cyberpunkz.org has address 198.174.169.125
(tried from several boxes with different isp's and nameservers; same results every time)
And, an example of what the parent poster was talking about:
$ host ads.web.aol.com
ads.web.aol.com. has address 64.12.184.121
ads.web.aol.com. has address 64.12.174.153
ads.web.aol.com. has address 64.12.174.185
ads.web.aol.com. has address 152.163.226.25
ads.web.aol.com. has address 152.163.226.89
ads.web.aol.com. has address 152.163.226.57
ads.web.aol.com. has address 152.163.226.121
ads.web.aol.com. has address 152.163.226.153
ads.web.aol.com. has address 152.163.226.185
ads.web.aol.com. has address 205.188.165.57
ads.web.aol.com. has address 205.188.165.121
ads.web.aol.com. has address 205.188.165.185
ads.web.aol.com. has address 205.188.165.249
ads.web.aol.com. has address 64.12.184.57
ads.web.aol.com. has address 64.12.184.25
ads.web.aol.com. has address 64.12.184.89
ah, the good ol' days (Score:5, Funny)
Of course, back then, you could blame people for running something they didn't understand, since it was on the order of getting a whack-a-bill game by email and just running it, whereas tainted downloads aren't quite as shameful, but ah, it does bring back the memories of the Wild Days of irc...
indeed (Score:2)
bullshit (Score:2)
See, this is what's cool about OSS.. (Score:3, Insightful)
Anti-GPL people (read Microsoft and their lackies) may try and take this as a weakness in OSS, but I look at it as a strength. If one of their developers gets something like this into one of their products (either on his/her own or with the blessing of the company, the world may never know). With OSS, it's out in the open for everyone to see/fix.
Re:See, this is what's cool about OSS.. (Score:5, Insightful)
Not to burst your bubble, but if BitchX was closed source, I doubt a third party would have access to the source code to inject the trojaned backdoor, modify the FTP server and set up a bizarre distribution method (has anyone figured this out yet?). Granted many eyes helped find this problem, but in a closed source world, this wouldn't happen unless you had a disgruntled employee or a really stupid project manager. If BitchX were a commercial, closed source product, the exploit would most likely be a buffer overflow, not a blatant backdoor.
Disclaimer: I use a closed source IRC product called, Ircle [ircle.com].
Re:See, this is what's cool about OSS.. (Score:2)
I guess the only backdoors in MS software are the ones the developers put there
Re:See, this is what's cool about OSS.. (Score:2)
Exactly! Check out this post [slashdot.org] in the same thread. I mentioned exactly this problem!!!
Re:See, this is what's cool about OSS.. (Score:2)
You do know about binary patches, I trust. Backdoors don't require access to the source code. Not if you're good at assembler. (I'm not, but I've had to do binary patches on a couple of mainframe programs a few decades ago.)
Still, when I first started working with computers binary patches were one of the common changes made to working programs. True, they were small. But with a compiler to generate the binary, all you need to do is patch in a jump to your code, and then a jump back afterwards.
Perhaps things have really changed in ways that I didn't catch after dropping assembler. If so I'm sure someone will let me know just how stupid I'm being. But I doubt it.
Re:See, this is what's cool about OSS.. (Score:2)
Not really. All you need is some regular C code and a JMP instruction somewhere.
Re:See, this is what's cool about OSS.. (Score:2)
If so that would make it a viral type infection rather than an error or backdoor in the original BitchX code.
Re:See, this is what's cool about OSS.. (Score:2)
Are you seriously claiming that it is not possible to modify a binary? It is only slightly more difficult than modifying the source, and if you are doing it for the purposes of spreading backdoored software, the small difference in difficulty is not relevant at all.
Re:See, this is what's cool about OSS.. (Score:2)
Yes, I am seriously saying that a third party would not modify the binary, give it back to the Software Publisher and have the Software Publisher redistribute the modified binary to the public through their corporate FTP server.
Did you think about your comment before you typed it? Or did you fail to read my original comment. It makes no sense what-so-ever what you typed.
Re:See, this is what's cool about OSS.. (Score:2)
Surely the availability of source has nothing to do with the security of an FTP server or the entire network (including DNS) between you and the FTP server.
Re:See, this is what's cool about OSS.. (Score:2)
Then you are seriously deluded. Did YOU even read your comment, because what you are saying is complete and utter nonsense.
This guy didn't offer it as a patch which was then incorporated into BitchX. The software was modified, the FTP server distributing the software was rooted, the software replaced with the backdoored software (obviously in a sophisticated enough manner to evade casual inspection of the server), and people downloaded it.
Binaries are an even more useful tool for distributing back doors, because it's even harder to notice, and those as blind to this avenue of attack as you appear to be will cheerfully run these back-doored binaries, believing erroneously that because it is a binary, it's safe. You couldn't be more wrong, and I hope you're never subject to the consequenses of your blindness in this area in the future.
Re:See, this is what's cool about OSS.. (Score:2)
If they had rooted the machine they _would_ have access to the source, but no white hats would.
Re:See, this is what's cool about OSS.. (Score:2)
Right. Because viruses *never* hijack the functionality of closed-source software. Computer viruses only make open-source programs malfunction.
Re:See, this is what's cool about OSS.. (Score:2)
Not really. [acm.org]
Re:See, this is what's cool about OSS.. (Score:4, Insightful)
Anti-GPL people (read Microsoft and their lackies) may try and take this as a weakness in OSS, but I look at it as a strength. If one of their developers gets something like this into one of their products (either on his/her own or with the blessing of the company, the world may never know). With OSS, it's out in the open for everyone to see/fix.
Please. It's open for everyone who has nothing better to do than read slashdot or bugtraq, maybe. What much of OSS needs but doesn't have is strict maintainers, who know what contributions are made to the product and know what they'll do before they're let in. Fortunately, some of the bigger projects have this (Linux kernel, *BSD, Mozilla), but alot of OSS today is about people being too lazy or incompetent to double check some 15-year-old hax0r's crappy-ass contribution until it's too late.
The other thing OSS needs to enforce a little better is something along the lines of code signing. From what I can tell, it looks like somebody hijacked the bitchx FTP domain on some routes and is returning trojaned copies to the downloaders who are going through it. This is a weakness of OSS. It's much easier for me to grab a piece of Open Source software, drop some malicious code in it, and redistribute it from a hijacked domain than it is for me to do so with something I don't have the source to. Granted, it's still possible, if I inject code into the compiled version, but it's a hell of a lot easier to do it with source.
The simplest move is to use MD5's for major releases and have some 3rd-party location to verify them. Freshmeat? Sourceforge? This, at least, could add some security, and would a central point for people to watch out for hijacking...
Get your head out of the damned OSS-as-a-religion sand and look at what needs to be done to make it viable to people who don't fuck around reading about the next idiot to shoot himself into space in a backyard rocket.
Meh. Enough ranting, for now.
-Andrew
Re:See, this is what's cool about OSS.. (Score:2)
Yes, for the short term. For a longer-term solution, we need real security: application sandboxing.
Re:See, this is what's cool about OSS.. (Score:5, Insightful)
Frankly I am quite tired of this common belief that thousands of eyes are constantly scanning OSS looking for problems to fix. In the 9 or so years I have been using Linux and GNU software I have never looked for such things. Maybe that is because I am a developer and spend enough time with my code. Even when I first started with Linux and things like CDROM and NICs required patching and compiling I was content with the code I was downloading. Hobbiests tended not to screw other hobbiests (unless money is changing hands) and I tend to still believe that. I really doubt there are that many people who police code. If you are working on something and notice a problem then you submit a patch but the belief of a huge and constant code review going on is a false one as far as I am concerned.
With the popularity of Linux and free software however and the perceived threat to some commercial software it might be wise for OSS project leaders to be extra careful of new code that slips in. I have belived for a while that sooner or later we will see companies like Microsoft or Sun let slip some pattented code into a free software project just so they can come back later and shut it down with a lawsuit. Face it, these companies are getting hurt. A project like Mono has the potential to hurt
Anyway, I don't think you can look at OSS or a closed source project and say one is more "secure" than the other. I think it really comes down to how it is managed and the quality of the people who are contributing. You might also want to consider they type of application.
As far as IRC goes, this is a community where you are judged by how "bad-ass" your kick scripts are and your "l33t h4xx0r" skills. I'd be cautious of any IRC tool I used for that matter.
Re:See, this is what's cool about OSS.. (Score:2)
But the way I figure it, new developers have their software scrutinized more closely so you'd figure that someone joining just to mess things up wouldn't ever be really trusted.
Not that this rules out an entire project whose purpose is simply to release a trojan. Which is why it is a good idea to check the mailing list archives and IRC channels first.
I know Debian uses package signing. Many other distributions do the same thing.
So safeguards are in place -- its just there's nothing full-proof about them.
Re:See, this is what's cool about OSS.. (Score:2)
Internally, yes, but users can't verify packages...yet. AFAIK, the plan is to go forward with integrating debsig-verify after woody's release.
Re:See, this is what's cool about OSS.. (Score:2)
When your closed-source OSes firewall alerts you to a problem, can you find it? Can you fix it?
Now, when this happens on an open-source OS, can you find and fix it?
BitchX certainly isn't a critical application. But what if this was your web server? Do you wait until your vendor can supply you a fix, or would you (as a developer) rather tear into the code and fix it in a few minutes?
That's the big difference. Its not just in the detection, but also in the speed of repair and availability of a fix.
IMHO, closed-source software is simply not on the ball when it comes to getting patches out within a reasonable amount of time (which, to me, is under 24 hours of being alerted for a critical application). At least with open-source, if the vendor won't help you, you can at least help yourself.
Re:See, this is what's cool about OSS.. (Score:2, Insightful)
What the hell do you think source is anyway. Have YOU ever looked at it? That any person can just "look" at it and go "Oh, here it is, I'll just fix it here. There done."
Apache had to fix that bug. And it wasn't in a day either, it took neary a week. Other people hacked at it. DIDN'T FIX IT, but SAID they did and tried distributing a broken patch. HORRAY OPEN SOURCE!
We had to wait for the vendor to patch. Just like closed source. Code is generally FAR too complicated for anyone not familiar with it to just start hacking away at a "fix". Especially a "Security fix", which would require full regression testing to make sure the product still works as advertised and that the fix actually worked.
Re:See, this is what's cool about OSS.. (Score:2)
Perhaps so, but if a program were making a connection of a specific port, how hard would a:
grep -r [port number] *
really be?
I would suggest that for many problems, especially backdoors (however, certainly not all) the fix should be obvious to anyone who has read a book on C.
>Have YOU ever looked at it?
I've not contracted a problem similar to the BitchX one, and others tend to be patched fast enough its not a problem.
However, if I did see this activity that the backdoored BitchX causes, I would have certainly teared into the source.
Like a surprising many other people. I only look at the source when I need to. But if I couldn't on those occasions when I needed to, I'd be sunk, or at least very disappointed.
>And it wasn't in a day either, it took neary a week.
That's why you have the source. Need a patch faster?
FIX IT YOURSELF!
>Other people hacked at it. DIDN'T FIX IT, but SAID they did and tried distributing a broken patch. HORRAY OPEN SOURCE!
If you're a moron who runs patches from random people thinking that's your fix, well, guess what! That's as dumb as running cracks on windows programs to bypass time limits! Don't come running to me when you do idiotic things.
>We had to wait for the vendor to patch.
Only because either your company was to friggin' lame to have an in-house coder, or the program wasn't that important to you.
My whole point, which you have failed miserably to disprove, is that you can fix open source software yourself if the vendor fails you. If you choose not to do so, that's your problem, not mine.
>Code is generally FAR too complicated for anyone not familiar with it to just start hacking away at a "fix"
Either hire competent coders, or don't fix the problem, but instead disable it.
Disabling a problem might leave you missing features, but its a hell of a lot easier, and a hell of a lot better than the closed source alternative of simply not running the program at all.
Case-in-point: Apache can have the problem disabled with a simple config hack if you weren't competent enough to have proper programmers to repair the problem properly.
In short, don't blame open source for your company's/government's incompetence. And if it isn't for a company/government, I doubt that turning off the service for a week will seriously impede your way of life.
Re:See, this is what's cool about OSS.. (Score:2)
Some of us despise the GPL and love open source. Please don't incorrectly associate the two. It may reinforce the popular idea that the GPL is the guardian of everyone and that those who submit to the will of RMS will be saved, but it does nothing but confuse people and obscure the truth. It's no better than saying "People who don't like Microsoft (Mac users) tend to be computer illiterate weenies."
This may be an indication (Score:2)
So, now we can expect people that mostly ignored us to come and crack our servers, install backdoors into our releases. They're probably going to write better viruses, too. I guess this is the price you pay when you become mainstream.
For years we've told the world how secure our OS was. Err, could be, once configured properly. The time has come, now, to do this.
Re:This may be an indication (Score:2)
Linux has never been ignored and it can actually be a more desireable breakin from a kiddy prespective since it's much easier to make use of a broken Linux/unix box thanks to the inherent flexability and added bragging abillity to have broken something widely thought to be more secure.
I see regular scans on my servers for wuftpd telnet and open bsd's ftp spectific holes. In fact last year I realised I hadn't secured a freebsd install while I was on the bus home. The next day I rushed in to secure but it was already rooted.(thankfully nothing installed yet)
Running Linux, Freebsd or even OpenBSD has *never* been an excuse for slacking off on keeping servers updated/secured.
Backdoor. (Score:4, Interesting)
While the vast majority of these "easter eggs" are completely harmless, it's only logical to assume that they present an opportunity for malicous activities. I mean, who among us doesn't have SOME "H4X0R" history? Doesn't it follow that some of that will come out when the opportunity to put in a "gift" presents itself?
Also, this seems to me to be one of the down sides of the Open Source fight. Most of the accomplished hackers that I know are strong advocates of Open Source. It leads me to believe that most of the proponents of Open Source are or were at some time at least a script kiddie with delusions of grandeur.
Nobody I know has the time to actually check every line of code in a 200 Meg build for one or two lines of backdoor code, especially when the application is DESIGNED to make and break connections.
Re:Backdoor. (Score:2, Interesting)
There was another relatively famous piece of software compromised the same way recently as well. Somebody is going through some great lengths to put backdoors in the source of some good OSS. Makes you wonder how much is being missed.
Re:Backdoor. (Score:2)
And people have discussed using so-called "anti-viruses" but there are too many legal issues to deal with. If people just patch their boxes, problem solved.
Re:Backdoor. (Score:2)
SELECT * FROM lusers WHERE clue > 0;
go
0 rows returned
Re:Backdoor. (Score:3, Insightful)
Viruses and worms have been mostly merely malicious. Same with cracking. And the malice involved is not very great. But what if people get serious about stealing data?
A few years ago I had an epiphany one night, and waltzed into a network security company the next day.
"Look", sez me, "Inbound connections and activity are, in the long run, not going to be the real threat. The real threat is trojaned applications that mine for data and somehow send it offsite. You need to be monitoring outbound activity for appropriateness. For example, eventually you're going to see corporate espionage where someone writes an attractive and actually useful little app, then social engineers a targeted person within an organization to download it and compromise security. This is just an example of the general problem."
They were actually pretty impressed, but the company's strategy was deliberately to avoid concerning itself with viruses or worms (more specifically, they wanted to stay only on the servers, monitoring network activity in a sophisticated manner). But it seemed to me that this was a natural extension of their product and technology. And they thought I was a pretty bright guy, but they didn't know what to do with me. Well, anyway. The irony is that they were only a year or so later bought by one of the big antivirus firms, mostly just to acquire their technology.
In this particular case, the BitchX irc app, it looks like an outside source injected some backdoor code into the application, and hacked the ftp server to distribute it in a selective manner, presumably to help lower the risk of detection. A lot of effort for not that great of a payoff, really. Here, as is often the case, it's mostly about proving how clever you are.
But we're starting to see rudimentary examples of what I was warning about with spyware and other apps that make outbound connections that are in some sense illicit. Firewalls monitoring outbound connections can only be so successful given that they're always going to let some through. I know that some of the client based firewalling/monitoring software looks at connections on a per application basis. That's a start.
Personally, my inclination is that we need a networking monitor that operates like a virus scanner -- on the client, in the background -- that accesses a secured database of allowed application to outbound connection mapping, with secured handling of exceptions or new applications referred to a security admin (ideally) or an admin. This way we don't have to use a brute-force approach that simply locks down all allowed applications and allowed outbound connections in a non-specific, usability-destroying way.
But whatever the solution, I have little doubt that this will be a growing problem which will make a transition from script-kiddie nuisance cracking to something much more sophisticated. Although I could be wrong.
Digitally sign your sources... (Score:5, Informative)
Many think that a simple md5sum alongside the sources is enough. IT IS NOT. Any attacker who replaces the sources can as easily replace the md5sum, which can be generated by anyone.
A digital signature (I suggest using gpg) can only be generated by YOU if you keep it in a secure place, and use it to sign the sources. The public side of this key should be widely distributed and preferably signed (that is recognized) by third parties... the most trustworthy these third parties can be, the better.
After the huge attack on the network where such sites as Apache were hosted, other Apache projects which did not sign their packages suddenly started signing them. They got scared. You should be too.
A lot of people instinctively trust their dns resolutions (oops) and also think that if they go to http://www.mozilla.org they will get their favorite browser for sure. They are also wrong. dns can be spoofed under certain conditions, so they could be going to crackersR.us instead, and downloading a neat trojaned source, for instance.
The more a project grows in fame, the more it will become a likely target for these kinds of attacks, so the more need to a degree of responsability that should not be needed, but it unfourtunately is since the danger is ubiquitous.
Be carefull, be very carefull.
Also avoid using user root period.
Re:Digitally sign your sources... (Score:2)
Re:Digitally sign your sources... (Score:2)
1) get their keys from them.
2) sign their keys.
3) have them sign yours.
Build a big web of trust. Get interconnected. Of course, this does require interpersonal contact, but with practice I'm certain you'll find that face-to-face contact isn't that repulsive.
Large projects such as mozilla or apache could also hand out cards with their public gpg key fingerprint on them at developer convention. (It is assumed that the saving grace here is that the fingerprints, being small, can be repeated all over the place.) Something like apache could then have a key that is used to sign the keys of subprojects.
True, no system is perfect. It's still always possible that a long-trusted developer will suddenly decide to put a backdoor in their own program, and therefore any system that defends against attacks that are more difficult than convincing a trusted developer to do just this is overkill. However, the open source web of trust is not nearly as interconnected as it should be, and this lack of connections creates a serious chance for failure points.
GNU/Linux needs signed downloads (Score:5, Insightful)
GNU/Linux downloads should be in signed archives like Netscape JAR files. JAR files are basically ZIP archives with a signature file stored inside the .zip in a standard place. When you unpack the archive, the unpacker checks the signature the same way a browser checks an SSL web site.
JAR files use a certificate chain ending in a certificate authority (usually a commercial one) but maybe the signed-download scheme could be signed against a certificate on the official developer's website. Of course that wouldn't be unspoofable, but it would be as secure as the current scheme of having a PGP public key on the developer website and signing against that. The main benefit is the checking would happen automatically, so it would be much harder to put crap into downloads. If someone makes a modified version, they would have to sign it themselves (with a signature pointing back to their own website) or else the unpacker would print a message saying the code was unsigned and the user should check it carefully before using it.
Re:GNU/Linux needs signed downloads (Score:3, Informative)
Re:GNU/Linux needs signed downloads (Score:2)
GNU/Linux, and *any* OS for that matter has the potential to provide for this sort of thing. the GNU/Linux layers (the kernel and basic system utilities) are too low a level too require this stuff. The difference of doing it by hand as opposed to doing it with a yes/no dialog is simply a matter of a simple utility integrated into a distribution and some signatures/public keys distributed in advanced through a trusted channel. In some form or another, it is already in place for a lot of things.
For example, I use gentoo and *always* install through the portage system. The portage tree includes ebuild build description and md5sums for the ditribution files. This requires an attacker go in and compromise the portage tree and also provide/hijack distribution files for that package. Not perfect but not too shabby. The emerge process always checks MD5s.
I'm not sure if apt-get, urpmi, apt-rpm, or the FreeBSD ports systems do this, but even if they didn't it wouldn't be a huge leap to add this functionality.
Perhaps the better thing to come away from this knowing is that sometimes using package management holds the answer. Sure you can download and check signatures manually, but many don't and so having a package distribution system that forces the issue can slow issues like these drastically..
GNU/Linux HAS signed downloads (Score:3, Informative)
Dpkg also recently added GPG support, buy you have to trust individuals rather than a specific company - no packager is going to lose their job if they're working in Albania on Debian trojaning packages.
Enough talk (Score:3, Funny)
Re:Enough talk (Score:5, Funny)
What would that be exactly? Sending too many visitors to their website?
Re:Enough talk (Score:2)
Re:Enough talk (Score:2)
Dan Bernstein bet $500 that qmail is, and he seems to have won. Or do you have some other definition of "secure" of which we're not aware?
If you were using a Trusted Computing machine . . (Score:5, Funny)
GnuPG (Score:2, Insightful)
Aha (Score:2)
Backdoored? (Score:3, Funny)
Put the client in a jail (Score:4, Insightful)
Jailing a browser is tougher, but an IRC client should be easy. Somebody who's into IRC and security should do this as a demo.
Re:Put the client in a jail (Score:4, Insightful)
As far as file system access, neither *truly* require write access to the disk nor read access to nothing more than a few config files. I know, browsers tend to use disk as cache and you want to download using your browser as well, but same goes for IRC, a large portion of users exchange files through the IRC client with the intent of the transferred file not being transient. For those who want to have non-transient downloads (and ability to save configuration, both sorts of clients equally likely to require this), chroot is as far as I would go.
Strictly speaking, all network applications have similar issues. While it may appear easy to pinpoint required operations of a piece of software, there are always enough deviations to make it not 100% possible to tighten it all down. The only place where you can really predict and jail based on those predictions what a network application needs to do and access is on the server end where you have the most control over how the network is used. Clients having to interoperate with oddball server configurations and users who want to use the software in different ways will always make the jailing you describe less feasible.
Of course, most any app could run fine in a chrooted environment if you have the disk space for the requisite libraries, and that by itself greatly reduces (but doesn't eliminate) threats to data outside the chroot jail.
Re:Put the client in a jail (Score:2)
That assumes you don't modify the client. I'm proposing that the clients be modified to live within tight security restrictions. The general idea is that you put the app in a restricted environment and fix the app until it works there. Maybe some features won't work; those are turned off.
The Unix/Linux world needs to make this work, as their response to Palladium. This is real security, not just signing and authentication.
Something like LOMAC may be helpful here. Systrace is useful to find what needs to be fixed in apps, but that approach doesn't result in a policy without holes.
IRC clients are a good place to start because 1) they get attacked quite a bit, and 2) they're not as big as browsers.
Re:Put the client in a jail (Score:2)
Look kids... (Score:4, Insightful)
Also, even though the box doesn't appear to be compromised, it could happen. I hope one of you kids out there is the first one attacked when a new apache or ssh bug is found. You can never be completely secure, especially when you are running anonymous servers for people to download programs.
kthx.
ice-man@efnet.
World domination. (Score:2)
Waste many months of otherwise useful time writing an IRC client. Make sure it gets really popular by adding neato colors. Oh, and give it a name that's sure to offend my mother.
Wait until everyone trusts me, then throw something slightly more interesting into the mix. Like a blatant back door. Hope no one notices.
Screw with my FTP server and make it looked hacked, to ensure deniability.
Assume global emperorship.
Of course, if I had done it, I would have made it more subtle. Perhaps a hard-to-find buffer overflow in CTCP handling, or such...
(The preceding was a JOKE...)
Yet another configure backdoor (Score:2)
Granted, exploit could be hidden from such a simple check but it still seems that above would be enough to prevent backdoors.
Escaped the radar (Score:2)
Re:XSS in Slashcode (Score:4, Interesting)
----- BEGIN BugTraq POST -----
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
Precedence: bulk
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Uns
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Del
Delivered-To: moderator for bugtraq@securityfocus.com
Received: (qmail 31935 invoked from network); 2 Jul 2002 08:55:04 -0000
Message-ID: <20020702085626.305.qmail@web21002.mail.yahoo.c om>
Date: Tue, 2 Jul 2002 01:56:26 -0700 (PDT)
From: gcsb <gcsbnz@yahoo.com>
Subject: XSS in Slashcode
To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-UIDL: "[K!!WR\"!nkN"!NSF"!
There is a nasty Cross Site Scripting(XSS) vuln in
Slashcode. This was used a day or so go on
slashdot.org and resulted in most of the site being
taken down for an hour or so. The maintainers of
slashcode have patched the problem in CVS but have not
even mentioned it anywhere that I can find. This
leaves all sites using slash vulnerable to this
exploit.
An example exploit (incomplete) is as follows:
<p > onMouseOver..insert javascript here...>
I am dissapointed that the slachcode maintainers have
silently fixed this on slashdot.org yet made no
mention of the problem elsewhere so that other sites
can patch themselves. No wonder there are so many
"trolls" on slashdot.org...ah well.
If you run a site using slashcode, get the latest CVS.
That is all. Move along.
_______________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
----- END BugTraq POSTING -----
You didn't even reformat the exploit code so that it showed up properly... sheesh.
- Jester
Re:XSS in Slashcode (Score:4, Informative)
Your Bugtraq response was fatuous at best. (Score:2, Insightful)
as the CVS tree is a pre-alpha version. We have not yet even
stamped it with a development release number (which will be 2.3.0
as soon as we feel it is stable enough for bleeding-edge users).
In spite of the fact that you haven't "stamped" the version with a release number, you had gone ahead and deployed a version of software which was open to and was, in fact, visibly exploited by XSS flaws. You then pretended that it never happened. No "whoops, we screwed up, here's what we did wrong so the rest of you can avoid our pitfalls" on the front page of the site that was exploited, no note on slashcode.com that people who have deployed the same version that you deployed are open to exploitation as well.
> Sites running CVS should stay as current as possible at all times,
of course. The courageous admins of those sites should probably
hang out on the IRC channel given on the slashcode.com homepage
(#slash on irc.openprojects.net).
This doesn't reflect reality. Many people pull down a CVS snapshot and run with it, but it's nice to know that you think that admins should spend what little free time they've got idling in IRC just in case there's another bug that you don't feel like publicizing is exploited.
Now that I think about it, doesn't that sound a whole lot like "security through obscurity"?
Re:XSS in Slashcode (Score:3, Insightful)
Re:How long... (Score:3, Insightful)
Re:That can't be! (Score:2)
Sheesh. For the first time in living memory we have had TWO security patches to install IN THE SAME WEEK! Omigod the walls are closing in! I must migrate immediately to Microsoft products, they'll save me!
Re:HA HA HA HA HA (Score:2)