Computrend Powergrid 902 Powerline Adaptors
This was originally published at Benscomputer.no-ip.org
I ran a variety of basic tests against the Computrend Powergrid 902 Powerline Adaptors, these are the results
Equipment Information
Designation |
MAC Address |
Serial Number |
Powerline-A |
001D204E244A |
08061011817A |
Powerline-B |
001D204E244B |
08061011817B |
Node Information
Designation |
DHCP/Static IP |
Operating System |
BT-HomeHub |
Static |
Unknown |
Linux-PC |
Static |
Gentoo Linux |
Linux-Laptop |
Static |
Gentoo Linux |
Network Information
Powerline SSID - 123456789
Designation |
I.P Address |
Connected To |
Encryption Algrithm |
Encryption Key |
Powerline-A |
192.168.1.68 |
BT-HomeHub |
3DES |
123456789A |
Powerline-B |
192.168.1.69 |
Linux-Laptop |
N/A |
N/A |
Linux-PC |
192.168.1.64 |
BT-HomeHub |
N/A |
N/A |
Linux-Laptop |
192.168.1.61 |
Powerline-B |
N/A |
N/A |
Network Topography
Linux-PC ----CAT5-E-----> BT-HomeHub ---------CAT5-E-----> Powerline-A -----Ethernet-Over-Mains ------~
~------Ethernet-Over-Mains ------- Powerline-B <------CAT5-E------ Linux-Laptop
Physical Layout
For many of the tests, the Powerline Adaptors will be plugged into the same 4-Gang Mains Extension lead. Any changes to this setup will be explicitly stated in the test criterion.
All other Mains powered devices will be powered from a seperate Mains Extension lead.
Powergrid 902 Status Light
The powergrid Status light has three modes. Red, Green and off. If the status light is off then the device is in standby mode (or not plugged in), Red means that the device is active but has not established a connection to another Powerline Adaptor. Green means that the device is active and has established a connection.
Test Procedures
All tests will be executed exactly as laid out in the test performa below. Each test will be assigned a status code based on an evaluation of the tests outcome when compared with the expected outcome. Any tests that are assigned the status code Inconclusive will be re-evaluated and repeated at a later date. It is expected that any Inconclusive results will require a re-assement of that test procedure.
Tests
Test ID |
Test |
Expected Outcome |
Actual Outcome |
Pass/Fail/ Inconclusive |
0 |
Connect and power up the Powerline Adaptors. Set both to use the same Encryption key and confirm that the status lights turn green. |
Status Lights Green |
Status Lights Green |
PASS |
1 |
Set Powerline Encryption keys to test specifications, allow 2 minutes for broadcasting and check status light to confirm connection. |
Different encryption keys should lead to Red Status Light |
Red Status Light |
PASS |
2 |
Run Wireshark in Promiscuos mode on Linux-Laptop, and generate network traffic between Linux-PC and BTHome-Hub. Run test for 5 minutes with a constant dataflow (using wget to repeatedly access the Web Configuration pages). Check Wiresharks log for any detected traffic. |
No traffic detected, except traffic between Powerline-B and Linux-Laptop |
No Traffic |
PASS |
3 |
Run arp -a on Linux-Laptop to see which MAC Addresses have been detected on the LAN |
MAC for Powerline-B should be only address displayed. |
Records shown for other nodes, but incomplete |
PASS |
4 |
From Linux-Laptop, attempt to ping the LAN IP address of Powerline-A. |
No route to host |
No route to host |
PASS |
5 |
From Linux-Laptop, attempt to ping the Powerline-IP of Powerline-A |
No route to host |
No route to host | PASS |
6 |
From Linux-Laptop, attempt to ping Powerline-A using arping |
No route to host |
No route to host | PASS |
7 |
Access Powerline-B Web Admin console from Linux-laptop and change the encryption key to a NULL value Save changes, and check status lights after 2 minutes |
Error on saving changes and/or status lights should remain red. |
Red Light |
PASS |
8 |
Access Powerline-B Web Admin console from Linux-laptop and change the encryption key to a wildcard (*) Save changes, and check status lights after 2 minutes |
Error on saving changes and/or status lights should remain red. | PASS |
Notes
Configuring the Powerline Adaptors for the tests took a lot more effort than expected/necessary. The adaptors have been disconnected from any power source since the last tests were run on the 11th of February. Whilst they successfully integrated into the network, and established comms between each other, they did not request an I.P Address from the DHCP server (in this case the BTHomeHub). They functioned as transparent devices with absolutely no noticeable presence on the network. Checking the pre-configured Static IP addresses also showed no hosts. In order to re-configure the devices it was necessary to reset the devices back to factory settings.
The default factory setting appears to be to use DHCP, and to use no network identifier, or encryption key on the mains side. Once the range of these devices has been established (i.e. does the electricity meter act as a firewall?) it will provide a rough insight into how secure these devices are out of the box.
Conclusions
Based on the very basic tests conducted, the Powergrid 902 Adaptors appear to be reasonably secure against outside intrusion. However, no direct attempt to compromise the adaptors was made. Instead checks for errors in the basic implementation of the system were made, this level of security should at least protect users from attacks by the garden variety 'script kiddy', but does little to illustrate how effectively the system would resist attacks from a more determined or advanced intruder.
The issue of using a NULL value as the default Network Identifier and Encryption key is somewhat concerning. However when the devices were received from the re-seller (in this case British Telecom) the devices did have both a network ID and an encryption key set. For this reason it is hard to project what percentage of users could be using the devices without any security set.
Based on these, and previous tests it appears that the biggest risk the devices pose is when an attacker gains access to the Network to which the devices are connected. The attacker would then be able to provide a simple Denial of Service against the devices, and anything connected to the other side of the bridge. Alternatively the attacker could view the network ID and Encryption settings in order to more easily gain access at a later date.
This could happen where a Wireless network is accidentally left open for a short time, or wherea worker leaves their desktop unlocked in an office setting. However regular rotation of the encryption key used on the devices could help to reduce this vector of attack.
Where an attacker is able to action a DoS attack against the devices, this could cause a complete loss of traffic for a segment of the network, and is likely to be highly inconvenient depending on the network that has been compromised. However as the attackers ability to launch the DoS highlights the fact that the LAN has been compromised it should probably be considered as little more than a regrettable side effect.
There may exist other vulnerabilities in the embedded software, in fact the principles of software testing state that there almost probably will be. However without access to the software it is reasonably difficult to find any new vulnerabilities.
Where security is considered important, whether due to commercial sensitivity, or due to untrustworthy neighbours it is probably best to try and avoid use of these devices. Where security is at a lower level, the devices do not appear to be critically insecure.