Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Cerberus Vulgaris (c3rb3rsympatico.ca)
Date: Fri Apr 19 2002 - 10:46:23 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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
    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
    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,
    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
    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
    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
    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
    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
    A vulnerability exists in ts_app_process.asp used to
    display/sign/approve etc.. timesheets because of a lack of authorization
    and can be exploited to display other users timesheets by modifying the
    TSN parameter in the URI with the following syntax:
    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
    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.Duchemintelus.com (| c3rb3rhotmail.com)

    Have a nice day.