Unix password cracking...

[docevi1]

Before anyone says anything, this is courswork for Uni - it's designed to show us what makes a bad password and ultimately what makes a good password.

What we have is 32 fictious names and passwords encrypted using Crypt and we have to try and find out as many as we can. We've written our own little programs (in java so on my 3.5Gig AMD I only get 45k comparions a second ) to work through dictionaries that we either produce or get from t'internet. So far we've managed to find 8 of the passwords by:

* Knowledge - making guesses as to who the person is, what their name is (some are lecturers at Uni, others are prominent figures in the celebrity world e.g. Michael Jackson) and similiar ideas - found 3.
* Dictionary - we found a few dictionaries from the internet, combined then into a 25Mb file (4709 pages in word) and came up with 4 more.
* We took the same dictionary and changed the case, added "l33t Speak", reversed the words... nothing but created a 250Mb dictionary.
* We've tried brute force on 3 characters long (found one password), on 4 characters long (found another, but only halfway through the potential options - we understand this is the only 4 character password however).
* We've tried every date from 1900 in various formats
* We've tried sending an email to the lecturer to "spoof" the Unix login in screen, but he didn't go for it although did give us a lot of background on the phishing technique.

I know from others that there exists a password of 5 characters long which is pretty much impossible to guess (other than by using brute force), that leaves 23 remaining passwords which are seemingly impossible to get at this stage.

Our main problem at the moment is time - we have two weeks in which to find out as much as we can so that we may write our report, which has a deadline of the 28th. Obviously we already have a fair bit to write about (i.e. what our obvious attacks were, what failed and what we tried next), but we'd all like to actually find as many as possible to try and "beat" the coursework.

We are still running the brute-force attack on 4 characters as it's taking about 3hours constanct computation to get through half the file. Our next stage, after completion of this file, is to try some data mining wherein we go to a website and try and get as much information on one of the candidates and re-run our dictionary attacks (with subsquent modifications), but we aren't holding our breath. Brute force isn't really an option as non of us have any PC's we can donate soley to this piece of coursework (it would take about 158,086,131,840 comparisons and about 40days constant computation from my PC). We do plan to try John or Jake the Ripper at some stage, but that will be used as a final resort as ultimately we'd prefer to say "we did this and found this" - I know of one lad who simply started John up and asked it to find the passwords, after 3days solid work (before it crashed) it had found 9 passwords, some of which we didn't have, but then it wouldn't actually find many of the ones we do.

Does anyone have any other ideas, we are kinda stumped at the moment?

cheers.

[ThatPhilBrettGuy]

Foreign dictionaries, and brute forcing a dictionary lookup with a few numbers tacked on the end.

Oh and change your program to C and use a good compiler!

[docevi1]

ThatPhilBrettGuy said:

Foreign dictionaries, and brute forcing a dictionary lookup with a few numbers tacked on the end. Oh and change your program to C and use a good compiler!

To some extent we have already used foreign dictionaries, but haven't tried adding numbers on the end yet (that was on the list to try but unsure on what to do)

[ThatPhilBrettGuy]

docevi1 said:

ThatPhilBrettGuy said: Foreign dictionaries, and brute forcing a dictionary lookup with a few numbers tacked on the end. Oh and change your program to C and use a good compiler! To some extent we have already used foreign dictionaries, but haven't tried adding numbers on the end yet (that was on the list to try but unsure on what to do)

blah1, blah2... blah01, blah02.. blah001... you get the idea.

Stuffing peoples extention numbers / all the office numbers on the end of a dictionary attack gets results sometimes.

[docevi1]

oh yes, add numbers in that way, but not sure as to what level to take it - do we try it on the small dictionary or the 250Mb beastie?

It's just making the decision on what time we can donate to it thats all. Thanks for ideas tho

edit:: these are fictious people so there are no extension numbers/office numbers or similar, it's all made up.

>> Edited by docevi1 on Thursday 17th February 20:01

[Marshy]

l0phtcrack used to be the tool of choice for password cracking - have a hunt around on the net for strategies used by it. There was an (older) program just called "crack" I think and it also had a bunch of strategies in addition to pure dictionary attacks.

If you're doing l33t speak, don't forget to substitute likely looking symbols for characters too. "!" for "i" and so on.

As has been suggested, change to C for a big speed boost, especially if your compiler will target your precise processor. You'll be wanting a bang up to date GCC for that, most likely. Have you enough RAM to cache large chunks of dictionary, for example? If you try that, watch out for limits on the maximum size a single process is allowed to occupy in physical RAM: look at "ulimit/limit" under Unix. Hmmm, another thing, is your CPU hyper-threaded? There's another thing to think about.

