Re: Catch22's in Vulnerability Management

[Renaud Deraison <deraison-lists () nessus org>]

[Sorry to answer late on this one]

A long time ago, I did a talk about this (in France, in French), called "Compromising your Network by Auditing it?". I 
described a bunch of attacks one could do against a scanner (ranging from something harmless but annoying, let 
injecting fake results in a scan, to more serious stuff such as doing client-side exploits to downgrading NTLM, 
stealing telnet credentials, etc...) and described how we tackled that on the Nessus side. Some stuff we can't protect 
against (a host replying with fake SYN|ACK to every SYN packet it gets), some we can. And some of the examples you give 
(MSSQL), you're correct we can't protect against (but the same is true for any admin using MSSQL at this point). 

The gist of it is that whenever we write a plugin, the safety of the scanner itself (and its data) is our #1 concern, 
and we added several layers of protection around it (ranging from coding practices to running every plugin in our 
scripting language, which itself creates a runtime that is time and space constrained), or we're honest about the risk 
and let the user know (there's always has been a "unsafe!" warning next to the SSH password field for instance -- if 
you use a SSH password and don't add a "known_hosts" file to your policy, you're definitely broadcasting your SSH 
password around). 

At the web interface level, Nessus runs a web server written in our own scripting language, which alleviates the risk 
of overflows/format strings/etc... It also allows us to do "privilege separation", in the sense that the web server 
can't read back the credentials entered by the user for instance, which in turn avoids the risk if we mess up elsewhere 
(ie: if there was a flaw allowing a user to read the policy of another user, he'd not get the creds). With Nessus 5, we 
also added stricter ACLs to the SQLite databases we use in the backend, and we cipher all the files on disk with a 
unique key (which can be ciphered using nessusd -K, something we recommend doing), so basically nothing uploaded gets 
stored in clear text (even though we recommend using FDE for all systems people install Nessus onto). Also, all the SQL 
statements use stored procedures, again to minimize the risk of attacks when parsing/storing data coming from remote 
servers. For the future, we're also working on sandboxing the scripts (via the scripting engine -- ie: to forbid 
scripts to read files outside of /opt/nessus/) and the engine at the OS-level (when the OS supports it).

Of course, there's always a balance between "ease of use" and "being super safe". Some customers do want to use SSH 
passwords (and not just one password, but multiple ones), and I'm not sure all of them upload a known_hosts file as 
part of their policy. There's some things we won't be able to change. For those who do care about security, we provide 
the tools to do so.

It's also worth noting that credentials are just one piece of the pie, so using agents like Marc Maiffret mentioned is 
interesting, but also adds network-wide risk (more code installed on each target host of the network means more attack 
vectors), does not solve all the credentials problems (MSSQL, etc...) and possibly adds a less audited protocol to 
transfer sensitive information around (I've not looked at/audited/used the Retina agents, so this should not be 
perceived as a vendor to vendor attack).

I also do find it interesting that while indeed the VA tools out there could pose significant risks if implemented 
badly, yet we get very few questions from our prospects and customers about the security features of Nessus. (For the 
readers considering Nessus for your scans and have questions, feel free to reach out to me directly or ask on 
https://discussions.nessus.org/ and we'll answer it)


Finally, with regards to false positives in unauthenticated scans, while I won't answer your comment about their 
quantity, I'd like to point out that using Canvas (or any similar tool) to "weed them out" is also a good way to 
generate false negatives. I'm sure your payloads for all exploits are of the highest quality, but sometime, on some odd 
OS with an odd config, they may not succeed and then you end up chalking up a true finding as a false negative. Whether 
it's good or bad is just a question of balance and context at this point.

-rd 

--
Renaud Deraison
Chief Research Officer, Tenable Network Security, Inc.
rderaison () tenable com



On Feb 6, 2013, at 2:03 PM, Dave Aitel <dave () immunityinc com> wrote:

> I love both our Qualys and Tenable friends, but I have to say, I worry about "authenticated scans". Perhaps my worry 
> is unwarranted, but having a domain admin that is connecting to and trying to authenticate to every host on the 
> network seems like a very bad idea. 
>
> For example: 
> What if you do a NTLM proxy attack? 
> What if you downgrade your accepted protocols to NTLMv1 and then crack the hash and now are domain admin for free? 
> What if there is some vulnerability in the web apps or host box that supports these programs?
> When Qualys, for example, logs into MS SQL, and I have MITM on that network, why can't I just take over the 
> connection and be admin from then on?
>
> https://community.qualys.com/docs/DOC-4095
> http://static.tenable.com/documentation/nessus_credential_checks.pdf
>
> If these attacks work, it's a bit of a catch22. In order to achieve compliance, you must be out of compliance!
>
> I assume people are using authenticated scans, because without it, you're generally getting lots of false positives 
> to weed through, which is annoying (and for which we sell CANVAS plugins :>). 
>
> -dave
>
> -- 
> INFILTRATE - the world's best offensive information security conference.
> April 2013 in Miami Beach
> www.infiltratecon.com
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunityinc com
> https://lists.immunityinc.com/mailman/listinfo/dailydave

_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave