|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1988)
DOCUMENT: Rutgers 'Security List' for May 1988 (14 messages, 14838 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1988/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- From: ZSYJKAA%WYOCDC1.BITNET@CUNYVM.CUNY.EDU 2-MAY-1988 18:25 To: security@aim.rutgers.edu
Thought I'd relate a recent incident to the group regarding computer virus writing and propogation. Apparently we have a professor who thought it would be a good experience for his students, as a project, to write (each) a virus, and demonstrate that it works. OK, in my opinion we're already on shaky ground assuming the 20 or so different viruses can remain totally isolated within the student-instructor environment. As you can guess, some of them have "leaked" out of the "lab". One report indicates that the instructor's hard disk was erased, and another that one student's final project was eaten by his own virus. At least one unrelated PC was found to be infected (in the University's Micro Resource Center!). There are arguments going backand forth about whether this was blatantly irresponsible, or if viral education is a good thing. One can't even consider firing the instructor because he's already leaving to go to another institution. So, this might be a good topic to kick back and forth for a while? What are the ethics/legalities of such an incident? For instance, in American law & philosophy, freedom of information is nearly sacred; is propoagation of the knowlege on how to write a virus itself a bad thing, or only the malicious and/or negligent spreading of one and it's symptoms/damage? Is the passing of this knowlege to a "random" group of students (where the professor is probably unable to evaluate each one's future intentions or views of morality) an unethical, if not illegal, act? Disclaimer: The above are my views, not my employer; I have not had direct contact with the professor or his students.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Sun, 1 May 88 13:33:11 +0100 From: Brian Randell <Brian_Randell%newcastle.ac.uk@NSS.Cs.Ucl.AC.UK> Subject: Prestel Hacking
The most celebrated "telephone hacking" court case in Britain so far involved penetration of British Telecom's Prestel viewdata service. Legal history seemed to have been made when the perpetrators were convicted of having committed forgery! However the Appeal Court threw out the conviction, and this decision has just been finally confirmed by the House of Lords. Thus in Britain, at any rate, it seems that new laws will be needed to cope with such activities. On April 28, the Guardian carried a lengthy article, written by one of the hackers. It is given here, in its entirety (without permssion), for the editor to hack out those parts which are most likely to be of interest to the RISKS readership. [Why should PGN have a British Telecom-like monopoly on bad puns!] Brian Randell HACKERS LET OFF THE HOOK Steve Gold explains what really happened in the Prestel case, resolved by the the Lords last week: "The first inkling I had that there was a world ready to be dialled up was when British Telecom installed international direct dialling in my home town, Sheffield, back in 1971. I soon discovered that you could dial certain codes and, subject to a slight deterioration in call quality, not incur any charges. This cost me dear. In May 1975, along with several other Sheffield students, I was fined (pounds)100 for placing national and international telephone calls without payment. Several years later, in 1983, I bought a computer. And while I was fiddling away with my Sinclair Spectrum, East Midlands Allied Press was busy negotiating with British Telecom to launch a microcomputing service on Prestel: Micronet 800. Initially the service was available to users of the Acorn BBC micro, but soon Micronet and Prestel launched a Sinclair Spectrum hard-wired modem, the Prism VTX5000. In August 1984 I bought one for (pounds) 74.95. I was equipped to use Prestel, but Prestel was boring. While waiting to be [admitted to Micronet 800, I discovered that, if you sounded plausible enough, you could gain editing rights to unrouted pages on the Prestel database. These pages were known as the prestel Scratchpad. A friend and I joined forces and developed a software editor for the Spectrum/VTX5000 combination and, much to Prestel's incredulity, began to use it to edit Prestel pages offline and upload them to the database. Before long, Micronet 800 hired us to edit pages on their database. In the summer of 1984, an electronic acquaintance (we had never met) told me that he'd discovered a simple ID of ten 2s and a password (1234) which gained admission to Prestel without paying. That was Robert Schifreen, and the ID was a Mr G. Reynolds, whose profile on Prestel identified him as a member of BT staff. He was entitled to look at areas on the database not normally accessible to members of the general public. Those pages contained the nucleus of how Prestel worked, right down to the telephone numbers of Prestel computers we'd never even heard of. One of these "development computers" had an unusual log-on frame: it welcomed modem users with, and prompted them to enter, their ID and password. It had a series of numbers on its log-on frame which both Robert and myself recognised as a Prestel ID and password. Keying in these numbers resulted in the user logging on (that is, gaining admission to the database) as the system manager. The system manager could do things with Prestel that no other user could do. this included interrogating the user files to obtain IDs and passwords by the cartload. Thus, at the press of a few keys, the system manager could obtain information that enabled him or her to log on as any other subscriber on the system. Also, using information-provider IDs and passwords, it was possible to alter or amend pages. We had hacked Prestel at the highest level. However, power brings responsibility, and since we were both active contributors to the Micronet database, we approached Micronet's staff to show them. Micronet duly contacted Prestel, who were made aware of the incredible loophole in their security. Prestel strove to protect the integrity of their database. Changing everyone's ID on the database was not worthwhile, in its opinion. Information providers - high-ranking subscribers who rented their own pages - were seen as a high risk, since anyone using their IDs and passwords (obtained using the system manager ID) could alter or delete pages at will. So within a matter of days, Prestel changed the information-provider passwords. But they made a mistake. Instead of changing them completely, they merely transposed the access and editing passwords! Since Robert and I were editors on the system (using Micronet-supplied IDs) we were notified that our original passwords of (say) ABCD and 1234 had turned into 1234 and ABCD. After a phenomenal process of deduction, we applied the same transposition to a selection of information-provider passwords in our possession. They worked. Fortunately for BT, information providers realised the crassness of Prestel's attempt to plug its security and changed their own passwords, thereby barring normal (but unauthorised) access to Prestel editing facilities to Robert and myself. But amazingly, Prestel had left a trapdoor for us to use. The high-speed update ports, by which information providers could edit their pages in bulk, required only an editing password. Most information providers kept their own editing password, believing that their access passwords had been changed. After noting a little judicious editing, Prestel was faced with the awful truth: it's security division had said that the hacker problem had been resolved, yet pages were being changed again under their noses. Prestel finally changed its information-provider IDs and passwords, thereby plugging the gap. And that seemed to be that. We had told Prestel (via Micronet) about the security lapse. We'd also had a little fun at Prestel's expense. Prestel recognised what we had done, and that we hadn't done anything stupid such as altering or deleting pages on the database. The incident passed into history, or so we thought. During October and November, Prestel placed a telephone tap on Robert's north London home telephone line. After monitoring his activities they found he was frequently calling a Sheffield number (he was comparing notes with me). By January 1985, they thought they had enough information to prosecute us both. Had we know about it, we would have expected a prosecution under the Theft Act - for theft of (minute amounts of) electricity. But Prestel and BT were worried about computer-hacking. IDs and passwords were being exchanged at an alarming rate. Prestel IDs (as passwords) were assuming the same level of security as train numbers. ID spotters (apprentice hackers) were hanging around on Prestel, using the message boards (chatlines) to exchange passwords. BT logged Robert sending me an electronic mail message (using someone else's ID and password). The message contained the ID and password of that account. BT later produced that message in court as confirmation of our hacking activities. Unknown to BT (and Robert) however, I had already obtained this particular ID and password from the Prestel chatlines. I already knew that these particular details were passing around dozens of users. Prestel had problems. Hordes of youthful users were staging multiple log-ons. One particular group even boasted of its intention to "clock' an account one weekend. Like car mileometers, Prestel accounts had a rolling tally of the charges on an account. These went up to (pounds) 9,999.99, at which point the meter would roll over to zero and start again. The chatline boasters intended continually to access chargeable areas of the database until the (pounds) 10,000 mark was broached. Such pointless activities took place often in 1985. Prestel thought they had tracked two major hackers in Robert and myself. In fact they had latched onto two journalists who were compiling a dossier of online security breaches. The real hackers were - and are - still at large. On Tuesday March 26, two groups of police officers and BT staff simultaneously raided my house in Sheffield and Robert's house in north London. We were both driven to Holborn police station in London and held overnight and throughout most of the following day. It was with some amazement that I discovered in the course of my interview with Detective Inspector John Austin and BT security chief Ron Aston, that I had been arrested for hacking. Up to that point I had suspected that someone - probably an online acquaintance - had committed a major bank robbery. We were subsequently charged with committing a number of offences contrary to the Forgery Act 1981. Forgery is, we were told, a serious offence and can carry a prison sentence of ten years. Ten years - just for breaking into Prestel, and telling them what we had done! Rather than printing dud fivers in our kitchens we had "forged" an area of Ram (random access memory) in the Prestel computer - using our modems over the telephone line - which existed for about one fortieth of a second before being wiped clean. Could BT provide the instrument (the area of Ram) in court, the judge asked. No, since the area of Ram was etherial. It was, in fact, an area of the program known as the user segment. Our guilt or innocence hinged on how an electronic signal was interpreted by the court. We were convicted and fined, but the case came up for appeal in July last year. The three Appeal Court judges - presided over by Lord Justice Lane - mulled over the arguments. Several weeks later, Lord Lane announced he was quashing the conviction, calling the case a blatant attempt to mould the facts of the case to fit the scope of the Forgery Act. I was dismayed to discover that BT had applied to take the case further, to the House of Lords. But the highest court in the land concurred with Lord Lane's decision from the Appeal Courts that, if hacking was to be considered a crime, then a change in the law was required. We are free, but the issue remains unresolved."
-----------[000002][next][prev][last][first]---------------------------------------------------- From: goldstein%star.DEC@decwrl.dec.com 3-MAY-1988 18:56 To: security@aim.rutgers.edu
ORG5NMC@CMS1.UCS.LEEDS.AC.UK asks...
(If you put your real name on the message, I'll feel like I'm
answering a person rather than a string of alphabet soup.)
> I want to ask a question about computer security. Are there
> any legal obligations (British or American) on a computer user
> who finds a major flaw within a popular OS?
Legal: no. The laws surrounding computer security are in an incredibly
primitive state. In the US and some European countries, unauthorized
use of computers is now explicitly illegal; in the UK, recent
decisions I've heard about indicate that there is no law against
simple unauthorized entry. Enforcement is yet another story, ranging
from the French throwing Steffen Wernery in the nick on suspicion of
hacking, to the Germans having to catch someone at home with his
fingers in the cookie jar, with the US somewhere in between.
But I know of no law that requires an individual to report security
problems. If I attempt to draw a parallel to other industry, I don't
believe there are any laws requiring private individuals to report,
say, safety problems they become aware of. In general, concealment of
risks is only illegal where the party who hides information stands to
gain from having the information remain secret (e.g., by avoiding a
costly recall campaign or expensive safety improvements in a factory)
or has control over the risk.
But I do think people whe find a security problem have a moral
obligation to report it. People who find security problems are in
general professionals or researchers, and carry an obligation to the
advancement and improvement of the art. Reporting problems is part of
that obligation.
> How could a private
> individual bring a bug to the attention of a computer manufacturer
> given that site computing personnel take a dim view of anybody who
> finds these bugs?
I'm distressed to heard that site management personnel would be so
short-sighted to discipline someone who searches for security bugs.
If a security problem exists, someone will find it sooner or later;
I'd rather it were the curious but responsible hacker than someone
malicious.
Do please report the problem to the manufacturer. Easier said than
done, of course. Most major computer manufacturers have large
bureaucracies dedicated to "customer service", and wading through
this bureaucracy and its rules can be tedious. DEC is no exception.
Try starting with the nearest software service office. See if you
can get through to someone technical. I like to think that we've
done a pretty good job of instilling in our technical support people
the appropriate Pavlovian response to the phrase "security problem in
VMS". (If you haven't guessed, that response is "contact engineering,
fast!")
If you can't get through this way, like because you can't get past
the secretary because you don't know your service contract number
or don't have one, see if you can get through to someone responsible
at a regional office like Basingstoke. (Colorado Springs in the US.)
If this doesn't work, try the informal but direct route. The engineering
folks of most of the major manufacturers are reachable via the
internets. All you have to do is find out who they are. Look for
people who discuss security things in the newsgroups (like me here,
for example). I can't give you specific names for all time because
people change jobs, but recent mail ought to give you some leads.
Once you get electronic mail to an interested party in the company,
chances are pretty good the information will get to the right person
in a matter of days or even hours.
[You may wonder, why doesn't DEC just publish an internet address for
the express purpose of reporting security problems? It has to do with
who owns the nets and what they're supposed to be used for. By and
large, they are government funded, and are supposed to exist for
the benefit of the educational and research organizations. Having a
manufacturer make such a direct use of the public nets smacks too
much of gaining commercial benefit from a publicly funded facility.
Also, it gives rise to complaints of preferential treatment for
sites that happen to have internet access. Obviously, any information
volunteered to individuals via the internet will be put to appropriate
use by the manufacturer, but expressly setting up a service appears
unseemly.]
If you've still gotten nowhere, you may have to try a broadcast
approach. Send a message to an appropriate newsgroup (like INFO-VAX
for VMS) to the effect "I have found a security problem in xxx and
would like to report it to the responsible party. Would someone in
engineering please contact me?" I would guess that all the
manufacturers monitor the important newsgroups (DEC certainly does),
and you should get response fast. Of course, your site people may also
be reading the newsgroup, and if this is something you haven't told
them about and they have the attitude you described above, you may
regret having done this. You'll have to weigh the pro's and con's.
There is a logical next step one might consider, which is to publish
the problem itself. This I implore you not to do. Please don't even
tell your friends. Yes, you'll get lots of attention and action, but
you'll also cause both the manufacturer but mainly the entire user
base much pain. Think about it. You're the only person (in all
probability) who knows about this problem. If you're a responsible
guy, it'll be safe with you. But there are a lot of not very nice
people in the world, and a lot of copycats. If you publicize a
security problem, you give all these dirtballs a tool to go messing up
the lives of a lot of innocent computer users.
Even publicizing a security problem to "responsible people" carries a
risk. The more people know about the problem, the greater the chance
it will get out somehow. Even if the whole story doesn't get out, if
partial or distorted information gets out, others still will know
where to look. Consider the probabilities. The typical mean time to
discovery of a security problem in VMS is a couple of years. You just
found it. But the chance that anyone else working independently will
find it in the next 6 months is fairly small. Resist the temptation to
conclude that just because you found this problem, all systems in your
company or university are at risk and must be notified immediately. It
ain't so. The bug always looks horribly simple and obvious after
you've found it. But it's buried in a million or so lines of code, and
you got lucky. It's only a problem if you tell others.
There is a set of people who disagree with the above philosophy, and
will probably jump all over me when they see this message. (I've
gotten jumped all over each time previously.) I still stand by my
position. Others will claim that once one cracker knows about a problem
you might as well assume everyone knows about it. Further, they
claim that suitably informed system managers can take their own
defensive measures if they are informed about a problem. I don't
buy it, for several reasons:
(1) My experience tells me the cracker communications aren't that good.
Yes, some of them will post the news on bulletin boards and it
will spread some, but they're just not that globally organized.
The Chaos Club is an exception to this rule, but they're not
everyone.
(2) You can't tell the good guys from the bad guys. Make the information
available, and you will guarantee that it will fall into more of
the wrong hands.
(3) Some system managers will be sufficiently competent to solve the
problem on their own. The majority are probably not. Sorry, it
sounds like a damned elitist thing to say, but an operating system
is a complicated gadget, and if you fix something wrong you're
more than likely to break something else worse. What if someone
publishes a patch for the problem? Would you trust a patch for
your operating system coming from someone you never heard of? If
you would, read some of the recent mail about viruses and think
again.
(4) You won't reach nearly everyone. The internets reach only a small
percentage of the customer base of any of the major manufacturers.
So you do publish a trustworthy patch for all the internet users.
The other 90% of the installations won't get your message, and now
they're all the more vulnerable because all the bad guys who read
the net news know what the problem is. Not even all the folks on
the internets will get the message. I recently saw mail go by from
some poor soul who had not heard about the V4.4 SECURESHR bug, and
that one has been discussed extensively in INFO-VAX for months.
I've been in this debate for some years now, and everything I've seen
and heard tells me that if you find out about a security bug, you should
(1) tell the manufacturer as effectively and directly as you can
(2) otherwise shut up.
Well, that was a long answer to a short question. But it's one of my
favorite subjects. Thanks for listening.
Andy Goldstein
VMS Development
-----------[000003][next][prev][last][first]---------------------------------------------------- From: darrell%odin@ucsd.edu 6-MAY-1988 19:30 To: misc-security@cs.ucsd.edu
I have a question about the security of TV broadcast systems. We've all heard of "Captain Midnight" and his interruption of HBO (or was it Showtime?) using a satellite up-link. The other night, while I was watching "Conan the Destroyer" (no comments about my taste in movies please), a message came on in plain white letters overlaying the bottom of the screen: "This program brought to you by the association of american leprosy societies." This was on cable, watching a LA broadcast channel. Does anyone know how this could have occured? Sorry, I don't have a video tape to back up my claim, it was out on loan (why do you think I was watching Conan?). DL
-----------[000004][next][prev][last][first]---------------------------------------------------- From: Rob van Hoboken <RCOPROB@HDETUD1> 13-MAY-1988 22:37 To: SECURITY@aim.rutgers.edu
I have found many bugs and/or security exposures in MVS and as such have had to think up a reaction to such finds. I have done the following: 1. create a proof for submission to the manufacturer, 2. send in a documented error report to the technical rep. and a high ranking management type of the manufacturer. When after several weeks nothing has happened: 3. send the above mentioned trouble report to <trusted> colleages in other computer centers, and have them submit a similar report to the manufacturer. I have made a policy of never going <public> with such exposures because of the seriousness of the situation. Consider a computing center being faced with an exposure in one of its key software systems (e.g. their transaction system). What options do they have? 1. They can not remove the software from their systems, that would lose them millions of dollars PER DAY. 2. They could try to hack a fix for the exposure. Estimated time of success several weeks of <highly qualified> syspro work. Risks of malfunction of the entire transaction system, no support from supplier. No dice. 3. Monitor abuse of the exposure. Difficult. 4. Contact the supplier, explain the predicament and suggest you go looking for a replacement of his product. Usually successful, but it takes about half a year for a security fix to arrive. I think it is immoral towards colleages in your site and other centers to publicly announce a security leak. Even discussing it with too many syspro types is risky, because one of them may be a blabbermouth and spill the news to an unfriendly hacker or newspaper type. It happens to be our reality that you cannot close down a system on account of a security exposure if that system is earning you money. Fixing it is risky and difficult, so waiting for you friendly supplier is the best you can do. In this respect IBM has the best policy I know of: each contract contains a clause that a security exposure shall be dealt with within a specific time. I've seen it work and I am impressed. Of course some sites never apply the fix, so not everybody will be covered, but that is their risk. Other suppliers (on the IBM market) do not have a similar policy. I know of several instances where an exposure was not even fixed after three years. In one case I persuaded some of my friends to remove the product from their systems and terminate the contract with the supplier. I don't want to sound too gloomy, but the morally acceptable method will not always yield results. The (in my view) immoral way <may> yield long term results, but in the period between public exposure and fix your systems are extremely vulnarable to practically every hacker with assembler knowledge. In no way can you guard against that many possible perpetrators. The only argument I can come up with to defend a security through ignorance policy, is the small number of attempts that will be made on your system. I <may> be better to keep relatively inexperienced hackers unaware of exposures when knowledgable folks can find out. In the worst case it will save you unscheduled IPLs.
-----------[000005][next][prev][last][first]---------------------------------------------------- From: dasys1!stanleyw@rutgers.edu 15-MAY-1988 18:30 To: misc-security@RUTGERS.edu
Medeco Lock Co. had their cylinder tested by a government lab at Port Hueneme, California. The test, I believe, used sound waves to determine pin height. The test was performed around 1980. Does anyone have any info on the test and is there an NTIS number. -- Stanley Wociechowski Big Electric Cat Public UNIX ..!cmcl2!phri!dasys1!stanleyw
-----------[000006][next][prev][last][first]---------------------------------------------------- From: iberall%rana.usc.edu@oberon.USC.EDU (Thea Iberall) 23-MAY-1988 08:38 To: mit-eddie!elbows@bloom-beacon.mit.edu, mit-eddie!hair@athena.mit.edu,
The instructions that are sent with the program say that when compiled and run the program will draw a nice picture of a turkey. I have been informed that the program is a Trojan Horse. It does not draw a turkey, but it does erase all of the unprotected files in your directory. You might want to pass this information along to people you know who use the networks.
-----------[000007][next][prev][last][first]---------------------------------------------------- From: Liisa Rautiainen <TKOP_LR@FINOU> 23-MAY-1988 08:53 To: SECURITY@aim.rutgers.edu
I'm studying system analysis at the University of Oulu. Now I'm working with my
pro grad thesis subject of which is information system security. During the
summer 1988 I'm going to develop an overall security program for a computer-
center. Therefore I'm interested in all aspects concerning information security
and vulnerability.
I'm very grateful if someone could give me some hints where and how to get
latest information of the owerall security programs for computer-centers or
send information about the subject:
classifications of the system security aspects,
computer risks, vulnerability, risk analysis,
contingency planning and so on.
Yours sincerely Liisa
-----------[000008][next][prev][last][first]---------------------------------------------------- From: seven@vax.ftp.com 23-MAY-1988 14:45 To: elbows@bloom-beacon.mit.edu, dev@vax.ftp.com
In the 4/88 issue of Progressive Architecture:
Security: The Next Stage
[...]
Not Just Bricks and Mortar
Highly developed design tools are beginning to emerge in areas related
to security. As has been the case in other areas of design
(structual and energy systems, for example), engineers are providing
architects with computer-based techniques for analysis and design.
One such example, apparently unique, is BombCAD(TM), developed
jointly by the Evertt I. Brown Company and the Lorron Corporation to
assess the possible effects of terrorist bombings on buildings and their
components and Occupants.
In demonstrations of the program, using a hypothetical building and
site, BombCAD's developers are able to show a highly detailed diagram of
bomb-induced overpressures and impulse loads at interior and exterior points
of the building. The effiacay of new architectural and site elements - for
example, placing an earth berm at the base of a building, or specifying
stronger glazing and framing members for a lobby partition - can be assessed
readily.
Much of the knowledge used to develop this software has been available
in other places (for example, in monographs and tables provided in various
military design manuals and guidelines). And, as its authors redily
acknowledge, BombCAD has limitations (one of which is that the program's
estimate of human injury are based only on primary plast effects, while much
empirical evidence suggest that an equal or greater number of fatalites and
serious injuries may result from secondary and tertiary effects, such
as flying debris or subsequent building collapse). Still there is no denying
that the software integrates existing knowledge and gives it new
applications.
As security conerns continue to grow in priority among the traditional
clients for design services, we can expect more design tools of this variety
to emerge.
- By Thomas Vanier, AIA
[Accompanying the article are two examples of the program output from
a video display]
In a demonstration of BombCAD analysis, a car bomb (top, show as a
white star) explodes outside a building lobby. The program sets shock
impulse load and overpressures (figures in yellow and red) on key parts
of the building exterior.
BombCAD also can estimate interior blast loads and overpressures.
Red stars indicate locations of other potential bombs, whose characteristics
and effects can be modeled seperately. A second example (above) illustrates
one of many possible placements of a so-called briefcase bomb. The program's
flexibility allows examination of many possible bomb locations and charge
weights.
-----------[000009][next][prev][last][first]---------------------------------------------------- From: NG44SPEL%MIAMIU.BITNET@CORNELLC.CCS.CORNELL.EDU 27-MAY-1988 00:25 To: SECURITY%AIM.RUTGERS.EDU@RELAY.CS.NET
I am currently researching "computer viruses", trojan horses, and the like. The report which I plan to prepare will include descriptions of various public domain and commercial software which claim to protect from or detect viruses. Some examples of software I am evaluating are: DataPhysician, Triad line, Protec, VI-RAID (commercial), Flushot+, Novirus, Checkup, and CRCDOS (public domain). If anyone is currently using any of these programs, or others like them, I would greatly appreciate your sending me information describing how they are implemented, access controls you have in place, and anything else which you think will be of help. I will be happy to describe the results of my research on SECURITY. Thanks. Neil Goldman (NG44SPEL at MIAMIU.BITNET)
-----------[000010][next][prev][last][first]---------------------------------------------------- From: wadlow@godot.psc.edu 27-MAY-1988 01:27 To: misc-security@uunet.uu.net
>Medeco Lock Co. had their cylinder tested by a government lab at Port >Hueneme, California. The test, I believe, used sound waves to determine >pin height. The test was performed around 1980. I have never seen any info about tests of that sort... It sounds kind of pointless to perform this sort of test on a Medeco though. Once you know pin heights, you still don't know the rotation of the assorted pins, so you still have a decent number of permutations in order to find the correct combination. I can see more use in performing this sort of test on a Best cylinder, or some other cylindar that doesn't rotate the pins. Steve
-----------[000011][next][prev][last][first]---------------------------------------------------- From: abrams%community_chest.mitre.org@gateway.mitre.org 27-MAY-1988 11:15 To: abrams%community-chest.mitre.org@gateway.mitre.org
This note is addressed to the entire list because (a) of its general interent and (b) Liisa's original note did not indicate which network to respond to. (Liisa, please contact me directly.) I recommend "Building A Secure Computer System" by Morrie Gasser, Van Nostrand Reinhold, 1988 and "Tutorial: Computer and Network Security" by Abrams & Podell, Computer Society of the IEEE, (Computer Society order number 756, IEEE Vatalog number EH0255-0), 1987. Sincerely, - Marshall D. Abrams, phone: (703) 883-6938 The MITRE Corporation, 7525 Colshire Drive Mail Stop Z670, Mc Lean, VA 22102 Alternate e-mail address: abrams@mitre.arpa
-----------[000012][next][prev][last][first]---------------------------------------------------- From: Douglas Humphrey <deh@eneevax.umd.edu> 27-MAY-1988 14:00 To: deh@eneevax.umd.edu
An interesting possibility for lock work would be a Sonogram system, used to look into peoples internal organs, etc. with sound waves. These seem to be pretty portable. I wonder how well they would work. Anyone know more about this? Doug
-----------[000013][next][prev][last][first]---------------------------------------------------- From: PALMER at DUVM 29-MAY-1988 16:05 To: SECURITY@aim.rutgers.edu
Taken from the Sydney Morning Herald and the May 22, 1988 issue of Awake magazine. In an effort to outwit phonebooth theives, Telecom, Australia's government- owned telephone company, has fitted the susceptible booths with Kirk safes. Named after the worker who invented them, the safe has so far proved 100- percent effective. As mentioned in the Sydney Morning Herald, it has with- stood 'oxy torches, ramset guns, angle-grinders, hydraulic jacks, pulley clamps, centre-punches and bricks.' Ironically, the new safes appear to have led to an increase in vandalism, as theives frustrated by the tough safes vent their anger on the booths. Telecom reports that the current rate of smashed glass and ruined handsets and cords is at a new high of 3,000 cases per month.
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |