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.Ducheminat_private (| c3rb3rat_private) Have a nice day.
This archive was generated by hypermail 2b30 : Fri Apr 19 2002 - 13:59:42 PDT