The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force.

While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with. This research was undertaken to start those conversations and encourage further interest.

ThingsBoard is an open source IoT platform designed with the intention of supporting as many different types of IoT devices as possible. Founded in 2016, this Ukraine-based organization quickly rose in popularity amongst both IoT enthusiasts and industry professionals. With thousands of active deployments ranging from small IoT developments to city infrastructure monitoring and management, ThingsBoard is one of the more popular open-source IoT platform solutions.

As a result of this project, a vulnerability involving insecure secret key management was discovered. This vulnerability, CVE-2023-26462, can be leveraged to escalate privileges within the system, using the secret key to manipulate the JSON Web Tokens underpinning the authentication system for the platform.

JSON web tokens

Before diving into the details of what the research found, a brief overview of JSON Web Tokens (JWTs) is in order. JWTs have become increasingly popular as a means of providing secure, stateless authentication for web and mobile applications. They are a compact, URL-safe means of representing claims to be transferred between two parties. There are three sections that make up the JWT: header, payload, and signature.

The JWT header contains metadata about the token, such as the encoding method. The payload contains the claims that are being transmitted, such as the User ID, role, and token lifetime. Lastly, the signature is a cryptographic signature used to verify that the contents of the payload are valid and have not been tampered with. This signature is generated using the algorithm specified in the header of the JWT and a secret key that resides on the server.

Protection of this key is critical. Unauthorized access to the key allows for arbitrary modification of claims stored within the payload, which in turn opens the door for unintended use. We will see an example of this in the IoT platform that was the subject of the research, ThingsBoard.

ThingsBoard

Like many web applications, ThingsBoard makes use of JSON Web Tokens for user authentication and authorization. These tokens identify the user account and define what tenants that user can access. It is intended that these claims about the user are set by the server which assigns the token and are then protected from tempering through the inclusion of the digital signature. If the signature is valid, any claims included in the payload will be assumed valid and therefore trusted by the server. In cases where a strong secret key is used, this system is generally secure.

However, during a review of the ThingsBoard source code, a static default secret key was discovered.

Using this key, it is possible to re-sign JWTs that have been modified, before sending them back to the server for validation. The signature will appear to be valid, as it was generated using the correct key, and thus the server will trust the claims made in the payload. One such claim made in the ThingsBoard platform is the role of the logged-in user account.

By editing this role value and generating a new, valid signature for the payload, a user can escalate privileges within the platform to the highest level. This grants access throughout the entirety of the platform, including other tenants, users, and devices not affiliated with the original account.

Because ThingsBoard allowed the default key to be used without requiring administrators to change it, and because that default key was also exposed publicly in the configuration files, the door was opened for attackers to gain unauthorized access in excess of what is intended.

Conclusion

IBM X-Force has brought this issue to the attention of the developers, and as of ThingsBoard version 3.4.2 a new system has been implemented. Rather than using a hardcoded default key, ThingsBoard will now generate a random secret key for new deployments and upgrades. There is no patch for earlier versions, so an update to version 3.4.2+ is recommended.

On existing deployments where updating may be a lengthy process, administrators are encouraged to check the secret key and ensure that it has not been left as the default string. This can be done either directly through the configuration file or through the System Administrator dashboard.

ThingsBoard is just one among many IoT Platforms which, much like the devices that connect to them, all deserve further research and scrutiny. Adoption of IoT devices in all industries will only continue to grow, and with it the need to ensure security in the platforms managing devices and collecting data. The conversation has been started, what will you do to be a part of it?

More from Offensive Security

AI vs. human deceit: Unravelling the new age of phishing tactics

7 min read - Attackers seem to innovate nearly as fast as technology develops. Day by day, both technology and threats surge forward. Now, as we enter the AI era, machines not only mimic human behavior but also permeate nearly every facet of our lives. Yet, despite the mounting anxiety about AI’s implications, the full extent of its potential misuse by attackers is largely unknown. To better understand how attackers can capitalize on generative AI, we conducted a research project that sheds light on…

When the absence of noise becomes signal: Defensive considerations for Lazarus FudModule

7 min read - In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Containers, security and risks within containerized environments

4 min read - Applications have historically been deployed and created in a manner reminiscent of classic shopping malls. First, a developer builds the mall, then creates the various stores inside. The stores conform to the dimensions of the mall and operate within its floor plan. In older approaches to application development, a developer would have a targeted system or set of systems for which they intend to create an application. This targeted system would be the mall. Then, when building the application, they would…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today