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…
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 jbrown@jato.jpl.nasa.gov [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