Re: Nessus + Authentication = Root?

[Nicolas Pouvesle <npouvesle () tenablesecurity com>]

On Sep 13, 2005, at 12:27 PM, Dave Aitel wrote:

> As far as I can intuitively smell, it wouldn't be that bad to do  
> key-based SSH scans for this, and I bet you could do it securely  
> with a password as long as you had grsec configured to lock that  
> user down properly.


No, SSH scans with a password are a bad idea. Because most of the  
time you don't scan one host but a subnet. In that case you just have  
to plug a machine on the network with a fake ssh server to grad the  
ssh login/password.
This is why we only recommand to use SSH public/private keys to do a  
SSH scan and why the 'SSH password' field in Nessus is called 'SSH  
password (unsafe!)'


> But I can't see a easy way to do this securely on Windows using  
> NTLM. Then again, I'm not an active directory administrator in my  
> spare time, so perhaps someone else can pipe up with how this is  
> working.
>
> Via Dildog:
> http://www.microsoft.com/technet/security/bulletin/fq00-067.mspx
>
> *"""Once the malicious user obtained the NTLM response, what could  
> he do with it?*
> NTLM hashes (or challenge/response pairs) could be fed into a  
> program that performs brute force password guessing. The "cracking"  
> program would iteratively try all possible passwords, hashing each  
> and comparing the result to the hash that the malicious user  
> obtained. When it located a match, the malicious user would know  
> that the password that produced the hash is the user's password."""
>
> I'll have to write a CANVAS module to really know, but aside from  
> the potential for downgrading the protocol into cleartext passwords  
> (there's some nessus variables in a few scripts referencing options  
> to disable this?), it looks to me that there's a risk for someone  
> to pass this hash right to the CANVAS World's Rainbow Tables  
> service and then go hacking with it realtime. Restricted admin is  
> still an authenticated user, which might get me into named pipes an  
> anonymous user can't. It might actually make tapi work remotely on  
> operating systems you otherwise couldn't. This would imply that  
> scanning using a service that requires remote admin is a very bad  
> idea.


It is not a problem with Nessus and credentials, it is the way you  
configure it.
Nessus does not allow you to do clear password authentication by  
default. You must select an option (with warning) to do that.

So if you really want to know how SMB authentication with Nessus works :

- Nessus identifies if the remote host support extended security

1) The remote host supports Extended security :

- if the remote host supports kerberos (Windows 2000/2003 domain) and  
the user configured Nessus with the KDC IP Nessus uses kerberos
- else (or if kerberos authentication failed) Nessus uses NTLMSSP  
with LMv2

2) The remote host does not support extended security :

- Nessus uses LMv2 to logon
- if logon failed, Nessus tries with NTLM


Now the only "weakness" is to do a "fake" Windows server to do NTLM  
authentication. BUT it can be disabled in Nessus by selecting the  
option "Use NTLMv2 only". It is not enabled by default because else  
SMB logon could fail on some old host.
So if the network is configured (it is a domain policy option),  
Nessus must be configured in the same way.


So with a correct configuration there is no such risk imho.
Even the mitm attack can be prevented by forcing SMB signing  
(supported by Nessus) in the Domain configuration (it is not related  
to Nessus but to Windows Domain configuration).


In the end the problem is not on the Nessus side, but on how the user  
configures it (and his Windows/Unix domain).

And by the way, this affects any scanner using credentials - be it  
Windows based or Samba-based.
Renaud did a talk (in french) about this at : http://tinyurl.com/8ssas


Regards,


Nicolas


PS: we will soon release a new whitepaper about credentials with  
Nessus to explain that in details.