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…
A Web site, http://www.aol-billsite.com/, was recently brought to my
attention. It has questionable content and most certainly a questionable
intent. From my investigation, it appears that the intent is to purloin the
information necessary for identity theft from unsuspecting AOL subscribers.
In summary, the domain name www.aol-billsite.com serves a web page that uses
a frame set to obscure the source of the real contents. The real contents
contain a very official looking form for "customers" to enter new billing
information for their AOL account. In addition to a credit-card number this
form asks for social security number, mother's maiden name, and a second
credit-card number.
If some poor, unsuspecting person actually presses the submit button on this
page, the information is sent in the clear to a CGI program on yet another
web server which presumably sends this information via e-mail (also in the
clear) to a hotmail.com e-mail account.
I believe it is immediately evident that the intention is to steal the
information necessary to perform identity theft.
Why don't I believe that it is not an official AOL page?
1) Original frameset page not served via https
2) Obfuscation of true source of content
3) Content not served via https
4) Form contents not sent via https to form target
5) Form contents sent to form target on third web server in
yet another domain
6) hotmail.com address given as argument to form target
7) Real page server via a residential broadband address
8) Form asks for home address, date of birth, SSN, mother's maiden name,
and a second credit-card number
9) Form asks for AOL password
10) Two of the relevant domains registered by individuals
11) Domain/host information spans the US (WA to CA to NJ to FL)
12) Form contents e-mail is sent via a completely insecure CGI program
(anyone can send e-mail anywhere with this script).
[Update: The abuse@hotmail.com auto-responder rejected my report, for the
following ERRONEOUS reason! (My e-mail has numerous references to
hotmail.) Mike
"Unfortunately, we cannot take action on the mail you sent us because it
does not reference a Hotmail account. Please send us another message that
contains the full Hotmail e-mail address and the full e-mail message to:
abuse@hotmail.com "
]
[If it this case is due to stupidity and ignorance rather than an
outright scam, that would be even more startling — although the
opportunities for privacy violations would still be enormous.
Furthermore, the recipient mailbox is reportedly saturated, which
suggests perhaps that people are incredibly gullible and have already
bitten for this scam! Also commented on by Fred Gilham. PGN]
More than five million Visa and MasterCard accounts throughout the U.S. were accessed after the computer system at an unidentified third-party merchants' processor was hacked into. It is currently believed that no fraudulent misuse has occurred. MasterCard began to notify its financial members during the week of 3 Feb that more than 2 million MasterCard accounts had been potentially compromised — as did Visa for about 3.4 million of its accounts. [Source: Reuters item, 18 Feb 2003; PGN-ed] http://story.news.yahoo.com/news ?tmpl=story2&cid=581&ncid=581&e=10&u=/nm/20030218/tc_nm/ financial_visamastercard_dc
A St. Lucie West Middle sixth-grader used the excuse of forgetting his lunch to return to his reading classroom and sat down at his teacher's computer to change five reading assignment grades, St. Lucie County sheriff's deputies said Tuesday. ... The 11-year-old student, who faces a 10-day suspension and a principal's recommendation that he be expelled, was arrested Monday on a felony charge of offense against intellectual property. ... The student was booked into the St. Lucie County jail, then released to his father. Mancini said he could face several years in a juvenile detention facility, if convicted. http://www.gopbi.com/partners/pbpost/epaper/editions/wednesday/ martin_stlucie_e394fc8032005260000b.html [With a little more imagination, he could have qualified for life imprisonment under the new anti-hacking law. PGN]
A computer technician in Winnipeg, Canada, had his Fluke inline network tester stolen (approx. value CDN$11,000) at the end of January. Later, he decided to check if the not-so-common device was being put up for sale on eBay and found two: one in Indianapolis and the other in Winnipeg. [First source: CBC Radio with an online article: <http://winnipeg.cbc.ca/template/servlet/View?filename=mb_ebay20030218>] After expressing interest and through correspondence with the seller, a serial number was obtained which confirmed that the network tester was the technician's. Police were contacted and a meeting was arranged at a local coffee shop where the seller/suspect was arrested. *The Winnipeg Free Press* for 18 Feb 2003 later mentioned that the meeting between seller and technician occurred with two plainclothes officers waiting at another table. [I presume the police were drinking Tester's Choice with their serial. PGN] It appears the CBC may have gotten their tip from the morning paper — I don't get to my own copy until the end of the day — and there's a bit of a difference between the radio and newspaper versions. Although the suspect may be innocent of the theft, the attempt to sell would seem to constitute a crime. The RISKS in not doing your on-line research before doing your on-line auction is — for the seller — one that might be costly and — for the thief — downright dumb. D. Joseph Creighton [ESTP] | Systems Analyst, Database Technologies, IST Joe_Creighton@UManitoba.CA | University of Manitoba Winnipeg, MB, Canada, eh?
[From asilomar-news, noted by Robert G. Kennedy III in Hackers newsgroup, sent to RISKS by Ken Knowlton. PGN] Edsger W. Dijkstra, *Communications of the ACM*, Mar 2001, Vol. 44, No. 3 In academia, in industry, and in the commercial world, there is a widespread belief that computing science as such has been all but completed and that, consequently, computing has matured from a theoretical topic for the scientists to a practical issue for the engineers, the managers, and the entrepreneurs. [...] I would therefore like to posit that computing's central challenge, "How not to make a mess of it," has not been met. On the contrary, most of our systems are much more complicated than can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. The average customer of the computing industry has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. For us scientists it is very tempting to blame the lack of education of the average engineer, the shortsightedness of the managers, and the malice of the entrepreneurs for this sorry state of affairs, but that won't do. You see, while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy. To put it bluntly, we simply do not know yet what we should be talking about, ... The moral is that whether computing science is finished will primarily depend on our courage and our imagination. [Stanley Mazor, Director Customer Services, Numerical Technologies Inc. 70 West Plumeria Drive, San Jose, CA 95134-2134 1-408-273-4485]
The Mac OS X operating system is a work in progress. Users are treated to
small upgrades every one or two months that fix bugs, improve security, and
occasionally provide increased functionality. Presumably in an effort to
add functionality to the built-in Apache server, the latest update installs
a brand new httpd.conf file. This is file that tells the Apache server how
to configure itself (which modules to load, where the root directory is,
etc.) The update kindly (and silently) saves the original httpd.conf as
httpd.conf.applesaved. The risk is that replacing the original, not telling
anyone, and then leaving the server active on restart can lead to a breach
of security. One of the things that you can use the httpd.conf file for is
to govern which directories are password protected and which are not [1].
This information is not retained in the new httpd.conf, so directories that
were password protected are opened to the world after the update has been
installed.
The risks are obvious, and so are the solutions. At a minimum, they should
have disabled Apache on startup and presented the user with a dialog box
informing them of the change.
[1] Apache httpd documentation: Basic Security
<http://httpd.apache.org/docs/howto/auth.html#basic>
<http://pubweb.northwestern.edu/~ldb371/>
At the faculty meeting at Bryn Mawr College on 12 Feb 2003, we were informed that a student at Haverford (our affiliated College) was arrested over the weekend when he was trying to do his homework assignment in Philadelphia. As part of the Cities project, he was taking photographs of SEPTA (our regional transit authority) facilities when he was arrested, detained for a few hours, and eventually released. Haverford administration is working to try to ensure that this event not be a part of the student's permanent police record. Apparently taking photographs at transit facilities is cause for arrest during "Code Orange" alert, the authorities explained. Faculty were advised to be careful about assigning "field trip" projects during such alerts. Rebecca Mercuri, Bryn Mawr Computer Science
In RISKS-22.55, the coverage of the hospital in Grand Rapids, Michigan didn't mention the possibility of *deliberate* abuse of the system where simply changing a 01 into a 20 causes the system to inform insurance carriers, the IRS, and presumably other agencies that one's dead. Since a hospital is a credible source for agencies, someone trying to vanish in America to make another life for themselves — either for honest reasons else for criminal reasons — could hack or bribe their way to access to the system and, after going to St. Mary's Mercy for a broken finger, have the hospital send credible notices of their own death. Love it. Death and taxes aren't quite so final in the Information Age.
> Fleet Center arena ... was missing from the 1994 design drawings...
> ...which (according to the headline) cost over $1 billion
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The RISK here is reading the headline instead of the article. The arena
missing from the design drawings cost slightly under $1 million extra. The
$1 billion figure is for all mistakes made by the Bechtel company resulting
in cost overruns over the past decade.
I have absolutely no training in probability theory, but it seems to me
intuitive that adding a mechanism that effectively tells you if you're
already half-right, is going to reduce the security of any password.
Consider an eight-digit combination lock versus two four-digit locks, where
the first four-digit lock goes "click" before you open it and move on to the
next. Clearly you only have to go round the 10000 combinations of the
second lock once, whereas in the 8-digit lock, you might have to do it 10000
times. Or to make it even clearer, consider eight one-digit locks.
The calculation of the relative ease of cracking the combination only
becomes non-trivial when the number of bits in the separate locks sums to
more than the number of bits in the single lock.
However, as long as the main limiting factor in determining the minimum
length of a password for, say, an online banking system, is the marketing
department ("Oh, no, we mustn't frighten the customer with a
hard-to-remember code; let's use four digits like for the ATM card. But
don't forget to insist on a 128-bit browser, because the user wants to feel
safe."), the debate will remain academic anyway. :-(
[Similar comments were received from Simon Waters and David Parnas.
Of course, one of the CLASSIC password attacks was the old TENEX flaw in
which passwords were checked one character at a time. By aligning the
password presented in a program so that the NEXT character lay across a
page boundary, you could detect whether or not a page fault had occurred
on the previous character, and thus iteratively reduce an exhaustive
search to a linear search. This was something like 30 years ago when
it was realized that visibility of intermediate results is riskful, and
that checking must be done in a single atomic transaction. PGN]
OK, since I am now getting not only questions about the reviews every day, but
multiple copies of the *same* questions, I suppose it is time for:
Questions Frequently Asked About Rob Slade's Innumerable Book Reviews --
Now With Answers!
Questions and answers
1) How do you find time to read all those books?
Darned if I know. I've always read a lot, and quickly. No, I don't do speed
reading: I find that I can't use those techniques. I read while waiting, I
read while traveling: sometimes I just read. I read and review as much as I
can spare time for. Those who have followed the series of reviews will
notice that sometimes I produce more than others: a lot depends on what else
I have to do at the time. Yes, I do read all of the books: every page
(although, I admit, sometimes not every word).
2) Do you have an archive of the reviews?
Yes, two, in fact. The "base" URLs are http://victoria.tc.ca/techrev,
courtesy of the Victoria, BC, Canada TelecommunityNet (aka VTN), and
http://sun.soci.niu.edu/~rslade, courtesy of Northern Illinois University
(former home of the Computer Underground Digest and aka NIU). All the
various pages and files are in those directories, so you can construct a
full URL by simply appending the filename. Also, all files are mirrored at
both sites. For example, a reference in one review, like "(cf.BKVR.RVW),"
would mean that the filename (converted to lower case) could be appended to
the base addresses, and you would find that both
http://victoria.tc.ca/techrev/bkvr.rvw and
http://sun.soci.niu.edu/~rslade/bkvr.rvw point to actual reviews. (If you
use only the base URLs, you will find an index file that points you at some
of the major pages.)
For those looking for the reviews, probably the most useful addresses will
be http://victoria.tc.ca/techrev/mnbk.htm or
http://sun.soci.niu.edu/~rslade/mnbk.htm; the top level of the topical menus
of book reviews (security is not the only topic); and
http://victoria.tc.ca/techrev/review.htm or
http://sun.soci.niu.edu/~rslade/review.htm; the main index to all
reviews. Due to increasing numbers of questions, I guess I will be
maintaining this FAQ at http://victoria.tc.ca/techrev/revfaq.htm and
http://sun.soci.niu.edu/~rslade/revfaq.htm.
3) Where can I find the reviews?
All kinds of places, apparently. There are, of course, the archives above,
and the various topically related lists and groups to which I post
messages. Others archive various subsets of the reviews to different sites,
reprint the reviews in college or user group newsletters, and repost the
reviews to other mailing lists. If you want to get on a mailing list for all
the reviews, I have created a mailing list at Yahoo Groups. You can
subscribe by sending an email message to techbooks-
subscribe@yahoogroups.com, or visiting the Web site at
http://groups.yahoo.com/list/techbooks/, where you can also find an archive
of the more recent reviews.
4) Don't you like *any* books?
OK, I'm a cruel reviewer. But fair!
But, yes, I do like some. In the absence of a "Rob's Picks" page (which I
may get around to some time) the closest alternative is probably the page of
references by the CISSP domains, at
http://victoria.tc.ca/techrev/mnbksccd.htm or
http://sun.soci.niu.edu/~rslade/mnbksccd.htm.
5) Why don't you rate the books you review?
Generally, the people who ask this question want me to assign a single
numeric value, preferably on a scale of 1-5, to every book.
Books are a little bit more complex than that. They are good or bad for
different reasons for different groups. A book for a novice is useless to an
expert. A book for an expert is useless to a novice. So I try to state who I
would recommend the book to, and why. I think it's a bit more reasonable
than just giving each book a number.
If I'd wanted to do that, I could have skipped writing the reviews
entirely. It'd sure save time. (See question 1 :-)
However, a partial answer, for those who want a quick fix, is to look at the
main review index. (See question 2 :-) I try to give a summary of my
reaction to the book, in not more than one sentence.
6) Where can I find your reviews of all the CISSP guides?
See http://victoria.tc.ca/techrev/mnbkscci.htm or
http://sun.soci.niu.edu/~rslade/mnbkscci.htm.
7) What's all that stuff at the beginning?
I was asked by the moderators of one newsgroup to use the standard UNIX
addlib format for publication information. It seemed to be a good set of
data, so I continued. The basic information is:
%A Author's name (use a separate %A line for each)
%C City (place of publication)
%D Date of publication
%E Editor (of book or series)
%G Government order number (use this for ISBN)
%I Issuer (publisher's name and imprint)
%O Comments/etc. (use for format/price, ordering info)
(also the links for purchase at online bookstores. Yes, I do
get a commission: see question 8.)
%P Page number(s) (use for page count)
%T Title of article or book
For more information, see the man page for the UNIX "refer" command.
8) How much money can you make reviewing books?
I find it quite bizarre that almost everyone seems to assume that a) I buy
all these books, or b) I get paid for doing these reviews. I get the books
free from publishers. (See question 9.) I don't get paid for doing the
reviews. Occasionally I use these reviews as the basis for review columns or
"best of" articles for magazines, and get a few bucks. If people
"click-through" the links on the reviews and buy books, I get a
commission. (Eventually my account may build up to enough money that they'll
actually send me a cheque.) I even get a bit of a tax break by getting a
"gift in kind" tax receipt when all these dead trees go to the library. But
this isn't exactly a business.
Of course, if any large corporation was interested in sponsoring the reviews
... :-)
9) How can I get started reviewing books?
In the immortal words of the advertising campaign, just do it. Grab some
books, and review them. Post the reviews. Once you have built a body of
work, you can start asking publishers for copies of books, especially if you
have proven you are serious by sending them copies of the drafts of your
reviews. (Before you post them on the net.)
You don't even have to buy a ton of books to get started. Review the ones
you've already got. If you use them, presumably you know why. If you want to
review new ones, try the library. (If you live in Vancouver, the Vancouver
Public Library has lots of recent technical books :-)
Of course, why would you want to? (See question 8.)
10) Where can I find books on (topic)?
Go to the main review index at http://victoria.tc.ca/techrev/review.htm or
http://sun.soci.niu.edu/~rslade/review.htm. Use the search function on your
browser (Ctrl-F for most Windows stuff, "/" for Lynx, etc). Search for terms
you think would be in the title or the topic of the book. (For privacy you
might want to search on "privacy," "private," or "confidential.") When you
find a likely title, there will be a link to the review itself.
======================
rslade@sprint.ca rslade@vcn.bc.ca slade@victoria.tc.ca p1@canada.com
============= for back issues:
[Victoria Freenet] site http://victoria.tc.ca/int-grps/books/techrev/
or http://www.victoria.tc.ca/techrev
or http://victoria.tc.ca/techrev
an alternate site has been provided by CuD and NIU at:
http://sun.soci.niu.edu/~rslade/
CISSP refs: [Victoria Freenet]mnbksccd.htm
PC Security: [Victoria Freenet]mnvrrvsc.htm
Security Dict.: [Victoria Freenet]secgloss.htm
Security Educ.: [Victoria Freenet]comseced.htm
Book reviews: [Victoria Freenet]mnbk.htm
[Victoria Freenet]review.htm
Partial/recent: http://groups.yahoo.com/group/techbooks/
Security Educ.: http://groups.yahoo.com/group/comseced/
Review mailing list: send mail to techbooks-subscribe@egroups.com
BKHNYPOT.RVW 20030126 "Honeypots: Tracking Hackers", Lance Spitzner, 2003, 0-321-10895-7, U$44.99/C$69.99 %A Lance Spitzner hostmaster@tracking-hackers.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2003 %G 0-321-10895-7 %I Addison-Wesley Publishing Co. %O U$44.99/C$69.99 800-822-6339 fax 617-944-7273 bkexpress@aw.com %O http://www.amazon.com/exec/obidos/ASIN/0321108957/robsladesinterne %P 452 p. + CD-ROM %T "Honeypots: Tracking Hackers" Chapter one is an introduction to the honeypot concepts, and the story of Spitzner's first attempt to run one. An overview of attackers and tools is given in chapter two. A history of honeypots is provided in chapter three, and a list of basic types. Chapter four looks at the benefits (and also the problems) of these types of programs. The types of honeypots are grouped into high, medium, and low interactivity, in chapter five. The explanations given, in this first section, are good and simple. Tables and figures provided, however, often require interpretation. Chapters six to eleven are reviews and descriptions of honeypots and related programs. There is a tutorial on the setup and use of Back Officer Friendly in chapter six. Specter, in chapter seven, gets a detailed review and a discussion of the program's options. Chapter eight discusses how honeyd emulates a network. Port monitoring, with netcat, and jails, using chroot, are covered in chapter nine. Mantrap cages are discussed in chapter ten. Chapter eleven reviews two generations of honeynets, with lots of details. Chapter twelve examines choosing and camouflaging honeypots. Maintaining and using a honeypot is in chapter thirteen. Chapter fourteen presents a couple of "case studies," integrating material from previous chapters. There is a reasonable discussion of legal issues in chapter fifteen. Future directions for honeypots are examined in chapter sixteen. "Know Your Enemy" (cf BKKNYREN.RVW) presented a fascinating glimpse into both honeypots and the blackhat community, but only a glimpse. This book provides much more detail into the inner workings, setup, and technologies involved in sensors for detecting and dissecting network intrusions. copyright, Robert M. Slade, 2003 BKHNYPOT.RVW 20030126 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer