MB Connect Line hard- and software investigated

Intro

While the awareness for cyber security in the ICT world has leapt forward in the last years, the awareness in the OT world definitely has not. Very few industrial devices are equipped with adequate cyber security measures. This shouldn’t be a surprise. For years, OT devices were left alone under the idea that “if it isn’t broken, don’t touch it”. These devices are also incredibly robust. A lot of companies still use devices that are more than a decade old! They are designed to last a lifetime, even in harsh environments.  But with industry 4.0 around the corner, more and more companies are connecting their OT devices to a network. Everything has to be connected. Data must be logged, machines have to be managed remotely.  Devices with an Ethernet port will be connected to a LAN network.
However, almost no industrial device employs a decent cyber security strategy. That’s where we come in.

MB Connect Line

MB Connect Line, founded in 1997, is a German manufacturer of both hardware and software for secure remote access, secure IIoT and OT Cybersecurity.  The products range from automation routers and firewalls to a complete Remote Service Portal software, offered both as a service on Internet (SAAS) or as a licensed virtual machine that runs independently on the user’s servers, completely under the control of one’s own IT.  These devices are perfectly suited to implement Industry 4.0 in a feasible manner in factories. MB Connect Line considers cyber security of paramount importance which translates into a responsive and constructive cooperation to resolve any security point we raised.
The mymbCONNECT24 RSP software and the mbNET (MDH816) were subject to a so-called pentest. We took on the role of a hacker and investigated whether it was possible to gain unauthorized information or access to the internal network.
Before we dive into the details, we can conclude that both the mymbCONNECT24 RSP software and the mbNET remote access router are safe. We found a few security concerns and reported them to MB Connect Line.  Most are addressed and fixed in the (now available) updates. Other issues are only a matter of a correct configuration. The attitude from MB Connect Line towards cyber security is commendable. Especially because the issues were sent directly to engineering and a conversation was started to get to the bottom of those problems.

mymbCONNECT24

mymbCONNECT24 is the private version of mbCONNECT24, the public Remote Services Portal (RSP) that mbCONNECT Line offers on Internet. It is a virtual machine and can be deployed on a server. It allows you to log into an internal network form an external location. This report provides a detailed overview of the research results that were performed on version 2.3.0.
All the virtual disks of this mymbCONNECT24 Virtual Machine are encrypted. This prevents you to simply open it as a storage unit and browse its content.  This is definitely a good practice in the IT world.

However, virtual machines have no control over the hardware it runs on. Since encrypted files cannot be executed, the key for this encryption must be present somewhere. After extensive research we found it and were able to browse all files on the virtual machine. This includes default usernames and passwords, configuration files, …
This is a side effect of using a virtual machine, and is not solvable. Our advice is to always source the VM distribution from the original manufacturer, making sure to run a genuine, untampered and authentic version of the VM, and to never share running VM’s, to prevent the leakage of the information they contain.

Since we gained access to an unencrypted virtual machine (see above), we were able to further pentest the inner workings.
During this, we found that the account database and system database contains usernames an passwords in plain text. Although only authorized system administrators would have access to this database, storing sensitive information in plain text is never recommended. Once such a database falls into the wrong hands, all passwords would be compromised. Note that only original passwords appeared in plain text.  Once the user changed the password, the new password was encrypted.  Nevertheless this had to be reported and corrected.

As of version 2.4.1, all passwords stored in the database are now hashed. A hash is the product of a so-called hash-function. A hash-function processes data to a hash, which, if chosen carefully, cannot be used to calculate the original data. This ensures that if sensitive information is leaked, it is not (immediately) usable.

The web interface, as seen in the image above, was accessible from both the LAN side (as expected) and the WAN side, which is more difficult to secure and, hence, not recommended.  In addition, traffic from the WAN to https://<WAN-IP-Address>/ was forwarded to https://<LAN-IP-address>/  login. This means that information about the structure of the LAN network was released to the internet without authorization. Not a huge problem, an attacker can’t do much with only an internal IP address, but nonetheless, information that shouldn’t be disclosed. Fortunately, this only happened at the first startup with a DHCP server. Once the server receives a fixed configuration, as should always be the case, this issue is resolved.

