-----BEGIN PGP SIGNED MESSAGE-----
PR07-31: Unauthenticated SQL Injection, XSS and Username Enumeration on
DPSnet Case Progress
Vulnerabilities Found: 23 May 2007
Vendor Contacted: 10 July 2007, 31 August 2007, 17 September 2007, 12
Note: the vendor stopped responding on 31 August 2007
Product description from vendor's site :
Progress is an internet based product which enables all parties involved
in a matter, such as clients, work providers, estate agents, brokers or
solicitors to look up and track all matter details, including WIP,
accounting information, actions taken and the progress being made on all
case management files over the Internet, 24 hours a day, 7 days a week.
Through a link from your firms own website or the DPS website, all
parties can log on to Progress and view a report of each matter. How
much each party can view of the progressed details made on a matter and
then subsequently published to the Internet is strictly controlled by
the solicitor through a secure internet link.
Unauthenticated SQL Injection:
Client input is being used to generate queries passed to the backend
database server. This input is not sufficiently sanitized before being
passed to the backend database server. As a result, a malicious user may
be able to craft queries that will be run on the backend database server
without any authentication, leading to sensitive information such as
administrator passwords being retrieved.
SQL injection can have very serious consequences, such as the bypassing
of authentication, querying/modifying/adding/deleting data from the
backend database and the remote execution of programs.
NO authentication is required to exploit this vulnerability.
XSS on login page:
DPSnet Case Progress is vulnerable to a vanilla XSS within the
"password" parameter processed by the login server-side script. The
victim user does NOT need to be authenticated for this vulnerability to
An attacker may be able to cause execution of malicious scripting code
in the browser of a user who clicks on a link to DPSnet Case Progress.
This type of attack can result in non-persistent defacement of the
target site, or the redirection of confidential information to
unauthorized third parties.
The login facility available on DPSnet Case Progress allows attackers to
enumerate existing usernames through manual username-guessing and
automated dictionary attacks.
Attackers can feasibly guess valid usernames provided that usernames are
predictable (i.e.: [dictionary_word], [number]).
This kind of attack will most likely be launched by attackers who want
to identify administrative usernames that have elevated privileges on
DPSnet Case Progress.
SQL injection proof of concept:
The following request dumps the first username in the current table
(which appeared to be the admin user during a penetration test):
SQL error returned (notice the username 'adminuser'):
"Syntax error converting the varchar value 'adminuser' to a column of
data type int."
SQL error returned (notice the password 'p4ssw0rd!!'):
"Syntax error converting the varchar value 'p4ssw0rd!!' to a column of
data type int."
The following PoC script dumps usernames and passwords:
XSS proof of concept:
Provided the victim is tricked to load the following URL, the
credentials would be sent to a third-party site (procheckup.com in this
case) when clicking on the login button.
Username enumeration proof of concept:
Submitting an invalid username, i.e.:
"The user name you have supplied is incorrect."
Providing a valid username, i.e.:
"Invalid password, please try again."
Affected Version: Unknown due to lack of response from vendor
Unauthenticated SQL Injection fix:
Ensure all data originating from a client request is adequately filtered
before being passed to the back-end database server. Special characters
such as quotation marks, apostrophes, semi-colons and hyphens should
particularly be filtered. Follow a white-listing input validation
approach whenever possible.
Since there is no patch available from the vendor, it is recommended to
enforce password authentication at the web server level, so that the
vulnerable script cannot be probed by anonymous users.
XSS on login page fix:
Ensure all input is filtered sufficiently before being echoed back to
the client. In particular, characters such as left and right angle
brackets, quotation marks, apostrophes and ampersands should be
filtered. It is highly recommended to follow a white-listing input
validation approach whenever possible.
Username enumeration fix:
Change error messages so that attackers cannot determine if the username
entered already exists. i.e. "Authentication failure: username/password
combination is incorrect."
ProCheckUp Security Vulnerabilities and Advisories:
Credits: Adrian Pastor of ProCheckUp Ltd (www.procheckup.com)
Copyright 2008 Procheckup Ltd. All rights reserved.
Permission is granted for copying and circulating this Bulletin to the
Internet community for the purpose of alerting them to problems, if and
only if, the Bulletin is not edited or changed in any way, is
attributed to Procheckup, and provided such reproduction and/or
distribution is performed for non-commercial purposes.
Any other use of this information is prohibited. Procheckup is not
liable for any misuse of this information by any third party.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----