>From the time of an upgrade on 1 Jan 1997 until 26 Jan 1997, the mechanisms that are supposed to block the Calling Number ID (misnamed Caller ID) service FAILED in the 510 and 415 areas codes. As many as 516 businesses with PBXs were able to obtain calling numbers despite presumed blocking. (Something on the order of 50% of the subscribers are rumored to have requested blocking.) [Source: *San Francisco Chronicle*, 14 Feb 1991. Watch out if you thought you were sending anonymous tele-valentines to companies with PBXs!]
In RISKS-18.81, we noted that Ian Goldberg of U.C. Berkeley had cracked the 40-bit RC5 in 3.5 hours — the first step in the RSA Data Security challenge posed on 28 Jan 1997. The second step was taken on 10 Feb 1997 by Germano Caronni, a graduate student at the Swiss Federal Institute of Technology. Caronni (with a lot of help from his friends) has recovered the key for text encrypted with 48-bit RC5, with the help of 3,500 computers and attaining an peak rate of 1.5 trillion keys searched per hour, over a period of 312 hours. A press release from RSA (given some circulation in the media) on gives some details. Close to the median expected effort, about 57% of the key space was exhausted. The Caronni team is now working on the next challenge, RC5-56. It is easy to clone yourself through virtual replication. [In this case, the team has a lot of Caronnis!]
The National Association of Securities Dealers (NASD) is the self-regulatory organization that oversees broker-dealers and their employees in the United States. It maintains a database of brokers and any disciplinary action taken against them, a database that the public can access by calling Disclosure, Inc. (1-800-638-8241 in the U.S.) It's a good idea before doing business with a new broker-dealer or a new broker to call Disclosure to check if they have been a problem for other investors in the past. Unfortunately, the NASD has purged 20,000 records from their files. According to the Associated Press, The NASD said it inadvertently issued faulty guidelines telling clerks that "revised'' rules allowed them to purge a broad range of disciplinary data from the central registration depository. The risks are (at least) threefold. First, that investors will not have access to this valuable information and that people may deal with unscrupulous brokers as a result. Second, other regulatory agencies that rely upon the NASD's record will not be able to perform their functions. Thirdly, the NASD itself will not be able to refer to past disciplinary records on these brokers in deciding penalties in response to new complaints. The NASD believes it will be able to reconstruct its records in a couple of months.
In this month's _Scientific American_ there is a section on the Internet. The first full-page graphic has a flow-chart-like diagram over the user's monitor. One line near the top illustrates the risks of technical illustrations without careful review by a knowledgeable person: (Conditional box) "Already open for exclusive use and not the supper user?" This error isn't as bad as the _Dr Dobb's_ cover illustration of a "red-black" tree where the elements of the tree weren't sorted (*oops*), or another "photorealistic" depiction of a lightbulb that could never be screwed into any socket on this planet (due to the image being flipped during layout), but it's still enough for me to wonder how much care went into the other graphics in the article. At least all of the countries in the European/middle Eastern map appear to be present. (Unlike a major newsweekly that attempted a very creative approach to regional peace a few years back. :-) Bear R Giles email@example.com [Pay to the Bear-R? or the Bare "R"? PGN] [I had to point out in my role as panel chair for the cryptographer's panel at the January 1997 RSA Data Security Conference that the artist who rendered the giant version of the standard RSA two-key logo had neglected to realize that the two keys were supposed to fit together. They did not. PGN]
Summary of recent attacks that have become more well known. These attacks have been discussed on NT Security mailing list but the knowledge about them has not spread widely outside of the security mailing list circle: NT CPU Port Attacks, NT DNS Denial Attack, NT Trojan Password DLL. * NT CPU Port Attacks On NT 3.51 and NT 4.0, there are TCP ports that are open that when an attacker connects to them, types in some random characters, and drops the connection, the CPU on the machine goes to 100% usage. For example, connect to TCP port 135 (RPC server), type in "thiswilldoacpuattack" and disconnect. Then check the CPU usage. The CPU will be at 100% usage and the machine will be noticeably slower. It is possible to kill and restart the rpcss process to stop the CPU usage. DNS (TCP port 53 & 65589) is susceptible to this attack as well. In 16-bits, port 65589 is port 53. 65589 = 0x10035. 53 = 0x35 Solution: On NT 4.0, there is filter capability to block all TCP ports except needed critical ones. You may want to enable that. There is a hotfix available on ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP2/RPC-fix There is a DNS beta that fixed the random character on the port attack. It is available via ftp from rhino.microsoft.com, log on as DNSBeta with a password of DNSBeta. In the /service_pack3/x86 directory there is a file called DNS.EXE dated 1/26/97. * NT DNS Denial Attack If an attacker spoofs a response that the DNS never requested, DNS will terminate. There is an advisory on this available at http://www.iss.net/lists/general/0118.html Solution: Currently, Microsoft is working on a solution. * NT Trojan Password DLL On NT 4.0 and 3.51, there is some entries in the registry that point to a DLL that does not exist, that lets an attacker to put their own DLL in place. There is one DLL that will capture all password changes into a file, so an attacker can obtain any passwords that get changed pertaining to passwords residing on that machine. Ideally for an attacker, placing the DLL on a domain controller machine where most password changes can take place may produce the greatest amount of password information. More information is available with source code for the password changer DLL at: ftp://ftp.iss.net/pub/lists/ntsecurity-digest.archive/v02.n114 or Knowledge Base article http://www.microsoft.com/kb/articles/q151/0/82.htm Solution: To defend against this type of Trojan attack is to protect access to your registry fiercely. A routine part of your security maintenance checks should be to take a close look at this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\Notification Packages Make sure that it does not contain any strange entries. NT 4.0 ships with a single entry to this registry key: FPNWCLN If anything else in this registry entry, find out what it is and whether or not it's needed. If not sure, remove the errant entry immediately. Netware requires the DLL, so if you already have installed the Netware DLL, then it should have be installed admin-writable only. If you do not have the Netware DLL installed, make sure the register entry is blank. Acknowledgments Thanks to the posters of the NT Security Mailing list where almost all of this information was derived. To subscribe, send e-mail to firstname.lastname@example.org and within the body of the message, type: "subscribe ntsecurity". Christopher William Klaus, Internet Security Systems, Inc., 41 Perimeter Center #660, East,Atlanta,GA 30346 http://www.iss.net/ (770)395-0150
In a German TV show, 3 East German hackers (remotely linked to in/famous Chaos Computer Club) demonstrated how inherent risks of Microsoft`s ActiveX technology can expropriate naive users. The hackers prepared a Web page attracting interest of surfers ("Becoming millionaire in 5 minutes"). When this Webpage was contacted via Microsoft`s Internet Explorer, an ActiveX control would be downloaded into the victims computer. This control would access Quicken (a program aimed at assisting electronic banking) to generate a transaction form to transfer some electronic cheque to some account specified by the hackers; this cheque would be trans- mitted with the next collective remittance. This may be the first "Hostile Control" which has been demonstrated in the public (btw: several Hostile Java Applets have appeared at several Internet sites; as such Hostile Applets as well as experiments with Java "viruses" have not been publicly displayed, the broad public tends to assume that Java Applets are "secure" :-). According to some Microsoft expert, "all users should know" that ActiveX may have such side-effects which may include sniffing of disks as well as remote installation of software. A spokesman representing Microsoft Germany even suggested to disable ActiveX if the system is used for purposes of electronic fund transfer. Concerning general protective action against malign effects of ActiveX, Microsoft suggests using its ActiveX "certification" option: users should "only allow" remote access from "trustworthy" programmers. A 3-level scheme (low - medium -high) of trust is supported. On "high", only controls with an "authenticode" are permitted; no warning is given when such a code is detected. Any programmer can buy his authenticode for 20 dollar. Any risk? No risk if you regard Microsoft or its affiliated programmers as "trustworthy". Klaus Brunnstein (10 Feb 1997) PS: concerning "trustworthiness": apart from many safety and security problems, users owe Microsoft the deployment of the first Macro virus (Concept.A), and the proliferation of several Wazzu`s which have escaped from several Microsoft CD- ROMs and WWW pages to the "interested public". Users will experience major problems with enhanced macro viruses to work under Office 97, and users will see more platforms to be attacked. Thanx to Microsoft :-)
While the security community has fully recognized the risk of accepting controls from untrusted sources, it seems to have completely ignored a secondary risk of an existing control being subverted in unexpected ways. Perhaps all of the controls that come with MSIE are perfectly safe, and can't be subverted in any way (no buffer overflows, no mistakes), but it seems highly unlikely that _all_ controls are written so perfectly. Since one is basically giving away control of ones desktop to a web author by enabling ActiveX within a browser, many companies are avoiding the technology like the plague. Filtering it out at ones firewall is hardly effective, unless one were to parse through every HTML page and automatically remove the components that drive ActiveX (i.e. VBscript, the Object tag, etc). Not allowing ActiveX to be enabled in a web browser would seem to be a minimum requirement, not allowing browsers that support ActiveX would seem to be even better (and easier for a firewall implementation to handle - if the firewall sees that the user agent supports it, it could refuse to service it). Until the vendor gives us more control over when/how a control gets _used_ (not just control over when they get downloaded), I'll personally avoid the technology. I hope Dan Wallach's supposition that the vendors are working on it is true, but if they are, they're keeping awfully quiet about it (refusing to acknowledge that there even _is_ a problem). Of course, that's nothing new. "Full disclosure" of security bugs has done more for improving security in the last few years than 20 years of discussion about "risks" has done (not to belittle the work done by the readers of _this_ mailing list/newsgroup, I just wish vendors would recognize that todays risks are tomorrows exploits). Joe Meadows [as always, usual disclaimers in risks.info apply]
Eastman Kodak Company has announced a product safety recall for some of its digital cameras because their battery packs overheat and rupture when charged. Only about 1900 "professional" cameras in the DCS 420 and 460, and AP NC 2000 series are affected. Kodak will handle replacement requests at (800) 698-3324 in the USA or through Kodak representatives overseas. This is barely a computer RISK. Ordinary cameras usually have tiny batteries and no provision for connection to mains power. So long as "digital" means "using lots of electrical power" portable digital devices may pose physical risks that older technologies do not engender. Mark S.
Researchers at the University of Toronto say that drivers whose attention is distracted while talking on a cellular phone are four times more likely to be involved in an accident. However, insurance companies do not plan to raise insurance premiums, because accident rates have not increased overall. The researchers also found little difference between the use of a receiver or hands-free model of phone, indicating that the problem is one of mental, rather than physical preoccupation. (*Toronto Globe & Mail*, 13 Feb 97, A1; Edupage, 13 Feb 1997)
In RISKS-18.81 about the IRS axing the Tax System Modernization project, PGN added a parenthetical comment: <>Gross is proposing to contract out the processing of individual returns to commercial firms (which raises all sorts of privacy issues), although that is only a small portion of the processing demands.<< This has shown up elsewhere, I guess expressing a concern that if the IRS used commercial firms to process tax returns, the risks to taxpayer privacy might *increase.* This concern must flow from a belief that a government agency or employee is less likely to compromise the privacy of a return than would a private sector employee. Of course, the government agency usually has a monopoly on processing and the government employee generally has little to fear as far as termination of employment due to inapropriate handling of sensitive materials. So, I think the motivation for meeting privacy standards is good deal stronger in the private sector. >From a privacy perspective, I don't think too many of us would want a government agency preparing our tax returns, handling our checking account, or storing the records of counseling sessions - yet we routinely rely on commercial firms for those private matters. The real risk of outsourcing such processing will be the realization that there are no defined policy/procedures/standards for what constitutes proper handling to maintain some level of privacy. If encryption is to be used, how strong? etc. John Pescatore, Trusted Information Systems, 15204 Omega Drive, Rockville, MD 20850 email@example.com 301-947-7153, 301-527-0482 (fax)
>3. Cyber Promotions Inc got dinged twice this week. .... federal court >barred them from falsifying their FROM: addresses. ... I assume the last one refers to the settlement between CP and AOL. That is, unfortunately, not what it said. The settlement AOL and CP signed onto says that CP will not be legally barred from sending e-mail to AOL's customers, but that they may do so only from a specified list of domains (five domain names, to be precise). AOL customers who wish to receive these messages (and AOL people assure me that, strange as it may seem, there are some who do!) can do so by disabling the PreferredMail blocking system. The benefit to AOL, of course, is that they will no longer have to update their list of blocked domains daily with whatever new domains CP came up with (some of which were not real, and some of which weren't even valid domains). Cyberpromo delenda est!
In RISKS-18.81, Nathan Myers talks about a Word virus that apparently got loose during a recent meeting of the C++ standards committee. I have a few more remarks to add: 1. At the time of the meeting, Microsoft had had a program available for more than a year that would detect and remove such viruses. Nevertheless, only a few committee members had that program installed on their machines. 2. The present version of Word has automatic macro execution turned off by default, so such viruses cannot propagate without explicit user action. 3. Troff has had the capability for similar viruses for many years. I suspect that the reason it hasn't been a problem has been the relatively smaller number of users. Once the existence of Word macro viruses became known, I think Microsoft acted reasonably promptly to make a defense available. Yes, they should have been aware of the possibility before that, but I think it's going a bit too far to say they deserve to be sued. Lots of software companies have done worse. Andrew Koenig firstname.lastname@example.org
Never mind 2000, some people are still having trouble dealing with 1990. A recent posting by Steve Lau in misc.transport.urban-transit refers to certain tickets used for combined travel on BART and Muni, two transit systems in the San Francisco area. Among other problems, he reports that: > the machines that dispense them can't print dates beyond 12-31-89. All > of the tickets come out dated 1987. Last year they came out dated 1986. And, yes, on at least one occasion it was claimed that his ticket was ten years out of date! Mark Brader, email@example.com, SoftQuad Inc., Toronto
Please report problems with the web pages to the maintainer