samba security

[Paul Bradshaw]

Hi there,

I scanned my Fedora server with NeWT and found this - should I be
concerned about it?

Thanks,

...Paul


microsoft-ds (445/tcp)



It was possible to log into the remote host using the following
login/password combinations :
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'

It was possible to log into the remote host using a NULL session.
The concept of a NULL session is to provide a null username and
a null password, which grants the user the 'guest' access

To prevent null sessions, see MS KB Article Q143474 (NT 4.0) and
Q246261 (Windows 2000).
Note that this won't completely disable null sessions, but will
prevent them from connecting to IPC$
Please see http://msgs.securepoint.com/cgi-bin/get/nessus-0204/50/1.html

The remote host defaults to guest when a user logs in using an invalid
login. For instance, we could log in using the account 'nessus/nessus'


All the smb tests will be done as ''/'whatever' in domain ALUMNI_HOUSE
CVE : CAN-1999-0504, CAN-1999-0506, CVE-2000-0222, CAN-1999-0505,
CAN-2002-1117
BID : 494, 990
Plugin ID : 10394 <http://cgi.nessus.org/plugins/newt.php?id=10394>


The following shares can be accessed using a NULL session :

- IPC$ - (readable?, writeable?)


*Solution : To restrict their access under WindowsNT, open the explorer,
do a right click on each,
go to the 'sharing' tab, and click on 'permissions'
Risk factor : High
CVE : CAN-1999-0519, CAN-1999-0520
BID : 8026
*

Plugin ID : 10396 <http://cgi.nessus.org/plugins/newt.php?id=10396>

[Scot L. Harris]

Post by Paul Bradshaw
Hi there,
I scanned my Fedora server with NeWT and found this - should I be
concerned about it?
Thanks,
...Paul
microsoft-ds (445/tcp)
It was possible to log into the remote host using the following
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'

Of course you should be concerned! Any good admin would. :)

I just went through this with a security scan using nessus. Not sure
about NeWT but I think it gets this based on the simple ID of the
service running on the port.

Best thing to do is actually try and login in from a remote system using
those ids and passwords. I found that I was not able to login using
those ids/passwords or with null passwords.

I suspect that both applications are using the same test code and report
similar issues when there is no real issue. Need to review the code to
see what they really are doing and why they send back a false positive
like this.

If you manually check it and it is secure then you don't need to worry.

[Paul Bradshaw]

Thanks Scot,

There's no administrator or guest account either on OS or Samba server,
so I figured it was something related to how Samba impersonates a
Windows fileshare. Samba is not actually vulnerable to to any Microsoft
Windows Exploits, is it? I always just assumed it wasn't, but I want to
make sure.

Post by Scot L. Harris

Post by Paul Bradshaw
Hi there,
I scanned my Fedora server with NeWT and found this - should I be
concerned about it?
Thanks,
...Paul
microsoft-ds (445/tcp)
It was possible to log into the remote host using the following
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'

Of course you should be concerned! Any good admin would. :)
I just went through this with a security scan using nessus. Not sure
about NeWT but I think it gets this based on the simple ID of the
service running on the port.
Best thing to do is actually try and login in from a remote system using
those ids and passwords. I found that I was not able to login using
those ids/passwords or with null passwords.
I suspect that both applications are using the same test code and report
similar issues when there is no real issue. Need to review the code to
see what they really are doing and why they send back a false positive
like this.
If you manually check it and it is secure then you don't need to worry.

[Scot L. Harris]

Post by Paul Bradshaw
Thanks Scot,
There's no administrator or guest account either on OS or Samba server,
so I figured it was something related to how Samba impersonates a
Windows fileshare. Samba is not actually vulnerable to to any Microsoft
Windows Exploits, is it? I always just assumed it wasn't, but I want to
make sure.

Then you should be OK. Like I said it is always best to test it
directly if you have any questions on it.

I don't know of any exploits at the moment. Not to say there won't be
any in the future. Probably the biggest hole is poor passwords. The
most likely security issue is someone shoulder surfing as you log in or
poor passwords which can easily be brute forced.

Just make sure you are using encrypted passwords so packet sniffing is
made a little more difficult. But in most networks your standard switch
makes sniffing traffic more difficult than the typical user can handle.

[Matt Morgan]

Post by Paul Bradshaw
Thanks Scot,
There's no administrator or guest account either on OS or Samba
server, so I figured it was something related to how Samba
impersonates a Windows fileshare. Samba is not actually vulnerable to
to any Microsoft Windows Exploits, is it? I always just assumed it
wasn't, but I want to make sure.

