Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Welcome, Guest. Please Login.
Nov 19th, 2017, 4:40am
News: Welcome to Pete Finnigan's Oracle security forum
Home | Help | Search | Members | Login
   Pete Finnigan's Oracle Security Forum
   Oracle Security
   Oracle Security tools
(Moderator: Pete Finnigan)
   Toolcrypt's orabf
« Previous topic | Next topic »
Pages: 1 2  Reply | Notify of replies | Send Topic | Print
   Author  Topic: Toolcrypt's orabf  (Read 25009 times)
kornbrust
PeteFinnigan.com Newbie
*





   
View Profile |

Gender: male
Posts: 27
Re: Toolcrypt's orabf
« Reply #15 on: Sep 22nd, 2005, 10:36am »
Quote | Modify

Ivan
 
where is the problem with & and @ in passwords?
 
+++++++++++++++++++++++++++++++
SQL> alter user scott identified by "&alex";
Enter value for alex: &alex
old 1: alter user scott identified by "&alex"
new 1: alter user scott identified by "&alex"
 
User altered.
 
or you could use the "set define off" command
SQL> set define off
SQL> alter user scott identified by "&alex";
 
User altered.
 
SQL> alter user scott identified by "@alex";
 
User altered.
+++++++++++++++++++++++++++++++
 
You mentioned in your post that orabf is checking impossible passwords like "!alex". That's not true. A DBA can (not must) use such a password and orabf is able to find it.
 
 
Regards
 
 Alexander
 
---  
« Last Edit: Sep 17th, 2009, 4:43pm by Pete Finnigan » IP Logged
isaez
PeteFinnigan.com Junior Member
**



Ivan

   
View Profile |

Gender: male
Posts: 76
Re: Toolcrypt's orabf
« Reply #16 on: Sep 22nd, 2005, 12:51pm »
Quote | Modify

Alexander,
 
With regard to & : you say it your self. You have to set define off  
With regard with @:  
 
ISAEZ on 22-SEP-05 at IVAN2 > alter user isaez identified by "@bla";
 
User altered.
 
ISAEZ on 22-SEP-05 at IVAN2 > connect isaez
Enter password:
SP2-0306: Invalid option.
Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
where <logon>  ::= <username>[/<password>][@<connect_identifier>] | /
 
You could always do: connect isaez/"@bla"
But try to tell this to your usersSmiley
The point I'm trying to make is that there is room for improvement for orabf. If a dba, like me, has a password policy defined for his users like ( for example in my case start with a alpha (A-Z), at least one digit, at least one punctuation ($_#) and at least 6 characters long) then orabf could take such a policy into account. It would be so much faster to check those passwords.
 
regards,
 
Ivan
IP Logged

regards,

Ivan
kornbrust
PeteFinnigan.com Newbie
*





   
View Profile |

Gender: male
Posts: 27
Re: Toolcrypt's orabf
« Reply #17 on: Sep 22nd, 2005, 6:50pm »
Quote | Modify

Ivan,
 
OK now I understand. Users can be diffcult . You suggest an additional mode for orabf.
 
In my opinion it makes more sense to change your password verify function. At least 9 characters + special characters for normal users and 12 characters for system accounts(sys,system,outln,dbsnmp, ...).
 
Instead of using BF I would recommend you the following approach:
 
1. BF hashkeys for short passwords (up to 6 characters), if these passwords are possible.
 
2. Check the rest of the passwords with a dictionary attack. The probability to guess/find a weak password is much higher than BF. And that's the goal, isn't it?
 
You can use John The Ripper to create permutations (even with your own rules) of your dictionary file.
 
 
checkpwd
[...]
Q: Is there a bigger dictionary file with permutations e.g. Oracle, 0racle, Oracle1, Oracle2, ...?  
A: You could use John the Ripper to create such a dictionary file (e.g. john.exe -wordfile:password_list.txt -stdout -rules > password_list_big.txt). The result is a 840 MB file.
[...]
 
 
Regards
 
 Alexander
 
------
« Last Edit: Sep 17th, 2009, 4:43pm by Pete Finnigan » IP Logged
isaez
PeteFinnigan.com Junior Member
**



Ivan

   
View Profile |

Gender: male
Posts: 76
Re: Toolcrypt's orabf
« Reply #18 on: Sep 22nd, 2005, 7:18pm »
Quote | Modify

Alexander,
 
