The company logically secure has mentioned about multiple vulnerabilities in Vembu Backup and Disaster Recovery product and we would like to address those concerns in detail. We certainly welcome security related feedback on the product as we are constantly addressing those on a regular basis as we receive feedback from partners. But the researchers analyzing the product should possess "basic domain knowledge" on the products that are being reviewed. Based on the analysis done by Logically Secure team, it seems they lack knowledge on how the product is actually used in our customer's environment and don't have a clue about how Backup and Disaster Recovery is actually deployed. Company Name : Vembu Technologies Inc Product Name : Vembu Backup and Disaster Recovery Release Version : 6.1 Website : www.vembu.com Subject : Addressing Concerns from Logically Secure team *Concern 1:* 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= get parameter which invokes request forwarding functionality allowing access the remote client interface. ​ *Answer: * This whole exploit is possible only when the remote user knows the username and password for the client web console. While reviewing this vulnerability, the user used a trial version of our product where we have the default username / password as admin and admin​, which the users can of course change while installation. In production version, we encourage our partners to specify a strong username and password and with that specified the whole vulnerability mentioned above is not possible. *​Concern2* : ​ In addition to the above mentioned issue we discovered reflected XSS vulnerabilities, Source code disclosure via incorrect processing of trailing slash (eghttp://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. *Answer : *Again another concern without understanding the nature of vulnerability. The source code that is revealed on the client side via incorrect processing of trailing is the PHP source code which basically handles the UI of our product. It doesn't even bother the application. In fact PHP codes gets bundled with the product already and one can open those codes easily from accessing our PHP folder. The answer is, you cannot do anything with those codes. You can even view these codes by simply right clicking and click 'View Source Code'. This is just UI and not the application. Again the password for MySQL, Storage Credentials (MD5) is all configurable by the end user when using the product. In order to facilitate easy evaluation of the software we can used some default values in the product which can be changed if the user wants. Our product is flexible and allows users to configure security parameters before beginning to use the product in production version. If the reviewer used a trial version of our product with default values and says that the product is not secure only shows the ignorance of the reviewer. Our product uses AES - 256 encryption algorithm for encrypting all data on the client side and it is encryption at transit and at rest. If the reviewer can break AES - 256 and tell us that this algorithm is vulnerable, we would be concerned. Otherwise there is not point in being concerned about our product is being flexible. Please feel free to contact Vembu for more questions regarding this. Regards, Len