Someone wrote something called UFC - Ultra Fast Crypt - some years back. It's the same as crypt but without the normal crippling delays built in to the libc version deliberately to stop brute forcing login prompts.

[dilbert]

I believe that passwords under Unix are one way encrypted and stored in an ordinary file.

You might be able to disassemble the encryption code, but you'll need some patience for that. Given the nature of Unix, you may be able to get hold of the source for it anyhow.

If you have an account with sufficient privileges to get the password file, distribute it between your freinds, and each of you use a different strategy.

Not that it's going to be available to you for your project, but if you have the file you can use dedicated hardware to attack multiple copies of the file.

You won't find anything about attack strategies on this site, but with a little lateral thinking I'm sure you can imagine a way in which their products could be beneficial.

www.xilinx.com

[docevi1]

I have the password file sitting here already, for example:

Gordon Brown:JN/MuUCRWmC9g
Alan Shearer:1lLMYsrgVzPUY
Ellen MacArthur:JTdFj.As0Zovw

there is no security involved - it's freely distributed on the coursework website.

I even have a version Java source version of the Algorithm which encrypts the passwords - it's one way, impossible to work backwards apparently.

Our other problem is that we can't use Unix/Linux at uni as they have a 5min process rule - anything which occupies more than 5mins of a workstations CPU time is shut down

Thanks for the ideas mind, Marshy you've pointed us in another direction !

[Marshy]

dilbert said:

I believe that passwords under Unix are one way encrypted and stored in an ordinary file. You might be able to disassemble the encryption code, but you'll need some patience for that. Given the nature of Unix, you may be able to get hold of the source for it anyhow.

Correct, and more correct that you can imagine. Yes, the passwords are one-way encrypted and stored in a plain ordinary file. It's the old sausage machine thing: you can put pig in at one end and crank out sausages, but the reverse does not apply. The crypt algorithm is freely available, and has been since (effectively) since the dawn of time.

Password files are cracked in the brute-force way: you throw dictionary words at the same encryption algorithm and watch for matching encrypted passwords. The trick is not just throwing a dictionary at the problem, but also trying to figure out what variants of the user login name, first name, surname, etc might have been used by people choosing weak passwords. Most times you just need one user with a weak brute-forceable password: then you can log on to the system and exploit some local vulnerabilty to get root (as they say).

