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.
