Return-Path: <sentto-279987-1379-993655278-fc=all.net@returns.onelist.com> Delivered-To: fc@all.net Received: from 204.181.12.215 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 n4.groups.yahoo.com (HELO hk.egroups.com) (216.115.96.54) by 204.181.12.215 with SMTP; 27 Jun 2001 14:23:20 -0000 X-eGroups-Return: sentto-279987-1379-993655278-fc=all.net@returns.onelist.com Received: from [10.1.4.55] by hk.egroups.com with NNFMP; 27 Jun 2001 15:21:18 -0000 X-Sender: dax@net4india.com X-Apparently-To: iwar@yahoogroups.com 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 (10.1.10.27) by l9.egroups.com with QMQP; 27 Jun 2001 15:20:15 -0000 Received: from unknown (HELO smtp.net4india.com) (202.71.128.225) by mta2 with SMTP; 27 Jun 2001 15:20:12 -0000 Received: from [202.71.134.34] (helo=hork) by smtp.net4india.com with smtp (Exim 3.21 #1) id 15FH6F-0000pW-00 for iwar@yahoogroups.com; Wed, 27 Jun 2001 20:49:27 +0530 Message-ID: <003d01c0ff1d$23fc5dd0$228647ca@hork> To: <iwar@yahoogroups.com> References: <993454685.1073.93287.l10@yahoogroups.com> 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" <dax@net4india.com> Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com Delivered-To: mailing list iwar@yahoogroups.com Precedence: bulk List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com> Date: Wed, 27 Jun 2001 20:52:22 +0530 Reply-To: iwar@yahoogroups.com Subject: Re: [iwar] Digest Number 442 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit ----- Original Message ----- From: <iwar@yahoogroups.com> To: <iwar@yahoogroups.com> Sent: Monday, June 25, 2001 1:08 PM Subject: [iwar] Digest Number 442 ------------------ http://all.net/ ------------------------------------------------------------------------ There are 3 messages in this issue. Topics in this digest: 1. Me spreading hysteria about cyberwar From: "Ravi V Prasad" <r_v_p@yahoo.com> 2. FW: [NEWS] Banking - Does It Belong Online? From: "Robert W. Miller" <snooker3@mindspring.com> 3. RE: Me spreading hysteria about cyberwar From: "JunkMail Rosenberger" <junkmail@barnowl.com> ________________________________________________________________________ ________________________________________________________________________ Message: 1 Date: Sun, 24 Jun 2001 10:21:44 -0000 From: "Ravi V Prasad" <r_v_p@yahoo.com> Subject: Me spreading hysteria about cyberwar An article in vmyths.com by George Smith attacking me and accusing me of spreading hysteria about cyberwar. Ravi Visvesvaraya Prasad ============================================= Rantings 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 story. 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 anonymity. 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 it. 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 it. 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 entertained. 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. --06/05/01 ________________________________________________________________________ ________________________________________________________________________ Message: 2 Date: Sun, 24 Jun 2001 13:48:57 -0600 From: "Robert W. Miller" <snooker3@mindspring.com> 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: 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 ________________________________________________________________________ ________________________________________________________________________ Message: 3 Date: Sun, 24 Jun 2001 16:04:26 -0500 From: "JunkMail Rosenberger" <junkmail@barnowl.com> Subject: RE: Me spreading hysteria about cyberwar >>An article in vmyths.com 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... Rob ________________________________________________________________________ ________________________________________________________________________ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------ http://all.net/ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.1.2 : 2001-06-30 21:44:19 PDT