Crack Modifications I'd Like to See: Comments on two breakins.
Dan R. Greening
>99.9% of today's crackers can't write a program to save their lives.
This is probably a 2-magnitude exaggeration, but I certainly suspect that
a majority are not programmers.
To put these comments in perspective, some computers at UCLA have been the
targets of crackers, who in fact were using "crack". The computers involved
are using an older version of HP-UX, and the people doing system administration
are graduate students who aren't paid to spend their time doing system
administration. The computers aren't very powerful, contain little that
might be considered useful, but the attack was damaging. It took time to
sort out the problem, time to crack-proof the systems.
I have advocated the public distribution of "crack". However, I would like
to suggest a modification.
I believe that the publically distributed "crack" should do this:
0. Be available on a set of well-publicized ftp distribution sites. (the
internet is the means by which most people are cracking systems.)
In my opinion, CERT should refer systems administrators to this system,
or should make this program available on cert.org.
1. All available dictionaries should be present on these distribution sites.
2. The crack routine should be embedded within an application which
automatically sends mail to tell the user to change their password.
3. It should be hard to run crack in a mode that would be used for breaking
a password file. (I would even suggest "very hard"--like you have to
write an interface program.)
I make these recommendations from experience: people can now crack a system,
using "crack", without even being decent programmers. There is no
rite-of-passage for these people, they may not even realize that there are
laws which could stick them in jail for years.
Someone once broke into another system which I control, I discovered it,
tracked them down, and they got fired. For what? This person wasn't even
a good programmer--they didn't even know they could be traced. I didn't
feel very good about this firing--didn't want them to be fired--I just
wanted to stop them from breaking into my system. When I discussed this
case with CERT, I made it clear that I didn't want the perpetrators arrested
since they did no damage, I just wanted them to stop. However, under
present US law they committed a felony. Frankly, it did waste about
$500 of my time. The CERT people tried to assuage my feelings: at least
they didn't get thrown in jail, because you didn't press charges, they said.
A publically available raw "crack" is somewhat like throwing a pile of guns
into a day care center. There isn't even a "safety" on crack.
I want to make it clear that I am not trying to impose some sort of mandate
onto the developers of "crack". They have the right to produce and
distribute whatever software they choose.
Instead, I am appealing to them to produce a piece of software which
errs more on the side of usefulness than destructiveness.
--
____
\ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd
\/ dgr...@cs.ucla.edu (408) 973-8081 x313 Cupertino, CA 95014
Alec David Muffett
>I have advocated the public distribution of "crack".
Thank you... 8-)
>However, I would like
>to suggest a modification.
Okay...
>I believe that the publically distributed "crack" should do this:
>0. Be available on a set of well-publicized ftp distribution sites. (the
> internet is the means by which most people are cracking systems.)
> In my opinion, CERT should refer systems administrators to this system,
> or should make this program available on cert.org.
YES YES YES YES YES !!! 'Tis pity I am not a CERT official nor has
anyone at CERT approached me about this. Remember: I am now nothing but
an unemployed solitary Unix programmer, developing Crack on my Amiga
A500 and testing on the local Uni's machines...
I emailed Dan Klein @ CERT a few months back, asking whether his code
could be made available to me (given Crack's success) and so that we
could swap ideas (he has a program in the same vein as Crack, which he
used to produce information that was published as a paper) and he (very
courteously) told me that "the powers that be" said "no" to doing this.
I will not vouchsafe my views upon this.
>1. All available dictionaries should be present on these distribution sites.
Actually, Crack 4.1 is going to the beta testers next week (hopefully).
I have been hoping to find a BIG site where I can shove a copy of 4.1
with the tons and tons of lovely dictionaries which I have snarfed from
all over the place... You've pre-empted me a bit... 8-)
Using LHArc, the source + dictionaries are < 300Kb.
>2. The crack routine should be embedded within an application which
> automatically sends mail to tell the user to change their password.
It's currently available as an option, and I am loath to make it mandatory:-
1) it would be UTTERLY TRIVIAL to override
2) it would lead to inflexibility in the code.
- but I suggest that you read my commentary on mailing users like this,
in the v4.0 docs...
>3. It should be hard to run crack in a mode that would be used for breaking
> a password file. (I would even suggest "very hard"--like you have to
> write an interface program.)
Run with a shadow password scheme: that way, in theory, the only person
who can run Crack is the SM, because he is the only person who can get
at the crypted text versions of the password. This should therefore
utterly defeat Crack.
Putting such a safety catch mechanism into Crack is just a plain silly
thing to do, because (to modify one of your own analogies) it would be
like fitting a safety catch to a gun, when all it needs is a screwdriver
to remove the safety catch. And lots and lots of people WANT to remove
the safety catch. And lots and lots of people NEED it without the
safety catch.
All that would happen is that there would be 'n' different versions of
Crack floating about, hacked up to varying degrees, and most of them
wouldn't work. At least with just one person doing the coding, all the
patches are consistent with the rest of the functionality. I don't want
it to wind up like some of the GNU software...
>I make these recommendations from experience: people can now crack a system,
>using "crack", without even being decent programmers.
Ahhhh... like your everyday run-of-the-mill chemistry department system
manager you mean... Jolly good show. That is precisely what I intended
to happen.
>There is no
>rite-of-passage for these people, they may not even realize that there are
>laws which could stick them in jail for years.
I do not believe in security through obscurity. Believing in security
through magical ability is even sillier.
>Someone once broke into another system which I control, I discovered it,
>tracked them down, and they got fired. For what? This person wasn't even
>a good programmer--they didn't even know they could be traced. I didn't
>feel very good about this firing--didn't want them to be fired--I just
>wanted to stop them from breaking into my system. When I discussed this
>case with CERT, I made it clear that I didn't want the perpetrators arrested
>since they did no damage, I just wanted them to stop. However, under
>present US law they committed a felony. Frankly, it did waste about
>$500 of my time. The CERT people tried to assuage my feelings: at least
>they didn't get thrown in jail, because you didn't press charges, they said.
Hard cheese... If I caught a stranger stomping through my bedroom I'd
deck him first and ask questions later. Even if he says that he wasn't
going to steal anything, the law would take a dim view of his actions.
Even if said person was a misguided innocent, it's still a crime...
probably.
>A publically available raw "crack" is somewhat like throwing a pile of guns
>into a day care center. There isn't even a "safety" on crack.
See the safety catch analogy above...
>I want to make it clear that I am not trying to impose some sort of mandate
>onto the developers of "crack". They have the right to produce and
>distribute whatever software they choose.
It's only me, I'm afraid... mea culpa, mea maxima culpa...
>Instead, I am appealing to them to produce a piece of software which
>errs more on the side of usefulness than destructiveness.
mea minima culpa... get shadow passwords running on your system.
>\ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd
- alec muffett, author and developer of the "Crack" password cracker.
--
|+ Alec David Edward Muffett, Unix Programmer and Unemployed Coffee Drinker. +|
|> a...@aber.ac.uk a...@uk.ac.aber aem%ab...@ukacrl.bitnet mcsun!ukc!aber!aem <|
| "I didn't invent the Unix Password Security problem. I just optimised it." |
King_Claudius
>I want to make it clear that I am not trying to impose some sort of mandate
>onto the developers of "crack". They have the right to produce and
>distribute whatever software they choose.
>
>Instead, I am appealing to them to produce a piece of software which
>errs more on the side of usefulness than destructiveness.
[very interesting article btw.]
some comments:
1) the writers of crack should distribute it with a disclamer and if possible
an explanation of the legal implications of cracking into another system, or
assisting another user to crack into a system.
2) having a dictionary file hotline, in effect, would be useful...there are a
couple underground dictionaries I'm sure...and when a system is hacked into and
the hackers caught, their dictionaries should be checked...also check out the
rules they used.
--
Hi, I'm a signature worm! Join in the fun and copy me into yours!
---King Claudius--- clau...@zeus.calpoly.edu
Dan R. Greening
>Run with a shadow password scheme: that way, in theory, the only person
>who can run Crack is the SM, because he is the only person who can get
>at the crypted text versions of the password. This should therefore
>utterly defeat Crack.
The HPs I referred to have no shadow password capability (HPUX 7.0: the
UCLA CSD doesn't have the cash to upgrade to 8.05). Nevertheless, I respect
your points, though I don't totally agree. The situation reminds me of
U.S. religious arguments: opposite sides refuse to acknowledge valid
criticism, and automatically reject intermediate positions. They become
extremists through the process of arguing.
I don't wish to associate myself with crack's detractors--it is a useful
program. I have observed problems with crack first-hand and wish there
were some way to eliminate them.
My remaining suggestions are these:
1. Could you please place a prominent warning before any other text in the
README file, that crack is intended as a security enhancing device, and
warns the builder that inappropriate use of Crack could result in a
jail term.
2. Could you spit out the same message, by default, upon running the program.
Some option could disable it: that would be OK.
3. Would you be willing to build in a "syslog" call to log use of the program
at the same level as "su"? Here you would log as facility=LOG_AUTH, and
priority=LOG_NOTICE.
>>I want to make it clear that I am not trying to impose some sort of mandate
>>onto the developers of "crack". They have the right to produce and
>>distribute whatever software they choose.
>
>It's only me, I'm afraid... mea culpa, mea maxima culpa...
Consider yourself the royal we.
Regards,
--
____
\ /Dan Greening Software Transformation 1601 Saratoga-Sunnyvale Rd
Randal L. Schwartz
| The HPs I referred to have no shadow password capability (HPUX 7.0: the
| UCLA CSD doesn't have the cash to upgrade to 8.05).
This is silly. Get Emacs or another suitable binary editor. Edit
your /bin/login and /bin/passwd and /bin/chfn binaries, replacing
/etc/passwd with /etc/p/sswd. Create the directory /etc/p, chmod 700,
mv /etc/passwd /etc/p/sswd. Now write a cronjob that scruffs
/etc/p/sswd putting the sanitized data into /etc/passwd. No
recompilation necessary.
You can even patch the binaries with Perl as in:
perl -pi.orig -e 's#/etc/passwd#/etc/p/sswd#g' /bin/login /bin/passwd /bin/chfn
Really. There's no reason for people to not have a shadow password if
they want one.
Just another security (and Perl) hacker,
--
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III |
| mer...@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
Neil Rickert
>This is silly. Get Emacs or another suitable binary editor. Edit
>your /bin/login and /bin/passwd and /bin/chfn binaries, replacing
>/etc/passwd with /etc/p/sswd. Create the directory /etc/p, chmod 700,
>mv /etc/passwd /etc/p/sswd. Now write a cronjob that scruffs
>/etc/p/sswd putting the sanitized data into /etc/passwd. No
>recompilation necessary.
Don't forget ftpd and rexecd . On a system which uses
dbm files you should also start building the dbm files in the new
directory.
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Neil W. Rickert, Computer Science <ric...@cs.niu.edu>
Northern Illinois Univ.
DeKalb, IL 60115 +1-815-753-6940
Chris Steinbroner
| The HPs I referred to have no shadow password capability (HPUX 7.0: the
| UCLA CSD doesn't have the cash to upgrade to 8.05).
shadow password files first appeared on the 9000 Series 300,
in HPUX 6.5. it then became available on 800 series machines
on release 7.0.
run SAM to "convert to trusted system."
-- hesh
Michael T Pins
>In article <1992Feb5.1...@cs.ucla.edu> dgr...@oahu.cs.ucla.edu (Dan R. Greening) writes:
->I have advocated the public distribution of "crack".
->I believe that the publically distributed "crack" should do this:
->0. Be available on a set of well-publicized ftp distribution sites. (the
-> internet is the means by which most people are cracking systems.)
-> In my opinion, CERT should refer systems administrators to this system,
-> or should make this program available on cert.org.
->1. All available dictionaries should be present on these distribution sites.
>Actually, Crack 4.1 is going to the beta testers next week (hopefully).
>I have been hoping to find a BIG site where I can shove a copy of 4.1
>with the tons and tons of lovely dictionaries which I have snarfed from
>all over the place... You've pre-empted me a bit... 8-)
>Using LHArc, the source + dictionaries are < 300Kb.
How does grind.isca.uiowa.edu sound?
I can just put it in the unix area, we're about due for another gig-drive
anyway.
Firestar
--
*****************************************************************************
* Michael Pins (Firestar) | Internet: ami...@isca.uiowa.edu *
* ISCA's Amiga Librarian | #include <std.disclaimer> *
*****************************************************************************
Steve Simmons
>In article <1992Feb7.0...@iWarp.intel.com> mer...@iWarp.intel.com (Randal L. Schwartz) writes:
>>This is silly. Get Emacs or another suitable binary editor. Edit
>>your /bin/login and /bin/passwd and /bin/chfn binaries, replacing
>>/etc/passwd with /etc/p/sswd. Create the directory /etc/p, chmod 700,
>>mv /etc/passwd /etc/p/sswd. Now write a cronjob that scruffs
>>/etc/p/sswd putting the sanitized data into /etc/passwd. No
>>recompilation necessary.
>Don't forget ftpd and rexecd . On a system which uses
>dbm files you should also start building the dbm files in the new
>directory.
And uucpd, and all your lock programs which use /etc/passwd. Don't forget
to make them all suid root so they can read /etc/p/sswd.
--
Simmons' Law Of Alcoholic Expectations:
The best stuff always happens after the meeting, when everyone goes to
the bar.
Correlary: Any meeting which doesn't adjourn to the bar isn't worth going to.
Scott Bennett
| The HPs I referred to have no shadow password capability (HPUX 7.0: the
| UCLA CSD doesn't have the cash to upgrade to 8.05).
If you're running HP/UX 7.0, then dig out the following manual:
_HP-UX_System_Security_:__HP_9000_Series_300/800_Computers
Turn to p. 5-4. Read that page. Then go back and read the rest of
the manual. Then convert to shadow passwords if you want to. Your
systems do have the capability of running with shadow passwords.
Scott Bennett, Comm. ASMELG, CFIAG
Systems Programming
Computer Center
Northern Illinois University
DeKalb, Illinois 60115
**********************************************************************
* Internet: ben...@cs.niu.edu *
* BITNET: A01SJB1@NIU *
*--------------------------------------------------------------------*
* "If it weren't for lawyers, we wouldn't need them." *
**********************************************************************
Edward DeHart
> >0. Be available on a set of well-publicized ftp distribution sites. (the
> > internet is the means by which most people are cracking systems.)
> > In my opinion, CERT should refer systems administrators to this system,
> > or should make this program available on cert.org.
>
> YES YES YES YES YES !!! 'Tis pity I am not a CERT official nor has
> anyone at CERT approached me about this.
When CERT was created, we made a decision to not duplicate existing
services. Since your program was already available via anonymous ftp,
we did not contact you about making it available from cert.sei.cmu.edu.
There aren't many programs that we do promote. The main reasons are limited
resources and a lack formal testing methods and policies. As we expand,
(we're looking for people) this could be one area for us to address. We do
inform people about new tools via the CERT Tools mailing list and via CERT
presentations. Crack is one of the programs that we suggest system managers
examine.
> I emailed Dan Klein @ CERT a few months back, asking whether his code
CERT is a project within the Software Engineering Institute (SEI) at Carnegie
Mellon University. Dan does work for the SEI but not for CERT. Dan has
been actively researching password cracking and I would recommend that
anyone interested in computer security read the paper Dan presented at the
last Usenix UNIX security symposium.
Thank you,
Ed DeHart
Computer Emergency Response Team
Internet E-mail: ce...@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.
Alec David Muffett
>some comments:
>1) the writers of crack should distribute it with a disclamer and if possible
>an explanation of the legal implications of cracking into another system, or
>assisting another user to crack into a system.
For which country ? Wales ? I could do that, sure...
"Look you, if you is going to be using this program to brrreak into
someone else's system password file like, you could be landing yourself
knee deep in cack, boyo..."
>2) having a dictionary file hotline, in effect, would be useful...there are a
>couple underground dictionaries I'm sure...and when a system is hacked into and
>the hackers caught, their dictionaries should be checked...also check out the
>rules they used.
Oh, umm, good. Will you buy the Uzi's for me, or do I have to get an
overdraft ? And who will provide tht paperwork ?
Seriously, Crack 4.1 is in betatesting a.t.m. and should be out shortly
afterwards. Once it's up and running, I'll publish a maillist address
that people should be able to get and swap info on... beyond that I can
do little more.
- alec
ps: I love the way everyone is refering to me as "them"
Alec David Muffett
>a...@aber.ac.uk (Alec David Muffett) writes:
>>dgr...@oahu.cs.ucla.edu (Dan R. Greening) writes:
>The HPs I referred to have no shadow password capability (HPUX 7.0: the
>UCLA CSD doesn't have the cash to upgrade to 8.05). Nevertheless, I respect
>your points, though I don't totally agree.
PD shadow schemes are available, but I'm not gonna try forcing anyones
hands. I would recommend whingeing at HP - if enough people do it,
maybe they'll fix it. I rather hoped that this is what would happen.
>The situation reminds me of
>U.S. religious arguments: opposite sides refuse to acknowledge valid
>criticism, and automatically reject intermediate positions. They become
>extremists through the process of arguing.
Can't say I feel particularly extreme about anything... Except I *DO*
prefer _single_malt_ whiskies... 8-)
>My remaining suggestions are these:
>1. Could you please place a prominent warning before any other text in the
> README file, that crack is intended as a security enhancing device, and
> warns the builder that inappropriate use of Crack could result in a
> jail term.
In which country &| legal system ? Perhaps:
"H.M. Government Warning:
Illegitimate use of this package may seriously affect your network access."
naaaahhh....
>2. Could you spit out the same message, by default, upon running the program.
> Some option could disable it: that would be OK.
Sounds a bit twee to me. I don't like being twee.
>3. Would you be willing to build in a "syslog" call to log use of the program
> at the same level as "su"? Here you would log as facility=LOG_AUTH, and
> priority=LOG_NOTICE.
Pray, what use is this? To inform a system manager that someone is
running Crack on his system ? Not everybody would read the logs, and all
it would take is 2 minutes work with an editor to remove it such a
warning. The canonical scenario for finding Crack running on your
system is when J Random Sysman starts wondering why his box is going
like a snail...
Anyway, I can think of at least 3 different portability constraints to
do with syslog that I would rather not get into... It'd be almost as
unportable as if I'd written Crack in ANSI-C... 8-)
Perhaps opening /dev/console and logging to that would be more portable,
but useless on workstations.
>>>I want to make it clear that I am not trying to impose some sort of mandate
>>>onto the developers of "crack". They have the right to produce and
>>>distribute whatever software they choose.
>>It's only me, I'm afraid... mea culpa, mea maxima culpa...
>Consider yourself the royal we.
- hey, I'm not a net.god, I think...
- alec
Charles Hannum
In article <1992Feb5.1...@cs.ucla.edu> dgr...@oahu.cs.ucla.edu
(Dan R. Greening) writes:
>
> A publically available raw "crack" is somewhat like throwing a pile
> of guns into a day care center. There isn't even a "safety" on
> crack.
Only because of the imagery in society of guns being neat toys, or of
really K00l DuDeZ shooting at each other.
Why don't we compare it to opening a hardware store? I sell you tools.
you can use them to fix your lawnmower, break into my house, build your
own house, or whatever else you want. I can give you recommendations
on what to do with the tools, but I'm not going to make any effort to
enforce them.
Peter Kaminski
>1. Could you please place a prominent warning before any other text in the
> README file, that crack is intended as a security enhancing device, and
> warns the builder that inappropriate use of Crack could result in a
> jail term.
Whether or not Mr. Muffett places a "warning: this is a gun and may be
hazardous to your health" message in his distribution, it's not a bad
idea for sysadmins to inform their users about the local laws and site
policy about cracking and password cracking programs.
Advantages are that you can 1) be specific about what laws are applicable,
and 2) set site policy to be more restrictive than the law. ("Password
cracking programs are not allowed on this system," for example.)
Obviously these measures are only effective with honest or intimidatable
users, but I think that was the intent of Mr. Greening's request.
w...@gandalf.umcs.maine.edu
|> m...@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
|>
||>
|> I believe that the publically distributed "crack" should do this:
|>
||>
|> automatically sends mail to tell the user to change their password.
|>
|
now be broken into and the warning mail intercepted. A better (perhaps)
alternative would to have it send mail to root.