Carlos Felipe Salgado Jr. ("Smak", 36, Daly City, CA) was arrested at San Francisco Airport on 21 May 1997 after he sold an encrypted diskette with personal data on more than 100,000 credit-card accounts to undercover FBI agents, who paid him $260,000, checked out the validity of the data, and then nabbed him. He reportedly had obtained the information by hacking into various company databases on the Internet or by packet-sniffing an unidentified SanDiego-based ISP. He faces up to 15 years in prison and $500,000 in fines. [Source: *San Francisco Chronicle, 22 May 1997, A25; 23 May 1997, D1-2] Add this case to the burgeoning Risks of Identity Theft file, including recent cases involving thefts of a Visa International database of 300,000 credit cards (RISKS-18.62), Caltrain's ticket-by-mail commuter database (RISKS-19.02), and Levi Strauss' 40,000 employees and retirees (RISKS-19.12).
Several weeks ago, we started receiving automated calls. When my wife picked up the line, there was just a slight hum for exactly 10 seconds, then the line would disconnect. Initially, my wife had thought some "female" was trying to call me, and hung up. It was only when I received the same calls that she believed me! After the first two weeks of this, we received another, automated 10-second hangup IMMEDIATELY followed by a call from South Central Bell inquiring as to whether we wanted to "TouchStar" telephone service, which allows the customer to find out (among other things) who had "called and hung up" for a "low" monthly fee. I complained that I thought it was rather coincidental that BellSouth would call right after another automated hang up, but they professed their innocence. Today, I started receiving them on BOTH of my lines at the same time. I called a friend (another RISKS reader) to ask what steps I could take (I live in AL, he lives in MD). To my surprise, he started getting the same 10-second automated hangups 3 weeks ago, and have not stopped! What I feel is happening is that the phone companies have tapped into a way to generate more money by causing people to dial the *69 number for the 75-cent fee. When people get tired of paying the fee, they subscribe to the service. I may just do that to see if the calls stop. I have tried the better business bureau, but no humans exist to speak to! The risk? Well, my marriage went south for the first two weeks, and people are possibly getting duped while the phone companies take the money and run.
RISKS readers may find the following transcript from the OK bombing trial to be particularly interesting: http://www.cnn.com/US/9703/okc.trial/transcripts/may/050697.eve.txt (Note CNN's Y2K problem, but that's for another time!) This transcript was brought to the attention of another usenet group due to its details of how the debit-card business works. The bulk of this transcript deals with the testimony of a Mr. John Kane, an executive of the company that handled the telephone debit card that was allegedly used. Problems: There was no one computer that had all of the information necessary to connect a phone debit-card number, the phone number from which a call was made, and the phone number to which the call was made. 3 different logs from 3 different computer systems whose clocks were not synchronized must be related in order to determine this information. Therefore, it is difficult to relate the logs in an unambiguous manner. Furthermore, the logs indicate only a physical port number, and the only way to determine the correspondence is to _physically inspect_ the connectivity of the cables. Q. How often were the cables rearranged? Since the system would work fine with a different permutation of the cables, what assurance do we have that the cables had not been rearranged by a technician who many never have told anyone, or not even realized himself? Due to the large sizes of these files (2.5 billion calls!), the 'matching' process allowed for +/- 4 minutes 'slop' in comparing the clock times of the different logs. Q. Did they take into account Daylight Savings Time (especially given the problems we're recently been talking about)? Q. Did they take into account the fact that on different days the clocks may have had different discrepancies? There are key items missing from the most important transaction log. This is because this computer was _intentionally rebooted_ 3 times every day (perhaps at midnight, 8AM, 4PM, all Los Angeles time). Each time the computer was rebooted, some transactions were lost; whether from not having been saved from the write buffer, or not being logged during a length boot process, was not made clear. Apparently, a very critical phone call was one of the transactions that were not logged due to this rebooting. (What are the chances of this??) Why was this computer rebooted 3X per day? Because it had apparently been crashing of its own accord prior to this, and those crashes had been very inconvenient, so it was decided that purposely rebooting would result in fewer complaints. This rebooting may have resulted in a slight loss of revenue, as well, as the missing calls may never have been logged. There is a presumption that if a PIN (in this case a 14-digit PIN) is being used, that only one person could possibly have used it. However, apparently this system did not check to see that multiple people (perhaps in different parts of the country) were not using the same PIN number at the same time. (Unlike many prepaid phone cards in Europe, there is no physical card to plug into the phone — the _only_ proof of identity is the PIN.) Henry Baker ftp://ftp.netcom.com/pub/hb/hbaker/home.html
AT&T Research (and probably some surrounding subsection of New Jersey) is getting a new area code (973). The old area code was (908). This morning I tried calling Avi Rubin (who said I should mention "Web Security Sourcebook", his new book), at his new number and got a "no such area code" message from the phone company. (Incidentally, Avi's new number came off his .sig from an e-mail he sent me.) Undaunted, I looked up his old number in my rolodex and called that. I was answered with a recorded message saying "...listen up, my new number is (973)...", which then terminated in silence. No chance to leave a message. No actual human being. This means that it is currently impossible to reach Avi by phone (something he doesn't seem too put out by)! After I sent Avi some e-mail, he called me in Virginia. He explained that he had tested the new number from within the old (908) range and it worked. Thus he assumed it worked in the rest of the world. It doesn't. The risk? You might actually get some work done if you never have to talk on the phone. New area code anyone? Gary McGraw, Reliable Software Technologies (RST), Sterling, VA firstname.lastname@example.org <http://www.rstcorp.com/~gem>
by Brian McWilliams, PC World News Radio May 20, 1997 - - A security window left open by AT&T's WorldNet Internet service may have exposed credit card, e-mail, and other personal information of WorldNet subscribers. PC World News Radio learned that the account access pages at the WorldNet site, where subscribers can change their user account information, are not protected by SSL, the widely used protocol that authenticates and encrypts transactions over the Internet. To get into the page, you type in your e-mail identification and a special security word that you select when you sign up for WorldNet service. When you type in the word, it becomes a hidden field in the HTML page. The service keeps sending the word as plain text every time you make another request on that Web site. "We sat there and just started grabbing packages and dumping them into a database," said Patrick Cline, a WorldNet subscriber who's a database engineer for a Georgia-based software company. "Read them off and you can get people's e-mail IDs, passwords, all that data." Cline says he discovered the hole in WorldNet's security recently when he was updating his account. Out of curiosity, he checked the HTML source code on the account access page and saw it was sending his account name, e-mail ID, and, most importantly, his security word, from his browser over the Net as plain, unencrypted text. Using what he said are widely available tools and techniques, Cline says he wrote an application that watched the WorldNet account access page and grabbed security words and account IDs. After an hour or so, he had collected information on some 20 user accounts. With that data, he said he could have logged into the users' accounts, read their e-mail, viewed their credit-card data, and essentially posed as those users. "I guess the idea of the security word is that only one single person would know it," said Cline. "But, if you can grab that data, you could do anything you want. You could be that person as far as WorldNet is concerned." A spokesperson for AT&T WorldNet confirmed that the service heard from Cline regarding the security vulnerability and was investigating the possible exposure. But he said the opportunities for hackers to get WorldNet users' information is small, because the account access page isn't available on the open Internet, but only to WorldNet users who dial into one of the company's points of presence. Nonetheless, Cline said that user information is at least available to hackers with a WorldNet account, and he advised fellow WorldNet subscribers, and Net users in general, to be vigilant about using sites that ask for confidential information without proper security protection. "People need to be aware of how easy, or how accessible, this technology is becoming to capture this information. Any idiot just coming out of school can do this, can just grab plain information that's just being sent, and encryption is the key to protecting people." Dave Kennedy, director of research for the National Computer Security Association, said he was surprised that a high-profile service like AT&T's would leave such a security window open. "If AT&T did this, that's a bad thing because they're such a major provider and certainly being as large as they are, would be expected to know better. " But he added that there are "far more good sites than there are clueless sites." As of news time, AT&T WorldNet's account access page was still operating without encryption. RealAudio: http://www.pcworld.com/cgi-bin/playradio.pl?Month=05&Day=20&Year=97&Bps=28 Text: http://www.pcworld.com/cgi-bin/database/body.pl?ID=970520182007
The top story in the 24 May 1997 edition of *The New York Times* describes how one of the top Generals in the Mexican army apparently sold his services to a drug dealer. The good news is that he rounded up some of the traffickers on the street. The bad news is that he only rounded up the competitors of his client who rewarded him well for such service. The story also notes that the General has denied the charges. RISKS readers will be interested in these quotes: * General Gutierrez's subordinates, working with Mr. Carrillo Fuentes's eavesdroppers and gunmen, detained and interrogated dozens of suspected Areliano Felix associates, the testimony indicates. ... * Before one joint operation [sic], the traffickers briefed one of the general's subordinates, showing him a file of reconnaissance photos of Arellan Felix associates and their residences, as well as tape recordings of telephone conversations the traffickers had intercepted, the testimony indicates. ... * Last October, the mutual trust was so high [sic] between General Gutierrez and the Carrillo Fuentes organization that the traffickers delivered a set of computerized, encrypted cellular phones that allowed Mr. Carrillo Fuentes and his aides to talk freely with the general, his driver and other military officers without being overheard, the testimony indicates. So, the debate is what to do about the eavesdropping and encryption in this story. Obviously, cheap and easy encryption would have allowed the rival organization a fighting chance to move its drugs into America and prevent a monopoly from developing. But encryption also allowed the allegedly corrupt General to speak freely with his partners, the drug barons. Could it be that the RISKS of technology may be the least of our RISKS?
AltaVista stores URLs containing username/password for shopping malls. When searching for (e.g.,) a specific music band, you might get a result including an autologin to a shopping mall. You have full control of the user information and are able to change the shipping address etc, but still having the original user having to pay for it. Never use the CGI GET method to submit parameters! Fredrik Pihl, Innovative Media AB, S-412 88 Goteborg SWEDEN <email@example.com> http://www.innovative.se/ Phone +46-31-7724013
In RISKS-19.16, Cliff Helsel reported that ETrade, IMHO one of the best of the on-line trading services, makes all customer passwords available to their customer service employees--perhaps to all their employees. So I asked them (via e-mail) if it were true. It took two weeks, but the answer came, and was: the procedure has been changed, and it is no longer true. Another problem solved, though of course I have no idea how well they have solved it. (Note the power of Risks! Use it prudently.) That left the question of whether the passwords are stored in the clear or encrypted (recognizing that someone, some day, insider or outsider, will break into the file). I asked, but have no idea whether they will tell. Stay tuned. Hal Lewis
>From WIRED online via PointCast News: Small-Time Spammer Slapped with Suit, by Ashley Craddock, 29 May 1997 Attempting to narrow the scope of spam wars, Internet activists in Austin, Texas, have slapped a novice junk e-mailer with a lawsuit charging that he illegally dumped his online garbage in someone else's mailbox. The author makes the following key points: * College student Craig Nowak admits having chosen a reply address at random for his first spam attack on the Net from his "short-lived" company, CN Enterprises. * He chose "flowers.com" and the legitimate owners of that address received 5,000 bounced messages and enraged responses to Nowak's fraudulently labelled junk e-mail. * Tracy LaQuey Parker has been joined in her lawsuit by the Electronic Frontier Foundation (Austin chapter) and the Texas Internet Service Providers Association. * Lawsuit demands "unspecified actual and punitive damages" for having falsely attached the flowers.com address to the junk, causing potential blacklisting of the legitimate firm. M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com=
In RISKS-19.18, Lance Hoffman notes the "anti-spam bill" introduced in the Senate. But it is not an anti-spam bill. It's an anti-commercial-e-mail bill. I read the bill and my reaction was `great, if I now send someone an e-mail with the URL of O'Reilly's webpage, I can be sued, but they still can't get me when I e-mail the bible to a million addresses'. It's a bad bill, for many reasons: - It only addresses the US, which is rather pointless on the Internet. I have seen a couple of machines outside the USA, and I bet they are able to send e-mail as well. - It doesn't address the real problem: misuse of the system. The problem isn't that the content of e-mail is commercial, the problem is that sending enormous amounts of mail at one time can bring mail delivery systems to their knees. A mail server of a large ISP that goes down under the load wouldn't have stayed up if the content was a fairy tale. - The proposed solution doesn't solve anything. Yes, adding 'Advertisement' in the subject makes it easier to filter it, but the net traffic stays the same, and so does the load on machines. (Hmm, extra filtering might even increase the load). - Faking an e-mail address is about as easy typing your name. How do you prove an alleged commercial e-mail actually comes from the address mentioned? Wouldn't an organisation like the Church of Scientology have some interesting (mis)uses for this bill? I don't have a solution for the problem of junkmailing, but I hope this bill will not pass the Senate. Abigail
When I worked for Digital's Systems Research Center, our e-mail interface program had a feature for resolving the aliases in a message without sending the message. I always used this before sending to make sure my messages went to the people I intended and to find out if I had the right alias (now I often generate bounced messages because I got the alias wrong or thought I had one that I didn't). It also had the advantage that I could create hierarchical alias lists, building aliases out of aliases, which enormously simplified the process of updating e-mail addresses. The resolver did not work recursively, but it was a simple matter to click the button a few times to get to the leaves (usually at most 2 levels deep). Dorothy Denning
When I worked at another (un-named) company a similar thing happened. Two people on two different continents were fired for exchanging private, shall we say "racy" (actually pornographic) letters between themselves. What happened is the e-mail system would allow the (inadvertent) attachment of one e-mail message to another. The ADD ATTACHMENT function key was "F7", the DELETE MESSAGE function key was "F6". So the first individual (accidentally --- you're ahead of me-- ) hit the F7 key before the F6 key, then proceeded to send a message to yet another mailing list on another subject....... One could observe (in the upper right corner) that there was "x" number of attachments to a mail message. If one was observant. If....... After THAT incident there were a LOT of people who became VERY observant of the upper right corner of their mail screen......... Of course the obvious risk is don't use the corporate mail system to exchange private mail, the corporate mail police are watching you! -Joe
Emin Gun Sirer of the University of Washington posted an article in RISKS-19.18 entitled "Java security architectures/testing methodology/flaws". [...] Emin Gun Sirer <firstname.lastname@example.org> wrote: > A few of the flaws involve breakdowns in the typesafety guarantees of > Java, which expose web users who execute foreign Java code to security > attacks. A flaw in typesafety may allow an application to gain access to > restricted data or to restricted services. Some of the other flaws are > deviations from the JVM specification, and a few are particular unenforced > interpretations of an ambiguous specification. It is perhaps worth noting the usage of "a few", "may allow", and "some of" in the above description. For the original JavaSoft statement on this issue, see http://java.sun.com/security/UW.html. For a much more detailed and more interesting exposition on the topic, see http://java.sun.com/security/UWdetails.html. Some excepts: 1. Why is there a discrepancy in the statements from UW and from JavaSoft? The University of Washington statement refers to 24 bugs found in the JDK system, and the JavaSoft statement refers to one bug that is fixed. Why this discrepancy? The University of Washington researchers tested several different verifier implementations, including those used by commercial Java browsers, and a development tool from JavaSoft called javap. Javap is a decompiler that takes Java bytecode as input, and produces a Java "pseudo source" file. It is possible to invoke javap with a verification option turned on, in which javap performs a subset of tests that the VM performs. When the Kimera project's test vectors are applied to the verifier used by the JDK platform, the appletviewer and HotJava, a different set of test results emerges. <"[...]" denotes requested deletion in archive copy. PGN>
Arrgh. > > It's not meaningful to compare a clock in Denver with a clock in > > California to within a microsecond, ... > Not true. The two locations are essentially fixed with respect to each Special relativity says there's no difference. General Relativity says there _is_ a difference. Somewhere _after_ chapter 1, I expect Misner, Thorne, and Wheeler mention this. (My copy's at home, and I'm not.) Clocks run more slowly in stronger gravitational fields, independent of relative motion or lack thereof. (Or so the theory goes.) I've not tried to run the numbers, but I suspect that actually getting a microsecond difference between Denver and someplace at sea-level would take longer than I care to wait. I greatly enjoy the RISKS news, but I would not depend on it for an education in physics. Too many contributors who know things that are not true. Steven M. Schweda, Provis Corporation, 5251 Program Avenue #100 Mounds View, MN 55112-4975 (+1) 612-785-2000 ext. 16 email@example.com
If fire ants are attracted to strong electrical fields, then this does suggest a way to create an effective fire ant trap & killing device. I am surprised that nobody has done it.
Doesn't anyone remember one of the biggest problems the Super Conducting Super Collider project ran into during construction in Texas? It wasn't politics... It was the Mecca of fire ants in all the extremely high-voltage conduits, junctions, transformers, and other high-strength field areas. The ants would eat the insulating compounds off and sit there basking in the emf high they apparently got. Occasionally, an ant would offer itself as sacrifice, prompting some Damn Big Breakers to blow... Sadly, the engineers rated a Major Duh! from the local farmers who have had to put up with the critters for years... Vexxallarius Venturi (aka The Really Cranky Dragon) <a href="http://www.omsi.edu/~rcdragon">http://www.omsi.edu/~rcdragon <firstname.lastname@example.org>
The web-site run by the USPS requires that you print out a form and mail it to your postmaster or give it to you postal carrier. I don't see how this is any different than paper forms. It is certainly not an `on-line' change. G. Allen Morris III [Also noted by Alan Winston <WINSTON@SSRL.SLAC.STANFORD.EDU>. But it is certainly easier to get the forms, especially if frauds are being coordinated from outside of the U.S. PGN]
The Postal Service Change-of-Address web page (http://www.usps.gov/moversnet/coa.html) does NOT allow you to send change-of-address notices via e-mail. It merely lets you create a form on your screen, with the help of an automated address/zip code lookup database, that you can print out, sign, and snail mail to the Post Office. Evan
The final (27 May 1997) version of the report ``The Risks of Key Recovery, Key Escrow and Trusted Third-Party Encryption'' is now available. The report, by Hal Abelson, Ross Anderson, Steve Bellovin, Josh Benaloh, Matt Blaze, Whit Diffie, John Gilmore, Peter Neumann, Ron Rivest, Jeff Schiller, and Bruce Schneier examines the technical implications, risks, and costs of the ``key recovery,'' ``key escrow'' and ``trusted third-party'' encryption systems being promoted by various governments. A preliminary version of the report was released last week [and noted in RISKS-19.17]; the final version is now available. The report is available as online as follows: On the web at: http://www.crypto.com/key_study In PostScript format via ftp: ftp://research.att.com/dist/mab/key_study.ps In plain ASCII text format via ftp: ftp://research.att.com/dist/mab/key_study.txt
Please report problems with the web pages to the maintainer