Thanks for your input.
Yes, I suggest an additional mode for orabf.
The problem is that we have a password policy that resembles very much another password policy for the OS. Users want to have the same password for Oracle as for the OS. Maybe a bad idea but we have to follow.  
By the way: OPS$ accounts are out of the question.
Users have passwords that for an outsider seems strong enough but for insiders are sometimes easy to guess. For example JDHG2.33 is composed of the users initial John Doe, the building HG and room 2.33.
Another popular form is JD#12256 (John Doe and internal phone number). So a dictionary attack is probably not very useful. So my idea was to have a orabf-like tool and let it check a subset of the posible password universum (namely those defined by the password policy).
I'll take a look at John The Ripper (not Jack?); maybe I can generate permutations for popular passwords.
 
In the long run a PKI/SSO solutions seems ideal but legacy applications makes it difficult.
 
Thanks.
 
regards,
 
Ivan
IP Logged

regards,

Ivan
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: Toolcrypt's orabf
« Reply #19 on: Sep 24th, 2005, 9:30pm »
Quote | Modify

Hi Ivan and Alex,
 
Can I make a few comments on this excellent discussion. The first to Ivan, the fact that you use a policy that is based on users names, locations and phone numbers sounds like a bad idea. If any hacker learns this all he has to do is steal phone lists, room numbers etc and he can crack any users password. It also sounds like users passwords are not changed often if at all if they are based on simple rules such as this.  
 
You said that brute force is easier. In fact in this case a dictionary attack is better although the dictionary is a custome one based on your users names, phone numbers and buildings. Also if an outsider happens to brute force a few passwords he might be able to guess the naming sequences used.
 
Alex, we have I think discussed this before in email or IM. I think a good order to crack passwords is:
 
1 - username=password
2 - username has a default password (or is a default user)
3 - username has a dictionary word for its password
4 - brute force up to 6 characters ASCII
5 - depending on time brute force ASCII+DIGITS for 6 characters
 
Of course as each password is cracked at each stage it would be then tried for all users at the same time and the list of users to crack would be reduced. I would also throw in the hashes from SYS.USER_HISTORY$ and also clear text passwords from various internal tables such as SYS.LINK$
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
isaez
PeteFinnigan.com Junior Member
**



Ivan

   
View Profile |

Gender: male
Posts: 76
Re: Toolcrypt's orabf
« Reply #20 on: Sep 25th, 2005, 7:50am »
Quote | Modify

Pete,
 
I don't use a policy that is based on user names, locations and phone numbers. The users do. Our policy, as I said, is based on another password policy: at least 6 chars, start with one alpha, at least one digit and at least one punctuation. I just noticed that users where using passwords with their initials, phone- and room numbers in it.
Passwords are changed every 3 months, old passwords can't be reused.  
So there is a password policy in place but the constructud passwords are predictable (not all of them of course). I think this is a common problem: if you don't have a password policy people tend to use common (short) words as passwords. Words like : sex, secret, topsecret, etc. Or password=username. And if you have a password policy they tend to device some sort of mechanisme to remember them (write it on a post-it and put it on the monitor). Apperantly users, maybe following some ones advice came up with these combinations of initials, phone/room number. I've told them not to use those passwords because they are predictable. And now I was hoping to check with orabf if they came up with more secure passwords. But for the longer passwords orabf's method take to long to crack.
A dictionary attack is indeed in those cases better (faster). But I was hoping that orabf could be learned about a password policy.  
For the time being I've a custom password verification policy that checks those predictable passwords and refuses the password when a user tries to change his password. But it's not 100% safe (false positives) and users find it very irritating.  
There is a great deal of psychology involved in passwords.  
 
regards,
 
Ivan
IP Logged

regards,

Ivan
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: Toolcrypt's orabf
« Reply #21 on: Sep 25th, 2005, 7:24pm »
Quote | Modify

Hi Ivan,
 
Thanks for your upate, I undertand your situation now. I think for you a custom version of orabf would be a great help. I think also for others as well it would be useful if the author of orabf could make a brute force version (policy might be a better description) that took into account (dynamically) password policies that are in use.  
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
gamyers
PeteFinnigan.com Junior Member
**



I love YaBB 1G - SP1!

   
View Profile |

Posts: 80
Re: Toolcrypt's orabf
« Reply #22 on: Sep 26th, 2005, 8:38am »
Quote | Modify

I think this raises the issue of why "strong" passwords can be worse that "weak" ones, albeit very differently from the paper mentioned :
"There is a paper from Lohkee that you can find through Google. Look for : Lohkee strong passwords zucchini "
 
The strong password is supposed to  
1) Make it harder for a brute force attack to succeed because the larger character set makes the task take longer.
2) Make it harder for a dictionary attack to succeed because passwords using these characters are less likely to be in the dictionary.
 
However, working against the "strong" password is that a person still has to choose and remember it. And quite simply, people are unable to choose 'random' passwords.
In many cases, they'll go for a a word and add a number and symbol to the end, or other simple 'munge', or use personal information such as a phone number, car's registration number etc.
 
