Xpede C00kb00k



// Note


As mentionned below in the "vendor status" section, i did not get any
reply after 3 mails, asking
for acknowledgment and an amount of working time expected before an
official patch release.
Well, at that time i still have no idea if intellisol/workforceroi is
currently working on these problems
and if any patch will see the light of day soon.(i feel skeptic about
it)
for this reason, there won't be any proof of concept attached but i
wrote some details
to help xpede users to well understand the vulnerabilities exposed and
perhaps,
to find better ideas than i did to mitigate the risk.


// About Xpede


quote from http://www.workforceroi.com/solutions/pa/index.shtml

"Intellisol Xpede is a browser-based time and expense entry and project
cost management module designed to connect a remote workforce on a
real-time basis.
Intellisol Project Accounting is designed for any professional service
organization such as consulting, software development, law,
architecture,
engineering, PR/advertising and more with between 10 and 500 million
dollars in revenue and up to 500 employees,
and integrates with Microsoft Great Plains Business Solutions financial
suites. "


// Overview


During my short survey of Xpede 4.1 security, i found several
additionnal serious vulnerabilities
both in the product design and its implementation.

Xpede database containing /users timesheets/expense claims/projects
details/customers names/,
the underlying mssql server and finally admin/users identity
can be remotely compromised in many ways detailed in the next section.
Note that all vulnerabilities described are remotely exploitable and
that except for vuln 2 & 4, all vulnerabilities
need a valid user asp session (cookie) before being triggered.
However a valid cookie/credential can be find in many ways, by using
either some well known browsers
vulnerabilities or may be the Xpede clientside vulnerabilities i
described in previous posts to bugtraq:

- http://online.securityfocus.com/bid/4346 (account password revealed in
re-authentication popup)
- http://online.securityfocus.com/bid/4344 (account password weak
encryption in cookie)

Additionnaly, please note that Xpede automatically assign a default
password "access" to all freshly created accounts
without demanding users to change it, and indeed, chances to takeover
some of them with "access"
are quite real.


// Details


/ Vuln 1

 Access to the /admin directory is not ACL restricted by default (no
related reference found in Xpede documentation)
and anyone with a valid regular (Xpede user) account can issue some
requests to the Xpede's administration tools
like /admin/adminproc.asp

 Because adminproc.asp omit to require any administrative authorizations

before issuing any sql request, a request from a regular xpede account
and directed to /admin/adminproc.asp
without parameter enumerates all users accounts giving their
usernames/email/full name.
A good start for social/engineering and account attacks.

 worse, /admin/adminproc.asp perform most of the administration tasks
and offers to change/delete/add users profiles and passwords.
While authenticated as a regular user, it is possible to issue malicious
requests
to takeover admin and other users accounts, to steal project managers
rights and to change account informations.
adminproc.asp will act as a gateway for the xpede sql stored procedures
that actually perform the changes.

Xpede seems to naively rely on the aspsession (for authentication) and a
good user behavior baseline (no authorization management).



/ Vuln 2

 An anonymous (no cookie, no xpede account needed) request to
/admin/datasource.asp shows an html form revealing the sql account name
used by xpede
to perform all the sql stuff it needs.
The formular offers to change the account password and, while
fortunately asking for an old password before validating, it still open
an opportunity
for bruteforce attacks.
the potential lose of the sql account password would then give a chance
for an intruder to mess with the underlying sqlserver and corporate
databases
if not placed behind a well configured firewall.


/ Vuln 3

     utils/sprc.asp is a regular vbscript used by every users to perform
various timesheets related tasks.
A very dangerous option "Qry" in sprc.asp offers to inject litteral sql
commands through the script and to the mssql server.
A regular user can do almost anything within the corporate databases
calling sprc.asp with this option.
 For instance, while every xpede users passwords including admin are
stored in the XPD00002 table inside the DYNAMICS database, an intruder
injecting a request like SELECT * FROM DYNAMICS..XPD00002 retrieve an
exhaustive list of all xpede passwords including ADMIN and
allow the attacker to unpersonate anyone inside the company.
He can also try to take advantage of various possible misconfigurations
and vulnerabilities to root the mssql database server,
and can access/destroy/change the company customers list, projects
details, financial informations stored in other databases as well
etc...
Consequences would be even more disastrous with "sa" as the xpede sql
user (never do that with any non trusted application anyway).



