Re: OpenVPN probes and script question

[Patrik Karlsson <patrik () cqure net>]

On 2 feb 2010, at 17.51, David Fifield wrote:

> 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.

I tested against OpenVPN 2.0.9, 2.1_rc15 and 2.1_rc7 all running in PKI mode (without --tls-auth obviously).

The probe sends the first packet that the client sends which basically contains.
- 0x38[8 random bytes (cli random)]\0\0\0\0\0

The server then responds with:
- 0x40[8 random bytes (srv random)]0x01\0\0\0\0[8 bytes of cli random]\0\0\0\0

So basically the response contains a whole bunch of nothing to get further version info of. One could obviously try to 
send a packet later in the sequence to try to get the server to spit an error back to the client, but so far I have 
seen no such behavior, and I've sent a lot of incorrect packets. I'll look at the source code when I have the time to 
see if I can find anything that way instead.

In the patch I sent I padded the probe packet with some data at the end. The reason for this is that if a correct 
packet is sent to the server, the server will start waiting for the next sequence of bytes to come. It will continue to 
do so until it times out which sort of wastes server resources. Furthermore, the random bytes generated by the client 
are used as some kind of session identifier (they're in every packet), so running the probe again (with our static 
session identifier) during the time that the server is waiting for additional data will result in no response. With the 
additional rubbish data appended to the probe the server skips the timeout loop and instantly returns allowing a 
connection with the same identifier to connect again.

> 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.
I see your point. In case the probe can't target two versions, what are the options? Two probes?

> How common is the use of public-key versus shared-key authentication.
Shared-key is mostly used in server-to-server VPNs is my guess. As soon as your doing client VPN, the public-key 
solution is probably the most common.

> 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.
I know, it looked *really* easy at first glance, and I had a rough script in place quite quickly so I though, what's 
the point? But now, it seems as if I need to go and dig in the source to see what I can come up with.

> > 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.
Sorry, I wasn't clear here. There's no error message sent to the client. The error message is in the server log.

> David Fifield


//Patrik

--
Patrik Karlsson
http://www.cqure.net




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