Message-ID: <CAL58m2WWhdnXYHT6ByCvRQdP=9nhJq8Qn7kksc3Y_k=Taar_pw@mail.gmail.com>
Date: Wed, 6 Aug 2014 13:35:16 -0700
From: Len Srinivasan <len@...bu.com>
To: fulldisclosure@...lists.org
Subject: [FD] Vulnerabilities in Vembu Backup and Disaster Recovery addressed

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=<ip/hostname> 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

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists