312 lines
16 KiB
Text
312 lines
16 KiB
Text
|
==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.
|
||
|
|