Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Intacct.com: Multiple bugs at financial services company
From: Nagi Prabhu <nagi () INTACCT COM>
Date: Tue, 5 Sep 2000 23:26:38 -0000

Your advisory posting outlines three areas of 
concern. FYI, we have taken immediate action and 
have already upgraded our web service to remedy 
the concerns you raised.


1. Clear Channel vs. SSL

By design, Intacct initially built its system to optimize 
customization and give its users a choice of 
channels: clear (http) or SSL (https). The reason 
being, that some users have older browsers that 
cannot run SSL.

  As of 8/30, users who request a clear channel (http) 
are denied access.

2. Session Key
This issue, was, in fact, a bug. We immediately fixed 
the bug and now the session key is working as it was 

3. Cookie Feature / Cross-scripting

The cookie feature was designed for those users 
who wanted the convenience
of being able to enter and re-enter the system without 
an additional login. However, there was a risk if a 
user visited a "evil" site without logging out of the 
Intacc system, an operation could be performed on 
behalf of the user from that site.

It should be noted here that this problem is pervasive 
on the internet which makes many prominent web 
services (I won't name them here) vulnerable. The 
common advice offered is to logout from any web 
service deemed critical before visiting sites of 
questionable origin.

We are in the process of changing our application to 
no longer make use of
Cookies for session identification. We expect to have 
these changes available in
our web site within the next 10 days. These changes 
will eliminate any vulnerability from cross-scripting.

Meanwhile we have issued a customer 
communication to further remind Intacct users that 
for maximum security, they should always log out of 
the service or exit their browser at the end of any 
Intacct session.

To minimize the risk from security vulnerabilities 
Intacct has began the
process of obtaining an AICPA SysTrust audit 
through one of the Big 5 accounting firms.

We hope that our actions satisfies your concerns and 
that you are convinced that Intacct is committed to 
providing online security for our customers.

Nagi Prabhu
Vice President, Engineering
Intacct Corporation

Security Advisory: Multiple Exploitable 
Vulnerabilities at Intacct.com


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.


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.


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


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:


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


Do not use Intacct's services.


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 
obvious to anyone who investigates Intacct.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]