Once logged in, we inspected various functions presented by the UI. One particularly interesting was “startFirmWareDownload()”. With only a few modifications, it was possible for an attacker to download random files to the device. This is the first step towards a Remote Code Execution vulnerability. We found no quick way to execute the newly downloaded file. Nevertheless, this vulnerability was fixed with version 2.4.1.

The last thing we inspected was the cookie for a Web2Go session. This is the browser access to the remote device embedded website. The cookie used was predictable and could be calculated from the URL. This made it possible to reach the local mbNET device login page. An attacker therefore had enough information with the URL visible on the browser of the victim to access this page. For example when a print screen is shared in which the URL is visible. This vulnerability was fixed with version 2.4.1.

mbNET (MDH816)

The mbNET is an industrial remote access router that is installed at the remote site, usually in a machine or in an electrical enclosure.
Firmware version 6.0.4 was tested on hardware version 2.

MB Connect Line practices a few security features with this model :

• Unique initial password : no more default passwords.
• Hardware security chip, built-in on the motherboard.
• A Digital Output on the device can be configured to notify local staff when someone is remotely connected with the unit.

The newer series of the mbNET, the mbNET.RoKey, is equipped with an onboard physical key to locally control the uplink and access to the LAN side.
As most industrial routers, you need to upload a configuration file (in this case “mbconnect24.mbn”) to the router. This file is downloaded from the RSP.  The configuration is activated by plugging the stick into the mbNET and pressing a hardware button.

However, this file is a simple .tar file (a compressed file) and can therefore be extracted. The content is not encrypted, which makes it possible to read various data such as Wi-Fi or APN passwords, network configuration, …  An attacker therefore only needs to obtain the file to gain access to confidential information.

MB Connect Line is actively working on a more secure and easier process for the initial device configuration, to be released summer 2019. The encryption of the configuration files will be available in a later update. In the meantime, this will still require the user to erase the files from the USB stick once used and format it thoroughly before disposing it.
This device also has a web interface and uses a session ID in its cookie to identify an user. The session ID was only partially random and contained the username and password in plain text. This means that, would a hacker intercepts that network traffic, he would also be in possession of the username and password to login to the device.  However, to capture this network traffic, a hacker would need access to the LAN side of the device (local or through VPN), in which case we have another problem. This has been fixed in version 6.0.5.

It is also possible to use a VPN with the mbNET. The default outgoing VPN connection uses simple authorization credentials. This may make it possible for an attacker to try and guess default passwords. As always, it is recommended to use a strong password.  However, in this case, mbConnect Line provides an additional layer of security, namely the VPN connection itself. This connection uses an asymmetric encryption. This means that as long as the keys are secure, even if the hacker guesses the password, he cannot set up a connection.

After logging in, a username and password for the user “web” can be found in the JavaScript. This login is used for internal services and could be accessible from LAN & WAN interfaces. This vulnerability has been fixed in version 6.0.6. The LAN & WAN access is now blocked by mbNET firewall and the password changes with every reboot.

The last issue we discovered involves the user configuration. When changing the password, the interface prompts the user for the old password.  However, any input given would have resulted in an error message “wrong password”, even if the correct password were entered. This message did not appear if no password were entered. This bug was present with new users who had not yet changed their password. Once the initial password had been changed, the functionality worked properly. This has some nasty consequences, because it enables a hacker to use a Cross Site Request Forgery (CSRF) attack. A CSRF is an attack whereby an attacker forges a link, which does more than a user expects. In this case, it would change the password, since the old password was not needed. If the user clicked on this link, the password would be changed without the  knowledge of the user. This vulnerability, along with the bug mentioned above, is no longer present in version 6.0.5.

Conclusion

As mentioned at the start of this article, both products are safe. None of the issues were highly critical and can be solved by updating the software or configuring it correctly.

Security is a dynamic concept. Researchers will always find vulnerabilities. No functional product is secure. What matters is the will and the ability of a manufacturer to update their products in response to found vulnerabilities. Our cooperation with MB Connect Line is a textbox example for a result-driven communication between a company and a third-party researcher.

Our final recommendation would be to improve the communication from MB Connect Line to its end users, with more detailed change logs. This may persuade the end user to install the updates to their software & firmware. We would like to thank MB Connect Line and Inelmatec, in particular Jean-Paul Verheylewegen and Koenraad De Can, to give us the opportunity to test these devices and software and the permission to write this report.

Tinus Umans & Tijl Deneut