COMMAND

	Xpede multiple remote vulnerabilities

SYSTEMS AFFECTED

	Xpede 4.1

PROBLEM

	In Gregory Duchemin [http://www.telus.com] advisory :
	

	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.
	

	

	 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 even, /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.

SOLUTION

	 Workarounds

	 ===========

	

	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.
	

	 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.
	

	 Weak initial password

	 =====================

	

	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).