Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 04 Issue 41 File 09
==Phrack Inc.==
Volume Four, Issue Forty-One, File 9 of 13
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Security Shortcomings of AppleShare Networks
By Bobby Zero
November 28, 1992
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
The purpose of this file is to inform all those underpaid Mac network
administrators or other interested parties of the problems with Macintosh
AppleShare and how to address those problems. AppleShare is quite respectable
in both its implementation and usage, blending seamlessly with the Macintosh OS
such that the casual user has no idea of the complexity behind the elegance.
For all its elegance, however, it does have some severe drawbacks in terms of
security-- nearly all of which are fixable, requiring a combination of common
sense and RTFM: Read The Fucking Manual.
This is in no way to be considered as a "How To" for persons of
questionable ethics and/or motives. That being said, however, I feel the
following is in order:
PROSECUTOR: [To WITNESS] ...And you are?
WITNESS: Miss America.
[Singing]
PROSECUTOR: Would you please tell the court why you feel Fielding Mellish is a
traitor to this country?
WITNESS: I feel that Fielding Mellish is a traitor to this country because his
views are different from the views of the President, and others of his kind.
Differences of views should be tolerated, but not when they are too different.
Then he becomes a subversive mother.
-- Woody Allen, "Bananas"
This file is divided into 5 sections: (1) the "AppleShare Prep" file,
(2) the "AShare File Srv" application, (3) Mixing VAXens & AppleShare, (4)
System 7 FileSharing, and (5) NCSA Telnet weaknesses. The fifth does not
particularly relate to AppleShare, but its security can be exploited via method
#4, so I thought to include it.
If there is sufficient interest, I will make a "Part II" [or three or
four or five..] detailing more problems. Send feedback to Phrack Loopback;
being a regular reader, I will respond accordingly. While writing this, I was
unsure of the approach -- either bland technical or "gh0d-these-people-
are-dumb" statements. I decided to just combine them, chao-like. Well, enough
of my rambling. On with the file!
- = - = - = - = -
THE "APPLESHARE PREP" FILE
~~~ ~~~~~~~~~~ ~~~~ ~~~~
(1) The "AppleShare Prep" file under both System 6 and 7 contains a BMLS
resource; this resource contains various information required to mount a volume
on startup. While this is an optional feature, many people choose it either by
accident or for convenience.
* The downside to this convenience is the fact that the user's name and
password for a server are stored in this file. Anyone with a copy of ResEdit
can open this file up, and view the BMLS resource.
* It's so easy to create a Trojan horse and slip it into a program or Hypercard
stack to copy the BMLS resource from the target's AppleShare Prep file and copy
it into a hidden file on the server drive where it can be retrieved at a later
date. If Mr. Ed is well-written, he would be nearly undetectable as it takes
but an eyeblink to copy the rez. Trojan horses aren't as sexy as viruses and
don't get much publicity, but it is exceedingly easy to fool a Macintosh user
[or any user, for that matter] into running something he or she shouldn't.
HOW TO SOLVE: Educate users of this flaw and urge them to log into the file
server manually. If computers in an open lab setting are used, configure them
to automatically log in as a guest, thereby circumventing the entire issue of
passwords entirely. Encryption of the BMLS resource is entirely up to Apple or
someone with enough knowledge of AppleShare to write a patch -- certainly not
me [yet...].
THE "ASHARE FILE SRV" SERVER
~~~ ~~~~~~ ~~~~ ~~~ ~~~~~~
(2) On AppleShare File Servers running v2.0:
* The file "Users & Groups" within the Server/System Folder contains the data
required for maintaining folder privileges & ownership. It also contains
user's names and passwords, in an unencrypted format. While obtaining this
file would be somewhat difficult [one must physically be able to access the
server: shut it down, restart it with a floppy, copy the file, reboot the
machine], the "rewards" would be considerably worthwhile, as one would now have
a copy of every user name and password, including that of the Administrator.
Once physical access is secured, one could conceivably write a program to
install on the server that would periodically make a copy of the file and put
it on the "server" side of the disk, and give it an innocuous name... an INIT
which would perform on every startup, or install a Time Task to do it daily, or
even going so far as to patch the AppleShare Admin program to update this file
every time a user is added or modified. It is also common knowledge that users
use the same passwords on different machines; armed with a list of names &
passwords for one machine, one could then enter another computer with the same
user/pass combination.
* There is no automatic lockout for users who enter an incorrect password. With
a bit o' knowledge and a copy of "Inside AppleTalk," a program could be written
that could use a dictionary of common passwords in conjunction with a list of
user names to try to manually "hack out" a valid user/password combination.
The speed of this varies greatly on the speed of and load on the server, the
speed of and load on the network, and the speed of the "attacking" computer. A
typical "hack" can take anywhere from .5 to 5 seconds, but there is no need to
tie up the attacking computer for that period of time; the program can use both
asynchronous AFPCommand calls and exist under Multifinder to allow for complete
"background hacking." It should be noted, however, that Apple has incorporated
a lockout into the hideously overpriced AppleShare 3.0 -- its hardware
requirements, however, seem to leave it out of the budgets of most sane
individuals.
* A group of individuals armed with the above program could go into a computer
lab, fire up said program, and then launch a word processing application and
seem to be doing homework while in reality they would be hacking passwords.
* The "Copy Protect File" in AppleShare Admin disallows using the Finder to
copy a "Protected" program. That does not deter, however, a "normal" copy
program such as DiskTop from copying the file. [That is about as lame as the
ol' "Bozo Bit."]
HOW TO SOLVE: Insure that physical access to the fileserver is impossible for
all but trusted persons. Upgrade to AppleShare 3.0 [$$ gag $$], which allows
"locking" of accounts after a certain number of bad attempts, or obtain a
logging program to keep track of invalid attempts and origins, then track down
the offenders. There's no way to stop the violation of the "Copy Protection"
-- it deters only those easily dismayed. All I can suggest is you keep your
non-PD programs away from Guests or other "non-trusted" persons.
VAXSHARE, PCLINK, AND OTHER VAX/APPLESHARE SERVER APPS
~~~~~~~~~ ~~~~~~~ ~~~ ~~~~~ ~~~ ~~~~~~~~~~ ~~~~~~ ~~~~
(3) There are various forms of AppleShare that can be run from a VAX; many
versions of these programs have severe flaws which can also be exploited.
* The prime example is the existence of "default" accounts: while "Guest"
logins might be disallowed, logging in as DEFAULT, password USER has been known
to be effective in "getting in" -- even FIELD, SERVICE has worked. Pathetic,
isn't it, that these guys haven't picked up on these things?
* The existence of a VAXShare [or similar] account used for AppleShare access
can oft times be used to access the VAX. For instance, if one is aware that a
VAX is being used in an open lab as an AppleShare File Server, one can use
method #1 to extract a username/password combination from the Prep file and use
that password to gain entrance to the VAX.
HOW TO SOLVE: Disallow interactive logins on the VAX-side of the account and
disable or repassword all "default" accounts. If your version of
VAX/AppleShare requires an interactive login, have a "special" program be run
whenever the user logs in, recording the date, time, and origin of login before
disconnecting.
SYSTEM 7 FILE SHARING
~~~~~~ ~ ~~~~ ~~~~~~~
(4) With the advent of System 7.0 and "File Sharing," many users simply put
their machines "on the net" without taking proper measures to disallow
unauthorized access to their machine. Several people turn Sharing on while
their drive is selected, unwittingly allowing others to read, write, copy,
delete, or modify the information on the drive. Oddly enough, by default, the
"Trash" folder is locked out, while the System Folder is, by default, left wide
open. A major oversight on Apple's part... I suppose it was to discourage the
perceived threat of "digital dumpster diving" ...? Even I cannot fathom that
one.
* Many times the "System Folder" is left unprotected, meaning various system
resources can be copied or modified. One can leech the AppleTalk Remote Access
files, any Timbuk2 or Timbuk2/Remote programs, etc. and use them to further
penetration.
* The "Users & Groups" file can be copied, then modified "at home" by a user
running 7.0 [or by the attacking machine, if it is running 7.0] -- adding
another "owner" account, for instance, to act as a "back door" in the event
guest privileges are locked out by a wiser individual.
* The integrity of important files can be challenged; the System file can have
resources moved in and out of it by the attacking computer -- one of these
resources could be a virus, a Trojan horse, or a really stupid font [like New
York -- ugh!].
* The disk is usually populated by copyrighted software; one could easily make
pirated copies of that software.
* The disk may be home to personal or otherwise "private" files -- files that
can be read, copied, deleted, or even modified. There was an instance in which
a file on a shared folder was found to contain user names and passwords to a
UNIX box on the campus network... incredibly foolish. Fortunately, the proper
persons were informed and the files were moved to a [presumably] safer
location.
* The attacker could have a malicious streak and choose to delete all that he
sees.
HOW TO SOLVE: Take a giant wooden plank and soundly whack all offending users.
Tell them of the intelligent way to use filesharing, and inform them that
*anyone* can go in and read their resume, love notes, financial info, erotic
poetry, etc.. that usually gets their attention. Tell them to, instead of
sharing the entire hard drive, create a folder and entitle it "Shares" or
something appropriately witty; then select the folder and go to "Sharing..."
To further security, disallow the <Any User> (Guest) logins. To better keep
track of who's using the Macintosh, keep the "File Sharing Monitor" open or get
a program like NokNok which notifies you when someone is using your Mac.
NCSA TELNET
~~~~ ~~~~~~
5) The NCSA Telnet application allows a user to use his or her Mac as a telnet
client and wander around the Internet. NCSA Telnet also handles incoming FTP
requests. While this FTP function is easily disabled, many users keep it on
because they either use it regularly or don't even know it exists.
* Anyone with a valid username/password can log in to the Mac via FTP and then
change to the "root" directory and perform the normal FTP functions.. both send
and receive. This means that *every* file on the Mac can be accessed from
*anywhere* on the Internet. It should be noted that NCSA Telnet does not log
the "who & where" information, meaning there is no log of who used the machine,
meaning there is no way for an intruder to be "caught."
* The file "ftppass" contains the list of users allowed to use FTP on that
Macintosh. If, by using one of the methods mentioned above, someone is able to
access it, it is easily cracked as it has a rather pathetic encryption scheme:
the data fork contains the user's name, a colon, and then an encrypted
password. The password is easily decrypted; unless it is the entire 10
characters, the last few characters are in order. That is, the next ASCII code
is 1 + the previous, etc. Observe this from my "ftppass" file:
sample:ucetcr&'()
The first part, "sample," is the user's name. The colon is the basic UNIX-like
delimiter, the rest is the password. The "real" part of the password is the
characters "ucetcr" ... the remaining "&'()" are just spaces... how do you
tell? It's in ASCII order. Look up "&" on an ASCII chart and "'" will follow,
then "(" then ")" .. you get the idea.
This password can be discovered by short program XORing the encrypted
characters with a number between 0 and 255. The program can either a) dump all
XOR results or b) if the password is not the maximum length, the program can
simply scan for a "space" [ASCII 032 decimal] in the password and print it.
The following "cracking" program is written in BASIC [hey, does anyone use that
any more?] and will allow you to decrypt the passwords. If you can tell that
the password has spaces at the end, you can go ahead and delete line 110.
Otherwise, leave that line in and use your brain [remember your brain?] to
determine if the encrypted goop is a "real" word or just goop.
5 REM "ftppass" brute-force hacker
10 INPUT "Encrypted password:";I$
20 FOR X=1 TO 255
30 FOR Y=1 TO LEN(I$)
40 Y$=MID$(I$,Y,1)
50 YA=ASC(Y$)
60 N=X XOR YA
70 IF N=32 THEN F=1
80 N$=N$+CHR$(N)
90 NEXT Y
100 IF F THEN ?"Possible password:"N$
110 ?I$" 'encrypts' to "N$: REM U can delete this line if len<10
120 N$="":F=0
130 NEXT X
140 ?"Finished."
Sample run: [with line 110 deleted]
Encrypted password:ucetcr&'() [gotta type the whole thing]
Possible password:secret !./ [boy, that was tough!]
Possible password:rdbsdu! /.
Possible password:}km|kz./ ! [etc.. just smack ^C at this point.]
So the password is "secret" [clever, no?]
It should be noted that this program is rather inelegant as I haven't really
reversed the algorithm, just written a brute-force "hacker" for it. This is
due to laziness on my part. If I really wanted to do this properly, I would
FTP to the NCSA anonymous site and leech the 700k+ of source and "reverse" it
thataway. I don't feel like doing that. I am lazy. This program works just
dandy for me... [I suspect the encryption program uses the users' name to
encrypt it, but I don't care enough to find out.]
I should say that I don't wish to offend the makers of NCSA Telnet or call the
application crap. It is, indeed, an impressive piece of work; I simply feel
that there are some aspects of it which could use improvement... if not in
terms of security, then at least allowing the user to save selections to disk!
BTW- I know that NCSA Telnet is also available for the IBM. I haven't tested
these with an IBM, but if it's a "true" port, these flaws should exist under
the IBM version as well.
- = - = - = - = -
Well, that does it. If you're a network coordinator and you're *still* sitting
on your skinny ass after reading this, get the hell up and fix the problems.
Don't be surprised to find someone running anonymously through your net,
leeching files and generally contributing to moral laxity ... I've seen it
before -- it's not a pretty sight.
And of course, if you run a network of any sort, you must encourage users to
use different passwords on different machines and passwords that don't exist in
a dictionary [gh0ds are we sick of hearing that!].. it will work wonders for
security. Every hacker knows the number of people who use ONE password to all
of their different accounts is unbelievably high... and they make very good use
of this oversight.
