Smart Meters – A proof of concept: hacking a smart meter

In previous articles, sufficient evidence has been provided (both from theory and passive observation PLC traffic) to prove that the PRIME protocol is vulnerable to cyberattacks due to the combination of a deprecated protocol (featuring different security flaws) and an inadequate configuration of communications security. These deficiencies cannot be easily fixed by a simple firmware upgrade (either from concentrator or meter manufacturers) as it would break existing compatibility with PRIME 1.3, therefore any mitigation measure should be carried out by distribution companies. The only unanswered question is, how feasible is to exploit these vulnerabilities?

In this article, we will test some of the previously-listed techniques with the ultimate goal of hacking a smart meter and operating it remotely. To carry out these tests, the Microchip test boards’ firmware has been modified to allow for hardware control by serial port. This new firmware will accept commands in the form of binary frames, describing commands such as displaying a PRIME frame, modifying the LCD content or changing the status of the board’s LEDs.

At the other end of the link you will find a laptop with a GNU/Linux distribution running the PLCHack software, a tool developed by Tarlogic to support the audit tasks of these types of networks. PLCHack will interact with the serial port and exchange the different PRIME frames that are received or have to be transmitted to the PLC network with the Microchip board.

A genius approach: announcing a new hub

Beyond the usual jamming and denial of service attacks, the simplest attack that can be considered is to impersonate a hub (different to any other hub), announce itself to the network through several BEACON frames and wait for a hub to hook up. The BEACON frames, according to the PRIME 1.3 specification, have the following structure:

Where a big-endian network byte order is expected, and where the most significant bit always appears on the left. The MAC header of these frames is reduced to the initialisation of the two HDR.HT bits to 2 (10₂) to identify it as a BEACON frame. All other fields must be initialised as follows:

Field	Description
BCN.QLTY	3 bits indicating the quality of the connection with the base node (in case this beacon is transmitted to a switch). In our case, by impersonating a base node, we will initialise it to 7 (excellent quality).
BCN.SID	Identifier of this switch in the network. Since we’re impersonating a hub, we’ll set it to 0.
BCN.CNT	Number of beacons in this frame. As there is only one beacon, it will be set at 1.
BCN.POS	Slot used in this frame. For beacons coming from hubs, this field must be worth 0.
BCN.CFP	Offset from the start of the contention-free period. We will not offer any, so we will set this field to zero.
BCN.LEVEL	Level in the hierarchy of base nodes and switches. As we are a hub, this level will be equal to 0.
BCN.SEQ	Sequence number of this beacon. It increases by one unit for each beacon transmitted.
BCN.FREQ	Frequency with which these frames are sent. We will choose a frequency of 0 to indicate that a beacon is sent in each frame.
BCN.SNA	MAC address of the hub. We must be consistent with this value (we can enter something such as aa:aa:aa:aa:aa:aa).
BCN.UPCOST BCN.DNCOST	Cost of sending or receiving a frame from this switch to the base node. Since we’re impersonating a hub, it will be 0 in both cases.
CRC	Checksum of this frame, with CRC polynomial G (x) = x32+x26+x23+x22+x16+x12+x11+x10+x8 +x7 +x5 +x4 +x2 +x+1

At the same time as injecting this frame we must intercept the different frames that are received by the network, waiting for a REG type control frame. These frames are sent by the service nodes trying to associate themselves to a base station, and whose structure is the following:

The fields REG.SNK and REG.AUK are only relevant for records using Profile 1.

Results

Unfortunately, it was only possible to capture one registration request after a full 24-hour cycle, and it has not been possible to reproduce it since. It is possible that due to the simplicity of the attack, the timings of the beacons are not being respected, which would rule out most of the requests. This brings us to a second iteration of the attack:

A little more difficult: injecting traffic

In a second approach, we could take advantage of the state of an existing association to inject traffic into the meter. To determine this state we must start with a passive observation over a certain period of time (in a 24-hour cycle, we can expect multiple data frames exchanges with the hub) and obtain at least the following parameters:

• NID (SID + LNID) of the meter.
• Connection LCID (mostly 0100)
• LEVEL (depth level in the switching tree)
• SNA of the subnet in which it is located (the 6 bytes of the MAC of the hub).
• PKTID of the last data packet, which identifies the packet being sent
• ACKID of the last data packet, which identifies the next packet expected from the other end of the communication.

Some of these parameters are distributed over the multiple levels of encapsulation of the PRIME data frames, while others must be deduced from them. In particular:

Data payload (DLMS requests and responses)

SSCS (IEC 61334-32 Connectionless LLC Sublayer)

SAR (common part of the convergence sublayer)

ARQ bytes (PKTID and ACKID)

PRIME DATA GPDU (NID, LCID, LEVEL)

Note that the SNA is not found in this diagram: this value is used implicitly in the CRC of the frame, concomitant with the SNA content.

In addition to the values listed, which are necessary for initialising the various headers of this encapsulation, there are many others that must be properly initialised:

