Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The URL "http://www.nando.net/newsroom/ntn/info/040696/info5_14984.html"
reports "one of the biggest breaches of security of personal data held
by the federal government". Apparently several employees of the Social
Security Administration sold information including SSNs and mother's
maiden names of more than 11,000 people to a credit-card fraud ring.
The fraud ring was able to use this information to activate cards which
were stolen from the mail. Citibank had implemented a scheme which
required customers to "activate" their credit cards when they receive
them by calling a phone number and providing personal information like
their mothers maiden name.
It seems that while systems are being designed to protect our property, it's
just causing the crime to move closer to the person. If someone steals your
credit card from the mail or your car from the parking lot, you're probably
at a safe distance. Instead, they are forced to carjack your car at a
stoplight because of your alarm system, or find out personal information
about you.
Similarly, I heard about home breakins on alarmed houses in which the
burglar would regularly trigger the alarm and be careful to leave no
traces. Once the police stopped coming (because the alarm was faulty),
they were free to break in and swipe whatever they like.
No matter how secure the system, the weakest link can be the clerk who's
paid $12K/year to work on the system. It doesn't take much money to
convince this person to hand out our personal information.
This sort of thing kind of makes the hassle I went through in keeping my
SSN from my insurance company. If you've never tried it, for me it was
a huge hassle... Apparently, all of my claims needed to be handled by
hand by one of the supervisors. Of course, if everyone did it, their
$4/hour clerks could take care of it.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD X11 scanning software.
[Also noted by Monty Solomon <monty@roscom.COM> quoting from Edupage,
and WOODWARD@BINAH.CC.BRANDEIS.EDU (Beverly Woodward), who cited the
article in "U.S. Workers Stole Data on 11,000, Agency Says" in
*The New York Times*, 06 Apr 1996, p. 6, from which most other
reports seem to have been drawn. PGN]
Terry Ewing (now 21, with 21 months in federal custody ahead of him)
downloaded 1,700 credit-card numbers off of a Tower Records computer system,
just before leaving for DefCon, the West Coast "hackers' convention". His
friend Michael Kim (now 20) is facing an 18-month sentence. Apparently,
Tower folks knew their systems had been under attack previously, and were
monitoring misuse. Police encouraged Tower to wait for the next attack --
in which the intruders used the Tower computer to sort the captured
credit-card numbers by expiration date and create a file of those with a
date at least a year away — while being observed. Agents tracked the
intrusion to their apartment, which was searched, revealing the purloined
information. The two young men were convicted of a felony, although they
had not profited from the credit-card numbers. [Source: *San Francisco
Chronicle*, 8 Apr 1996, p.A2.]
The article concludes with a quote from Mike Godwin of EFF about those
who ``have this myth that they are cool guys, and [that] the cool guys
always win over the suits. But the fact is that they are half-socialized,
post-adolescents with serious ethical and moral-boundary problems.''
[Stores should not store credit-card numbers, but I guess we can no
longer number the stores that do not behave sensibly. I just asked a
mail-order outfit if they would keep a card number around for a
long-deferred delivery; the answer was, ``yes, but we keep in a place
where no one can access it.'' I am sure that gives you RISKS readers a
lot of comfort. PGN]
The 6-7 Apr 1996 edition of 'The Weekend Australian' carries a report (p 5) on a court case involving the large Australian insurance company AMP and an attempt to build a large database of all Australian households. It was alleged that the "massive database... was supposed to identify every household in Australia, give each household a unique identifier number, detail the dwelling type of each household - whether it was two-story, weatherboard [timber] or brick - and also detail the fire, storm and flood risk rating of each home." The contractor developing the database, Indata, expected this database to give AMP a significant commercial advantage. This database was alleged in court to to have been based on a magnetic tape of the Australian electoral roll. Under the Australian Electoral Act, magnetic tapes of the electoral roll cannot be obtained for commercial purposes. The former manager of Indata said that he had assumed AMP had investigated the legalities of purchasing the tape and that Indata and AMP were acting within the law. The tape had already been purchased before the manager joined Indata. The court case is a committal hearing against a former AMP client manager who is charged with 12 counts of attempting to defraud AMP. The fraud involves payments to Indata totalling $324,809 (Aus). AMP is expected to claim that was not aware of the illegal purchase of the electoral roll and that their client manager had inappropriately authorised payment to Indata. AMP has demanded return of the money. The committal hearing will continue next month. andrew waugh
At http://www.timing.se/Daylight.html there is a brief discussion of the rules for Daylight Savings Time changeovers for central Europe and the UK. At the end of the page it says: > NOTE: From autumn 1996 the rule of changing from standard time to > daylight time is changed. The new rule is valid for central Europe > including the UK is: > > Standard time to Daylight Saving LAST SUNDAY OF MARCH > Daylight Saving to Standard time LAST SUNDAY OF OCTOBER > > The rule is a "de facto standard," not a law. > > The switching occurs at 01:00 UTC for central Europe (Stockholm Paris etc.) > Local time that is at 02:00 STD to DST and 03:00 DST to STD. > (STD = Standard time, DST = Daylight Saving Time or Summer Time.) > > Note: The legal switching is steered by laws that state dates for a couple > of years. When a period ends a new law is issued that gives the dates for > the next years. > > The Laws do not state any general rule. Only dates for a couple years > each time. The "de facto rule" works, but there is no warranty it will > work forever! With all of our scrambling about to deal with the Year 2000 problem, shouldn't we be just as concerned with this inconsistency that arises yearly (especially if there are no 'hard and fast' laws/standards to dictate DST changeovers)? M. Welsh, mdw@cs.cornell.edu
If my bank kept my money in a cardboard box in their parking lot and children stole it, I would blame the bank before the children. As long as corporations and institutions design their computer systems only for convenience and least cost, with maybe a superficial gesture at something called 'security', they won't solve the problem. The biggest risk of all is from people who won't accept their responsibility. - William Ehrich
Like most e-mail clients, Microsoft's Exchange allows you to maintain lists of user's addresses along with aliases. In our simple configuration, we have two, a personal list and a global list. Up until recently, since our e-mail system was closed and limited to project members, my personal list was almost empty. Since we have added an Internet gateway, I've begun adding addresses not on the global list to my personal list. Exchange has another useful feature as well, it will expand names from just the first characters. If multiple names match the abbreviation, it will ask you to pick one. Today I sent out an internal message, using "schu" as an abbreviation for schumacher, which I have done many times in the past. Shortly there after the message was returned from the AOL e-mail daemon as undeliverable, highly surprising since it was an internal message not destined for the Internet. It turns out that last week I incorrectly added an AOL user whose name also begins with "schu" to my personal address list. Exchange apparently only checks one list at time, flagging multiple possibles only within the list. In this case, it checked my personal list first, matched the AOL user, and quietly sent the message on. If the name at AOL had been correct, I would have not known about the misdirection at all. The risks are obvious - instead of a somewhat trivial and incomprehensible internal message, the message could have been highly confidential or time critical. The solution is trivial as well - check all mail lists for conflicts (or at least have that as the default configuration & easily selectable).
>Usenet (at least NNTP) is generally 8-bit transparent, and any European >soc.culture group will tell you that ISO 8859-1 usually works, ... Though many machines on Usenet are eight-bit clean, NNTP is defined to be seven-bit. There's no guarantee that the use of raw characters in ISO-Latin-1 will come out unharmed on the other end. More risks: assuming that an action is advisable simply because it "usually works." This, unfortunately, is becoming more and more common even among news software developers, some of whom have simply conceded the seven-bit encoding battle and now write for an eight-bit net.
On 2 Apr 1996 16:20:16 GMT, sandee@Think.COM (Daan Sandee) said:
> [...] "co=F6perate", "na=EFf", and "Bront=EB.". [...] It was already
> mangled in the RISKS posting
Apparently, these examples were sent to RISKS encoded as "quoted-printable".
I guess, they were contained in an e-mail item adorned with the appropriate
MIME headers to announce that transfer encoding to any interested parties.
However, in the process of digesting, all header fields (except the From,
To, and Subject fields) were stripped off.
This seems to be a general problem with contemporary mail-digesting software.
Of course, the transfer-encoding has to be undone before you can safely
remove the pertinent header field. I hope, our moderator will be able to find
a mail-digesting program that handles MIME headers properly.
> [...] I wish people wouldn't assume that the way their machine handles
> non-ASCII characters is the same as everyone else's.
This is exactly the reason MIME was invented for.
> Usenet (at least NNTP) is generally 8-bit transparent, and any European
> soc.culture group will tell you that ISO 8859-1 usually works [...]
Not quite so! There are mail transfer agents, and perhaps other intermediate
software, that still will drop the most significant bit of every 8-bit
character.
> This post of mine, however, goes out by e-mail (SMTP) and upper bits will
> be stripped [...]
Hence, contributions to RISKS, and other e-mail based services, must exploit
MIME to convey those characters (until, eventually, the powers that be might
agree on a 8-bit, or even 16-bit, based mail protocol). It is the digester's
duty to undo any transfer-encoding before the mail is digested, and to encode
the whole digest for transport, as necessary.
> Well, I can handle diaereses all right, as long as they arrive in a form
> recognizable by my software.
And it will be the subscriber's duty to undo the transfer-encoding of the
whole digest.
Otto Stolz
[I have asked several folks what I would need to do to MIME-ify RISKS.
I get responses that it is not that easy, or that it won't help
those who don't deal with MIME, or that perhaps I should just
wait until things settle down. Meanwhile, we have a justification
for indigestion with undigestification. PGN]
Summary: a new CompuServe Information Service (CIS) logon protocol was designed to prevent passive and active attacks (where the attacker impersonates a CompuServe node) but a flawed implementation in the WinCIM 2.0(.1) client software still allows active attacks. Version 2.0 of the "WinCIM" access software introduced a new logon protocol. Previous versions of the software had transmitted the user's UID AND his/her password in plaintext during logon. The risks are obvious, especially when connecting via the Internet to CompuServe (e.g. to save long distance telephone charges). The new, "secure logon protocol" is a challenge-response type protocol where the "challenge" is to compute a keyed hash-function, the key is derived from the shared secret, the user's password: 1) The client (WinCIM) generates a pseudorandom string of bits, its "nonce" (RB) 2) The client transmits the user's UID (e.g. 12345,6789) and the additional parameter "/secure:1" to request a secure login. 3) The host transmits its pseudo random nonce (RA) (The old protocol would instead prompt for the password) 4) client sends RB to the host 5) client computes UR:=MD5(S|Z|RA|RB|S) and sends it to the host (where S (128 bits) is a function of the password, "|" stands for concatenation, Z is a 128bits block of 0s and MD5 is the well known message digest function.) 6) The host performs the same calculation with it's copy of the user's password. If the results match, the host sends HR:=MD5(S|Z|RB|RA|S) (Note the symmetry in the calculation of HR and UR) 7) The client software verifies HR with it's copy of the password to make sure the host is really a CIS node (!) (See the script-files cserve.scr and seclog.scr in the subdirectory SCRIPTS of a WINCIM 2.0(.1) installation, WinCim is available via anon. ftp at ftp.compuserve.com). Weaknesses: a) The scriptfile cserve.scr (versions 3.8 & 3.8.1) has the following bug: even after requesting a secure logon, the client software will fall back into the old protocol when receiving a "Password" prompt (Client: "I want a secure logon" Host:"OK, but anyway, give me your password" Client "Well ok then, here it is ..."). It will send the password in plaintext! This makes the protection against active attacks (see step 7) obsolete. b) A timeout condition or even an invalid HR response form the host will (seclog.scr & cserve.scr version 3.8.1) restart the protocol (it won't disconnect!), using *the same* client-nonce RB again, instead of generating a new one. If a spoofing host can predict RB as in this situation, it can pick the same nonce, leading to HR=UR=MD5(S|Z|RB|RB|S), so the host can just send back UR as HR. Note that unlike a), b) does not compromise the user's password. There may be other ways to predict the client software's nonce e.g. *if* the PRNG used by WinCIM is predictable (this calls for further investigation). Note that *offline* dictionary attacks to guess the password are possible after a passive, eavesdropping attack (so you still have to pick a "good" password). It's debatable whether CIS's password recommendation (<word>
IBMMAIL e-mail address woes
Erik Naggum <erik@naggum.no> 03 Apr 1996 13:11:21 UTYou may not know the IBMMAIL system. Internet addresses are translated to a seven-digit number, which users use instead of real addresses. It so happens that I once ran a large mailing list and needed to track down which messages were not delivered to which people, and so generated a unique Return-Path for each message. This caused a large number of IBMMAIL numbers to be assigned to such addresses. About once a month, I receive confirmations of business transactions between Hong Kong and Singapore companies to one of these addresses. Clearly, the RISK is that humans mistype numbers all the time, and when the addresses in a given range are all valid, will send mail to the wrong recipient every now and then, just as people misdial telephone numbers. All information expressed in long numbers whose accuracy matter to either party include redundant digits to reduce the number of valid numbers and to provide consistency checks. The same should be true of IBMMAIL numbers. (Indeed, it should perhaps be true of domain names and usernames, too.) #<Erik>
Re: X-Confirm-Reading-To: Pegasus woes on mailing lists...
Peter Yamamoto <pjyamamo@daisy.uwaterloo.ca> Thu, 4 Apr 1996 10:42:36 -0500 (EST)> Recently, on a mailing list I maintain, a Pegasus (the name of a > Mac/Windows e-mail reader) user posted a message with a line: > > > X-Confirm-Reading-To:
The risks of .forward
<cpbeaure@undergrad.math.uwaterloo.ca> Tue, 2 Apr 1996 11:12:20 -0500 (EST)Standard procedure for us net types is to leave .forward files when we change accounts. This is what I did when I left my previous employer. Because of the nature of the Internet firewall we had there, to access the net users had to actually log into the firewall machine - a bad idea in itself, but it gets worse. One fine day, I logged in to find a message informing me that the firewall password had changed. Conveniently, the message also included the new password. It seems that when I left, not only had they not erased the .forward file, but they hadn't removed me from the system alias file. The risks? 1) Clean up after your old employees. 2) E-mail goes everywhere. 3) Don't e-mail passwords. Ever.
Re: Wrong approach to Java security (Stuart, RISKS-18.01)
Andrew Berman <aberman@cs.washington.edu> Fri, 05 Apr 1996 16:59:49 PST>In RISKS-17.95, Jacob Palme suggests that the reputation of "well-kept >depositories" and PICS-like ratings can be used to guard against malicious >Java code. A more useful idea along the same lines is to allow for code to >carry a digital signature. ... Neither PICS-like ratings nor Digital Signatures is going to solve the problem. Yes, they might constrain some malicious users. But what about the data loss from buggy software? Also, decentralization of code is a promise of web-based languages. A world in which every piece of code has to be checked against a database of signatures is a much less flexible world than one in which code runs in a "safe" environment. Not to mention that a digital signature for a company will undoubtedly be known by more people than a digital signature for a single user. Thus, the opportunities for theft of the signature would increase dramatically. Andrew P. Berman Dept. Of Computer Science, University Of Washington aberman@cs.washington.edu| http://www.cs.washington.edu/homes/aberman
Re: Risks of rewritable BIOSes (Epstein, RISKS-8.01)
JEREMY J EPSTEIN <JEPSTEIN@mail.cordant.com> Tue, 09 Apr 1996 09:58:42 -0500After my posting in RISKS-18.01, several people sent me e-mail. A few clarifications to my original note: * Some PC vendors have a jumper that disables writing the flash. In my experience, this is unusual, although it's clearly present in some cases. For those who are lucky enough, the jumper is even documented. Clearly this is a good solution for those whose PCs have the option. Of course most users won't read the manual that comes with the PC and thus won't realize that there's a risk, much less understand how to thwart it. [Pointed out by mark@leasion.demon.co.uk (Mark Evans) and afelson@milton.ecte.uswc.uswest.com (Adam Felson).] [AND also by "Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU>, with the default being disabled — see the next item. PGN] * I wrote "...each vendor has solved the problem differently..." The word "vendor" should be understood as the vendor of the motherboard, which may not be the same as the PC vendor. That is, a brand X PC may use a brand Y or brand Z motherboard. So looking at the outside of the case may be insufficient to determine whether the PC is "safe". [Pointed out by Mark Evans.] * As an aside I wrote that the risk would be eliminated if people used more modern systems such as UNIX, OS/2, or NT. As pointed out by Benedikt Stockebrand (benedikt@devnull.ruhr.de), it doesn't *eliminate* the risk, because there may be bugs that allow subverting the system and thus gaining access to the flash RAM. Stockebrand also pointed out that (on UNIX systems) if you can get the virus/trojan run by root, then all bets are off. Perhaps I should have said that running a more modern system *reduces* the risk, since a virus/trojan would have to be a lot smarter than in a DOS/Windows environment. The above not withstanding, the point stands: most Pentium-based PCs are extremely vulnerable to flash-based attacks.
Re: Risks of rewritable BIOSes (Epstein, RISKS-17.81)
"Nicholas C. Weaver" <nweaver@CS.Berkeley.EDU> Fri, 5 Apr 1996 10:52:40 -0800Although I believe software solutions are necessary for correcting the flash-BIOS problem on existing motherboards, I think all future motherboards should just resort to an old-fashioned physical jumper. If the jumper is in place, then the BIOS is reprogrammable. (If a malicious person has access to your motherboard, he/she can do a LOT more damage then simply reflashing the BIOS, but a malicious program can't — especially if the motherboard is shipped without the jumper in-place.)
Re: Computers, Freedom and Privacy '96 (RISKS-18.01)
"Shabbir J. Safdar" <shabbir@panix.com> Sat, 6 Apr 1996 15:59:55 -0500 (EST)My RISKS commentary about the Bruce Sterling piece at CFP '96 drew many pieces of e-mail. You can get a RealAudio recording of it from URL:http://www.w3.org/pub/WWW/CFP4/live.ram (I don't have a RealAudio player on this machine, so I cannot verify that it works..) The live version left me feeling numb and panicky. [oram@unixg.ubc.ca (John Oram) reported that the audio version of the entire CFP 96 is available for your listening pleasure "(in the bandwidth-conserving RealAudio format)" at: http://swissnet.ai.mit.edu/~switz/cfp96/ .]Please report problems with the web pages to the maintainer
xTop