Hi all,

I recently signed up with a hosting company which has been recommended on this board (but doesn't post here). I did some poking around from a shell to get a sense of how well they administer their servers. I discovered that the software they use for email account management uses standard unix DES encryption and keeps encrypted email passwords in a file that anyone can read. That means any user with a cracking script can have a field day. Each account's main email password is the same as its login password, so someone could use a cracked email password to gain full access to an account (I verified this).

This host has been in business for 4-5 years, hosts 10,000+ sites, gets very few complaints from customers and advertises their sysadmin expertise....

Is this a case of extreme negligence on the host's part?
Was it wrong of me to snoop?
How can someone be sure that their host is adequately protecting their security?
What level of security can you expect from a hosting company?

Hoping for some enlightenment.

Originally posted by worrywort
Is this a case of extreme negligence on the host's part?
Was it wrong of me to snoop?
How can someone be sure that their host is adequately protecting their security?
What level of security can you expect from a hosting company?


Yes. No. By "snooping", exactly as you did. Much more than that.

Standard practice upon discovery of a security hole is to alert the responsible persons to the problem, and then release details (eg, the name of the host) publicly 1-2 weeks later.

Originally posted by cperciva
Much more than that.

To elaborate further, an acceptable minimum level of security from my point of view is one which only a Three Letter Agency could reliably break without detection, and which can only be detectably broken at the expense of $10K or more.

Originally posted by cperciva


To elaborate further, an acceptable minimum level of security from my point of view is one which only a Three Letter Agency could reliably break without detection, and which can only be detectably broken at the expense of $10K or more.

just a note :
A great write up on "practical threat analysis and risk management" in Linux Journal issue 93 jan 2002.

I've checked your previous post cperciva, ( for 2 months or so ) your very correct on many of your posted statements. This write up is defintely something to place within your arsenal.

summary:
how to make a value ($) for the risk
how to plot the risk
how to invest in the proper protection to prevent (reduce) the risk from happening.

IE: most people can't hire a bodyguard, but most people can learn self defense.

Side note :
the information that this person has is worth allot of money in the wrong hands so please open a non usa based e-mail account (yahoo, hotmail, and msn can have a court order showing the ip logs ) and give your hosting company an e-mail showing them what you did. Also you should consider backing up your files because a log review should show your break in.

just a thought

Thanks to cperciva and ADEhost for the good advice.

cperciva suggested notifying the host and then making the information public in a week or two.

I've already emailed my host about the situation using an anonymous remailer (hard to say what they might do if they get panicky).

I have mixed feelings about whether or not to make the host's identity public in the end. On the one hand, if they don't tighten up their security in a reasonable amount of time, customers should be warned.

On the other hand, this isn't a root-level incident. It (only?) endangers the data of users who chose insecure passwords (there are thousands of them -- seems like the host has an extremely lax password policy). If they do the right thing and fix the problem, should I still divulge the host's identity, possibly damaging their (relatively spotless) reputation? Maybe not.

- worrywort

Originally posted by ADEhost
how to make a value ($) for the risk

Of course, that's much easier said than done when it isn't your data at risk. Unless you're going to insert into your ASP "you may not store confidential or proprietary data, for which the cost of loss or disclosure would exceed $xxx, on our services", it is only reasonable to act on the assumption that there is such data at risk.

Originally posted by worrywort
I have mixed feelings about whether or not to make the host's identity public in the end. On the one hand, if they don't tighten up their security in a reasonable amount of time, customers should be warned.

On the other hand, this isn't a root-level incident. It (only?) endangers the data of users who chose insecure passwords (there are thousands of them -- seems like the host has an extremely lax password policy). If they do the right thing and fix the problem, should I still divulge the host's identity, possibly damaging their (relatively spotless) reputation? Maybe not.


I'd still make full disclosure. There is no excuse for such a security issue existing in the first place; fixing a security hole after the fact doesn't alter the fact that it existed to begin with. There are inevitably going to be companies which care more about the perception of security than security itself, and publicly shaming one company is likely to make others revisit their security provisions.

Also note that this effects everyone on that server: DES is weak enough that any of the passwords could be brute forced in a relatively short time (you might not find the *same* password, but you'd find one which worked).

Originally posted by cperciva


Also note that this effects everyone on that server: DES is weak enough that any of the passwords could be brute forced in a relatively short time (you might not find the *same* password, but you'd find one which worked).

Hey there,
Not everyone has there own Beowolf cluster in thier data center ( maybe some do have there own private ones ) but anyway, your right. a brute force attack would gain you entry. but at some point a sysadmin has to wake up and say ..." what are all these request "

mike

Hi,
I'd just close your account and tell you to look for a new host, no host is going to waste their time on changing a perfectly fine encryptiong method to your method of your choice

DES is fine, that is how /etc/shadow is encrypted.

That is the least of your problems anyway. hackers do not want your "email passwords" when they can just root your servers and sniff out all that credit card data.


Sounds like you have too much time on your hand.

Originally posted by CLEARVERT
Hi,
I'd just close your account and tell you to look for a new host, no host is going to waste their time on changing a perfectly fine encryptiong method to your method of your choice

DES is fine, that is how /etc/shadow is encrypted.

That is the least of your problems anyway. hackers do not want your "email passwords" when they can just root your servers and sniff out all that credit card data.


Dear CLEARVERT,

<sarcasm>I hope more security people read this and stick to it </sarcasm> no I hope not. It's bad enough that the password traves in cleartext but that's another story.

E-mail, on this scale of 1000 accounts from different companies have a higher market value than the the credit card fraud. somebody would apy good money for this sort of stuf.

Also this is the first step of a break in, given they might not learn alot. Good hacks require lot's of time.

Mike

I would simply suggest contacting the host (preferably a high level manager), discussing the problem, affording them an opportunity to respond professionally. If they do, then I would be thankful I didn't encounter major problems from their lack of security, test again in the future and give them a chance to prove this was a one time mistake.

To me what one really wants to accomplish is correcting the problem and insuring it doesn't recur. Posting the host's name does not assist in either. In fact, all it does is open their sites to more attempts to bypass security and put your service as well as that of others at even greater risk. So, this would hurt the host as well as those innocent parties who host with him.

I just believe one should give any vendor an opportunity to atone for their mistakes first. Then if they fail, or if they continue to display disappointing service it is ok to disclose more in the forum. This is common courtesy.

Again, I strongly support this forum and find it to be a great service and appreciate your warning to all hosts and all customers. I just believe the host in question deserves to be contacted outside of this forum and given a chance to correct his mistake.

worrywort you been and kicked your banks back door recently? You never know they might have one of those cheap locks and anyone could get in, or maybe throw a brick at the window see if it breaks? I mean if you visit your bank manager and he invites you into his office and then leaves you alone for a few minutes do you try all of his filing cabinet draws to see if they are open? I agree with CLEARVERT

E-mail, on this scale of 1000 accounts from different companies have a higher market value than the the credit card fraud. somebody would apy good money for this sort of stuf

Why:confused: when they could root a machine for next to nothing stick on a sniffer and get thousands free?

Allowing a customer shell access is placing your trust in that customer, just like a retailer has to trust staff not to empty the till into their pockets each night, to that end your host may also want to review their procedures on who they allow shell access to

Originally posted by shorty
Why:confused: when they could root a machine for next to nothing stick on a sniffer and get thousands free?

Some people work on the hypothesis that good security includes patching root holes.

Let me quickly summarize the nature of my host's security problem. The vulnerability makes the cyphertexts of both user email and login passwords visible to any user, exposing them to cracking. This won't help a user gain root access (only the passwords of ordinary users are exposed), but it does make it really easy for somebody without much knowledge to run amok and cause a lot of damage.

According to CLEARVERT,
DES is fine, that is how /etc/shadow is encrypted.

I disagree. The unix implementation of DES might have been ok in 1979, but it's hardly adequate to withstand attacks by today's computers. That's the reason encrypted passwords were taken out of the /etc/passwd file and put into /etc/shadow (which is _not_ world-readable). The shadow password system is a kludge that was created because of DES's inadequacy. DES-encrypted passwords are especially vulnerable when passwords are short or use a limited character set. The password that was first assigned to my account used only lower-case letters, three of which were repeated. That was an early warning signal that this host was weak on security. With passwords like that, it should be a piece of cake for a password cracker to harvest a large percentage of all the user passwords. I don't mean to sound like a know-it-all, I'm far from that. This stuff is pretty much common knowledge--which is precisely my point. This host manages around 10,000 user accounts (this host uses very capable Sun servers, not your typical couple-hundred-user Linux boxes), and every one of them has shell access, so there's a pretty good chance that a few out of those thousands of users are savvy enough and malicious enough to find the vulnerability and cause a lot of damage.

shorty said,
worrywort you been and kicked your banks back door recently? You never know they might have one of those cheap locks and anyone could get in, or maybe throw a brick at the window see if it breaks? I mean if you visit your bank manager and he invites you into his office and then leaves you alone for a few minutes do you try all of his filing cabinet draws to see if they are open?

The bank metaphor is useful, but not in the way that shorty intended. If you knew that your bank left the door to the vault containing the customers' safety deposit boxes wide open and unguarded, and protected those boxes with flimsy padlocks, would you store your valuables in that bank? Wouldn't you feel a responsibility to warn other customers about the problem? I don't see it as a matter of trust at all. What bank is going to stay in business longer, the one that trusts its customers not to filch each other's belongings, or the one that uses bombproof vaults guarded by shotgun-wielding Sikhs (I'm writing from Hong Kong, where this is a common sight)? I'd say that it's another case of "Only the paranoid survive".

worrywort

So who is the host?

Originally posted by worrywort
The bank metaphor is useful, but not in the way that shorty intended. If you knew that your bank left the door to the vault containing the customers' safety deposit boxes wide open and unguarded, and protected those boxes with flimsy padlocks, would you store your valuables in that bank? Wouldn't you feel a responsibility to warn other customers about the problem? I don't see it as a matter of trust at all. What bank is going to stay in business longer, the one that trusts its customers not to filch each other's belongings, or the one that uses bombproof vaults guarded by shotgun-wielding Sikhs (I'm writing from Hong Kong, where this is a common sight)? I'd say that it's another case of "Only the paranoid survive".
worrywort

No, a more realistic analogy for this situation is that the vault is controlled by a 20 digit keycode that must be punched in. Sure, if a person tried every single combination, they could get in, but first of all - that would take a very long time (The DES decryption record is around 23 hours with an international cluster of computers working on it) second of all, is nobody going to notice this or isn't there some sort of alarm that would sound (In UNIX, it normally tells in the server logs as well as scrolls on the screen when there is a failed login attempt). I seriously think that you are making way too big a deal of this.

I don't really know what DES is, but I have a question:
If DES is good enough for Unix password file, how come it isnt good enough for an e-mail program?
And if it is a bad defense, why Unix uses it?
And if im not mistaken, everything is breakable, so one defence takes 23 hours and one takes 46, isnt that true?
help me on this

jw wrote:

No, a more realistic analogy for this situation is that the vault is controlled by a 20 digit keycode that must be punched in. Sure, if a person tried every single combination, they could get in, but first of all - that would take a very long time (The DES decryption record is around 23 hours with an international cluster of computers working on it) second of all, is nobody going to notice this or isn't there some sort of alarm that would sound (In UNIX, it normally tells in the server logs as well as scrolls on the screen when there is a failed login attempt). I seriously think that you are making way too big a deal of this.

I may be deluded, but I see a few problems with this poster's point of view.

1. jw assumes that users are well protected because DES takes a lot of resources to crack. The typical method of cracking DES-encrypted passwords is a trial-and-error process of generating a bunch of password candidates, _encrypting_ each candidate to get a cyphertext, then comparing the cyphertext of each encrypted candidate with cyphertexts from the password file, looking for matches. In particular, the kind of attack that jw is talking about is a brute-force approach that tries every possible key in the whole 56-bit keyspace, which still takes more computing power than ordinary people have sitting on their desktops. That kind of attack is not necessary if the attacker is just aiming at guessing a number of poorly chosen passwords. A modern PC can try out more than a million password candidates per second, which is more than fast enough to harvest a large percentage of passwords on a system that lets users have weak passwords. That's only possible if the attacker can get ahold of a list of encrypted passwords, though. The shadow password system's job is to hide this information from ordinary users. My host exposed this information to everyone on the system.

2. jw is assuming that I'm talking about an outsider trying out a bunch of passwords over the network, which would certainly cause "some kind of alarm to sound", in addition to being spectacularly inefficient. I thought I was pretty clear in my posts that the threat is from somebody who already has an account getting ahold of other people's encrypted passwords (and presumably cracking them at home). Some of the other posters seem to have the same misunderstanding. I think it's because when some people hear "security vulnerability", they automatically think of bad guys lurking somewhere out on the Internet, getting in over the network. I'd say that security is about protecting user data and system resources from a wide range of threats, including other users, human error and also hardware failure. By that standard, this is clearly a serious problem, and not something I'm making "too big a deal" about.

Damn, reading over what I just wrote, I sound like a big geek... guess it's bred in the bone. To those people who think that these DES-encrypted passwords aren't vulnerable, should I run Crack on the list and see how many passwords we can get in a day? It would invalidate my TOS agreement, but I'm sure it would be fun and also make my point.

What do you think, if I run a password cracker but don't do anything harmful with the information, am I stepping over some kind of line?

worrywort

I don't see it as a matter of trust at all

you obviously don't and you obviously miss the point, so I will ask again - did you go snooping around your bank to check its security? No you didn't and if you did you would probably be breaking the law.

What you did is the same, did you ask this host either before signing up or before SNOOPING what his security arrangemnets were and whether they used DES? Let me guess NO!

You were obviously snooping around looking for something what was stopping you from opening a support ticket and asking this host or emailing their support team?

if I run a password cracker but don't do anything harmful with the information, am I stepping over some kind of line?

check the terms of service with your host and hopefully he will have this covered and hopefully he'll kick you off - who died and left you in charge of this guys security? If you don't like it cancel your contract and go someplace else and this time ask before snooping

It really annoys me when people think they can get away with doing stuff in the virtual world that they would get arrested for in the bricks and mortar world

As I saud above worrywort go snoop around your bank and see what happens

You bring up a good question, shorty: Am I doing a _bad thing_ by snooping around my host's server and even violating my TOS agreement, when the only consequences are that the host has a chance to tighten up their security before someone takes advantage of the problem to do some real mischief? Is it better that the problem is found by a confirmed snoop like me, who would never dream of damaging my host's servers or harming any other user, or by someone with no qualms about messing with other users' data or even selling passwords? If the only people that ever pried, tested and snooped were the bad guys, we'd be living in a much less secure world.

Shorty introduced an indignant and moralizing tone to the discussion... I don't claim to be a moral exemplar, but I don't see myself as having done a bad thing, either, even if I violated the host's TOS. If my actions cause harm to others, they're bad, no question about it. If they end up benefitting other people, what's the problem? And if I end up annoying people like shorty, that's just frosting on the cake!

If you're walking down the street and you see that a bank's back door has been left wide open, is it wrong to report it? Is it wrong to be walking down the street, because you might happen to notice such things?

Of course not.

Reporting a broken back door is legal, but going into that back door to see how safe it is, and start playing with the combination safe numbers to see how hard it is to crack is wrong.

As I asked before, did you email your host before snooping around and ask these questions?

Shorty introduced an indignant and moralizing tone to the discussion

you are dead right, what you did isn't acceptable in any part of either personal or business life and I'm really not sure why you think it is, your justification is so weak. TOS are TOS, placing trust in customers is just that, if your host wanted customers to test the security of their system I am sure they would ask you. Do you ask your friend if their ATM pin number is easy to guess, ie based on birthday etc, and if it is advise them to change it, or do you steal it out of their pocket and go try it in a machine?

If you had accidently stumbled upon a security hole whilst carrying out normal activities then fine, but you went looking for them that isn't acceptable whether you mean well or not - if you wanted to act as a security consultant for the host offer your services in competition with the other security specialist firms.

What's really sad is you think you are doing someone a service, you're not, you think you haven't done harm, you have, when that host finds out a trusted customer has been probing his systems security how do you think he will react? He will probably do something about any security hole highlighted and probably not trust anyone to access his servers by shell again, which means the honest users lose out.

Originally posted by shorty
As I asked before, did you email your host before snooping around and ask these questions?


Would a "bad guy" do that? You have to understand that anybody can buy the same account you buy from your Web host. The only qualification is a few bucks to spare - and a cracker might just use a fake or stolen credit card anyhow.

Therefore, the assumption has to be that the server has to be protected from every customer. You cannot assume that customers are magically trustworthy, well-intentioned, or in fact not going to cause problems accidentally. You have to assume that every account could have bad intentions, or could be compromised by someone with bad intentions.

The original concern about DES passwords being available is somewhat valid. MD5 would be better. Having the passwords stored in a way the user account cannot access might be better, but then requires additional privileges for any program that does require those passwords (which could mean another process running as root that could otherwise run as the appropriate user). That's a tradeoff.

Security through obscurity is no security at all. Security based on everyone "not looking too hard" for vulnerabilities is no security at all. Security vulnerabilities should be found, reported, and if not fixed in a reasonable timeframe, disclosed publicly in order to encourage a fix. I'm sure Microsoft doesn't agree, but most of the security community knows better.

Kevin

Originally posted by sigma
Having the passwords stored in a way the user account cannot access might be better, but then requires additional privileges for any program that does require those passwords (which could mean another process running as root that could otherwise run as the appropriate user).

Of course, we all know that the Right Solution to this problem is to have a password verifier which is chmod 4550, uid root, gid group-of-users-who-are-allowed-to-check-passwords, while running everything else at low priviledges.

Originally posted by cperciva
Of course, we all know that the Right Solution to this problem is to have a password verifier which is chmod 4550, uid root, gid group-of-users-who-are-allowed-to-check-passwords, while running everything else at low priviledges.

Unless each user's set of passwords is in its own file, in which case that file can be readable only by the user, and the appropriate process can run as that user.

If they are in one master file together, then yes, you will need a helper process, or you will have to leave the file readable as the unnamed host appears to have done.

Kevin

Originally posted by sigma
Unless each user's set of passwords is in its own file, in which case that file can be readable only by the user, and the appropriate process can run as that user.

In the context of humans who reuse passwords, I don't think this is the Right Solution. An exploitable cgi could be leveraged into knowledge of a user password, which could then be used to gain access to other systems.

Originally posted by cperciva
In the context of humans who reuse passwords, I don't think this is the Right Solution. An exploitable cgi could be leveraged into knowledge of a user password, which could then be used to gain access to other systems.

Respectfully disagreeing. An exploitable CGI could be leveraged into all kinds of nastiness which would cause the user grief, whether they reuse passwords or not. You could trojan their account and get whatever you wanted.

Also, you're storing MD5-encrypted passwords for extra mailboxes, not the main account itself. And MD5 is harder to crack than DES.

On a minor point, the exploitable CGI vulnerability only applies in instances where the user is going through cgiwrap or suexec.

Ultimately, no system is secure "in the context of humans" :)

Kevin

Hi folks,

Judging from some of the previous posts on this thread, what I'm about to say next is going to piss some people off. I think this information could be useful, though, so I'll go right ahead and post it.

I ran a password cracking program on the (infamous) list of email passwords on my home pc for 48 hours. My computer has a Celeron processor running at 850 MHz--not exactly cutting-edge technology. The list contains more than 30,000 passwords. In that time, about 40% of the email passwords were cracked. It looks like more than 1000 of those passwords are to primary email accounts (as opposed to extra email accounts), which means that they are also login passwords (that's the policy of this host).

Looking at the cracked passwords, it's easy to see why so many fell in such a short time. The vast majority consist of only lowercase letters, which makes them easy to crack.

In the wrong hands, a list of more than 1000 account passwords might bring this host to its knees. Kaput. Out of business. Not to mention the harm to individual users. Am I wrong?

Note that this problem only exists because the host made a series of mistakes.

1) Using an email system with a world-readable list of passwords
2) Adding login passwords to the email system.
3) Allowing passwords that are easy to crack

If any one of these conditions were absent, the problem would be much reduced or eliminated. For example, if the host made people choose passwords with a combination of upper and lower case letters, numbers and symbols, I might not have been able to crack any of the passwords.

My host uses a commercially available email package. For all I know, this same situation exists on many of the servers out there.

* change of topic *

Looking over the other posts on this thread, I can see two kinds of response to what I'm saying. One looks at the issue in moral terms: I've violated the trust that the host placed in me. I've violated the privacy of these users. The host should cancel my account. I'm bad.

The other view comes from people who are technically competent: Security problems should be investigated and brought to the attention of the host. It's the host's responsibility to take adequate security measures.

I wouldn't be surprised if most of the people who run web hosting companies fall into the first group. They don't have a strong technical background. Many of them got into the business as resellers because they thought it was an easy way to make money. They lack the expertise needed to run a secure server.

Which kind of person would you like running your web host?

I have a couple of opinions on this, some of which I think people will disagree with, but here goes...

One, I think that many servers can be broken into and to a degree, security is (what is the phrase?), something like security by obscurity? Something like that.

My point being that there are many hosts out there and I highly doubt all of them, let alone whatever percentage I could come up with, are security experts. Some of this might be due to lack of understanding, but some of this is due to the fact that this stuff is complex and as with home computer op. systems (read: microsoft), people find a way to hack just about anything, one way or another. A bind exploit here, sendmail there, etc.

I would contact the company and request the owners email address/phone # asking to discuss a serious security issue. You might get a consulting gig out of it.

Hi Chicken,

As ever, you're the voice of reason and moderation (sorry, stupid pun). I'm sure you're right that customers generally can't expect a high level of security from their web hosts (I hope I'm not misrepresenting your opinion by putting it like this). That's a fact of life in this industry. It might shock a lot of naive web hosting clients to hear this, though.

I sent an email to the owner of the host at his personal account several days ago (first I used a remailer, then I thought some dialogue would be nice and sent a more detailed message from an anonymous account). I haven't heard back yet, so I'll contact their email support directly, which has always processed my tickets within 24 hours. I'll post the details here 'as the story develops'.

I would never think to offer myself as a consultant, Chicken. My technical background consists of a few cs classes I took in college. The security problem we've been discussing was found using three of the first unix commands they teach you: ls, cd and cat. Thanks for the encouragement, though!

Don't you all think this discussion is kind of wasting time?

What are we talking about here? Shared hosting!
Who is going to use highly confidential material on a cheap shared hosting account?
I don't give a damn if someone reads my normal email and I don't care that it travels the net as plaintext. You want to read my boring email? Go ahead!

Don't you guys think that for a more secure (internet) environment people/businesses shell out major bucks for a dedictated server and put some people on it with real knowledge about security?

Am I wrong here?
My point is that the security discussions for shared hosting accounts are a little bit overblown and useless since I think most users really don't have a clue and don't care as long as there family and friends can see there page and email arrives.

Originally posted by Domenico
Don't you all think this discussion is kind of wasting time?

What are we talking about here? Shared hosting!
Who is going to use highly confidential material on a cheap shared hosting account?
I don't give a damn if someone reads my normal email and I don't care that it travels the net as plaintext. You want to read my boring email? Go ahead!


There are many reasons to care about good security other than merely not letting someone read your e-mail to Aunt Sally.

A compromised account is typically abused for all sorts of unpleasant activities - connection laundering, attacks on other systems, sending out Spam, warez download services, and so forth. The risk to the hosting client is the loss of their work and time, not to mention potentially being blamed for the abuse.

The risk to the hosting service is even greater, especially if they have known vulnerabilities and/or a reputation for not catching abusers quickly. I've seen hosting services where every server had several compromised accounts on it, sometimes with root. That's a Bad Thing(TM).

Kevin

Looking over the other posts on this thread, I can see two kinds of response to what I'm saying. One looks at the issue in moral terms: I've violated the trust that the host placed in me. I've violated the privacy of these users. The host should cancel my account. I'm bad

strange why you think the 2 groups of people are mutually exclusive - the fact is you are wrong, you have broken the Terms of service you have done something any decent host would and should have a TOS to stop

At the end of the day you are just plain nosey - all of the information you found could have been done above board without going behind your hosts back and trying to crack the system, every system is insecure and is vulnerable if you are competent enough to find the weakness - security experts do say if you want a secure machine disconnect it from the network.

We, like many other good hosts, employ a security company to test our systems and keep us updated with security issues - this by no means ensures our servers integrity as I mentioned above and as chicken mentioned getting into a system is possible no matter what your security arrangements are

so worrywort you've had your 15 minutes of fame why not do the decent thing and contact your host and ask the right questions - then maybe go and check your bank out who knows someone may be stealing your money as we speak.

Originally posted by shorty

We, like many other good hosts, employ a security company to test our systems and keep us updated with security issues - this by no means ensures our servers integrity as I mentioned above and as chicken mentioned getting into a system is possible no matter what your security arrangements are


Is this one of those companies that runs a penetration testing tool, charges you a few hundred bucks a month, and gives you a sense of security as a result? Or are they actually tiger teaming your server from the inside?

If everyone adopted your approach of "please don't look for security problems, you're a bad person if you do that" then the only way vulnerabilities would ever be found is after they are exploited by people with genuinely bad intentions.

No offense, but it is very naive to think that people "just shouldn't look and everything will be fine".

Kevin

One thing I have never said is that hosts should not look for security holes what I am saying is customers should not internally probe a systems security, as a host it is immpossible to differentiate between an 'honest' customer who is 'just doing it for the good of mankind' and a cracker.

If a customer did this on our servers they would be kicked off - otherwise every cracker and his friend would claim, 'I was just checking your security, I wasn't going to do anything with the 30,000 passwords I've just got, honest'

How exactly do you explain to the FBI why your PC has 30,000 email passwords on it and that really it was just to see if you could do it....come on

If a customer asks 'do you use xyz' and we say yes and he says do you know it has a security hole we would certainly act - if a customer takes it into his own hands to probe our systems security then we would kick him off and have

Our security firm tests the integrity of the machine from both inside 'as a customer' and outside - I have to say we are happy with the results and it has on a number of occasions enabled us to be ahead of the field on security updates - this does not mean our servers are invincible none are

Originally posted by shorty
One thing I have never said is that hosts should not look for security holes what I am saying is customers should not internally probe a systems security, as a host it is immpossible to differentiate between an 'honest' customer who is 'just doing it for the good of mankind' and a cracker.


I will accept your implied point, which is that it's hard to draw the line between acceptable curiosity/concern/research and inappropriate behavior. You choose to draw that line at the "don't ask don't tell" line and ask your clients to trust that you have done the best job possible to secure your systems.

I choose to draw the line somewhat more liberally, although I wouldn't approve of going as far as running Crack on DES passwords - one should already know, statistically, that once you've gotten that far, anyone could crack 40% of the passwords. There's nothing left to prove.

For interesting reading on a closely related subject, try http://www.lightlink.com/spacenka/fors/

Kevin

Yow! Reading about the Randal Schwartz case got me sweating! By a strange coincidence, Oregon, the state where Schwartz was prosecuted for unauthorized possession of password-related data under an ill-conceived computer crime law, is also my home state. In other respects, we differ: I'm a relative newby, while Schwartz is real unix hacker, a living legend. Also, it looks like this incident will turn out better than the Schwartz case for all involved. Customer support wrote me back:

From my letter to support:
The NWAuth module you appear to be using for email authentication uses standard UNIX DES-encrypted passwords in a world-readable file.
<snip>
Also, the email password files nwauth.txt and nwauth.add are world-writeable, which opens the door to other kinds of abuse.


Response:
Thanks for the notice; You should see now that those files have been shored up - normal users have no access to them. I don't see how that was setup in the first place; but it has been corrected now.


You can see that the problem was actually more serious than I originally described. The authentication helper app was running as root, but the email password files were world-writeable as well as world-readable.

Needless to say, this hole could have been abused in many ways (one of the fields of the password file is for forwarding directives and the like--imagine).

The original permissions problem was so egregious, it makes me wonder if the faulty permissions weren't set by an intruder who had already gotten root access--it would be very hard for a sysadmin with even a bare minimum of knowledge to make such a mistake.

let me put this question to the hosts here:

your security log comes in at 6am today and in it user worrywort has accessed, copied and then downloaded your DES encrypted password file - what do you do?

Firstly disconnect the machine from the network, check and plug the security hole, change all passwords, disable worryworts account, put the machine back on the network and inform the authorities.

User worrywort explains 'I was only checking your system'

What do you do? belive him, just like you believe all those people you cut off for spammining when they say 'I didn't know sending out 10,000 emails was spam'

I don't think so, if a customer is concerned about a hosts security it is not there job to go and test it otherwise they could end up in a lot of trouble, there job should be to ask the host and explain their fears not go gungho into probing the system and breaking the law

So lets hope the Oregon authorities come knocking on your door

Originally posted by shorty
your security log comes in at 6am today and in it user worrywort has accessed, copied and then downloaded your DES encrypted password file - what do you do?


I would be thankful that such a scenario isn't possible, since if we had made such a mistake, hopefully someone would have caught it before then. Of course, if you make a fundamental mistake like leaving DES passwords accessible, you probably wouldn't have any way of logging who had read that file, so it could be happening all the time and you wouldn't know the difference.


I don't think so, if a customer is concerned about a hosts security it is not there job to go and test it otherwise they could end up in a lot of trouble, there job should be to ask the host and explain their fears not go gungho into probing the system and breaking the law

So lets hope the Oregon authorities come knocking on your door

Wow, you must live in a Judge Dredd world.

Microsoft likes your attitude, though. They want everyone to just shut up about security problems. They promise they'll police themselves. You know you can trust them, right? ;)

Kevin

Originally posted by shorty
your security log comes in at 6am today and in it user worrywort has accessed, copied and then downloaded your DES encrypted password file - what do you do?

1. close the immediate security hole
2. identify if a root compromise was possible
3a. If no root compromise was possible, then send out an advisory telling users that their passwords might have been compromised.
3b. If a root compromise was possible, shut down the system, mount the drive in a known secure box, and compare md5 checksums to find out if any system files were tampered with.
3b(i). If no files were modified, remount the drive in the original system and proceed as in 3a, apologizing for the downtime and explaining that an urgent security audit was necessary.
3b(ii). If files were tampered with, call in the FBI.

Discovering a security hole is not illegal. Exploiting a security hole is illegal.