• The SAR (Segmentation and Reassembly) is part of the common part of the convergence layer. It consists of a byte that provides fragmentation information about the packet payload. As our frames will generally be small, this byte can be initialised to 0, indicating the first of a single fragment.
• The IEC 61334-4-32 sublayer provides LLC services, and is part of the specific part of the convergence layer (SSCS). The specification of this sublayer is paid-for (approx. €300), so it should be initialised based on experimental observations.

The study of the communications protocol has served to determine that the convergence sublayer in the PRIME + DLMS/COSEM stacks consists of three bytes, of which the first is always 0x90, and the next two depend on both the direction and intentionality of the traffic exchanged. In particular:

• For traffic destined for read-only queries (and this includes both DLMS authentication and all intermediate messages until the completion of queries with a release message), the remaining two bytes have the meaning of “source address” and “destination address” respectively. These addresses are assigned at the LLC level by an unknown procedure. The hub address is always 01.
• For traffic intended to perform read and write queries (including the execution of DLMS methods) both bytes must be 01, both in upstream and downstream traffic.

Clearing up the unknown

The only way to determine if a data packet from a certain subnet has arrived correctly is to determine its subnet address (SNA), which always matches the 6 bytes of the hub MAC. PLCHack can determine the SNA by passively listening to hub beacons and computing CRCs based on the SNAs observed in the beacons it has received. As beacons can take several seconds to arrive, manual entry is also considered.

Upon receipt of any valid PRIME data frame correctly associated with its subnet, the NID, LCID, LEVEL, PKTID and ACKID of the packet to be injected are obtained directly. There are rare cases where PKTID and ACKID may not appear (which only happens if both meter and hub have agreed not to use ARQ mechanisms, which has not been observed to date). In all other cases, immediately after obtaining these parameters, the desired PRIME frame can (and should) be constructed, its CRC calculated based on its SNA and injected directly into the medium. The only thing to bear in mind at this point is that, unlike the other parameters, simply copying the PKTID and ACKID is not enough: these parameters are related to the sequencing of data traffic, and must evolve with each frame exchanged:

• If the data frame received comes from the hub (bit HDR.DO of the header equal to 1), the ACKID of the frame to be injected must be equal to the ACKID of the captured frame. This is because the next PKTID expected from the meter is still ACKID. However, the PKTID of the injected frame must be equal to the PKTID of the received frame + 1. Another way of looking at it is that, as we are falsifying the hub, we only need to capture the last data frame sent by it, replace its payload and increase its PKTID.
• If the data frame comes from the meter (bit HDR.DO of the header equal to 0), the situation is reversed: the meter frame indicates that the next data packet to be injected must have a PKTID equal to the ACKID of the captured frame, and vice versa, the ACKID of the frame to be injected must be equal to the PKTID of the captured frame + 1.

The PLCHack command seqsnoop is able to display this set of parameters for each captured data frame and optionally suggest other PLCHack commands to inject frames based on these parameters:

Proceeding with the injection

The commands suggested by seqsnoop include the full set of parameters required to inject a given type of DLMS message. These commands are:

• authenticate: This sends a message to the meter for writing, with a given password. In terms of DLMS, it is sending an AARQmessage.
• cut: This sends a supply cut order, opening the internal meter switch. In DLMS terms, it is an ACTION_REQUEST towards a COSEM object specific method related to shutdown control.
• connect: This sends a reset order by closing the internal switch of the meter. This is another ACTION_REQUEST to the same COSEM object used by the cut command, simply varying the parameters of the method called.

The following screenshot shows the use of the commands seqsnoop, authenticate, cut and connect to cause a temporary power failure.

Going beyond

The problem related to the previously mentioned attack is the need for passive observation of the data traffic, which can take a long time to appear. A slightly more interactive strategy is to receive any type of generic PRIME frames (GPDU), associate them to an SNA and examine their LEVEL and NID fields. In practice, as the only LCID observed is 0x100, the only parameters left to be determined are the PKTID and the ACKID. Laboratory tests have shown that, due to the small size of these identifiers (both 6-bit), it is possible to build a small program that will go through all ACKIDs and PKTIDs by sending the same payload, while waiting for a response from the meter. Once the answer is obtained, the entire state of the connection can be reconstructed, and a two-way communication can be started with the other end.

This is exactly what the PLCHack command dataprobe implements: starting from the SNA, NID, LCID and LEVEL of the frames to be injected, it runs through all the ACKIDs and PKTIDs in a loop, until a data response is produced from the other end. This data response is used to reconstruct the state of the connection and start a more complex DLMS communication: an authentication DLMS message is sent (AARQ), a response is expected (AARE) and, if successful, an exchange of internal switch on and off requests is started, thus proving that a meter hack is possible. The result of the execution of this program at the Tarlogic PLC meter laboratory can be seen in the following video:

Discover our work and cybersecurity services at www.tarlogic.com