Onderwerp: An undetectable Online Bank Vulnerability?

December 20, 2003

RE: Banking/eCommerce Basic Vulnerability - Undetectable

Due to the well-known documented ability of XSS/CSS capabilities and the proliferation of 3rd-party web-services, can anyone confirm the following:

If an Online Bank utilizes 3rd-party webservices (javascript/.JS) via either web-analytic measurements or a banner-ad server - Is there not indeed a theoretical backdoor to the client-side browser if this 3rd-party webservice/webserver was compromised wit
h malicious code?

All one has to do is attack the server that is providing the commercial webservice and in theory, one would have complete control over the consumer's webbrowser (client-side browser), without detection from an Online Bank - or internal security intrusion
detection from the Bank itself.

Is this not correct?

Behind closed doors, I have confirmation of this independently. Although no one in public seems to be willing to formally acknowledge these basic vulnerabilities in Online Banking.

I have a list of Banks that currently utilize webservices from another 3rd-party.

I have searched the entire Internet for anyone else who may have reported this obvious vulnerability to an online bank. What I haven't found is a technical solution to it, nor dissemination on the basics of just how vulnerable online banking is to consum
ers.

Can anyone debate me publicly on this on grounds of the technical merits of this Online Banking Security issue? Without throwing accusations around?

I am a writer, and wanted to address the fact that there is a theoretical backdoor, that could escape detection from Intrusion Countermeasures - because this theory is made up of the following:

1) Find a COMMERCIAL WEBSITE with 3rd-party services running on it.
2) Attack the weakest part - the company providing webservices to this website.
3) Compromise the code on the server that is providing it to the COMMERCIAL WEBSITE.
4) This compromised code could in theory launch a new Popup() window or new browser session mimicking the entire content of the COMMERCIAL WEBSITE.
5) This technique bypasses the COMMERCIAL WEBSITE's SERVER and INTRUSION DETECTION capability, by launching straight into the users client-browser session (client-side).

In theory would this not be a Backdoor to Online Banking/Commerce? It is also undetectable because of its client-side orientation, is this not also correct?

Obvious solutions: Remove 3rd-party webservices from sensitive websites. Inform customers to disable Javascript or Mobile Code.

Any comments would be appreciated.

--/2994txjAzEdQwm5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 21, 2003 at 05:18:21PM -0000, Mark Peterson wrote:
> If an Online Bank utilizes 3rd-party webservices (javascript/.JS) via
> either web-analytic measurements or a banner-ad server - Is there not
> indeed a theoretical backdoor to the client-side browser if this
> 3rd-party webservice/webserver was compromised with malicious code?

Any half-way reasonable web browser will strongly enforce a separation
of content, javascript, etc between the bank and its third-party content
suppliers. Whether or not any specific user's web browser is "reasonable"
is a matter of implementation, and I rather suspect some Very Popular
browsers are going to let the user down in pretty drastic ways.

(I can confirm that at least mozilla 1.4 on linux appears to enforce
this separation: MBNA has introduced a new 'throwaway creditcard number'
service, ShopSafe, to allow users to generate new numbers per merchant.
Yay! Finally! Of course, the server that serves the javascript references
images served on a different server, and the mozilla javascript engine
refuses to allow this.)

So, while you've found a method to slip malicious content to clients
that people rarely think about, at least the core problem is several
years old at this point, so web browser authors have had more than
ample opportunity to repair these problems -- and some have used that
opportunity. Hopefully, the efforts of http-equiv, Liu Die Yu, Jelmer,
3APA3A, Guninksi, and other auditors[1], will help browser authors fix
bugs before they are exploited by nefarious sorts.

Thanks

[1]: Sorry this list is not exhaustive -- I certainly don't mean to
slight anyone by their absence from this list!

--=20
The DMCA is anti-consumer. The RIAA and MPAA have no right to rewrite
copyright laws to suit themselves.

--/2994txjAzEdQwm5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/6OH6+9nuM9mwoJkRAgQGAKCDRAqAprGvPcsgFP3kYJDjfczQSw CgoiBg
cJ2tKPLmXqf/g30uTqvKvE4=
=V1SF
-----END PGP SIGNATURE-----

--/2994txjAzEdQwm5--

Here is a part of some of my information again:

Fortunately Bank of America and ASBBank (New Zealand) have moved this
previous (3rd-party) remote script to one executing locally on their own
servers.


-----Original Message-----
From: M Peterson [mailto:apalamen@sbcglobal.net]
Sent: Thursday, April 29, 2004 7:25 PM
To: 'Sachin Hamirwasia'; 'bugtraq@securityfocus.com'
Subject: RE: An undetectable Online Bank Vulnerability?

Exactly, so here is an actual LIVE examples to provide:

1. <script language="javascript1.1"
src="/{WEBSERVER}/homepage-utils.js"></SCRIPT>
</script>

2. <img src="//{WEBSERVER}/cgi-bin/m?ci={CLIENT}&amp;cg=0" alt="">


So this would fit your original vulnerability assessment, would it not?
Since this code executes at the client-side, how could a bank's webservers
detect altered code? A bank recently took notice of this basic security
vulnerability and incorporated this script on their own local servers:

1. <SCRIPT language="JavaScript1.2"
src="js/{WEBMEASUREMENT_CODE}.js"></SCRIPT>

If one were to put this code on controlled webservers, then yes it would be
far more unlikely to be compromised. One would need to target the bank's
webservers and insert their redirection {MALICIOUS} code at this point.
This is obvious. Although I think people get very uncomfortable mentioning
the inherent risks of utilizing third-party services and the theoritical
security issues of plausible scenarios to discuss this to get peoples
attention on these issues before the damage is done. Although this is a
very basic inherent vulnerability of the Internet, I felt that people of
this Internet Security and Awareness Forum should let me know why if I am
completely wrong here, and if so, exactly why?

-Mark



-----Original Message-----
From: Sachin Hamirwasia [mailto:sachinh@singnet.com.sg]
Sent: Tuesday, December 23, 2003 11:07 AM
To: 'Mark Peterson'; bugtraq@securityfocus.com
Subject: RE: An undetectable Online Bank Vulnerability?


Mark,

I would not expect any Online Bank (worthy of its name) to simply insert a
raw script code (either client side or server side assembly) on its web
pages. Most web-analytic measurement sites (like doubleclient.net,
RedSheriff, Akamai) would provide a script code to insert on your pages, not
a URL based insertion. So I don't see XSS/CSS being a case to exploit here.

But yes, if Bank A has a webpage (http://www.bank-a.com/index.html) which
has a line like this:

<html>
.....
<script src="http://www.another-site.com/analysis/counter.js"></script>
....
</html>

then Bank A is vulnerable to severe XSS exploitations. But I find it
difficult to imagine a bank doing this...

Can you provide a more concrete example of what you are suggesting? Is there
any online bank where you have noticed something to this effect?

~cheers~


-----Original Message-----
From: Mark Peterson [mailto:apalamen@sbcglobal.net]
Sent: Monday, December 22, 2003 1:18 AM
To: bugtraq@securityfocus.com
Subject: An undetectable Online Bank Vulnerability?



December 20, 2003

RE: Banking/eCommerce Basic Vulnerability - Undetectable

Due to the well-known documented ability of XSS/CSS capabilities and the
proliferation of 3rd-party web-services, can anyone confirm the following:

If an Online Bank utilizes 3rd-party webservices (javascript/.JS) via either
web-analytic measurements or a banner-ad server - Is there not indeed a
theoretical backdoor to the client-side browser if this 3rd-party
webservice/webserver was compromised with malicious code?

All one has to do is attack the server that is providing the commercial
webservice and in theory, one would have complete control over the
consumer's webbrowser (client-side browser), without detection from an
Online Bank - or internal security intrusion detection from the Bank itself.

Is this not correct?

Behind closed doors, I have confirmation of this independently. Although no
one in public seems to be willing to formally acknowledge these basic
vulnerabilities in Online Banking.

I have a list of Banks that currently utilize webservices from another
3rd-party.

I have searched the entire Internet for anyone else who may have reported
this obvious vulnerability to an online bank. What I haven't found is a
technical solution to it, nor dissemination on the basics of just how
vulnerable online banking is to consumers.

Can anyone debate me publicly on this on grounds of the technical merits of
this Online Banking Security issue? Without throwing accusations around?

I am a writer, and wanted to address the fact that there is a theoretical
backdoor, that could escape detection from Intrusion Countermeasures -
because this theory is made up of the following:

1) Find a COMMERCIAL WEBSITE with 3rd-party services running on it.
2) Attack the weakest part - the company providing webservices to this
website.
3) Compromise the code on the server that is providing it to the COMMERCIAL
WEBSITE.
4) This compromised code could in theory launch a new Popup() window or new
browser session mimicking the entire content of the COMMERCIAL WEBSITE.
5) This technique bypasses the COMMERCIAL WEBSITE's SERVER and INTRUSION
DETECTION capability, by launching straight into the users client-browser
session (client-side).

In theory would this not be a Backdoor to Online Banking/Commerce? It is
also undetectable because of its client-side orientation, is this not also
correct?

Obvious solutions: Remove 3rd-party webservices from sensitive websites.
Inform customers to disable Javascript or Mobile Code.

Any comments would be appreciated.

--
Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.230 / Virus Database: 262.9.10 - Release Date: 4/28/2004