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
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
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.
Vice President, Engineering
Security Advisory: Multiple Exploitable
Vulnerabilities at Intacct.com
26 August 2000
This security advisory is Copyright 2000 by Jeffrey
(jwbaker () acm org). The advisory may be
distributed in whole or in part
These vulnerabilities were discovered while I was
security of online accounting firms such as Intacct
. 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 , they
claim to have "world-class security you expect from
a top-tier financial
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
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
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 , 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
. 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.
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.
4: I will not reveal them, but the three values will be
obvious to anyone who investigates Intacct.
- Re: Intacct.com: Multiple bugs at financial services company Nagi Prabhu (Sep 06)