Password security is a balancing act: you can (and should!) enforce password security: minimum length, combinations of (mixed case letters/numbers/symbols, maximum age. If you do this, though, you need to make sure you don't go overboard and force users to write passwords on post-its hidden under their keyboard.


>> Edited by Marshy on Thursday 17th February 21:09

[docevi1]

if you are going to write your program, make damned sure when you modify it to increase performance and find that it doesn't, you change everything back. That way, you will allow yourself to check all passwords, rather than just half of the sodding things!

However, after that bombshell (means I need to re-run the dictionaries) I looked into l0phtcrack, but whereas my java program (and Java isn't known to be fast) can compute around 45kpwd/s, it was only doing around 6k.

Bugger!

John The Ripper looks like an option still, but I think we are going to try getting a C program written/working. Hopefully shouldn't be that hard considering it's just file IO and some for loops, then again, having never written anything in C before it could be fun!

[si_j]

Hasn't l0phtcrack now become Lc4 or L4c??

Haven't used it for over a year but it was pretty good as a last resort for some forgotten admin passwords.
Sounds like an interesting project, with they had them like that when I was at Uni.

[docevi1]

l0phtcrack still exists as is up to version 1.5 and is still open source, however the company @somethingorother have "optimised it" and it is no LC5 (previous incarnations = LC4 of course).

It is an interesting project, but it is let down by the sheer amount of work to be done, before actually starting the write up. It's not a difficult task by any means (well finding what to search on/tools to use/optimasation techniques can be), it's just the sheer about of computation time it takes up - time in which I need my PC generally.

That is why we now need to box clever and hence why I've asked for some advice

[Marshy]

God, I'm losing it, had completely forgotten about John the Ripper.

[trooperiziz]

docevi1 said:

edit:: these are fictious people so there are no extension numbers/office numbers or similar, it's all made up.

You could try keyboard patterns as opposed to word patterns.


I'd make sure you include in your summary that this experiment will show up bad passwords but isn't really a good test of password security. The single biggest problem with password security is the person that knows it. They will write it down somewhere, use a password that refers to something in their office, allow themselves to be watched typing it in, use the same password across all their systems. Using fictional people takes all this out of the equation and makes the job a lot harder...

[zaktoo]

I'm astounded that your java thingy can do 45k pws but the l0phtcrack thing only 6k! That aside, don't forget the favourite non-alpha char ever for passwords (in my experience with lusers anyway ;-) - the underscore "_"... also tack on every year since say 1950 to the end of dictionary words, eg apple_1974 ;-) Someone is going to have a word that they fancy for some or other reason, and happened to have been born in that year...

Ciao

Zak_1963 (ooops!)

[zumbruk]

dilbert said:

I believe that passwords under Unix are one way encrypted and stored in an ordinary file. You might be able to disassemble the encryption code,

Err, no you won't. As has rightly been pointed out, the algorithm is unidirectional (on most Unices, it implements a one-rotor machine designed along the lines of the German Enigma, but with a 256-element rotor. On newer ones you can choose the encryption algorithm.)

dilbert said:

but you'll need some patience for that. Given the nature of Unix, you may be able to get hold of the source for it anyhow.

Not that that will help. Any decent security system should be amenable to inspection of the source without compromising security (the "crystal box" principle.)

dilbert said:

If you have an account with sufficient privileges to get the password file,

On older Unices, the passwd file contains encrypted passwords and is world readable, so no privilege is required. On newer ones, the passwords are contained in a seperate file, readable only by root. If you already have root, the contents of the shadow password file are irrelevant!

[docevi1]

trooperiziz said:

You could try keyboard patterns as opposed to word patterns. I'd make sure you include in your summary that this experiment will show up bad passwords but isn't really a good test of password security. The single biggest problem with password security is the person that knows it. They will write it down somewhere, use a password that refers to something in their office, allow themselves to be watched typing it in, use the same password across all their systems. Using fictional people takes all this out of the equation and makes the job a lot harder...

That is a very good point, we had thought of something similar, but hadn't put it into words yet Thank you!

[docevi1]

zaktoo said:

I'm astounded that your java thingy can do 45k pws but the l0phtcrack thing only 6k!

To be fair I'm not.

All my Java program does is load a password file into an array, and then reads in a line of the dictionary and compares it against the array e.g.:

while((inputLine = in.readLine())!=null)
for(int i=0; i<names.length(); i++)
//check password

whereas LC5 has a lot of graphical output, calculates remaining time dynamically, shows graphs... ours is a command line ultility with very little flair. Compare ours to what JtR could do and I'd expect the exact opposite to hold, but then we don't know what JtR is doing so can't write it up as easily.

[victormeldrew]

Another key point for your report is the fact that you are not simulating a real attack on the computer. You have the password file already, which no genuine attacker would have. This makes your job of cracking the passwords a lot easier, as normally you wouldn't be able to fire passwords at a login prompt ad nauseum.

[dilbert]

zumbruk said:

dilbert said: I believe that passwords under Unix are one way encrypted and stored in an ordinary file. You might be able to disassemble the encryption code, Err, no you won't. As has rightly been pointed out, the algorithm is unidirectional (on most Unices, it implements a one-rotor machine designed along the lines of the German Enigma, but with a 256-element rotor. On newer ones you can choose the encryption algorithm.)

Well pardon me for being so ignorant. Once you know the algorithm, if you can perform in excess of a giga password per second in the forward direction, who cares if it's one way encrypted.

If it's open source, that just makes it easier.

>> Edited by dilbert on Friday 18th February 12:21

On further consideration, I reckon you could achieve that capability in a box the size of a standard PC compatible, using programmable logic.

As a part of your investigation you might want to do some cursory research into languages like VHDL, Verilog and System C. These would be the most likely mechanisim by which you could get your code into programmable logic or silicon.

Ultimately it is the language that drives the silicon compiler, that provides the environment for programmers in languages like "C" (and assembler). It is then "C" (and assembler) that provide the environment for interpreted languages like Java.

I believe Sun produced silicon for a product they called "Pico Java" at one point. It's a shame it died a death really (at least I think it did). The idea of computer language unification is quite cool, but I think quite distant.

I think the biggest problem is that the fundamental architecture for the Java Virtual Machine is based around a LIFO interface to the ALU. This makes it pretty efficient when running as a virtual machine, but if you put it on silicon, it sucks compared to broadly equivalent microcontrollers.

>> Edited by dilbert on Friday 18th February 12:51