Security breach in Linksys QuickVPN

Security breach in Linksys-Cisco QuickVPN

By
Moshe Valenci

26 Dec 2006

Draft Version 0.52

TERMS OF USE:

THIS DOCUMENT MAY BE DISTRIBUTED FREELY. YOU ARE NOT ALLOWED TO MODIFY THIS DOCUMENT OR COPY SECTIONS FROM IT WITHOUT AUTHOR’S PERMISSION.

THE DATA IN THIS DOCUMENT IS TESTED AND VERIFIED BY THE AUTHOR, NEVERTHELESS YOU ARE ENCOURAGED TO VERIFY THE FACTS PRESENTED HERE USING YOUR BEST SKILLS. IN CASE OF AN ERROR, PLEASE NOTIFY THE AUTHOR BY EMAIL.

IF YOU ARE POSTING THIS DOCUMENT ON A PUBLIC WEBSITE, YOU MAY WANT TO REQUEST THE MOST RECENT VERSION OF THIS DOCUMENT FROM THE AUTHOR.

COMMENTS AND CORRECTIONS ARE WELCOME.

2 Introduction

QuickVPN is VPN solution, which is combined of a client application that connects to a line of Linksys-Cisco router products.

The application uses a username/password and an IP address to remotely connect to the gateway for the small of home office network (SOHO).

The QuickVPN protocol is proprietary and has no public technical specifications nor does it have any GPL code available for the community to look at.
This document exposes the way it works and exposes several security weaknesses in its implementation.

The implementation allows man in the middle attack (MIM), which allows an attacker to decrypt the remote access session (IPSec traffic) or extract the remote access password.

The protocol is not ultimately insecure; however the implementation in the Linksys-Cisco routers and the QuickVPN client definitely is – as it fails to understand the nature of "trust" in public key cryptosystems.

Linksys-Cisco sells an upgradeable license to QuickVPN to allow more remote users to connect to the gateway. This security breach applies also to that version.

Below is a list of affected Linksys-Cisco products, for a full list, please refer to the Linksys-Cisco website.

Linksys VPNRouters	Max.VPN Tunnels	QuickVPN Users Supported
WRV54G	50	50
WRV200	10	10
RV016	100	100
RV082	100	100
RV042	30	30

Though tests were made on WRV54G, one can verify that this security breach is applicable to ALL Linksys-Cisco routers that support QuickVPN.

Lately, and as a result of my finding, which was posted at numerous forums, Linksys-Cisco released an upgrade to QuickVPN that addresses some of the security issues.
They have even posted a firmware upgrade to some of their routers, which addresses some of the security issues on the router side.

This document is intended for people who would like to understand the nature of this security breach and analyze what could get wrong with or without the Linksys-Cisco upgrade.

3 Protocol overview

Analyzing the traffic between the QuickVPN application and the router shows that:

Step1:
The user types in a gateway IP, username and password.

The QuickVPN client initiates an SSL connection to the router @ port 443.
Within the SSL session, the username and password is sent using HTTP Basic Authentication (Base64 encoding). Note that if it is possible to break the SSL session at this point, one could get the access password.

Step2:
The router responds using the IPSec shared keys as a text response.
Note that if it is possible to break the SSL session at this point, one could get the IPSec keys.
When receiving the keys, the QuickVPN application pushes these keys to the IPSec stack. The SA presence can be observed on the "IP Security Monitor" snap-in in the Microsoft management console (mmc.exe).

Step3:
IPSec traffic flows between the client and the router.

The handshake for getting IPSec SA reminds the IKE protocol with the slight difference of being insecure (details below).

In order to extract the date from the SSL session, one may want to use the keys from Appendix A and any of the free or commercial tools that let you do so ("Cain & Abel" is one of this tools). The Author wrote a sample application, which can be sent upon request.

4 Weak points in the protocol and implementation

In theory, both ends achieve mutual authentication when the client verifies the authenticity of the router by validating its asymmetric signature and the router checking that the user is able to provide the right username and password.
The following sections would identify weak points in this assumption:

4.1 Identical RSA keys in all manufactured devices

Linksys-Cisco uses the default X.509 Certificate and RSA keys for all manufactured devices. The default key and certificate cannot be replaced in many of their devices.
In Appendix A, you may find the default certificate and RSA keys that are used in the WRV54G series.
Extracting the secret RSA keys can be done on major portions of the devices in the industry (extraction techniques are not specified in this document).
Gaining access to the private RSA key means that you were able to gain a shared secret used by all the routers ever manufactured from that series (this may vary between firmware versions, however this is likely to be unchanged) - this clears the way to set up a Man-In-The-Middle attack.