Samba at least is subject to different threats :-). I don't think I've
ever heard of a Windows exploit that affects Samba, and it makes sense
that there wouldn't be, but there have been one or two holes uncovered
in Samba in my memory.

[Scot L. Harris]

Post by Paul Bradshaw
Thanks Scot,
There's no administrator or guest account either on OS or Samba server,
so I figured it was something related to how Samba impersonates a
Windows fileshare. Samba is not actually vulnerable to to any Microsoft
Windows Exploits, is it? I always just assumed it wasn't, but I want to
make sure.

Then you should be OK. Like I said it is always best to test it
directly if you have any questions on it.

I don't know of any exploits at the moment. Not to say there won't be
any in the future. Probably the biggest hole is poor passwords. The
most likely security issue is someone shoulder surfing as you log in or
poor passwords which can easily be brute forced.

Just make sure you are using encrypted passwords so packet sniffing is
made a little more difficult. But in most networks your standard switch
makes sniffing traffic more difficult than the typical user can handle.

[Matt Morgan]

Post by Paul Bradshaw
Thanks Scot,
There's no administrator or guest account either on OS or Samba
server, so I figured it was something related to how Samba
impersonates a Windows fileshare. Samba is not actually vulnerable to
to any Microsoft Windows Exploits, is it? I always just assumed it
wasn't, but I want to make sure.

Samba at least is subject to different threats :-). I don't think I've
ever heard of a Windows exploit that affects Samba, and it makes sense
that there wouldn't be, but there have been one or two holes uncovered
in Samba in my memory.

[Paul Bradshaw]

Thanks Scot,

There's no administrator or guest account either on OS or Samba server,
so I figured it was something related to how Samba impersonates a
Windows fileshare. Samba is not actually vulnerable to to any Microsoft
Windows Exploits, is it? I always just assumed it wasn't, but I want to
make sure.

Post by Scot L. Harris

Post by Paul Bradshaw
Hi there,
I scanned my Fedora server with NeWT and found this - should I be
concerned about it?
Thanks,
...Paul
microsoft-ds (445/tcp)
It was possible to log into the remote host using the following
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'

Of course you should be concerned! Any good admin would. :)
I just went through this with a security scan using nessus. Not sure
about NeWT but I think it gets this based on the simple ID of the
service running on the port.
Best thing to do is actually try and login in from a remote system using
those ids and passwords. I found that I was not able to login using
those ids/passwords or with null passwords.
I suspect that both applications are using the same test code and report
similar issues when there is no real issue. Need to review the code to
see what they really are doing and why they send back a false positive
like this.
If you manually check it and it is secure then you don't need to worry.

[James Wilkinson]

Post by Paul Bradshaw
I scanned my Fedora server with NeWT and found this - should I be
concerned about it?

<snip>

Post by Paul Bradshaw
microsoft-ds (445/tcp)
It was possible to log into the remote host using the following
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'
It was possible to log into the remote host using a NULL session.
The concept of a NULL session is to provide a null username and
a null password, which grants the user the 'guest' access
To prevent null sessions, see MS KB Article Q143474 (NT 4.0) and
Q246261 (Windows 2000).
Note that this won't completely disable null sessions, but will
prevent them from connecting to IPC$

Um. I've a feeling that this is the way Samba works.

/usr/share/doc/samba-3.0.3/docs/htmldocs/Samba-Guide.html says:
# The IPC$ share serves a vital purpose[1] in SMB/CIFS based
# networking. A Windows client connects to this resource to obtain the
# list of resources that are available on the server. The server
# responds with the shares and print queues that are available. In most
# but not all cases, the connection is made with a NULL username and a
# NULL password.

So it looks to me as though Windows, by default, connects to Samba with
a null username and a null password, to see which shares are available.
(This is necessary because different shares on the same machine can have
different passwords for the same user: think about the case when the
password is per-share, not per-user).

So an SMB server needs to export a list of all shares available without
(real) password authentication. This is a limit of the way Windows
networking works.

So, presumably, Samba exports this information to any client with any
username/password pair (the data is available to any interested client,
anyway) since the programmers want Samba to work even when the client
sends something different.

It looks to me as though this is all NeWT is testing.

Real password security (or the SMB approximation thereto) is only used
when the client actually connects to one of the "real" shares.

I'd like to find some better documentation. Is there anyone who knows
Samba better who would like to comment?