If they are given a random password, it will probably be forgotten or written down. Perhaps there is scope for an application that generates random passwords plus a mnemonic for remembering them ?  
 
The crackers posted here make it clear that dictionary words and short (six/seven and even eight character) passwords are easily cracked. 'Munged' and nine/ten character passwords won't stand up much longer. CPUs are catching up with them.
 
But this is based on knowledge of the HASH password. I wonder if the next step is up to Oracle and making this less accessible.
IP Logged
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: Toolcrypt's orabf
« Reply #23 on: Sep 26th, 2005, 6:08pm »
Quote | Modify

Hi Gary,
 
I liked the comments that you have made. You are right a password policy to make a supposed stronger password could make it weaker but only if the hash is known and only if the policy is known. Remember we are discussing auditing and not hacking. A hacker should not have the password hashes in an ideal world so use of orabf would then not be possible. He would need to resort to other methods such as connect scripts which would nevre be practical for brute forcing. Also in an ideal world the hacker would not have access to the complete password policy. It would be contained in the profile and also in code in a verification function. The profiles should only be read if a user has already been compromised that has access to profiles and the same if a user has been compromised that has access to the password function code. If the function were wrapped then that would be much harder.
 
So as you point out the need is to be able to protect the hashes. block access to SYS.USER$, DBA-USERS, SYS.USER_HISTORY$ ... also orapwd file, full exports, list files from sqlplus etc...  
 
Also the issue of reading the password policy from the database is controlled by ensuring access to all base tables and views are locked down to DBA's ior SYS and that these users have passwords of 12 characters.
 
I agree with what you are saying but its as complex landscape that depends on knowedge of the hash and policy to make it easier to crack with brute force.
 
Nice comments gary.
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Marcel-Jan
PeteFinnigan.com Junior Member
**






   
View Profile | WWW |

Gender: male
Posts: 83
Re: Toolcrypt's orabf
« Reply #24 on: Sep 28th, 2005, 10:41am »
Quote | Modify

Hi everybody,
 
I did some new time measurements, this time with passwords with alphanumerical character plus special characters (the entire keyspace). Again I've used my Pentium 4 1,7 Ghz with 512Mb. Also I tried to crack passwords that contain ~ characters, which are at the end of the list of ASCII characters orabf scans for. Therefor it will take the most time per character.
 
USERNAMEPASSWORDPASSWORDHASHTime to crackNumber passw. tried
--------------------------------------------------------------------
Z~E45D4F87F172005800d 00:00:0070
Z~~7CA60AB459936F7400d 00:00:004831
Z~~~74579775C249B06A00d 00:00:00333340
Z~~~~B8A8583F562B1AE200d 00:00:3623000461
Z~~~~~373D8989A86FBDE700d 00:42:401587031810
Z~~~~~~6F08342ABF265F9101d 16:47:23109505194891

 
 
Notice how much longer it takes to crack passwords of 6 characters. I could try to crack a 7 character password, but it is obviously going to take more than a month. So I calculated it:
 
USERNAMEPASSWORDPASSWORDHASHTime to crackNumber passw. tried
--------------------------------------------------------------------
Z~~~~~~~AE7E50824EB70A9A117d 06:30:007555858447480
Z~~~~~~~~C0249B54717714E78091d 16:00:00521354232876121

 
So if you use passwords of eight characters and special characters, cracking that hash will take anything between 117 and 8091 days. Sounds like that that is still pretty safe.
IP Logged
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: Toolcrypt's orabf
« Reply #25 on: Sep 29th, 2005, 1:01pm »
Quote | Modify

Hi Marcel-Jan,
 
Thanks for your updated timings, they are very useful and interesting. I have two comments/observations.  
 
The first is that your use of a one character username will skew the results a bit as the total number of characters in the username/password has a bearing on the crack time. Study the algorithm and you will see. It will not have the same effect as the difference between 6 and 7 character passwords or 7 and 8 character passwords for instance but would have some effect.This can be measured by testing the number of hashes per second on orabf for a 8 character username/password combination and also a 9 character one, the same test can be done on a 17 character combination. This result could be plugged into your results.  
 
Also passwords of 7 and 8 characters are probably out of the reach of most people but if the password being cracked were important enough to crack then "someone" (a government for instance) would certainly have the computing power to crack them in a reasonable time. Even utilizing the power of the net would be a possibility for hackers. For instance to crack an 8 character password would take 8091 days or one day for 8091 computers. Hackers routinely take over groups of PC's to send out spam so it is not inconcievable for hackers to do the same for cracking Oracle passwords.  
 
A third point (OK, sorry I promised 2 points) is that whilst your measurements are valid the time to crack a 1 character to 8 character password the time could be reduced as we should take into account probability. e.g. it is probable that some passwords would be found at the beginning of the keyspace search and also probably that some would be found at the end of the keyspace. Therefore we could use an average time (or whatever the probability mean (whas the name? - standard deviation?) is).  
 
