Re: Samba 2.0.7 SWAT vulnerabilities

[Patrik Sternudd <patrik.sternudd () COPPER SE>]

You can create the generic* account in the FW-1
users rule base to get rid of this behaviour.

generic* triggers on all user names that has not
been explicitly defined. This works with versions
4.0 and 4.1 at least, I don't know if it applies
to earlier versions as well.

So I wouldn't say this is a design error/bug, it's
more of a implementation issue.

But yes, if you do not deploy the generic*,
then you're vulnerable for this type of
user database fingerprinting.

Regards,

Patrik Sternudd
Copper AB

> -----Original Message-----
> From: Ryan Gray [mailto:ryan () SNIPER ORG]
> Sent: Thursday, November 02, 2000 2:47 AM
> To: BUGTRAQ () SECURITYFOCUS COM
> Subject: Re: Samba 2.0.7 SWAT vulnerabilities
>
>
> CheckPoint Firewall-1 (at least up to version 4.0) has
> similar behavior.
> Firewall-1 uses port 259 for client authentication.
>
> If a valid username and invalid password is used:
>
> User: validuser
> FireWall-1 password: ******
> Access denied by FireWall-1 authentication
>
> User:
> ###################################
>
> And if an invalid username is used:
>
> User: invaliduser
> User someuser not found
>
> User:
> ###################################
>
>
> I'm not sure about 4.1, but from the work that I've done with it, I'd
> imagine that it behaves the same.
>
>
> Regards,
> Ryan Gray
> Catalyst Solutions, Inc.
>
> On Tue, 31 Oct 2000, Richard Trott wrote:
>
>
> > I'm sure if everyone reported these problems to BugTraq, we
> could generate
> > a very, very long list of products that have this same problem.  I'd
> > actually like to generate just such a list of products.
> Feel free to send
> > example products (free, commercial, whatever) to me (and/or
> to Bugtraq;
> > hey, it's moderated) and if I get enough, maybe I'll post a
> Web page.
> > [CorporateTime for the Web also appears to do other
> > not-so-security-conscious things like create a world writeable log
> > directory (lexacal-private/log--and that private directory
> is created with
> > world read and execute permissions, so it is not private at all).]
> >
> > Rich