Re: Superfish support for ssl-known-key?

[Daniel Miller <bonsaiviking () gmail com>]

On Thu, Feb 19, 2015 at 3:30 PM, David Fifield <david () bamsoftware com>
wrote:

> On Thu, Feb 19, 2015 at 12:59:31PM -0600, Daniel Miller wrote:
> > But how do we report it? It's not something one would expect to find on a
> > server, since it's used to MITM a client. If Nmap finds certs signed
> with this
> > root cert, I can see a few possibilities:
> >
> > 1. Nmap's traffic is being MITM'd by Superfish on the same machine. Not
> sure if
> > this is possible, since I don't know how it's actually modifying the
> traffic.
> > 2. Nmap's traffic is being MITM'd by someone on the LAN. This is a real
> attack
> > to watch for, since the certificate and key are now public, and it can be
> > assumed there are hundreds or thousands of Lenovo laptops which will
> trust it.
> > 3. The server actually has a Superfish-signed cert on the service. This
> seems
> > like the least-likely scenario, but it is the most-likely way that
> someone
> > would interpret the output of ssl-known-key, since Nmap isn't normally
> used for
> > detecting MITM.
>
> Maybe it should be a different script. Case 2 is the one I really care
> about, but case 3 is interesting too. Nmap is good for finding
> information about the network path (i.e. filtering middleboxes), in
> which category I would include SSL MITM.
>
> Maybe something like:
> |_Certificate signed by untrustworthy CA: Superfish, Inc. <SHA-1 etc.>

This is a better script idea, I think. We could have a small blacklist of
CA certs that are known-bad (Diginotar, Superfish, Comodo, etc), but it
could be used with other bad-ca-lists that the user can provide. Or even
put it in whitelist mode with a "trust store" and report those that don't
validate (though validating is quite a bit different than just checking
whether the root cert in a chain has a particular bad fingerprint; maybe
this is not the best way forward, at least at first). Then it could be used
to check for known MITM problems (self-signed certs even) against
known-good servers, or to audit for weirdness like case 3 (which apparently
HDM already did: https://twitter.com/hdmoore/status/568521949371969537 )

Dan

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/