I talked a few times about this issue, but unfortunately I didn't get a response to my CVE number request. So here's the full thing:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Security Advisory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Severity: High
     Title: Watchguard Fireware SSL-VPN MiTM Multiple Vulnerabilities
      Date: November 29, 2008
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 * Project: WatchGuard Firewall SSL-VPN
 * Version affected: 
            WatchGuard Fireware 10.0 up to 10.2.2 
            WatchGuard Mobile VPN with SSL 10.0 for Macintosh
            WatchGuard Mobile VPN with SSL 10.0.2 for Macintosh
            WatchGuard Mobile VPN with SSL 10.0 for Windows

 * Discovered:  April 06, 2008
 * Reported  :  April 08, 2008
 * Fixed     :  October 07, 2008  (only for Windows)
 * Advisory  :  November 29, 2008

 * Not Fixed :  Mobile VPN with SSL for Macintosh
 
 * Security risk: High Severity
 * Vulnerability: MiTM Multiple Vulnerabilities with Abritrary Code Execution

 * Discovered by: Christophe Vandeplas <christophe@vandeplas.com>

 
-------- SHORT DESCRIPTION --------
Due to bad design of the 'WatchGuard Mobile VPN with SSL Client'
it is vulnerable to a MiTM attack resulting in multiple consequences:
- Username and password gathering
- OpenVPN configuration poisoning 
- Upload of malware on the victims machine
- Redirection to another VPN server
- Full transparent MiTM for the complete VPN tunnel
- Arbitrary code execution on the victims machine

This vulnerability should be classed as high severity.

-------- REMEDIATION --------

For Windows computers update ASAP your software.
Stop using the software on Macintosh computers until Watchguard
releases a fixed Macintosh version of the client.

-------- FULL DESCRIPTION --------

-- [ How the Watchguard Fireware SSL-VPN Works

The Watchguard SSL-VPN system consists of four parts:
- OpenVPN Client
- WatchGuard Mobile VPN with SSL GUI Client (or Watchguard GUI Client)
- OpenVPN Server
- Webserver where the client-configuration resides (port 4100)

The OpenVPN Client and Server take care of the full VPN tunnel. As 
authentication the 'auth-user-pass', 'server-certificate' and 
'client-cert' mechanisms are used. These are good security practices.
The Watchguard GUI takes care of two different tasks. It takes care
as management interface for entering the OpenVPN credentials and it
downloads the client configuration from the webserver on port 4100.
The webserver for the client-configuration runs on port 4100 and 
uses SSL for encryption. The certificate is self signed.

-- [ The Flow:

The Watchguard GUI Client needs the Firebox IP, username and 
password. When the user clicks on 'connect' the GUI Client connects 
on the webserver on ip:4100 using SSL encryption where it downloads
the 'client.wgssl' file with the following HTTP GET:
GET /?action=sslvpn_download&username=testuser&password=testpass&filename=client.wgssl
A file called 'client.wgssl' is then downloaded on the machine.
This file is a TGZ and contains the following files:
MD5SUM      - Checksums of the different files from the wgssl package
VERSION     - File with version info from Watchguard
ca.crt      - Certificate authority public key
client.crt  - Client public key
client.ovpn - OpenVPN configuration file
client.pem  - Private key for the client

The Watchguard GUI Client extracts the files and then starts up
OpenVPN with this configuration.
OpenVPN then takes care of setting up the VPN tunnel. When the 
username and password are required it communicates with the 
Watchguard GUI Client using the OpenVPN management interface.
The VPN tunnel is started.

-- [ The problem:

The problem resides in the way GUI Client downloads the configuration. 
The webserver:4100 works with a self-signed certificate. The 
validity of this certificate is never checked correctly.
The Client GUI does check the strings in the following fields:
Common Name (CN)         = Fireware Web Server
Organization (O)         = Watchguard
Organizational Unit (OU) = Fireware

These checks are insufficient. A full certificate check should be 
performed using either the manually imported certificate before 
connection or using an imported CA-cert. 

This results in:
1) Anyone can generate a certificate with these values. An attacker 
   could run a webserver and impersonate the original SSL-VPN server.
2) The password is stored in clear-text in the GET method. 
3) The checks on the content of the client.wgssl are almost nihil. 
   It is possible to completely replace the existing client 
   configuration and to add extra files in the configuration 
   directory of the client machine.
4) It is possible to redirect the client to another VPN server. As 
   we have complete control the full VPN tunnel could be MiTM-ed 
   without the user noticing this.
5) Combined with the 'up cmd' option of the OpenVPN configuration file 
   arbitrary code could be executed on the victims machine.


-------- PROOF OF CONCEPT --------

