[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. [email protected] On Feb 6, 2013, at 2:03 PM, Dave Aitel <[email protected]> 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 > [email protected] > https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
