Everyone may want to take a look at the following article that was in the
latest issue of Phrack (9-9-99).
Black Book of AFS
http://www.phrack.com/search.phtml?view&article=p55-13
A pretty simple and basic intro of AFS to the hacker community, however,
it did reveal a couple of concerns.
The first concern was sites that set up web servers with the root document
tree as /afs. Transarc is the most obvious site that currently does this.
What this allows is anyone with a web browser to start poking around
AFS cells. So if someone wanted to start looking at Transarc's cell they
can go to the following URL:
http://www.transarc.com/afs/transarc.com/
and start traversing directories to see what they had access to. So now
any sites with incorrectly set up ACLs, that are mounted in Transarc's cell,
are vulnerable to ANY user (not just AFS users) accessing files.
Now it is usually the cell admin's job to make sure that ACL's are set up
in such a way that this wouldn't be much of a concern. However, with some
of the larger cells it is hard (or impossible) to keep track of every ACL in
every directory in the cell.
Another concern that I had is that there is no way to prevent access to
our cell from a remote web server. We tried tried setting a negative ACL
for Transarc's web server in our root.cell volume, but the system:anyuser
makes this useless (I'll probably post another message soon why I think
this is a bug in the negative ACL's).
I think that Transarc should modify how they have their web servers set up
so that /afs is not the root of the document tree (the article mentioned a
cell at MIT that does this as well). But there may be other sites that are
currently doing this, or may do it in the future.
So as admins we need to be aware of (as much as possible) bad ACL's in
our cells. Especially since exploration of AFS has been highlighted in
a magazine like Phrack. Here are some examples from the article of
directories they have found to be "Interesting":
/afs/andrew.cmu.edu/local/src/os/
.... Left over from a time when Irix source resided there.
/afs/ncat.edu/common/
.... Root directory of an Ultrix installation
/afs/ir.stanford.edu/users/c/l/clinton
.... Not the daughter of the U.S. President, but a reasonable
facsimile thereof which causes much excitement among readers.
/afs/rose-hulman.edu/users/manager/agnello/compromised/
.... AFS follows the 'user-managed' philosophy of resource
management, leaving it up to individual users to secure the
permissions on their own files. This unfortunate admin
forgot to set the permissions on data collected during a
recent (08.08.1999) security compromise. The world,
including the intruder, can now browse his work and see
what they have found.
/afs/umbc.edu/public/cores/
.... Corefiles from fileserver crashes at the University of
Maryland. No further comment.
/afs/net.mit.edu/reference/multics/
.... Once in a blue moon, you come along a gem like this one.
Source code, project notes, and electronic messages from
the Multics project. ./udd/multics/Rochlis contains the
mail, messages, and notes in case you can't find it.
I noticed most of these are now not accessible. But I noticed there are
many other users directories that are system:anyuser rl. For instance
I ran across a directory under one cell where all mail was readable (one
mailbox was called Payroll).
--
James J. Barlow <[EMAIL PROTECTED]>
Senior System Engineer
National Center for Supercomputing Applications
605 East Springfield Avenue Voice : (217)244-6403
Champaign, IL 61820 Cell : (217)840-0601
http://www.ncsa.uiuc.edu/People/jbarlow Fax : (217)244-1987
