Smart Meters – Assessing Concentrator Risk

A key element in any remote management infrastructure is the concentrator.  This device, located between the PLC network to which the smart meters are connected and the IP network of the distributor, performs the following functions:

• Meter detection in each of its phases (concentrators usually have a three-phase supply)
• Reception of consumption data
• Sending orders and report requests to meters
• Connection to the FTP server for measurement storage
• Acceptance of remote management orders (STG-DC)

This device is not usually exposed to the Internet. In particular, it is often found in the distribution substation in neighbourhoods where there are intelligent meters, connected to a private network for which the distribution company is responsible. This means that, in order to compromise the logical safety of these concentrators, the physical safety of these substations must first be compromised. Unfortunately, the latter cannot be considered a safety measure at all.

Assuming that the attacker has been able to physically access the concentrator, we can repeat the same methodology to give a lower level of risk for this type of device.

Regarding the detection of meters, the main risk would have to do either with the denial of service attacks (something that could be done from the home PLC network itself if the meters do not have adequate filtering measures) or with the introduction of dummy meters.

The risk, for a particular meter, is in general high or critical due to the nature of PLC deployments: a poorly designed switch-mode power supply can flood the switching harmonic cable, many of which will enter the CENELEC bands through which this type of communication runs, becoming an accidental jammer. For the whole network, the risk can be assessed as medium because it is necessary to be relatively close to the concentrator and to control the three phases in which it works. However, due to inadequate insulation in the supply lines, it is still possible to inject noise into the line by inductive coupling.

Regarding the reception of consumption measures, the main risk would be related to the injection of false measures, both from the attacker and by impersonating other meters. From a privacy standpoint, there is also a risk that an attacker will capture the consumption measurements of other meters.

Regarding the connection to the FTP server, the main risk is the FTP itself. FTP is generally an insecure protocol, and the risks would range from server credential theft to impersonation of the FTP server, putting not only data privacy at risk, but also data integrity.

And with respect to acceptance of remote management orders, there would be a risk of unauthorised access to this service. Note that the remote management system protocol (STG-DC) developed by Iberdrola follows a closed standard, the specification of which must be explicitly requested from this company.

The next question we must ask is, how many of these risks pose real threats? To answer this question we will have to go to the laboratory and audit the concentrator. Let’s get to it.

Auditing a concentrator

As previously mentioned, a concentrator has connectivity at two ends (minimum): a PLC end used to interact with the meters, and an IP end to communicate with the distributor. The most obvious test you can do is to simply enter the modem-concentrator link and perform a port scan against the concentrator using nmap. In the case of the Telecon TL-3001 concentrator we recorded results like this:

Which reveals a minimum of 4 lines of investigation:

SSH Ports

The concentrator’s Ethernet port exposes several services, including a running SSH server against which authentication has not been possible. It has also been possible to demonstrate that the SSH server validates the client’s public key. As this service is not documented and there is no way to set this key from the administration portal, it may be a maintenance service reserved for the manufacturer. However, its presence should not be evident: adequate patching should conceal the presence of this service from an attacker.

FTP Service

The aim of this FTP service is to provide a simple interface to the hypothetical remote management system in order to access the accumulated measurements of the set of meters connected to the concentrator.  However, the presence of an FTP service is a weakness in itself: FTP is an old, plain-text protocol in which even authentication is not protected. All security is delegated to the network to which it belongs. If this network is not protected, a simple MITM performed on a 24-hour cycle would be sufficient to obtain such credentials.

Even so, there is no indication that this service is a standard: it is possible that different manufacturers implement access to these measures in different ways, which would give distributors some leeway in deciding which concentrator best suits their requirements.

Old acquaintances

Default management interface and credentials

On the same Ethernet port, the portal for the meter management interface is displayed, authenticated by user and password. The default credentials are the already known admin:admin:

Luckily, as you would expect, these credentials can be changed according to the distributor’s password policy.

The mysterious protocol of STG-DC

The STG-DC protocol (Remote Management System – Data Concentrator) is a proprietary protocol designed by a Spanish distributor, based on SOAP, which allows remote meter management by the distributor communicating directly with the concentrator. The specification of this protocol can be found in document “STG – DC Interface specification”, which is restricted to manufacturers.

In principle, this protocol would mediate between the concentrator and a hypothetical remote management system (provided by a third party) which would offer distributors a simple interface for carrying out these tasks in an integrated manner with their billing and telemetering system.

In the field of cybersecurity, the correlation between closed specifications and security deficiencies is well known, with the concept of “security by obscurantism” being a particularly widespread one in this type of protocol. For this reason and the very criticality of the protocol, STG-DC is especially worthy of an exhaustive security analysis.

To approach this protocol we will start from the following working hypothesis: the SOAP endpoints are behind a web server, and this web server is exposed to the concentrator’s IP network. Indeed, if we do a port scan on the concentrator, we find a web server on port 9090, different to the usual administration portal.

Although the exact syntax of requests for this protocol is unknown, the XML/SOAP responses to them are known (which can even be found in the printed concentrator manual). In the worst case, this gives us a clue to its syntax and will help with protocol brute-forcing.

After several dictionary tests, it was possible to derive the syntax of a request for information from a concentrator and make a successful query. As expected, the protocol does not accept any kind of authentication and responds to these requests without any problem.

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