Computer filer got $325,000 in phony refunds, IRS claims John King, Globe Staff (Boston Globe of Thursday, August 17) Clever tax preparers are one thing, but a clever bookkeeper who allegedly pried 325,000 dollars from the Internal Revenue Service found himself on the wrong side of the law yesterday. In what may be the nation's first charge of electronic tax fraud, IRS special agents yesterday arrested Alan N. Scott of West Roxbury [a part of Boston], saying he claimed 45 fraudulent income tax refunds for amounts ranging from 3,000 dollars to 23,000 dollars. The IRS charges that Scott, 37, used the service's new electronic filing system -- open only to tax preparers -- to submit phony claims with assumed names and Social Security numbers. In some cases, the names used were of people in prison, according to Chief Kenneth Claunch, IRS Criminal Investigation Division. ``The computer age has spawned a new breed of criminal,'' Claunch said in a statement. New in tools, perhaps. As for the basic idea -- filing a false return in order to snare an unwarranted refund -- that's old hat, admitted IRS spokeswoman Marti Melecio. ``I can't say that it's a new trick. We've had fraud cases with paper returns,'' Melecio said. ``The time frame is different, though. With electronic filings, the returns come back in two or three weeks.'' According to the IRS, Scott received electronic filing status on Jan. 31. He did this by using a false Social Security number, and making false statements on his application. However, the IRS also says Scott electronically filed 10 returns where he used his own name as a preparer, and these returns appear to be legitimate. The scheme was uncovered by the a [sic] ``questionable refund detection team,'' at the IRS service center in Andover [Massachusetts]. Also, the IRS credited a tip from an unnamed boston bank ``which reported a suspicious electronic transfer of funds to an individual,'' presumably Lewis [sic]. If conviced, Lewis [sic] faces a possible prison sentence and up to 250,000 dollars in fines on each of the counts of fraud.
In Friday's (11 Aug) Wall Street Journal, there was an article on cellular telephones. Of particular interest was the discussion of using cellular phones to replace two way radio in police departments in "sting" operations. It seems that the people they were chasing listened to police band scanners and were evading the police, so the police switched to celluar telephones to maintain secrecy. I'm not sure if I'm more touched or scared by such misplaced faith in a new technology. (The lack of secrecy in cellular phones has been discussed at length in this forum.) --David Wittenberg
The August 7 issue of _Aviation Week and Space Technology_ has a feature story on how well flight automation has been received by aircrews. Earl Wiener (co-editor of _Human Factors in Aviation_, in which similar stats were revealed) has released the results of a survey of some 200 757 pilots. The data shows strikingly opposed opinions--either the pilots love the automated systems, or they hate them. The article mentions one problem, which hasn't gotten much press attention, is that the automated systems encourage a "heads-down" atmosphere under 10,000'. The UI's are apparently so bad that a single pilot must devote all his attention to updating and manipulating information in their flight management and control control systems (FMCS), in effect reducing the cockpit to single-pilot operation for substantial periods. The article also mentions identification of various problems that need attention: "* Further reduction of workload in low-workload phases of flight caused by automation (for example, long haul over water. * Further increase in workload in high-workload phases of flight caused by automation (for example, terminal area). * A potential for substantially increased "head-down" time. * Difficulty in recovering from automation failure. * Reluctance of flight crews to take over a malfunctioning automated system. * Deterioration of pilot/controller basic skills. * Complacancy, lack of vigilance and boredom in workers. * Introduction of unanticipated failure modes. * Incompatibility between advanced automated aircraft, existing air traffic control capability and the rest of the fleet." The article also notes some fairly critical UI problems: "Pilots even work around aspects of the computer program that do[es] not provide the desired performance. For example, crews who want to start vertical navigation descents earlier than the computed top-of-descent point simply tell the computer they plan to use anti-ice when, in fact, they do not, or they program in a fictitious tail wind. The computer then refigures a new top-of-descent poin tto the pilot's liking. This procedure is often needed because the Boeing 757, considered an aerodynamically stable aircraft, does not descend as readily as earlier models. Pilots like to avoid using speed brakes to conserve fuel and avoid disturbing passengers." It's interesting to note that Wiener wishes to solve the automation problem by imposing a greater level of automation (the article is fairly vague about what he has in mind--my interpretation is a combination of higher-level services and better-designed user interfaces). The article doesn't treat cockpits utilizing unconventional control laws, such as those the A320's fly-by-wire system utilizes (but otherwise, A320 flight management principles are quite similar to the systems utilized elsehwere). Some comments and opinions: The problems at altitudes less than 10,000' are quite interesting. Automation has generally been marketed as a "workload-saving" item. Particularly after the midair collision between a PSA 727 and a Cessna 172 in 1978, simplified cockpits, and consequent automation, was marketed as a means of keeping the pilots' eyes looking out of the airplane. In effect, however, the basic problem is unsolved (if, indeed, it was a problem, which is another story). Automation has done *nothing* to simplify the actual tasks of *flying* the airplane: the older autopilots, with heading, altitude, and airspeed select, were excellent aids to operating in control environments. The key in the current problems seems to be in the flight management control system, which first started entering widespread use in 1982-83. The idea behind the FMCS was that it could be programmed with economical flight profiles, and then be coupled to the autopilot, thus creating a highly economical flight. Comments in the Aviation Week article (which, incidentally, runs counter to the gung-ho attitudes in similar technology reviews in _Flying_ and _Flight International_) suggest that pilots are not utilizing the system, and that the system itself is not selecting the most optimal flight characteristics. In effect, they appear to be reverting to manual manipulation of the autoqpilot. Robert Dorsett UUCP: ...cs.utexas.edu!rascal.ics.utexas.edu!rdd
Many computers connected to the Internet have recently experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "telnet" programs illicitly replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs. (As a first step, frequent telnet users should change their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators can do to detect whether the security on their machines has been compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators should do the following: o Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail". In general, we suggest that site administrators be attentive to configuration management issues. These include the following: o Test authenticity of critical programs - Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords should be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on-line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes. o Privileged programs - Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) can be exploited to gain unrestricted access to systems. System administrators should watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access. o Monitor system logs - System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. o Terminal servers - Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts. o Passwords - Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets. System administrators should make sure that all accounts are password protected and encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. o Anonymous file transfer - Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol - which requires no username/password authentication) should always be configured to run as a non-privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, should not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure. o Apply fixes - Many of the old "holes" in UNIX have been closed. Check with your vendor and install all of the latest fixes. If system administrators do discover any unauthorized system activity, they are urged to contact the Computer Emergency Response Team (CERT). Kenneth R. van Wyk, Computer Emergency Response Team cert@SEI.CMU.EDU (412) 268-7090 (24 hour hotline)
I am aware of the RISKS attitude to redundancy, however I would like to present an Australian viewpoint on this incident. (see RISKS 9.9) First, some background. I have worked for the Australian Defence Dept. for six and a half years: five and a half as a programmer/analyst on real-time systems, and twelve months in Computer Security. I am currently on a twelve-month posting with the NCSC, gaining experience in software verification. The following newspaper article arrived in the mail from home yesterday. It is from the Melbourne 'Sun News-Pictorial', dated 8/8/89. "Terminal virus rocks defence" by George Megalogenis. "Australia's Defence Department has been bugged by a computer virus posing as a messenger for an illicit drug. Confused staff where [sic] greeted with the message: 'Your machine has been stoned - Legalise marijuana' when they tried to operate infected terminals last week. A spokesman confirmed yesterday that eight high-security terminals in Canberra came down with the bug. The defence bug was reported as having destroyed sensitive departmental data. The department is remaining tight-lipped on the source of the infection as it does not want to encourage computer hackers to pull similar stunts. A computer virus begins life as an innocent program on a particular terminal. But a hacker can use it to cause mischief by spreading the unwanted or false information to other terminals and systems. The programmer can also direct the virus to destroy existing files. The department spokesman said the technical virus had been 'isolated and the computers decontaminated'. The spokesman said he could not rule out the possibility that the virus was created by accident. The department was working on programs designed to weed out future intruders before they caused any damage, he said." A few remarks on the preceding: Ignoring (for the moment) the quality of the article: I am not surprised "the department is remaining tight-lipped"; based on my knowledge of the department, and of similar occurences in other government organisations, the most likely explanation for the appearance of the virus on Defence PCs is that someone brought into the office their own infected floppies, probably to play games. This sort of thing is not looked on kindly by the Department (to put it mildly). [The RISKS 9.9 posting suggested that the office, involved in virus/anti-virus research, might have had an internal accident: certainly possible - eight machines infected smacks of carelessness, but obviously someone was, somewhere along the line, whatever the actual cause.] Now to the quality of the article: this is (fairly obviously) an appalling piece of reportage - lack of technical knowledge on the part of the writer (and sub-editor) is quite evident in (among other things) the persistent use of the word "terminal" instead of "personal computer", and the amazing statement that "A computer virus begins life as an innocent program...". It is acknowledeged that the 'Sun' is not the highest quality newspaper in Australia - nevertheless it is not a typical tabloid-style either. Therefore, I personally find the lack of quality of information in this article disturbing (especially as the 'Sun' had given good-quality reporting and commentary on the Internet worm). The main RISK? the 'Sun' is the highest circulation paper in Victoria, if not Australia [approx. 650,000 daily]; its readership is typically blue-collar and secretarial/clerical type people - those most likely to be naive users of personal computers, and most likely to be influenced by (i.e. believe verbatim) the contents of this article. Anthony J. Apted DISCLAIMER: Any original thoughts expressed in the above are my own, and do not represent the views of either the Australian or American governments (any unoriginal thoughts are the responsibility of their owners).
W. German computer hackers accused of spying for Soviets (Boston Globe of Thursday, August 17) Associated Press (Frankfurt) --- Three computer hackers, suspected of giving the Soviet Union information from military and industrial computers worldwide, have been indicted on espionage charges, prosecutors said yesterday. The West German government called the breakup of the spy ring, which gave the KGB secret data from 12 countries, including the United States, ``a major blow'' to the Soviets. In a four-page statement, Kurt Rebman, the chief federal prosecutor, said it was the first time his office had prosecuted hackers for endangering national security. [See RISKS-9.34 for the earlier background on the Wily Hackers. PGN]
Another message in the thread of comments from my friend (replies to me for relaying, or to RISKS). Tim Douglas W. Jones states that the terms software engineering and software engineer have gotten out of control. He is correct, but it seems to me that his solution, to regulate the use of the title "software engineer", is a rather weak one. In his comment, he gives a general outline of a set of standards that have been suggested to restrict the use of the term engineer, and suggests that some similar approach might be used: > 1) People who have passed a state professional engineering examination. > > 2) People who have graduated from an accredited 4-year engineering program. > > 3) People who have graduate degrees. The problem with regulating the term is that it does not regulate the work that the individual does. In my last comment, I mentioned that I have worked with people who had A.A. degrees or were merely high school graduates who were called "software engineers". What I should probably have made clearer is that it is not simply that they call themselves that; it is what they are called by their employers. They will be doing the same work, with or without the title, as long as they continue to work for those employers. Software engineering, even compared to electrical engineering is a very young discipline. While I would meet the second of the criteria he lists, most of the professors I studied under to get the degree would not. As a group, their doctorates were in areas ranging from Physics to English, with only the younger members of the department having degrees in Computer Science. Software engineering is still very much in its infancy. There are several basic rules that derive from this fact: 1) Acceptable levels of knowledge and techniques for today will not be acceptable tomorrow. 2) There are not enough "real" software engineers available to do the work that requires their services. 3) There are a lot of people out there who call themselves software engineers who are not "real". An engineer, as defined by the firm I happen to work for now, is someone with a degree in an engineering discipline from a school with a recognized engineering department. A software engineer is an engineer who writes software, as opposed to a computer programmer who is a non-engineer who writes software. The two may work side-by-side on exactly the same task, doing exactly the same thing, but that is the only difference. Who gets assigned to what task is largely dictated by what the previous experience of the person is, not job title. This is in a large aerospace firm. An engineer, as defined by the last place I worked for, was someone with a certain minimum level of experience who worked overtime for free. The degree was accepted in lieu of that minimum level of experience, but that was about the only difference. The two people, one degreed, one not may work side-by-side on exactly the same task, doing exactly the same thing, with exactly the same job title. Who gets assigned to what task is largely dictated by what the previous experience of the person is, not degree status. This is not a large aerospace firm, but how different is it really? Is the fact that the software engineer got a degree 29 years ago in electrical engineering that significant to his job function? Many of the professors I studied under when I got my own degree had their degrees in areas unrelated to computer science. One of the most reliable (in terms of safe and effective product) "software engineers" I had the pleasure of working with in the past is not degreed. He learned his trade by the apprenticeship method, still one of the most reliable methods. He spent a great deal of time and effort in understanding the application area in which he worked, and the effort showed. One of the least reliable "software engineers" I worked with went to great lengths to make sure we all know he had a MS in Software Engineering from a good technical school. He was ultimately laid off because of the terrible quality of the code he produced, and because he refused to learn from people who were academically "beneath" him. it is unreasonable trying to regulate something that is not be possible to regulate. (Sure we can limit the use of the term, but can any agency actually place that stringent a limit on who actually does the work? When the people are simply not there to do it? Ask the INS about illegal aliens doing household chores and working in factories sometime.) I feel that a far more effective solution at this time, is to attempt to communicate with the companies involved with RISKy projects (either building them, buying them, or using them) about the type of expertise needed for these projects, to develop a set of livable standards that take into account the level of expertise presently available in the general population of "software engineers" available in the field (as the MOD has tried to do), and to attempt to produce enough QUALIFIED people to meet the genuine need for them. In this way, we have a livable (albeit painful) solution for the short term, and a reasonable hope for something better in the future.
> From: Rodney Hoffman <Hoffman.ElSegundo@Xerox.com> > Investigators said the individuals put together a major conspiracy > by knowing how to access airline computers to put travel itineraries > in the computer system. ++++++++++++++++++ In the interests of equal access to scammery to all, I will divulge some of the deep secrets of how to access airline computers and insert travel itineraries. This can be done from virtually any telephone nationwide (even a dial phone!). The process is virtually immune to tracing if you use a public phone; your identity is protected. First, it is necessary to determine the secret access code for the airline computer. To do this it is necessary to penetrate the telephone company's databases. Pick up the phone and dial 1-800-555-1212. This will connect you to a human-assisted database of access codes. Say (for instance) "American Airlines Reservations". The database system will read you a number, 800-433-7300. Hang up and dial this number (probably prefixed by a 1). This will connect you to another human-assisted database which stores all of American Airlines' itineraries. Simply state the date, flight number, departure and destination cities, and passenger name. It's that easy! You can later dial the same access number and cancel or modify your itineraries. The system even includes search functions if you don't know the flight number, and an extensive help system (just say "How do I make a reservation?"). It's almost like they tried to make this sort of illicit use simple. Jordan Brown firstname.lastname@example.org [Cute. But I suspect unauthorized on-line access might also be parlayed into other spin-offs, such as getting tickets issued without paying. PGN]
Please report problems with the web pages to the maintainer