As a result of my finding, Linksys-Cisco released firmware upgrade to some of their newer products allowing generating a new key pair by the device.
I wonder if Linksys-Cisco has enforced a key generation once the firmware was upgraded – if not, this is definitely a weak point.
Unfortunately, Cisco-Linksys seems to hate me for finding this bug, so I didn’t get a new-generation device to validate this point.
Weakening this would require attacking the PRNG of the device.
Personally, I have expected a simpler approach (and maybe safer) allowing the device to import a new key pair.

4.2 QuickVPN does not have a trust mechanism

While trying to extract the secret RSA key from the device, I found that the QuickVPN application does not check the server certificate that it gets during the handshake mechanism (the SSL session is not failing during the session initiation).
This surprising fact allows anyone to set up a spoofed router with just any certificate and lure the QuickVPN application to connect to it, disclosing the password.
Once the password is obtained, the man-in-the-middle can start a new session with the real router, acting as a mediator between the QuickVPN application and the real router.
As a result of my finding, Linksys-Cisco released a QuickVPN upgrade, which relies on a certificate, which is pulled from the router and installed on the client side.
Note that this document concludes that fix does not worth much if your router’s private RSA key is common across all manufactured devices.

4.3 Attack strategies

Below is a list of attack strategies, which might be used against the Linksys-Cisco QuickVPN protocol implementation.
This list does not pretend to be full and if the use cases here does not seem reasonable to you, rest assure that there may be plenty of more creative ways to perform MIM attack.

An attacker can install an infrastructure network and set up its man-in-the-middle routing point to your router. This might happen on a competitor´s network or simply by a curious Internet provider such as an iCafe.
Attack to manipulate DNS –
Attacking DNS/DDNS entries on the external network may allow an attacker to direct the QuickVPN client traffic towards a set-up man-in-the-middle point (in case host name is used in the router address dialog, rather than the actual IP address).
An attacker from your local subnet may deflect your "default gateway" traffic by manipulating your ARP tables.
An attacker may deploy a "free" wireless infrastructure, hunting down people who use it to QuickVPN.

5 Linksys-Cisco response

