Multiple vulnerabilities exist in the Vembu Storegrid Backup and Disaster Recovery solution affecting both the client and server software (see Additional Information section) include but are not limited to reflected XSS, source code/sensitive information disclosure, privilege escalation, remote code execution, Denial of Service, and poorly implemented business logic in the client which can be leveraged to allow an unauthenticated user to exfiltrate full disk backups from a target machine via a rogue server. This is a white-label product and may be labelled as something else.
None, however Issues may be addressed in version 6.2 (vendor reviewing the feasibility of a patch)
The main vulnerability takes advantage of the client enrolment procedure. In it?s default state it is possible for an unauthenticated attacker to register a client to a rogue backup server. During this enrolment phase a new admin user is automatically created on the client using the attacker specified credentials, the attacker can then bounce through their rogue server using the cln=<ip/hostname> get parameter which invokes request forwarding functionality allowing access the remote client interface. From here they can schedule their own backups to their server and specify their own encryption keys. These backups can then be restored to an attacker controlled virtual machine allowing the attacker full access to whatever has been taken. It is also possible to backup a directory containing a toolbox of malicious scripts and executables from the attacker controlled virtual machine and restore these to a target machine. We found an option in the client web interface which allows a user to disable the ability to enrol new servers but were able to bypass this using common attack vectors.
The backup functionality also allows the user to execute commands as part of the backup process by default these run with system level privs. We have successfully gained system level remote shells using this method. From there we were able to manipulate the web console to hide all traces of our exploits from the regular user, kill AV, drop the firewall, access the registry, dump password hashes and finally screw up the machine (by deleting arbitrary system files) so it wouldn?t boot and needed restoring (thus removing traces of our activity).
The whole process could easily be automated to target an entire subnet.
In addition to the above mentioned issue we discovered reflected XSS vulnerabilities, Source code disclosure via incorrect processing of trailing slash (eg http://clientip/index.php/), Denial of Service via unhandled exceptions in the client, Local privilege escalation, insecure storage of credentials (MD5), poor mysql implementation (default root user configured with a simple password), and several others.
Note: We first discovered the vulnerabilities whilst testing a corporate network with around 60 active installs of the client software ranging from domain controllers to HR machines, and client laptops containing personal data. We were able to siphon off any data we liked. The client supports our decision to go public now they have removed the software.
We will be providing a full writeup as well as examples on our website shortly.
Note2: This software is white-label and is commonly distributed under many names.
Note3: According to the vendor they have a network of over 3000+ partners holding over 25PB of critical data.
@mantcliffe @EdTredgett @LogicallySecure