lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 7 May 2004 21:57:44 -0500
From: "M Peterson" <apalamen@...global.net>
To: <apalamen@...mail.com>, "'David Ahmad'" <da@...urityfocus.com>,
	<bugtraq@...urityfocus.com>
Subject: RE: An undetectable Online Bank Vulnerability?


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@...global.net]
Sent: Thursday, April 29, 2004 7:25 PM
To: 'Sachin Hamirwasia'; 'bugtraq@...urityfocus.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@...gnet.com.sg]
Sent: Tuesday, December 23, 2003 11:07 AM
To: 'Mark Peterson'; bugtraq@...urityfocus.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@...global.net]
Sent: Monday, December 22, 2003 1:18 AM
To: bugtraq@...urityfocus.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





Powered by blists - more mailing lists