In the context of my thesis where the topic was role-based access control for openHAB users, I implemented the beginning of the RBAC model in openHAB in this fork at the
Groups (of roles) and roles are managed in openHAB, where each user contains roles and groups. Users, groups, roles are stored persistently in registries. Each group contains roles. Each role contains Item names that are unique. An Item name identifies an Item. An Item represents a resource of the platform. Therefore, the set of Item names within a role
specifies the authorized resources (Items) that the role will assign to users who own the role.
Roles and role groups can be assigned to a user with the
openhab:users command and the
openhab:ac command. Functions have been added to the
openhab:users command and the
openhab:ac command did not exist and thus has been added. The main interface has also been modified a bit to see the available users with their roles and groups, the available groups, and the available roles.
OpenHAB uses JWT to manage the access control of the platform. For each request from a user (client side) made to openHAB (server side), the JWT is checked, and the user’s name is extracted from the JWT payload. With the user’s username, the groups and roles that belong to the user can be obtained. With the obtained groups and roles, the Item names are collected to know which Items (resources) should be returned to the user. The user (on the client side) will only see in his interface the resources that correspond to his authorized elements. As a result of this filter and the management of roles and groups in openHAB, the role-based access control model has been incorporated into openHAB.
The code is not yet clean for a pull request and all HTTP requests for items are not yet handled (but for the most part yes). A video has been made to summarize what has been done at this link. A scenario has been configured which is a house with a family where the user with the administrator role is the father and the three children have the role of user. The scenario shows the usefulness of the RBAC model in openHAB. In fact, each child can only have access to his or her own devices because the father has configured openHAB’s access control with roles and groups such that each child can only access his or her own smart home devices.
By implementing the RBAC model in openHAB, some potential vulnerabilities were found, and should be fixed, and announced and explained as follows:
The functions of the
openah:userscommand in the openHAB console allow a user to delete an openHAB user or create an openHAB user. These actions can be performed by any user with access to the smart home openHAB console. So, let’s assume that a user with the least privilege in the platform or even a malicious person knows the password of the openHAB console (by default it is habopen and can be changed) and manages to reach it. He will be able to delete users with the administrator role and create a new user with the administrator role whose password he knows. As a result, the single user or malicious person removes all access of the users with the highest privilege and gets all access to the platform. This security vulnerability should be fixed by asking for the password and username of an openHAB user with the administrator role (this is implemented in this fork). Additionally (this is not implemented in the fork), a check that the parse string (which contains the username and password) contains only alphabetic numbers and letters should be done to add protection against the buffer overflow attack.
The password sent by a user to the platform is not hashed. Therefore, a person can scan the smart home’s local network and retrieve the password of the user who may be a user with the role of administrator. To prove this security vulnerability, the local network where an instance of openHAB is running was scanned with Wireshark and as shown in the Figure below, the password of the user nico can be obtained. To solve this security problem, the password must be hashed on the client-side and the server-side must store the hashed password and verify the password with the hashes. \
JWTs are used by openHAB to authenticate each request of openHAB users. Therefore the JWT must be checked for each request made by a user of openHAB. However, in openHAB, a user’s JWT is checked only when the client-side page is refreshed. Therefore, anyone can forge an HTTP request and send it to the server to get information about the smart home for example. The server will accept the HTTP request because it does not check the JWT in the HTTP request header. In the fork where the RBAC model has been implemented (see the code here), the security vulnerability has been fixed for HTTP methods that are used and managed to handle RBAC for openHAB users but have not been fixed for all HTTP methods used and managed by openHAB.
The user (client-side) has to verify the JWT put in the HTTP response with the RSA public key that matches the RSA private key used by openHAB (server-side) to generate the JWTs. With this verification, the user (client-side) can be sure that the HTTP response is coming from openHAB (server-side). However, the client does not receive the RSA public key to verify the JWT in the HTTP response header. Therefore, anyone can forge and send a fake HTTP response to a user (client-side) and the user will accept the fake HTTP response because the JWT in the HTTP response header is not verified. To solve this security problem, the user (client-side) must receive the RSA public key used by openHAB (server-side) to generate the JWT. Then, the user (client-side) must verify the JWT in every HTTP response received by openHAB (server-side).
However, a malicious person is able to exploit any of the above security vulnerabilities only if he/she has access to the local network where openHAB is running. Considering that the local network is a network with the minimum security that is required. In order to access the local network, the user needs to know the Wi-Fi password of the local network. Furthermore, the local network is protected by a firewall. In addition, HTTPS can be used in openHAB. So if HTTPS is used, (for the second security vulnerability listed above) the password cannot be recovered but it is still better to send and handle passwords that are hashed, and (for the fourth security vulnerability listed above) the client side will not accept incoming fake HTTP responses because of the HTTPS connection. However, even with HTTPS, the third vulnerability (among those listed above) can be realized because the server accepts HTTP requests. In this link in the openHAB documentation, it says that it is vitally important that the openHAB instance is not exposed to the internet because there is no authentication in place for the users and surely because of the potential security vulnerability found.
To conclude, fixing these security vulnerabilities should be a contribution that should be made to openHAB. I plan to put the written thesis in a reply to this post once the defense is done.
Enjoy the video. (here)
Thanks to the help of the openHAB community where it would not have been possible to achieve what I did.
EDIT: You can find my thesis at this link: https://dial.uclouvain.be/downloader/downloader_thesis.php?pid=thesis:35683&datastream=PDF_01&key=25873d79b4fff20bac82323f43c9b3e9