/ Vuln 4

 When a user submits an expense claim, xpede save it in the temporary
directory /reports/temp.
this directory, at least, should obviously not be indexable althougth i
found no documentation related to that point.
For security reasons, filenames are "randomly" crafted, begining with
the fixed string "expenserpt" followed by 5 random chars and a .htm
suffix.
this 5 chars are choosen within the regex class [0-9A-F] giving
something like expenserpt0AF4E.htm for instance.
Anyone is allowed to anonymously download these files and even if
obfuscated (indexing off),
is able to launch a bruteforce attack on a filename basis trying to
exhaust all the 1 048 576 combinaisons.
This expense claims may contains interresting informations like
project/user informations/customers and can be exploited for
social engineering as well.


/ Vuln 5

 After submiting a timesheet with xpede, a user has to sign it before
his/her project manager to approve it.
At this point the user is shown a screen displaying the new timesheet
details to be signed through the ts_app.htm page (called by
ts_app_process.asp).
A vulnerability exists in ts_app_process.asp used to
display/sign/approve etc.. timesheets because of a lack of authorization
checkup
and can be exploited to display other users timesheets by modifying the
TSN parameter in the URI with the following syntax:
http://xpede.target.com/approval/ts_app.htm?TSN=anyTSNnumber
where TSN number is a global timesheet index incremented by one after
each new timesheet submission, whoever made it,
therefore it is trivial to find valid index starting from the current
TSN value and by decrementing it.
A valid TSN index will reveal /project names/working hours/price rate/
on a daily basis of the employee who submited it.


// Temporary workarounds

Despite the fact that most of these vulnerabilities actually need the
asp files to be fixed and that obviously the whole product need
a bunch of modifications in its global design for accessing data, i try
some possible workarounds to help mitigate the risk.

Note that vuln 1 & 3 may be the two most dangerous vulnerabilities u may
wish to fix right now.

All Vuln

Don't use any priviledged sql user (forget sa) and create a specific
regular user for xpede database (as usual).
supress any right for this user to access other databases.
Ensure you have patched your mssql server against xp formatstrings
attacks and that authorizations for master..xprocedures are set.
Protect your mssql server behind a firewall and disallow the port number
it is binded on from outside requests.
moreover, I would suggest to use NTLM1 authentication on the whole web
site to ensure that "NT authenticated" users are accessing
the system rather than only relying on xpede authentication process.
In this manner you will probably limit the potential risk to your
population of legitimate users.

Vuln 1 & 2

Change permissions for /admin directory, use NTLM1 authentication and
give only access to the "Xpede admin" NT account.
Choose a hard to guess password for your xpede sql account (for
datasource.asp vuln).


Vuln 3

 utils/sprc.asp can be called for various reasons during a usual user
session and i'm not really sure of the best approach to use.
hope intellisol will patch it soon.



Vuln 4

Disallow index browsing on the whole site, especially true for
/reports/temp/,
filter all requests directed to /reports/temp from your firewall if any,
nids or your web server when possible.
or simply don't use claims feature if u still feel at risk.
it may be possible to write a little batch to clean the directory on a
regular and short time basis without interfering with xpede.


Vuln 5

no idea at date because ts_app_process.asp and TSN numbers are necessary
for thimesheets overall process
and because of the incremental nature of Timesheet numbers, filtering
seems quite impossible.
Waiting for a patch.


Weak 1

for the "default 'access' password" weakness, it may be usefull to write
a scheduled piece of sql code to help find all emails of "access"
passworded accounts
through DYNAMICS..XPD00002 database, to warn people by email when
necessary (and eventually to freeze accounts after a short period by
replacing 'access'
with a 'hard to guess' password).





// Vendor status


Intellisol/workforceroi support team was contacted by three times, on
April 4 & 5 and 15,
but did not reply.



// Versions


Xpede 4.1 suffers all vulnerabilities reported in this paper.
As far, i dunno if 7.x serie suffers them as well.
input would be appreciated.


// Author & Date


Gregory Duchemin // 16 Aprl. 02

TELUS solutions d'affaires Inc.
111, rue Duke
Bureau 4200
Montreal (Quebec)
H3C 2M1

Gregory.Duchemin@telus.com (| c3rb3r@hotmail.com)




Have a nice day.