--[ Main Setup

Take an original 'client.wgssl' file, rename it to 'client.wgssl.tgz'
and extract it.
  Change the 'remote' value to another IP (1.1.1.1) in the
  'client.ovpn' file and recalculate the checksum. 
  Copy a 'malware.exe' in the same diractory. (this could be 
  childporn or a virus)
  Compress all files again in a new .tgz package with the right 
  filename.

An Apache webserver has been configured to run on port 4100 using 
the SSLEngine. 
The SSL certificate was generated with the following values:
  Common Name (CN)         = Fireware Web Server  
  Organization (O)         = Watchguard
  Organizational Unit (OU) = Fireware
In the webroot of the webserver we uploaded a small script that 
saves the parametes into a database and returns a client.wgssl file 
as datastream.

-- [ Connect

Now open the Watchguard GUI Client and connect to the IP of the 
webserver. (192.168.1.110)
The Client downloads the new 'client.wgssl' file and extracts it.

-- [ Results:

1) The Watchguard GUI accepts the fake certificate 
2) When checking the logfile we see a successful download of 
   the configuration file: 
   192.168.1.120 - - [08/Apr/2008:19:06:14 +0200] "GET /?action=sslvpn_download&username=testuser&password=testpass&filename=client.wgssl HTTP/1.1" 200 12 "-" "-"
   These usernames and passwords could be stored in a database using 
   a php script. (see PHP Sample Script)

3a) The client configuration is completely rewritten with our own 
    configuration file.
3b) Check the Watchguard GUI Client directory for the 'malware.exe'
    file.

4a) Check the logging, you will notice that the client doesn't 
    connect to 192.168.1.110 but to 1.1.1.1
4b) Out of scope of this POC
5) Out of scope of this POC

-------- Technical SOLUTIONS for Watchguard --------

The WatchGuard Mobile VPN with SSL Client should correctly check the
validity of the SSL Certificate using the well-defined standards when 
connecting to the configuration-website on port 4100.

The Watchguard firewall should enable the user to generate and upload 
certificates and to link these certificates to the webservers. 
An even better solution would be to run both OpenVPN and the 
configuration-website on the same port and use the same certificates. 
OpenVPN starting from version 2.1 supports a feature called 
port-sharing where OpenVPN can share a port with a webserver or 
other service.


-------- PHP Sample Script --------
<?php 
// Do whatever we want with the variables
$user=$_GET['username']; 
$pass=$_GET['password'];

// Return the client.wgssl configuration file
header("Content-Type: application/octet-stream");
header("content-disposition: attachment; filename=\"client.wgssl\"");
$file=file_get_contents("client.wgssl");
echo $file;
?>


-------- LINKS --------
- Watchguard Release Notes
https://www.watchguard.com/Download/Files/WSM/10_2_3/EN_ReleaseNotes_WSM... 

- OpenVPN 2.1 Manual
http://openvpn.net/index.php/documentation/manuals/openvpn-21.html

Six months ago I discovered a huge vulnerability in the Watchguard SSL-VPN implementation. The consequences are quite important as, if exploited correctly, it is possible to perform arbitrary code execution on the victims machine.

For six months now I've been in contact with 'someone' from the Watchguard security team. He has promised me many times a date when the fix will be released. I'm still waiting for it...
In his last mail he said the fix was committed to the beta-team and I was going to be added to the beta-testers-list so I could try it out and play around with it. I'm still waiting to be added...

• I informed them privately of two important vulnerabilities.
• I accepted to keep the details about the fixed problem confidential as courtesy.
• I keep waiting for 6 months with many beautiful promises about a fix and access to the beta.
• I don't ask any money for these reports.

For ethical reasons I will not publish the full disclosure without the fix. But next time I find a leak in their products I might start thinking about selling it to the highest bidder.

PS: This is not related to this other problem that has already been fixed.

Edit: Mark told me another way, that gives less a blackmailing-feeling. It's kindly requesting the company to make a donation to a charity before giving them the information about the vulnerability in private. I think I'll do that next time.

Edit 2: Watchguard released a new version v10.2.3 fixing this huge problem. Quote Release Notes: The Mobile VPN with SSL client and gateway now protect against "Man in the Middle" attacks. The Mobile VPN with SSL gateway generates a self-signed x.509 certificate when an IP address is assigned to the external interface of the Firebox. This certificate is presented by the gateway the first time a v10.2.3 client connects. Because the certificate is self-signed, a warning message about an “un-trusted” certificate is presented to the user the first time they connect to the Firebox. The user is given the option to confirm the certificate as trusted and save the certificate locally. Accepting the certificate as “trusted” allows the SSL client to warn the user if the certificate changes to alert the user of a possible Man in the Middle attack. [27304].

From here: https://www.watchguard.com/archive/showhtml.asp?pack=70113 (you probably need a login to see this page)
Together with Watchguard we took the decision not to make a full-disclosure with all the details of the leak and exploit. Why? Well it will take some time before all the customers move away from their v10.0 version and publishing the full details would not be a good idea for both Watchguard and the customers.

Some days ago I analyzed the internals of the Watchguard SSL-VPN system. When you realize it uses OpenVPN you think it's quite secure. Except when you implement it completely wrong and screw it all up.

I finally freed some time today to work out a POC and indeed, my attack works like a charm. It can do even more than I expected :-)

Tomorrow I'll be at a Watchguard Seminar about new features in Fireware v10. I'll probably see my Watchguard contact and discuss this issue with him. He'll probably be able to give me more direct contacts where to send the advisory. Let's hope they will fix this asap as I consider this vulnerability as High Risk.
More info later when they fixed it...