Re: [iwar] Digest Number 442

From: Sunil Dhaka (
Date: 2001-06-27 08:22:22

Return-Path: <>
Received: from by localhost with POP3 (fetchmail-5.1.0) for fc@localhost (single-drop); Wed, 27 Jun 2001 08:22:07 -0700 (PDT)
Received: (qmail 18392 invoked by uid 510); 27 Jun 2001 14:23:20 -0000
Received: from (HELO ( by with SMTP; 27 Jun 2001 14:23:20 -0000
Received: from [] by with NNFMP; 27 Jun 2001 15:21:18 -0000
Received: (EGP: mail-7_1_3); 27 Jun 2001 15:21:17 -0000
Received: (qmail 41596 invoked from network); 27 Jun 2001 15:20:15 -0000
Received: from unknown ( by with QMQP; 27 Jun 2001 15:20:15 -0000
Received: from unknown (HELO ( by mta2 with SMTP; 27 Jun 2001 15:20:12 -0000
Received: from [] (helo=hork) by with smtp (Exim 3.21 #1) id 15FH6F-0000pW-00 for; Wed, 27 Jun 2001 20:49:27 +0530
Message-ID: <003d01c0ff1d$23fc5dd0$228647ca@hork>
To: <>
References: <>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
From: "Sunil Dhaka" <>
Mailing-List: list; contact
Delivered-To: mailing list
Precedence: bulk
List-Unsubscribe: <>
Date: Wed, 27 Jun 2001 20:52:22 +0530
Subject: Re: [iwar] Digest Number 442
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

----- Original Message -----
From: <>
To: <>
Sent: Monday, June 25, 2001 1:08 PM
Subject: [iwar] Digest Number 442


There are 3 messages in this issue.

Topics in this digest:

      1. Me spreading hysteria about cyberwar
           From: "Ravi V Prasad" <>
      2. FW: [NEWS] Banking - Does It Belong Online?
           From: "Robert W. Miller" <>
      3. RE: Me spreading hysteria about cyberwar
           From: "JunkMail Rosenberger" <>


Message: 1
   Date: Sun, 24 Jun 2001 10:21:44 -0000
   From: "Ravi V Prasad" <>
Subject: Me spreading hysteria about cyberwar

An article in by George Smith attacking me and accusing me
of spreading hysteria about cyberwar.

Ravi Visvesvaraya Prasad


Mumblings of monkey-men mock moderation
by George C. Smith, Ph.D.

LOCAL LOS ANGELES TV news anchormen had a great time with the monkey-
man of India -- an allegedly fierce creature fond of attacking the
destitute while they slept. I bet yours did, too. Thanks to a
strategically placed news story in the Los Angeles Times and
subsequent legs on the Times-Post newswire in May, everyone was
laughing it up over this story of queer beans emanating from the
subcontinent. "Look at those backward perishers in Gobble-Wallah,"
was the smug subtext. "They don't know ---- from shinola!"

"Leading Hindu nationalists insisted that the military intelligence
agency in Pakistan had sent the monkey-man in a sinister plot to
destabilize India. Several members of Parliament demanded that the
government send in crack paramilitary units to catch the ape-man."
-- from a May 2001 story in the Los Angeles Times on the hysteria
surrounding a recent urban legend of India

However, our myths are just as good. We just spackle them over with a
snobby, less proletarian techno-veneer. The monkey-man would have
been fine for America in the early-70's, around the time of the
filming of "The Legend of Boggy Creek," but now that we've invented
the Internet, "digital Pearl Harbor" and "information warfare"
derivatives are better socio-cultural fits.

So infatuated was I by the tale of the monkey-man of New Delhi I went
in search of more news on the Internet and in so doing discovered
that one of our special monkey-men had wandered away and merged with
the cyber-lore of foreign lands.

It was said in the Los Angeles newspaper that an analysis in the
Hindustan Times wrestled with explaining the belief in the monkey-
man. Desperation and hard times was what it boiled down to, according
to the Times -- superstition cooked up by "poor people" driven to
aggravation by 10-hour power black-outs and water shortages.

Looking for the Hindustan Times on the Web for further copy, however,
got me sidetracked onto another article published by the newspaper.
In a piece from the June 8, 2000 edition, journalist Ravi V. Prasad
mulled over "cyber-terrorism and the threat to India" in the wake of
the KillerRésumé and ILoveYou computer viruses.

Prasad quoted R. James Woolsey, former director of the CIA, as an
expert on computer viruses. In the Hindustan Times, Prasad alleged
Woolsey had claimed the existence of "an entirely new class of
viruses which he termed instructive viruses" during a talk given to a
Washington-based think tank.

"An instructive virus can instruct [which would seem inarguable]
critical computers to shut down vital infrastructure," went the

The Hindustan Times also claimed the National Security Agency had
developed a "virus called Blitzkrieg ... based on research in quantum
electrodynamics and chaos theory, which can destroy networks of
entire nations ... the equivalent of the deadly human Ebola virus..."

"While there is no significant reason to suspect that the US may use
Blitzkrieg or instructive viruses against India, we should be on our
guard," continued the newspaper.

"Because the monkey-man reportedly attacked only sleeping people in
the dead of night, actual sightings were hard to come by."
-- "...Sinister Simians Roam," the Los Angeles Times, May 2001

U.S. CYBER-MONKEY-MEN HAVE much in common with the New Delhi species.
Sightings of terrorists plotting to douse the lights from the refuge
of an offshore cyber-bunker or Russian henchmen downloading precious
U.S. Department of Defense intellectual treasure are often cited but
occur only in the American equivalent of very dim moonlight: hearsay
of classified goings-on or vague but stunningly grandiose mumblings
delivered by parties who speak under the shields of secrecy and

With the case of the NSA Blitzkrieg virus, the legend concerning it
was already just about two years old when come upon by the Hindustan
Times. In April of 1998, SIGNAL, the magazine organ of the Armed
Forces Communications and Electronics Association, a publication
notable for jargon-riddled articles on the repeatedly alleged utter
supremacy of Department of Defense digital widgetry and a servile
regard for the details of Pentagon contracting, ran a cover story on

Like many news items which take on the proportion of myths, this
story concealed a small nugget of truth -- in this case, word of a
still-in-development piece of commercial computer network security
software -- within a billowing cloud of grandiloquent, often common-
sense-defying huffing and hooting.

"A growing echelon of chief technology officers are likening the
stealthy [Blitzkrieg] virus to the digital equivalent of Star Wars
technology," alleged a sample. Yet another segment of the now mythic
story referred to an apparently very excitable but unnamed CIA
computer security specialist who claimed Blitzkrieg virus to
be "potentially more dangerous than nuclear weapons."

Mostly, all the magazine's blustering was aimed at getting the
interested to attend an annual high tech conference sponsored by
AFCEA. And, in the fullness of time, that was pretty much the end of

No "Star Wars" computing technology gained supremacy. Despite a great
deal of wishful thinking on the subject, no digital "nuclear weapons"
appeared. Virus-writers made ILoveYou and Melissa and Kournikova and
a few thousand others of no account. Cyber-World Wars were said to be
started and stopped, won and lost, lost and won, stalemated,
checkmated, fool's-mated and deadlocked. It was Serbia vs. NATO,
India vs. Pakistan, Arab vs. Israeli, Chancre Jack China vs. Commie
China, Commie China vs. America, Lick-Spittle vs. the Cyber-
Pantywaist, cats vs. dogs, a dozen or so I've forgotten, and Me vs.
You -- you crusty botch of nature!

Are you beginning to grasp where your editor is going with this?

"One man who claimed that he had looked the monkey-man straight in
the eye said the beast immediately turned into a cat and ran away."
-- from the Los Angeles Times

If one takes the wide-angle view, it becomes painfully obvious that
it doesn't really matter if the songs we sing to each other are based
on nothing at all. If enough believe the myths have merit then
subsequent public discussions and national policy can and does arise
as a response to them.

In this specific case, empty-headed talk -- tales of monkey-men -- of
U.S. origin about network blitzkriegs and instructive viruses is
taken as an indication, by a foreign country's Washington Post, that
the American military has taken a lead in development of cyber-
weapons and that it might be rational to think about devising
balancing forces.

IRONICALLY, THIS IS not the view from the cyber-trouble front
typically presented in the American mainstream. Instead, the US-
centric view, which in and of itself is a rather selective myth, is
best explained in connection with the Department of Defense buzz-
term -- "asymmetric threat."

Invoked ad nauseum since the middle of the past decade by Pentagon-
wonks, "asymmetric threats" are "weapons [like 'instructive viruses']
and tactics that relatively weak enemies ... use to foil [U.S.]
technological supremacy." Or, for another common example, they can be
explained as features of "a war where [the adversary] will strive to
fight electronically" instead of irrationally attacking the U.S.
military head on.

Always in accompaniment is the vaguely-defined received wisdom that
such menaces arise more or less spontaneously in foreign powers or
agencies crazy-mad bent on attacking America in the future. The
heretical idea that an "asymmetric threat" might not actually be so,
that it might just be a sign of symmetry -- a refection or reaction
stemming from a perception that the U.S. military has an aggressive
interest in the same type of offensive warfighting -- is not

In other words, the myth of the asymmetric cyber-threat will
generally appear in our national news media as a reported condition
in which American infrastructure is always said to be the target of
foreign operations or plans in development. And it will present in a
vacuum in which examples from the foreign perspective (of which there
are now, unsurprisingly, quite a few) are excluded. One never expects
to see mention of an article from the New Delhi (or any foreign
capital's) newspaper suggesting the need for cyber-war agencies as a
response to a presumed corresponding and quite possibly precedent
American build-up. The exception to the rule is one in which such an
article is filtered through a government, military or private sector
source who paraphrases only the portion where information warfare
agencies are recommended -- not the context in which it is delivered.

"If he's a monkey, I'm ready for him."
-- a New Delhi man "now in the monkey management business" waiting
and hoping for a call to take on the monkey-man

However, this is not all bad news! Rampant confusion and mass
insanity can be good for the economy. The multiplication of monkey-
men myths creates job stimulus. Professionals recruited to
prevent "instructive viruses" or network Blitzkriegers can be thought
of as our more technologically informed variety of monkey-man
managers. Indeed, they can spawn even more jobs and goods,
creating "synergies" with strategic forecasting services or threat
warning and information sharing networks. Anyone can get in the game,
from federal agencies like the National Infrastructure Protection
Center or the National Security Council to the private sector.

Better still, the work is inexpensive and can turn a substantial
profit upon mark-up prior to delivery of the finished product. You
see, the dirty little secret of monkey-man prediction is that it is
the technological equivalent of unskilled labor.

That is, unless you consider daily Web-surfing and the collection of
electronic gossip tasks requiring scholarly rigor.



Message: 2
   Date: Sun, 24 Jun 2001 13:48:57 -0600
   From: "Robert W. Miller" <>
Subject: FW: [NEWS] Banking - Does It Belong Online?

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

Banking - Does It Belong Online?


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

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


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
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
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

* 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

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

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:

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}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
{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).


The information has been provided by  <> 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
In order to subscribe to the mailing list, simply forward this email to:


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

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
PGP key available at:
search on


Message: 3
   Date: Sun, 24 Jun 2001 16:04:26 -0500
   From: "JunkMail Rosenberger" <>
Subject: RE: Me spreading hysteria about cyberwar

  >>An article in by George Smith attacking me and accusing
  >>me of spreading hysteria about cyberwar.

You seem to imply his accusation doesn't hold water.  Can you elaborate?

I, for one, would love to hear more about the Blitzkrieg virus you
mentioned.  God knows Blitzkrieg creator Larry Wood won't disclose anything
substantial about it...



Your use of Yahoo! Groups is subject to


Your use of Yahoo! Groups is subject to 

This archive was generated by hypermail 2.1.2 : 2001-06-30 21:44:19 PDT