Various vendors of network-connected devices, specifically in home automation, use port forwarding and Dynamic DNS as a means to provide remote access to their devices, both for end users and for remote service purposes. However, as a recent case in Germany showed, this is a very bad idea as it opens the door for various security vulnerabilities. In the particular case, a manufacturer of heating systems used NAT port forwarding on the end user’s internet router along with a custom Dynamic DNS service to allow remote access to a user’s heating system controller for both the end user, as well as the vendor’s service staff.
The particular heating system’s controller has a built-in web server that, via a Java applet (which has various issues of its own, but that’s not the topic of this post), allows for remote monitoring and parameterization/configuration of the heating system. Different levels of access — end user, service technician and developer — are available, with the respective authentication via specific passwords (or PINs). Higher access levels provide extensive access to system parameters, with the possibility of turning the system off remotely, or changing certain parameters in such a way that physical damage to the system is possible.
What are the problems of this remote access approach? First, plain unencrypted HTTP is used for communication. This means that passwords are always transmitted in clear text over the internet (unless HTTP digest authentication would be used, which is, however, very uncommon). It would not be too hard to obtain such a password by capturing and analyzing all network traffic in a public network such as a Wi-Fi hotspot, for example. Second, due to a severe programming or design error, the system reports all passwords, as well as other information about the system, by simply requesting a particular web page. This does not even require prior authentication. Third, due to the predictable naming scheme used for Dynamic DNS, all customer systems are easily discoverable. Fourth, the system also allows remote, unencrypted FTP access, with potential even more severe consequences, given the manufacturers apparent lack of attention to security issues.
Another bad practice is to allow developer access to end-user systems. While this would be understandable for a system that’s still in field testing, where developers need access to learn what’s happening in the real world, such a deep level of access should never be possible to end-user systems.
Given the various design failures of the system, the choice of port forwarding and Dynamic DNS is just a part of the problem. However, even with a proper design and implementation of the web interface (use of HTTPS, secure passwords, etc.), directly exposing an embedded system to the internet via port forwarding is a very bad idea. Given the limited processing power of typical embedded systems used in home automation, it would not require much to launch a denial-of-service attack against such a system, simply by swamping the web server with lots of requests. In fact, the use of HTTPS would make this even easier, as encryption requires lots of processing power. It is possible to implement the system in a way to protect itself against DoS attacks, but most of the systems in use today are not. The use of Dynamic DNS makes this issue even more severe, especially if an easily guessable naming scheme is used. At least such a naming scheme should use random UUIDs, which are much harder to guess. But then, it’s much better to simply not use port forwarding and Dynamic DNS for such purposes at all.
What are the alternatives to port forwarding and Dynamic DNS for providing remote access to devices? One alternative would be to use a VPN, where each device opens a VPN connection to a network controlled by the vendor. This works for providing remote access to service technicians. However, providing remote access to end users cannot be easily implemented this way. Also, setting up a propert VPN server infrastructure for a large number of end-user devices requires a considerable effort. Another viable alternative is to use a system like <a href=”http://www.my-devices.net”>my-devices.net</a>, which provides all access through a central server (or server cluster). Each embedded system opens a secure tunnel connection to the server, and the server forwards incoming requests to the device’s web server only after proper authentication and authorization. Of course, both the connection between the web browser and the server, and the connection between the device and the server are encrypted.
Unfortunately, a case like the one in Germany is just the tip of the iceberg. A lot of other devices have similar issues. Embedded device security is still a topic that does not get proper attention during the development of a system. Given the current trends — internet of things, smart home, industrial internet, security will become a major issue. Proper training and awareness of everyone involved in the development of such systems — from developers to management — is of utmost importance.