Re: OpenVPN probes and script question

[David Fifield <david () bamsoftware com>]

On Fri, Jan 29, 2010 at 09:42:39PM +0100, Patrik Karlsson wrote:
> I'm toying around with OpenVPN for the moment and I've implemented
> probes that detect it running on both UDP and TCP.  As far as I can
> tell it's only possible to detect it if it's running in PKI mode eg.
> not using static keys. The reason for this is that when running with a
> static key, if the receiving part receives a message it can't decrypt
> it simply doesn't answer. There does not appear to be any kind of
> handshake that could be triggered when running in this mode. But, I'm
> implementing it based on packet dumps between two test systems so I
> could be wrong.

An OpenVPN probe would be a good thing to have. From some web searching
last night, the OpenVPN protocol is not well supported by security
tools.

What versions of OpenVPN did you test against, and in what
configurations? A problem with the match lines is that they just say
"OpenVPN". Including a version number, at least, would be nice. It's not
always possible to distinguish different versions of a protocol that
doesn't have the number built into the protocol, but it's good to try
when possible.

Another aspect of testing on multiple systems: we want probes that get a
response from the widest possible range of versions. If these probes
turn out to be specific to (for example) version 2, and version 1
servers don't respond, the probe isn't reaching its full potential.

How common is the use of public-key versus shared-key authentication.

Since the source to OpenVPN is available, you shouldn't have to be
reverse-engineering packet captures. I think you can find a really good
OpenVPN probe, ideally with protocol documentation, but it could be some
work.

> Regarding the probes,  I appended some text to the end of the byte
> sequence of the UDP probe in order to trigger an error, rather than
> having OpenVPN waiting for additional UDP packets. Without this text,
> two scans in a row will fail because the service is waiting for more
> packets until a certain timeout occurs.

Sometimes error messages can be better than other messages for version
detection. A really good probe might be something like this.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/