3 min read
Holes in home gateway security allow for a malicious hacker to take over a gateway in the way they would any other computer system. While the holes in most cases have been complex and deep seated bugs that would be hard to find without a lot of work, there are some easy to find bugs that seem obvious but would be missed without negative testing.
Most application protocols use some method of authentication to ensure security and control identity management of users of the service. The most common way to do this is with a username and password combination. Most web services today also make use of the SSL/TLS layer through the use of certificates for authentication.
Sometimes, either because of a legitimate software bug or because of oversight during testing, a device will accept credentials that it should reject. This is simple in the case of usernames and passwords; the device may accept a bad password for a known username, visa versa, or both. This is a common problem with CPE that support FTP, such as NAS devices.
More complex is the issue of certificate authentication. While a CPE in error might ignore bad certificate credentials, there are many aspects of a certificate that could be ignored, making the error harder to pin down.
Sometimes, the certificate may just be incorrect. It may be the wrong certificate, the contents may have been changed, or the format may be incorrect. If you’re trying to avoid this, validate the certificate to make sure it’s the right one and in the right format.
Certificates may be signed by a CA (certificate authority) or may be self-signed. In the former case, the certificate of the CA is also required to authenticate the session. In CDRouter TR-069, for example, a file containing the root CA (and optionally intermediate CAs) used by the CDRouter ACS must be installed on the CPE for SSL/TLS authentication to succeed. If any one of these components are missing or flawed, certificate authentication should fail - if it doesn’t something is wrong.
Certificate authentication of web services match what is called the “common name” or identity when authenticating the session, usually the URL of the server. If the CPE is expecting something else (for example, if it is configured for the server’s IP address as the URL rather than its domain name), then SSL/TLS will fail.
Certificate security is complicated, so if it seems like your device is passing tests too easily without all of these pieces in place, you may need to perform some negative testing to make sure there are not important security holes.
These examples aren’t just meant as a list of troubleshooting techniques for when a service or test is failing. It’s just as, if not more, important to perform “negative testing” on devices to ensure that in addition to doing what they are supposed to do, they don’t do what they aren’t supposed to do, particularly in matters of security. Negative testing involves testing those cases where a device may pass a normal test but for abnormal reasons - a false positive that is harder to catch than doing simple pass/fail protocol testing.
CDRouter has many negative test cases included in its modules and add-ons. For examples, look at the CDRouter TR-069 test cases for od128_test_2.4, which makes sure the CPE rejects bad certificates. In CDRouter Storage, we test for bad credentials in tests 30 and 31 of each file transfer protocol test module.
