SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


Try our Premium Alert Service
 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service





Category:   Device (Router/Bridge/Hub)  >   Linksys Router Vendors:   Cisco, Linksys
Linksys WRT54G Common SSL Certificate and Private Key Lets Remote Users Decrypt Management Sessions
SecurityTracker Alert ID:  1014596
SecurityTracker URL:  http://securitytracker.com/id/1014596
CVE Reference:   CVE-2005-2434   (Links to External Site)
Updated:  Jul 18 2008
Original Entry Date:  Jul 29 2005
Impact:   Disclosure of system information, Disclosure of user information
Vendor Confirmed:  Yes  
Version(s): WRT54G
Description:   A vulnerability was reported in the Linksys WRT54G wireless router in the SSL implementation. The device uses a common certificate and private key.

A remote user with access to an SSL management session can decrypt the session.

Nick Simicich reported this vulnerability.

Impact:   A remote user with access to SSL management session traffic can decrypt the session.
Solution:   No solution was available at the time of this entry.
Vendor URL:  www.linksys.com/ (Links to External Site)
Cause:   Authentication error

Message History:   None.


 Source Message Contents

Subject:  Vulnerability in Linksys Router access


Many months ago, I reported a vulnerability to Linksys/Cisco regarding
the WRT54G.  The vulnerability is simple: SSL is used to secure
communications with the router. 

That is a good thing.  However, SSL is not secure when you just
implement part of it.  SSL was implemented in a miserably insecure
manner. All routers used the same certificate and private key. The
certificate and private key were part of the software load.

Thus, anyone who works at it a very small amount and who records the SSL
entire session can decrypt it.

The software writers are caught between a rock and a hard place in terms
of how to implement certificates.  Self signed certificates are at risk
for MITM (Man In The Middle) attacks. Anyone can dynamically self sign a
certificate and present it.  Certificates that are signed by a well
known certifying agency or even using a common signing certificate
programmed into a browser  (where the signing certificate's private key
is properly protected) help prevent MITM attacks due to details of SSL.

But you need a different certificate/key pair for every presenter, and
you need to secure the key.

Installing a different certificate signed by a well known certifying
agency into each separate software load would require that EVERY
different router have a unique software load. It might well also
increase the cost of the router significantly.  These routers are
$49.99, quantity 1, through Amazon.com.  The cost of a certificate would
be a significant fraction of that amount.

So you have three possibilities:

1.  A common certificate.
2.  Individual software loads.
3.  dynamically built, randomly generated self-signed certificates.

I was assured shortly after I reported this, that the newer versions of
the router software would be changed to build a random private key and
use a self-signed certificate. I have not installed the latest version
of my software in my router, so I can't attest to this.  They didn't
answer my last few e-mails.


Many people configure these routers by simply accessing a wired directly
connected router using a browser. Arguably, it does not matter whether
that initial encryption is secure or not, since the wire is arguably
secure. If a random, self-signed certificate is used, then the
certificate fingerprint can be recorded.  

If you then tell your browser to keep accepting that certificate, you
should be notified if, later, a MITM attack is undertaken - the MITM
attacker should present some other certificate.

You should assume that if you are using ssl to access a router where the
path to the router is in an adverse environment, and you are using a
version of the software where a shared private key and shared
certificate are used, that your communication might be intercepted and
decoded.

If you are using a randomly generated key, you should record the key
fingerprint, either using a browser facility or manually, and then, when
you contact the router, you should verify that you are using the same
certificate.

If these routers are used in an adverse environment, administrators
might consider installing a different private key and certificate in
each software load.  In that case, the private key and associated
certificate could be used with a single signing key and the browser used
to access those routers could accept that signing key.

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2018, SecurityGlobal.net LLC