==Phrack Inc.==
Volume Four, Issue Forty-One, File 9 of 13
= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
Security Shortcomings of AppleShare NetworksBy Bobby Zero November 28, 1992= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
The purpose of this file is to inform all those underpaid Mac networkadministrators 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 ofquestionable 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.
- = - = - = - = - = - = - = - =- = - = - = - =- = - = - = - =- = - = - = - = -