Linksys- Cisco representatives got this document during my effort to resolve this issue. I was told that it is being reviewed by HQ but never got a reply that tried to communicate a resolution.
After going to the LinksysInfo (http://www.linksysinfo.org , and being flamed/silenced/demonized there by Linksys admirers, stakeholders and protectors) a Cisco contact from emailed me trying to understand this issue further. His best response to comment on that issue was:

"Quick VPN is a design effort that considered how to get a less technically capable audience of users into using some of the more sophisticated features of our products. Quick VPN was to provide that streamlined tool to get VPN tunnels running between remote users and their offices."

Later on and after several months, recognizing their mistake and the enormous bad PR that they were getting, they released an upgrade to QuickVPN which relies on a certificate which is pulled from the router and installed on the client side.
This release is supposed to address the first part of the security breach but I did not have enough time to validate it.

Linksys-Cisco, also released a firmware upgrade to a small set of their products allow generating a new set of key pair and certificate.
Note that importing an external key/certificate (a feature not included in their firmware update) may be considered a better approach, as the device has no hardware RNG and there is no way to verify the strength of the key pair generation algorithm, especially where the code is not open-sourced – you´d be surprised to find out that this might be a very practical backdoor (see previous references to breaking the Netscape SSL).

6 What can be done to fix this?

Addressing these issues requires a fix in both the firmware and QuickVPN client.
The obvious recommendations that can be stresses out are:

The router should allow updating the default key/certificate.
A fix in one of the firmware versions (I believe RXxx) allows generating a new key pair however and as far as I know it will not allow you to update your own key pair, bypassing the PRNG mechanism.
The QuickVPN client application should check the custom (updated) router certificate and fail the handshake, not disclosing the password, in case the peer certificate is not validated – this was fixed in the latest QuickVPN release.

I was very disappointed to see that Linksys-Cisco was failing to deliver a fix for all their products.
The Linksys-Cisco fans at the LinksysInfo.org consider this as a very minor issue (because they are fans and replace their hardware every while and than), but as a matter of fact there are hundreds of thousands out there that are left unprotected and unsupported.

7 Conclusions and wonders

Linksys-Cisco implemented a proprietary protocol with no external review; they have kept this approach in their recent QuickVPN update (software/firmware), which still left with some holes in it (enforcement of this fix, old hardware).
Needless to say that this issue has caused Linksys-Cisco lots of embarrassment, they failed in controlling the report before I sent it out (I could commit to a period of silence in case they really wanted to have a fix in a committed date). This caused a bad PR during the resolution period and after it.

To irritate, Cisco-Linksys released a firmware upgrade just to a small set of their routers, supposedly because they want to leverage this security hole to encourage their customers to upgrade their hardware.
That was not the intention while I found this security hole, and I hate to think that Linksys-Cisco would make a hefty ransom on my back.

I´d encourage a public opinion movement, to convince Cisco-Linksys with pushing a fix to all their products – I would not want to buy a Linksys-Cisco product if it is not supported after a couple of years and it´s "open-source" is not exposed for the public to maintain and improve – just in case a new issue arises

It is somewhat ironic to find that NDS, a company from Jerusalem/Israel, with a very strong reputation in encryption technologies for satellite TVs bout Jungo, the company that is listed on the WRV54G certificate.
Could it be that Linksys-Cisco took Jungo´s code without really validating it...

8 About myself and why I did this

I´m a senior software engineer, having a master’s degree in computer sciences from the Hebrew University Jerusalem.

I own several Linksys routers, including the WRV54G router.
Knowing that the router is supposed to be based off an open source distribution, I tried to code several lacking remote connectivity features for the router.
Unfortunately, I found that, Linksys does not release a full source code for the product, so I begun reverse engineering it and give it my best shot.

While working on this product, I discovered these security breaches and tried to negotiate with Linksys-Cisco a resolution. Several months after, I have given up the negotiations, understanding that the company is not interested in providing real solution.

Hoping that the public opinion would do its work, I´m released this document to the public.

Appendix A – listing the device keys

This section reflects the information, which exists in the recent firmware of WRV54G. This information may change as the router firmware advances.
The author is willing try and extract additional certificates and their matching secret keys should any sample devices sent for inspection.
Please note, that this document concludes that obtaining the secret key is a key point in setting a MIM attack for newer versions of QuickVPN (and it does not matter much for older versions of it).

Connecting to the gateway using HTTPS makes obtaining the device certificate @ port 443 and exporting it to a file.

The WRV54G device´s X.509 certificate is:

Assuming that the content of the certificate is copied to a text file named "server.cer", the following OpenSSL command yields this information:

openssl x509 -noout -text -in server.crt

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number:
           a8:a2:98:c0:8d:21:b9:17
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=US, CN=ORname_Jungo OpenRG Products Group
       Validity
           Not Before: Apr 6 09:01:17 2005 GMT
           Not After : Apr 1 09:01:17 2025 GMT
       Subject: C=US, CN=ORname_Jungo OpenRG Products Group
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:c0:e8:a0:93:e0:c1:f6:88:78:ce:21:bd:2f:a9:
                   6c:45:83:37:b4:05:07:bf:16:4e:ef:16:98:c1:21:
                   32:e2:bb:91:04:46:a1:d3:03:cd:8d:bf:bf:1e:e4:
                   2b:bb:ec:ba:dc:f4:12:f8:3a:de:b7:e5:bf:47:04:
                   51:e9:85:c3:59:34:da:6d:fd:a0:a0:57:47:f5:36:
                   9d:35:4d:f6:94:f4:38:19:f7:9a:23:42:cc:ec:83:
                   3a:ff:b1:2f:43:a7:9a:3b:2d:c7:87:51:ec:72:fa:
                   a7:c7:18:26:3a:13:b3:e3:df:53:ca:b8:f7:01:3c:
                   9b:f2:dd:67:65:20:c3:5a:61
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Basic Constraints:
               CA:TRUE, pathlen:5
           X509v3 Key Usage:
               Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Certificate Sign
           X509v3 Extended Key Usage:
            TLS Web Client Authentication, Code Signing, E-mail Protection, TLS Web Server Authentication
           Netscape Comment:
               Jungo OpenRG Products Group standard certificate
           Netscape Cert Type:
               SSL Client, SSL Server, SSL CA
   Signature Algorithm: md5WithRSAEncryption
       84:75:86:1f:17:30:20:08:f6:b5:89:e9:df:81:9e:86:58:aa:
       41:ae:c8:19:03:2c:63:fa:39:3f:45:9a:f6:83:57:1a:51:ab:
       8d:0e:25:61:b8:4f:e0:65:8c:82:3d:cf:96:67:af:a9:f4:96:
       27:0c:6c:3f:27:cd:71:8a:4e:77:5e:78:69:80:dd:1a:2e:5d:
       21:13:74:39:d1:f7:8d:73:dd:e6:7f:25:5e:02:04:c4:f8:16:
       01:25:ad:06:41:5e:cd:f6:f7:63:ab:86:1e:87:90:36:0a:0d:
       94:7c:6a:96:16:fb:27:36:ff:6a:9c:59:3c:1d:58:22:6b:e4:
      d8:b1

Far more interesting, the WRV54G secret RSA key is a common secret across all devices, disclosing it means that all manufactured devices can be faked to act as a valid gateway.

The WRV54G secret RSA key is:

Assuming that the content of the key is copied to a text file named "server.key", the following OpenSSL command yields this information:

openssl rsa -noout -text -in server.key

Private-Key: (1024 bit)
modulus:
   00:c0:e8:a0:93:e0:c1:f6:88:78:ce:21:bd:2f:a9:
   6c:45:83:37:b4:05:07:bf:16:4e:ef:16:98:c1:21:
   32:e2:bb:91:04:46:a1:d3:03:cd:8d:bf:bf:1e:e4:
   2b:bb:ec:ba:dc:f4:12:f8:3a:de:b7:e5:bf:47:04:
   51:e9:85:c3:59:34:da:6d:fd:a0:a0:57:47:f5:36:
   9d:35:4d:f6:94:f4:38:19:f7:9a:23:42:cc:ec:83:
   3a:ff:b1:2f:43:a7:9a:3b:2d:c7:87:51:ec:72:fa:
   a7:c7:18:26:3a:13:b3:e3:df:53:ca:b8:f7:01:3c:
   9b:f2:dd:67:65:20:c3:5a:61
publicExponent: 65537 (0x10001)
privateExponent:
   56:61:54:56:23:54:77:32:50:f5:ec:81:ac:6f:ee:
   fd:89:6e:4d:fb:da:a6:24:35:20:36:3c:1c:6e:e3:
   3c:47:c4:fd:e7:2a:db:34:5e:bc:d4:59:9e:59:89:
   83:d2:d3:31:d1:51:15:3a:37:34:9d:79:f3:30:ea:
   04:e9:52:b9:3d:dc:54:3b:35:bf:ef:f0:df:ab:06:
   c5:29:b3:ea:1b:97:07:9e:ab:eb:3b:16:52:d4:1d:
   34:5c:fd:98:3f:76:bf:83:0c:b9:ee:a5:de:a5:56:
   5e:27:12:05:5a:62:40:8b:d0:bd:ba:28:d8:e0:40:
   33:eb:23:4e:ac:ff:a4:61
prime1:
   00:ec:76:4d:d3:b9:b2:1d:cf:e5:3e:82:7f:3d:0a:
   ff:86:ea:2b:d4:43:33:15:b5:c7:4d:f0:b6:be:16:
   47:2e:89:c7:08:14:67:5d:75:5e:f7:71:9f:7e:32:
   87:9b:ca:43:9b:eb:60:61:91:9e:5f:a7:91:18:bf:
   e9:dc:4a:af:fd
prime2:
   00:d0:d9:12:78:c7:b9:ad:41:fa:e4:df:b8:a0:6e:
   12:51:27:07:c0:bb:ad:96:ed:88:f2:eb:e4:78:76:
   82:43:ca:34:19:de:59:96:7f:4d:47:d2:61:32:e8:
   8b:78:86:d5:3b:5a:83:9d:3f:b5:84:78:ae:5d:c6:
   a4:bc:81:07:35
exponent1:
   00:c8:e3:e1:4e:e5:4e:7b:a1:6a:03:67:5e:ad:ff:
   b0:03:70:e2:f7:9c:77:c4:14:01:55:28:12:39:00:
   38:4d:43:64:42:6b:03:3e:15:3f:2f:3d:ea:e0:8e:
   11:43:bb:dd:20:94:21:f8:02:7c:e8:8b:35:ec:2e:
   ef:81:e6:3a:09
exponent2:
   00:8b:75:d8:da:e4:6b:fd:e1:48:5b:db:75:1b:54:
   45:51:01:a2:30:b6:62:b5:9d:4a:cd:04:6e:9d:6e:
   6d:90:3d:0f:4b:92:e9:fa:10:6a:17:a2:c9:9b:48:
   24:12:48:df:4c:f2:25:5f:35:32:ce:12:14:45:b4:
   a7:3e:e5:5e:5d
coefficient:
   00:c3:30:e6:0a:91:38:f0:e6:8e:a4:a5:6a:b9:2d:
   e0:f6:b9:2f:8f:6d:80:0c:53:e9:b8:fc:57:51:37:
   a9:8e:c6:15:69:be:5a:62:8d:a5:40:a9:ee:5a:e3:
   e6:2b:5f:f8:a0:72:bc:eb:d0:a5:90:a2:a5:74:a1:
   a2:77:fd:83:7f