Jump to content

Community Rainbow Tables :: What Technology Next?


silivrenion

Which Rainbow Table technology will we explore next?  

88 members have voted

  1. 1.

    • Cisco PIX
      2
    • MD2
      0
    • MD4
      0
    • MD5
      24
    • MySQL SHA1
      0
    • MySQL v.3.23
      3
    • NT LanMan
      10
    • RIPEMD-160
      1
    • SHA1
      6


Recommended Posts

For those of you who are unfamiliar with the Community Rainbow Tables project, you can check us out at http://www.hak5.org/wiki/index.php?title=C..._Rainbow_Tables

For everyone else, we have successfully filled the active rainbow tables list with generating tables!!! That means, there's no more unassigned tables left!!!

::pause for cheering/beer/etc.::

Alright. The battle's half over with LM Hashes. We need to finish up generating the tables and create a torrent distribution of it.

The next question is what are we going to do now? Now that there's no unassigned sections, we need to start thinking about the next direction we will start building in.

Our choices for upcoming tables consist of Cisco PIX, MD2, MD4, MD5, MySQL SHA1, MySQL v.3.23, NT LanMan, RIPEMD-160, and SHA1. We need to compare and contrast the hardware, time, disk space, bandwidth requirements, distributability, and mathematical preferences behind these choices to make sure we pick a next table group that will be an important significance to the community.

Please discuss the pros and cons, and feasability of these technologies, so that we can choose which will be the next in line.

Link to comment
Share on other sites

You ask for a technical discussion on the merits of the various algorithms, but no links to additional info on them.

Obviously with the NTLM, MySQL and Cisco ones it's trivial to determine the practical use of them, but what systems use any of the algorithms, and what do they use them for?

From an emotional standpoint I'm leaning primarily towards NTLM and SHA1, but I have no technical points to bring up that will add actual merit to this particular preference.

Link to comment
Share on other sites

heh, sorry about that, I was kind of hoping other people had more information than me about the actual technologies...

Basically, google searching gives some good insight into the different technologies and what they do from a usage standpoint.

Cisco PIX tables would contribute to Cisco PIX firewall password cracking.

Information about MD2,4,5 are available via RSA Security :: http://www.rsasecurity.com/rsalabs/node.asp?id=2253

Practical applications for MD encryption I'm at a lack of information about.

The usage of MySQL SHA1 encryption is defined in the MySQL 5.0 Ref Manual at http://dev.mysql.com/doc/refman/5.0/en/enc...l#function_sha1

There's an excellent NTLM article at wikipedia at http://en.wikipedia.org/wiki/NTLM

RIPEMD-160 is also explained in wikipedia at http://en.wikipedia.org/wiki/RIPEMD-160

Last, but not least SHA1 information can be found at http://en.wikipedia.org/wiki/SHA1 and http://www.w3.org/PICS/DSig/SHA1_1_0.html

Link to comment
Share on other sites

How about sticking up some linux & windows howto's with links that work.... try hosting the software you guys use for this on one of these remote storage thingys such as: fasthost (well they're shit really im sure someone could find a better one).

and yea... so when all this is done.... anyone thought of any apps for this uber table thing? .... im this one some thought ive come up with a few but i need to stew a bit on them.... until then good job boys

Link to comment
Share on other sites

SHA512

not really implemented all that widely, and it would take REALLY long and be REALLY big, but why the hell not. There's no use for it, but lets just do it anyway.

But seriously, if you have nothing to do with your extra CPU time, why not just leave a folding client on running. At least that way you're helping scientists to fold proteins.

Link to comment
Share on other sites

Many websites that are "password protected" use MD5, so it seems like a useful target. NTLM would also be useful, for obvious reasons.

I don't know how much call there is for PIX passwords: can the passwords be dumped from a PIX router easily? I would think it would already require access to the router.

Does anyone know of a non-windows (i.e., webbased) tool for calculating success probabilties or table sizes? Or even the equations to do so? If anyone can point me to those, I could put something online to compare the different algorithms in terms of precomputation time, storage size, and success probability.

Link to comment
Share on other sites

That page is really trivial to make, and getting rcrack to only spit out the relevant information isn't a challenge by a long shot (bash script and sed should be all you need).

What I'm currently looking at is what the rcrack program is actually doing. From the looks of it it blindly searches through the file(s) at hand sequentially for a hit. I'm thinking if it would be possible to make some sort of hash table index over it, load that once and keep running so that the rcrack-equivalent program won't need to pour over the 200+ gb of data for every query (but rather, only a couple of megs). Not sure if this is feasible, but it's worth a shot.

Link to comment
Share on other sites

Cooper, If I understand crypto hashes, the result should be random yet unique. Which would really lay ruin to a hash table, because it make it very difficult to map them to a memory address, and keep the collisions low. However, What you probably want is a Binary Search Tree, where each node points a position in the table (1/2, 1/4, 3/4, etc.) That should be O(log(n)) for those that are counting. I doubt you'll get anything more efficient than that.

EDIT: I forgot to mention that the Rainbow table should be sorted first

Link to comment
Share on other sites

Well, yeah, but here's what got me thinking.

The rcrack program has its main function in RainbowCrack.cpp. It sets up some variables, then calls the CCrackEngine::Run method from the CrackEngine.cpp file. This function sorts the list of rainbowtable filenames, and then passes them, one at a time, on to the SearchRainbowTable method of the same class. This method reads a chain from the file and passes it on to the SearchTableChunk method. At that point I cut out. Need more time to figure out what's going on behind the scenes. What the structures are. What a rainbowtable looks like, and why it looks like that. (What is it with coders these days? Someone convince them that commenting code is a cardinal sin or something?)

The theory is that a single record of the data that's being searched (the hash / passcode combo) is signnificantly larger than 12 bytes. Those 12 bytes are the first 4 bytes of the hash and 8 bytes for the filepointer (making the assumption that even if they aren't stored in one big file, it can be viewed as such). You can store the positions in the file(s) where the hashes that start with XXXX are kept, and then at subsequent calls just check those locations, reducing the amount of file to actually test by 2^32.

You could even store it on the filesystem using a directory structure.

The main thing is that even though you can sort the rainbowtable, I don't see a fastpath in the code that says 'This file is sorted. The beginning is too low and so is the ending. Next file please!'. It appears to dig through the entire file indiscriminately and dies quickly if the file _isn't_ sorted. Maybe I'm missing something in the code. If so, please point it out. The reading of the file happens in that SearchRainbowTable method I mentioned earlier.

Link to comment
Share on other sites

I'm all for doing MD5 next, but...

MD5 is most widely used on Linux and BSD, to my knowledge.

Matir:

Many websites that are "password protected" use MD5, so it seems like a useful target.

However, most *NIX distros now use md5 + salt, which makes Rainbow Tables nearly ineffective. I'm sure there is a work around of sorts, but I just thought that this would be good to mention, before we all start generating almost-useless MD5 tables.

Link to comment
Share on other sites

I'm all for SHA1 then, which is quite widely used, and I think without salt.

Alot of IRC networks and other use it to store oper block passwords (as I discovered by experience *nod to Silivrenion*). As you can see, this would be extremely usefull.

Maybe SHA1, then NTLM, then whatever they want to come out besides MD5? MD5 is still very widely used, so it would be very usefull. Maybe SHA1 and NTLM after MD5? I'm just worried we might do it all for kaput.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...