Re: [cobalt-security] URGENT Hacking

[Gossi The Dog <gossi@xxxxxxxxxxxxxx>]

Two quick notes:

1) if users change their password using /bin/passwd (via telnet), then
Cobalts version of passwd forces them to choose a reasonably secure
password (non dictionary, over 6 characters etc).

2) I don't believe this is true for the admin interface (I disabled it,
due to it presenting a security risk in itself).

Of course, however secure you make users passwords, you are still open to
brute force attacks and such.  This is where log reading and such are
key.  Its a sad fact that Cobalt aim their products at users who probably
have 0 prior UNIX experience, and provide no way to view logs from the
admin interface.  I might be 'underestimating' the average sysadmin here,
but I suspect most of them probably don't have a clue how to view
/var/log/messages (but of course, they can set up trusted relationships
between BDCs in NT4 and stuff :)..

Theres also the angle of Cobalt actually releasing security patches.  
It'd appear they don't have anybody handling security (and only security),
and so patches are only being release when they get around to looking at
the issue.  The classic example is thats there's still no patch for
qpopper, and so all Cobalt RaQ's are remotely ownable.  And its been this
way for months now.  Hopefully one day Cobalt will realise they need
somebody to be looking at things like this, or they are going to get some
seriously bad PR :\

Rant over.
Gossi.



On Tue, 5 Sep 2000, WebFusion System Administrator wrote:

> [Note that I work for the company which hosts Mark's RaQ. This email is
> my opinion and not that of WebFusion in any way]
> 
> Mark Baker wrote:
> > Thanks Chris, but a lot of these issues we'd expect cobalt fix
> > as the Raq's are sold as the simple machine which is what we like
> > to get, but are happy to play with.
> 
> In this case, the fault doesn't lie at Cobalt's door. It doesn't lie at
> our door. It isn't even your fault, Mark. It is in fact the fault of one
> of your users - passwords are the first line of defence. Making a
> password short, simple or based on a dictionary word is a recipe for
> disaster - that's why when changing a password on most Unix and
> Unix-based systems using the 'passwd' command will spit out errors like:
> 
> BAD PASSWORD - based on a dictionary word
> BAD PASSWORD - it's WAY too short!
> 
> Perhaps Cobalt could integrate this into their GUI. Changing the
> connection limit in the FTP config makes no difference to a determined
> cracker. They'll just put in a timeout and come back when the lockout
> has expired.
> 
> System security on RaQs is as much the responsibility of the system
> administrator (as Chris already pointed out) as it is that of the
> supplier. You wouldn't expect the company who built your house to bolt
> the door when you go out, just as you shouldn't expect Cobalt to supply
> patches for what are in fact configuration issues. Familiarity with the
> underlying systems, in this case, breeds a tendency toward paranoia
> which a little of in this business is always healthy.
> 
> I know it's not much consolation right now but I personally would
> recommend that you get hold of a decent Linux administration book and
> familiarise yourself with the nuts and bolts underpinning your system.
> Then you'll be in a position to really shout at Cobalt when things go
> wrong.
> 
> Regards,
> 
> Graeme Fowler
> Systems Administrator
> --
> THIS EMAIL IS MY OPINION AND MY OPINION ALONE.
> 
> 
> _______________________________________________
> cobalt-security mailing list
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security
>