Today, Fortra is publishing two zero-day vulnerabilities found in the Veritas InfoScale Operations Manager that our vulnerability research team discovered and brought to the attention of Veritas. Veritas has been extremely professional and worked diligently with Digital Defense engineering staff to understand, resolve and verify the fixes for these security issues.
Veritas has released fixes for the issues.
Contact Veritas technical support to obtain the patch. [https://www.veritas.com/support/en_US.html]
Clients who currently use our Fortra VM platform, or prospects using our trial-system to check their external networks, can sweep for the presence of all of these issues by performing a full vulnerability assessment scan.
Details of the vulnerabilities are as follows:
Vendor: Veritas
Product: InfoScale Operations Manager
Versions: Tested on 7.0 and 7.1
Link: https://www.veritas.com/en/uk/form/trialware/infoscale-operations-manager
Brief product description: Veritas InfoScale Operations Manager is a graphical management framework that provides centralized visibility and control to all InfoScale products.
Summary:
- DDI-VRT-2016-67: Authenticated Remote Command Execution in pl
- DDI-VRT-2016-68: Unauthenticated Blind SQL Injection in dbsync.pl
Details:
Vulnerability: Authenticated Command Injection in add_host.pl (Tested when management server is installed on Linux)
Internal Tracking ID: DDI-VRT-2016-67: Authenticated Remote Command Execution in add_host.pl
Impact: Arbitrary command execution with the same privileges as the "xprtld" process, which runs as root on Linux. Full compromise of the system hosting InfoScale Operations Manager.
Attack scenario: An unprivileged user on the Linux host running InfoScale Operations Manager, but with Admin access to the "Management server" perspective could use this vulnerability to escalate privileges to root. Alternatively, if LDAP authentication is used, a user with no direct access to the host running InfoScale Operations Manager (no user account on the local Linux system) could use this vulnerability to fully compromise this host.
Details: Users with the "Admin" role for the "Management server" perspective can remotely install the managed host package via the web interface on port 14161. The user could be an unprivileged user on the system hosting the InfoScale Operations Manager or it can be any LDAP user that is configured with the "Admin" role for the "Management server" perspective. The vulnerability can be exploited by navigating to the Settings > Add Hosts > Agent page and selecting Install managed host package on Linux/Unix and check the box for "Use root password". The command injection vulnerability is in the "Root Password" field. The injection can be submitted via the web interface with no additional tools required, simply submit the command inside backticks via the "Root Password" field and click "Finish". The supplied host, username, password and root password are then passed to the "xprtld" process via a HTTP POST request to port 5634 at the following path /admin/cgi-bin/add_host.pl. Then add_host.pl attempts to run the mh_installer.pl with the attacker controlled arguments without sanitizing the "--supassword" command line parameter ($supassword variable in add_host.pl). The command is then executed before being processed by mh_installer.pl.
Vulnerability: Unauthenticated Blind SQL Injection in dbsync.pl
Internal Tracking ID: DDI-VRT-2016-68: Unauthenticated Blind SQL Injection in dbsync.pl
Impact: Remote code execution as an unprivileged user when the manager is installed on Linux and remote code execution as SYSTEM when installed on Windows. This results in complete host compromise when the manager is installed on Windows.
Details: The InfoScale Operations Manager has a web management interface running on port 14161 that requires a user to login before accessing additional functionality. The SQL injection can be triggered via a crafted HTTP POST request to the login form where the SQL injection payload is URL encoded and appended to the domain name. When the HTTP POST request is submitted, a message containing the who (username, domain + SQL injection), what (login), where (IP address of user), why (login) is logged to "audit.msg" via the "logit" function in Audit.pm, no sanitization is performed on user supplied data by the "logit" function. Every 5 minutes "audit.msg" is read and truncated by the "_add_audit_records" function in JSONReporter.pm which converts the "audit.msg" entry into JSON format which includes the database table and columns names for the audit entry. No sanitization is done on user controlled data in this function before the JSON formatted data is written to a file. After this, dbsync.pl takes the JSON formatted data and passes it to the "convert_to_sql" in Canonical.pm, which does no sanitization on the user supplied data before writing it to a ".sql" file. dbsync.pl then attempts to use the ".sql" file created by the "convert_to_sql" function to insert the data into the database using the "xdbadm" binary which is when the SQL injection payload is executed. The SQL injection can be used to run arbitrary OS commands and/or write a Perl script to disk and execute it with the same privileges as the PostgreSQL database process.