Zero Science Lab

The application is vulnerable to improper access control that allows an authenticated operator to disclose SHA1 password hashes (client-side) of other users/operators.

The SCADA controller is vulnerable to unauthenticated file write/overwrite and delete vulnerability. This allows an attacker to execute critical file CRUD operations on the device that can potentially allow system access and impact availability.

The weakness is caused due to the login script and how it verifies provided credentials. An attacker can use this weakness to enumerate valid users on the affected application via 'txtUsrName' POST parameter.

The application is prone to a DoS after receiving a long server response (more than 2K bytes) leading to 100% CPU consumption.

The application allows directory listing and information disclosure of some sensitive files that can allow an attacker to leverage the disclosed information and gain full BMS access.

Unauthenticated Server-Side Request Forgery (SSRF) and Remote File Include (RFI) vulnerability exists in OpenBMCS within its functionalities. The application parses user supplied data in the POST parameter 'ip' to query a server IP on port 81 by default. Since no validation is carried out on the parameter, an attacker can specify an external domain and force the application to make an HTTP request to an arbitrary destination host. This can be used by an external attacker for example to bypass firewalls and initiate a service and network enumeration on the internal network through the affected application, allows hijacking the current session of the user, execute cross-site scripting code or changing the look of the page and content modification on current display.

The application suffers from an insecure permissions and privilege escalation vulnerability. A regular user can create administrative users and/or elevate her privileges by sending an HTTP POST request to specific PHP scripts in '/plugins/useradmin/' directory.

OpenBMCS suffers from an SQL Injection vulnerability. Input passed via the 'id' GET parameter is not properly sanitised before being returned to the user or used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

The application interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform certain actions with administrative privileges if a logged-in user visits a malicious web site.

The application doesn't allow creation of more than one administrator account on the system. This also applies for deletion of the administrative account. The logic behind this restriction can be bypassed by parameter manipulation using dangerous verbs like PUT and DELETE and improper server-side validation. Once a normal account with 'viewer' or 'operator' permissions has been added by the default admin user 'i3admin', a PUT request can be issued calling the 'UserPermission' endpoint with the ID of created account and set it to 'admin' userType, successfully adding a second administrative account.