So why write a tool completely in PL/SQL?
A number of reasons really. I wanted to have a tool that just runs and checks the basics without extracting password hashes, usernames etc from the database. I know checkpwd connects to the database and also that woraauthbf will do so soon as well (I am writing some OCI code for Laszlo to allow this, just not much time recently to complete it..:-( )
Any binary based tool, is well a binary.... it needs an Oracle client that works out of the box, the instant client often requires some tweaking to make it work. If the tool doesnt connect to the database you need to gather the usernames/hashes first. Just running with no dependancies is attractive.
In the olden days before C based crackers were freely available the only free Oracle passwords crackers were PL/SQL based (the most popular was the bear dang one that did brute force checks and the Adam Martin one that did a dictionary attack) but they all used the ALTER USER command to alter the users password in the database for each password guess and then compared the hash generated. This has a number of issues, the first is that the database is altered (any security tool should not alter the software or data being checked), any password management would become locked or would need to be removed, any triggers, audit etc would be affected.....more.....
I wanted to see if its possible to write a PL/SQL based password cracked in PL/SQL that doesnt use ALTER USER commands but actually implements the encryption routines so that any password can be checked. Also I wanted the tool to be an anonymous block in PL/SQL so that it can be run from any client with no external or internal dependancies in the database.
Let's take a look at it running and then discuss it:
|
The script runs fairly fast for a PL/SQL script, its no where near as fast as a C based approach but thats not its intention. My intention was to have a script that runs fast enough to check:
- username=password
- password=known default
- password=simple word
- known hash but not cracked
- simple brute force
What do the columns mean? - the first means 'U'ser or 'R'ole, the second is the name, the third the cracked password, if its an impossible password it says so, if its EXTERNAL or GLOBAL it says so and also if we know its a default hash but don't know the password it says. The CR column defines the mode of being cracked, PU => pass=username, DE => default password, DI => dictionary word, BF => brute force, IM => impossible password. The FL column is CRacked or not, the final colum is the account status.
The release code will include more account analysis.
Then the idea is to output the relevant input for worauthbf. The key aim of this script is to allow people to easily check their databases for the worst sins that can be aimed at passwords, i.e. very simple passwords. I am starting to see a number of sites cracking passwords for their databases in an attempt to strengthen passwords. This sqlplus script will make that process much easier.
The speed is not bad, between 13,000 and 16,000 hashes per second, its not the 1.2Million hashes per second with woraauthbf BUT remember that i am testing on a laptop, this code will actually run on your production database server, thats not as easy to do with a binary based approach and also its not the intention to replace woraauthbf, its an attempt to get people to test the basics more easily.
If anyone would like this script then I will release the code next week after I have tidied it up and added some extra bits I want to add. So please watch out for a post next week with the code in it.
September 22nd, 2008 at 06:35 pm
Pete Finnigan says:
This looks like a cool program. Any updates on when you will be posting it?
cracker-v2.0.sql
Thanks