Nice testing though Marcel-Jan,
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Marcel-Jan
PeteFinnigan.com Junior Member
**






   
View Profile | WWW |

Gender: male
Posts: 83
Re: Toolcrypt's orabf
« Reply #26 on: Oct 5th, 2005, 9:25am »
Quote | Modify

Hi Pete,
 
Thanks for the feedback. I've tried cracking the same password with different usernames:
 
USERNAMEPASSWORDPASSWORDHASHTime to crackNumber passw. tried
--------------------------------------------------------------------
Z~~~~~373D8989A86FBDE700d 00:42:401587031810
ZZ~~~~~6A5210699D12B45500d 00:37:141587031810
ZZZ~~~~~A321E37C438FDC8A00d 00:37:371587031810
ZZZZ~~~~~66712F4DD8D1549300d 00:51:471587031810
ZZZZZ~~~~~9495C316A1CDBD4E00d 00:45:091587031810
ZZZZZZ~~~~~5F0FBC104CEC7DAE00d 00:44:251587031810
ZZZZZZZ~~~~~B995ED989374B5F300d 00:41:141587031810
ZZZZZZZZ~~~~~CFB3E087D3C4AB3900d 00:58:521587031810

 
So this proves your first point.  
 
About your second point. Yes, I suppose that when you would have a distributed computing version of orabf, you could do that. And there are enough zombie-pc's to go around. On the other hand you need to have someones username/hash. On the other other hand (hang on, that's three hands) these are often too easily available (dbsnmp/dbsnmp anyone?).
 
And to conclude this post: the standard deviation of measured time to crack above is 438.0 seconds (according to Excel's stdev function), the average time is 2692 seconds (44 minutes and 52 seconds).
IP Logged
Lucas
PeteFinnigan.com Newbie
*



I love YaBB 1G - SP1!

   
View Profile |

Posts: 1
Re: Toolcrypt's orabf
« Reply #27 on: Nov 4th, 2005, 1:20pm »
Quote | Modify

i wrote mine tool less then a year ago for my final thesis Wink
 
my proggie cracks around 13k/sec in a dictionary mode which is not that bad i suppose Tongue
also when it comes to BF to compare you have to use the same characters(alphabet) in every programm  
i dont know what alphabet is used by orabf for example
 
i wanted to ask is there orabf source code available?
 
if not is it possible to get some details about methods/algoriths used inside (not the hashing one)
language used/compiler and so on
generally what makes this tool so fast Wink
 
im asking because i had some problems with finding good ones already written by someone
and i have done it from scratch
for example i had asm code that leaded to 100%memory consumption in a fewseconds
 
greetings
Lucas
 
ps. hello to everybody since this is my first post Wink
IP Logged
Growlor
PeteFinnigan.com Newbie
*





   
View Profile |

Gender: male
Posts: 1
Output to file?
« Reply #28 on: Dec 30th, 2005, 5:32am »
Quote | Modify

All,
 
I feel kind of silly asking this, but I've been struggling with what I thought would be an easy thing to do: I would like to audit some of my Oracle passwords by feeding orabf a list of password hashes with user ID's,use a large password file list, then let it run for a while. I was able to use the cmd script included in the orabf download to grind through the list and display the results to the screen with no problem (except it output so much info that I lost some of the data in my command window.) So, I decided to re-run it and output the results to a file. This seemed pretty easy, but so far no luck. I have tried a couple of variations of "orabf hash:userID passwordfile 4 8 > outputfile.txt" (with a userID = password combination to make testing run quickly) and have had no luck. If I don't attempt to redirect the output to a file, orabf reports it has found the password and displays it. If I try the simple redirection above, the screen does not display the password and a 0 length file is created. I am hoping I am just missing something really simple and one of you can point me in the right direction.
 
Thank you for your time,
John
« Last Edit: Dec 30th, 2005, 5:33am by Growlor » IP Logged
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: Toolcrypt's orabf
« Reply #29 on: Dec 30th, 2005, 9:55am »
Quote | Modify

Hi,
 
I am not a DOS (is it still DOS?) expert. Ihave had the same problem withn redirecting output to a file in DOS. I took an alternate route. Go to the system menu of the DOS window, top left c:\ icon and choose properties. In the layout tab change the screen buffer height to 9999 and it should then be possible to run it to the screen and mark and copy the results to a file.
 
hth
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pages: 1 2  Reply | Notify of replies | Send Topic | Print

« Previous topic | Next topic »

Powered by YaBB 1 Gold - SP 1.4!
Forum software copyright 2000-2004 Yet another Bulletin Board