Vembu Storegrid Security Exploit Published – All Storegrid Users at Risk
Those of you who read my blog regularly (my mom and my aunt Clara) might think I’m a bit overboard with the Vembu articles. I’ve been warning you about this Storegrid software for years – warning that it is insecure and dangerous – installing it can cause harm to users’ data and seriously compromise their network security.
Now the details of a very simple exploit that places all Vembu Storegrid end users and Partners at great risk for data theft and network penetration has been made public.
Even as I warned about this issue, people just kept buying Storegrid and risking their businesses on a shaky product. They didn’t seem to care that they were putting their users at risk. Even after a security firm publically disclosed these risks and vulnerabilities in August of 2014, people kept buying and deploying Storegrid.
I suggested removing the product immediately because its vulnerabilities could easily cause serious legal problems for the consultants who deploy it and for the firms who use it. This software is usually branded by the consultants who deploy it. Who do you think is going to get sued when users’ networks are compromised and data stolen? The company whose name is on it!
I warned that the security company who discovered and first published these problems would eventually publish exact instructions on how to compromise a Vembu Storegrid installation unless Vembu fixed the problems, thereby making ALL Storegrid end users easy targets – sitting ducks for any noob hacker who wants to try his hand at something really easy.
Vembu discontinued the Storegrid product after the security revelations, and after refusing to correct its problems, publically denied that they exist. As a result of their inaction, the entire exploit (just one of several, with more to come) has just been published on the very popular public forum called WebHosting Talk, and now you (and everyone else) can read it.
This is now a very serious matter for former Vembu partners, putting them at very high risk of serious legal action, and at the very least, at risk of damaging their reputations when their end users find out about this and ask, “Did you install this on our computers? Is it STILL here?”
End users will not sue an obscure little company in India, 8,000 miles away. They’re going to sue you, with your logo on the software, right here where you live.
Yes, Vembu was in competition with my company, and if it weren’t for my reputation as a staunch and vocal advocate of great Online Backup software (and not just mine), these articles would be considered bad form for attacking a competitor in print.
But it’s a dangerous situation, and now everyone knows it. The cat is out of the bag, and former Vembu partners need to immediately stop “swapping MCALs”, stop discussing which “software to use” and instead, get this software off your end users’ networks – immediately!
Replace it with something – anything. I hope you replace it with my RBackup, but do replace it with something, and quickly.
Here is a link to the post over at WebHosting Talk.
Here’s the most recent article, copied verbatim:
I am one of the consultants who published the issues with Storegrid earlier this month. We are a seasoned security company based in the UK and specialise in Penetration testing, Incident response, digital forensics, secure coding reviews, and development. The team I lead on this engagement have over 25 years cumulative experience in information security and hold a wide range of certifications and commendations in the field.
To anybody that wants the details:We discovered these issues on a production network which had been configured by Vembu partners. We highlighted this in several emails to Vembu AND our original disclosure. We have since tested these findings on several configurations across 4 different versions and all were vulnerable. The “trial” we tested was additional to the initial discovery and only to see if they had fixed them.
It is worth noting that even a “trial” is expected to be secure. This is the version that gets installed the most!! I hate to think how many people out there have this software installed, but the vendor states that 25,000+ businesses use their products!!
The response by Len at Vembu is misleading, It seems he does not understand the nature of the issues.
here are the steps you need to recreate our findings:
NOTE: NO CREDENTIALS ARE NEEDED TO PERFORM THIS ATTACK, THE ONLY REQUIREMENT IS THAT YOU CAN ACCESS PORT 6060 OF THE TARGET CLIENT MACHINE. WE HAVE WITNESSED SHARED MACHINES RUNNING THIS SOFTWARE IN PUBLIC AREAS, UNIVERSITIES USING IT, AS WELL AS ROAMING CLIENTS CONNECTED TO COFFEE SHOP WIRELESS NETWORKS SO THE EXCUSE OF “BUT THEY ARE BEHIND A FIREWALL” IS TERRIBLE.. ALSO, BAD GUYS WORK IN OFFICES TOO
To validate the main finding do the following:
– Install the client software as you would normally.
– Configure it to use a genuine server.
– Change the admin password to something extremely secure.
– Log out
– Now set up another server to act as a bad guy server. Ensure automatic enrolment is active.
– Open the browser here: http://clientip:6060
– Click the sign up link beneath the login box (DO NO LOG IN) or visit http://clientip:6060/xchangeoptions.sgp?xopt=19 if the link is not visible.
– Enter the customer ID/Key available from your bad guy server and set a password. (record the username and password as you will use these later to log in!!)
– Once the enrolment process is complete, try to log into the client with the new credentials. This may or may not work depending on the client settings.
– If it works then you now have full access to the system.
– If it fails, visit the following address in your browser: https://badserverip:6061/index.php?cln=clientip
– Now sign in with the new credentials. You will be authenticated with the client as a NEW administrator and can create backup jobs as well as specify your own encryption keys.AES256 means nothing if the attacker has set the encryption key!!
When a client is registered to a new backup server, a new admin level account is created on the client. the problem is, you don’t need to log in to add a new backup server (Logic fail).
The restore process can be also be utilised to infect a machine with malware, or deploy an attackers toolkit. As the application runs at system level by default, you have the ability to execute your evil software with “system” privs (by making use of the pre-backup commands function when creating a backup job). Once a single machine has been compromised it is possible to configure it to connect to an external server and use to attack other machines inside the network (ie, once the coffee shop guy goes into the office).
To validate the source-code disclosure just add a trailing slash to a url like so: http://clientip:6060/index.php/
This is absolutely nothing like clicking view source on a web page. these PHP files contain the specific configuration for the product as performed by the distributor.
Whilst it IS possible to view the source on the local machine, it is also possible to obfuscate the code so no user can make sense of it. this does not excuse poor coding practices.
The MySQL database for the windows client has the following credentials:
User: root
Password: adminThis means a standard low privileged user can easily extract the password hashes of any account (including those of the backup provider aka you guys) and crack them offline. the algorithm used is MD5. We performed a rainbow table attack against on of the passwords used in a production network and broke it in a matter of minutes.
Once equipped with these credentials there is a risk that all or some of the machines on the network will have the same credentials, and that they may even be used on the backup and replication servers.
As far as we can see through some very quick testing of the latest version, these issues are still present in version 2.0.0 (the latest version released 14/08/2014)
The vendor seems to reject the idea that these issues are a significant problem and by all means make your own decisions, but remember, when one of your customers loses their network and all of its data to an attacker and Storegrid is found to be the source, the client will most likely point the legal big guns at the person that sold it them. After all.. If you have configured it, it probably has your logo on it.