Paul, if you're still interested or worried, could you ask the same
question of the Samba mailing lists, and report the answer back?

Thanks,

James.

[Paul Bradshaw]

Hi there,

I scanned my Fedora server with NeWT and found this - should I be
concerned about it?

Thanks,

...Paul


microsoft-ds (445/tcp)



It was possible to log into the remote host using the following
login/password combinations :
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'

It was possible to log into the remote host using a NULL session.
The concept of a NULL session is to provide a null username and
a null password, which grants the user the 'guest' access

To prevent null sessions, see MS KB Article Q143474 (NT 4.0) and
Q246261 (Windows 2000).
Note that this won't completely disable null sessions, but will
prevent them from connecting to IPC$
Please see http://msgs.securepoint.com/cgi-bin/get/nessus-0204/50/1.html

The remote host defaults to guest when a user logs in using an invalid
login. For instance, we could log in using the account 'nessus/nessus'


All the smb tests will be done as ''/'whatever' in domain ALUMNI_HOUSE
CVE : CAN-1999-0504, CAN-1999-0506, CVE-2000-0222, CAN-1999-0505,
CAN-2002-1117
BID : 494, 990
Plugin ID : 10394 <http://cgi.nessus.org/plugins/newt.php?id=10394>


The following shares can be accessed using a NULL session :

- IPC$ - (readable?, writeable?)


*Solution : To restrict their access under WindowsNT, open the explorer,
do a right click on each,
go to the 'sharing' tab, and click on 'permissions'
Risk factor : High
CVE : CAN-1999-0519, CAN-1999-0520
BID : 8026
*

Plugin ID : 10396 <http://cgi.nessus.org/plugins/newt.php?id=10396>

[Scot L. Harris]

Post by Paul Bradshaw
Hi there,
I scanned my Fedora server with NeWT and found this - should I be
concerned about it?
Thanks,
...Paul
microsoft-ds (445/tcp)
It was possible to log into the remote host using the following
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'

Of course you should be concerned! Any good admin would. :)

I just went through this with a security scan using nessus. Not sure
about NeWT but I think it gets this based on the simple ID of the
service running on the port.

Best thing to do is actually try and login in from a remote system using
those ids and passwords. I found that I was not able to login using
those ids/passwords or with null passwords.

I suspect that both applications are using the same test code and report
similar issues when there is no real issue. Need to review the code to
see what they really are doing and why they send back a false positive
like this.

If you manually check it and it is secure then you don't need to worry.

[James Wilkinson]

Post by Paul Bradshaw
I scanned my Fedora server with NeWT and found this - should I be
concerned about it?

<snip>

Post by Paul Bradshaw
microsoft-ds (445/tcp)
It was possible to log into the remote host using the following
'administrator'/''
'administrator'/'administrator'
'guest'/''
'guest'/'guest'
It was possible to log into the remote host using a NULL session.
The concept of a NULL session is to provide a null username and
a null password, which grants the user the 'guest' access
To prevent null sessions, see MS KB Article Q143474 (NT 4.0) and
Q246261 (Windows 2000).
Note that this won't completely disable null sessions, but will
prevent them from connecting to IPC$

Um. I've a feeling that this is the way Samba works.

/usr/share/doc/samba-3.0.3/docs/htmldocs/Samba-Guide.html says:
# The IPC$ share serves a vital purpose[1] in SMB/CIFS based
# networking. A Windows client connects to this resource to obtain the
# list of resources that are available on the server. The server
# responds with the shares and print queues that are available. In most
# but not all cases, the connection is made with a NULL username and a
# NULL password.

So it looks to me as though Windows, by default, connects to Samba with
a null username and a null password, to see which shares are available.
(This is necessary because different shares on the same machine can have
different passwords for the same user: think about the case when the
password is per-share, not per-user).

So an SMB server needs to export a list of all shares available without
(real) password authentication. This is a limit of the way Windows
networking works.

So, presumably, Samba exports this information to any client with any
username/password pair (the data is available to any interested client,
anyway) since the programmers want Samba to work even when the client
sends something different.

It looks to me as though this is all NeWT is testing.

Real password security (or the SMB approximation thereto) is only used
when the client actually connects to one of the "real" shares.

I'd like to find some better documentation. Is there anyone who knows
Samba better who would like to comment?

Paul, if you're still interested or worried, could you ask the same
question of the Samba mailing lists, and report the answer back?

Thanks,

James.