Close

Content Author


Nicolas Merle

ICS Security Researcher

Modbus-tcp-gateway

Exploiting a Kunbus Gateway module for Modbus TCP

Nicolas Merle

ICS Security Researcher

We take a look at how vulnerable this device from Kunbus really is, and the security risks to consider when implementing new devices in your Operation Technology (OT) environment.

After travelling to Germany last year, I picked up my Kunbus Gateway souvenir for one main reason: a competitively priced device of around 200€ would be attractive to purchase and install across a range of industrial facilities and would potentially be a perfect example of overlooking security when implementing new devices.

The Modbus TCP gateway is an industrial device manufactured by Kunbus; primarily used to interconnect devices utilising different protocols. Such devices are typically found in a variety of industries ranging from manufacturing to the utilities sectors. The impact of exploiting this device in a live production environment could result in the manipulation or denial of process control communications. We examined all of the interfaces available on the device at a network level and looked at the hardware – with only the network interface research covered in this article.

In this blog post, we focus on the main security issues present on the gateway module, and the level of difficulty required to exploit them.

Searching for vulnerabilities in the Gateway Module

We power up the device and scan the default IP provided and we get the following port open:


Attacking the web server

We start by connecting to the port 80 to find the webserver that serves us the main login page:

We have the default credentials and so we connect to the device as Admin.

Upon arriving on the admin page, we notice two things:

The username and password are sent in clear text and as parameter of a GET request, allowing the credentials to be identified. We can easily locate the credentials in Wireshark:

The first impression of the level of security is not promising – and with further investigation, we stumble upon more issues. On the admin page we have four main functions, show Modbus registers, change configuration, change password and reboot.

Those function names are self-explanatory, and I won’t explain each of them in detail. Now let’s try to access those pages after logging out.

For the configuration page we get an error message:

Fair enough, now let’s try the change password page:

Strangely we can access this function – let’s see how far we can take it.

It looks like it worked. Allowing credentials like this to be changed without being logged in could prove to be a large issue if exploited. Again, the passwords are sent over GET parameters, but that’s just a detail at this point.

Diving deeper into this, the password can only be changed of the last user who logged in during the uptime of the gateway. As it is a very small device, the documentation gives the credentials for the admin user - even if there is an unprivileged user available. The operator will most likely connect with the admin user, configure the device and then keep it connected. Once the device has been rebooted, there is no way to recover the password.

In this scenario, the password can be changed without access, and could allow an attacker to connect to the device, change the password, reset the device and change the configuration. The only option left for the operator is to purchase a new device and return this one to Kunbus.

Let’s look at the third page option, the reset page:

Like the password page, this can also be accessed without authentication to reset the device.

As for the last function to test, modifying the Modbus input and output values is available without being authenticated.

To conclude on the web interface, we can change the value of the Modbus registers and reset the device (possible to chain the request to create a DOS) without authentication. Also available is the ability to change the password of the admin account if it has already been logged in at any point during the uptime of the device (even if logged out). Resetting the device after changing the password completely locks down the device for any other user even legitimate.


Attacking the FTP

Let’s now look at the FTP. We can connect to it using the credentials we have for the web interface. Upon connection, we find one file and one directory:

The password.xml file contains the username and password in plain text for all the users along with their permission level. When you change the password, the FTP connection is not cut. The passwords are changed in real time, allowing you to revert to the default password, stay connected and await for the admin to change the password, so you can identify the new credentials.

In the web folder you get access to all the shtm files used by the device. You can modify them to inject code. Here again, you can steal the password by injecting JavaScript to retrieve the arguments sent at login, or when the password is being changed.

Finally, if you try to retrieve a file via ftp with a file name larger than 256 characters, the device crashes completely, requiring an electrical reboot. This is likely a buffer overflow, although could not be identified as there was no debugger on the device and as it is an authenticated vulnerability, we did not spend more time trying to develop an exploit.

Attacking the rest of the device

After identifying the existing issues within the web server and the FTP, it was determined that this device was insecure and as such we did not conduct further analysis on the Modbus port or on the last port.

The disclosure process

Kunbus did not have procedures in place to respond to our security enquiry on initial contact, which lead to large delays and the need to contact ICS-CERT for the disclosure process. Attempts were made to contact the vendor regarding the issues through our responsible disclosure process. After more than 10 months, no response was received. Contact was made to ICS-CERT, which in turn contacted the Federal Office for Information Security in Germany in order to trigger a response – leading to the published security advisory.

Kunbus since acknowledged the need for security and proper incident management processes and have stated they are working towards implementing such processes. Kunbus has since released an update for their software with an updated manual explaining how to implement users with different permission levels and instructions for updating the device.

Recommendations

Any company designing a product should follow some basic guidelines:

  • Make sure that the authentication mechanism is implemented securely
  • Restrict all features of the device to logged in users, even read only or view features
  • Store credentials in a safe way on the device

All those recommendations are already expressed in a large number of ICS standards like the IEC 62443 and should be followed as part of secure development lifecycle (SDLC).

For those using the device in their facility, Applied Risk recommends updating the device to firmware version R02 which fixes all of the vulnerabilities in the advisory with the exception of the insecure password storage and the password transfer over GET request, which will be address in a future update. The R02 update is available on the Kunbus website.

Lessons Learned

Before buying any device or creating a new DCS, the security of it should be checked. This can be achieved by implementing some procedures:

  • Designing your network with security in mind buy following reference architecture from ICS standards like IEC 62243
  • Drafting security requirements for the vendors based on ICS standards
  • Testing the critical devices separately for implementation errors and vulnerabilities during the FAT
  • Testing the full infrastructure for misconfigurations and vulnerabilities during the SAT


Conclusion

To summarise - it looks like basic security features are either not working or not implemented. An attacker with network access to this device could, without any authentication, reset the device continuously which would prevent the device from operating. They could also change the values of the Modbus registers. Being able to change the Modbus values without authentication is expected behaviour when using Modbus. However, it should not be possible to do it from the web interface. This could allow an attacker who has a foothold on the network to get control over the physical process.

If an engineer is connected during the uptime of the device, things get worse, as an attacker could simply change the Admin password. This would completely lock out any legitimate user forever. It would force the company to completely replace the device and return it to Kunbus for factory reset. Once the attacker has got credentials to login, they can effectively crash the device making it inoperable until an operator disconnects and reconnect the power supply.

Another issue is that the passwords for all the users are stored in clear text on the device and are directly accessible via the FTP service. Password could be retrieved this way. As people are reusing password, getting a password on one device could help to get access to other systems on the network.

The best recommendation Applied Risk could provide is to keep security in mind when implementing new devices in your industrial networks. Using industry wide standards such as the IEC62443 as a framework for your security is a comprehensive approach to protecting your production environments. If the Kunbus Gateway Module is already integrated in your network, ensure it is protected by additional layers of security.

With its extensive knowledge of securing infrastructure in operations environments, Applied Risk can assist in assessing current levels of security and implementing improved security controls in line with widely recommended industry standards.

Disclosure timeline

7th of February 2018: Disclosure of vulnerabilities to the vendor.

9th of February 2018: Acknowledgement by the vendor that the vulnerabilities were received.

5th of June 2018: Update that the case was still under review.

2nd of August 2018: Follow-up on vendor before disclosure.

15th of November 2018: Contact of ICS-CERT

27th of November 2018: Contact established with BSI

17th of January 2019: Release of the R02 update for the Modbus gateway which fixes critical issues discovered by Applied Risk.

6th of February 2018: Responsible disclosure by Applied Risk and ICS-CERT

Thank you for your submission!