Pete Finnigan's Oracle Security Forum

Forum

Home/Forum

Welcome, Guest. Please Login. Apr 22^nd, 2025, 11:25pm 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 39045 times)

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 #15 on: Sep 22^nd, 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

---

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

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 #16 on: Sep 22^nd, 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 users

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

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 #17 on: Sep 22^nd, 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

------

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 #18 on: Sep 22^nd, 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

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 24^th, 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
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 #20 on: Sep 25^th, 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

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 25^th, 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
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 #22 on: Sep 26^th, 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 26^th, 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
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 #24 on: Sep 28^th, 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.

USERNAME	PASSWORD	PASSWORDHASH	Time to crack	Number passw. tried
--------	---------	----------------	----------------	-------------------
Z	~	E45D4F87F1720058	00d 00:00:00	70
Z	~~	7CA60AB459936F74	00d 00:00:00	4831
Z	~~~	74579775C249B06A	00d 00:00:00	333340
Z	~~~~	B8A8583F562B1AE2	00d 00:00:36	23000461
Z	~~~~~	373D8989A86FBDE7	00d 00:42:40	1587031810
Z	~~~~~~	6F08342ABF265F91	01d 16:47:23	109505194891

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:

USERNAME	PASSWORD	PASSWORDHASH	Time to crack	Number passw. tried
--------	---------	----------------	----------------	-------------------
Z	~~~~~~~	AE7E50824EB70A9A	117d 06:30:00	7555858447480
Z	~~~~~~~~	C0249B54717714E7	8091d 16:00:00	521354232876121

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 29^th, 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
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 #26 on: Oct 5^th, 2005, 9:25am »

Quote | Modify

Hi Pete,

Thanks for the feedback. I've tried cracking the same password with different usernames:

USERNAME	PASSWORD	PASSWORDHASH	Time to crack	Number passw. tried
--------	---------	----------------	----------------	-------------------
Z	~~~~~	373D8989A86FBDE7	00d 00:42:40	1587031810
ZZ	~~~~~	6A5210699D12B455	00d 00:37:14	1587031810
ZZZ	~~~~~	A321E37C438FDC8A	00d 00:37:37	1587031810
ZZZZ	~~~~~	66712F4DD8D15493	00d 00:51:47	1587031810
ZZZZZ	~~~~~	9495C316A1CDBD4E	00d 00:45:09	1587031810
ZZZZZZ	~~~~~	5F0FBC104CEC7DAE	00d 00:44:25	1587031810
ZZZZZZZ	~~~~~	B995ED989374B5F3	00d 00:41:14	1587031810
ZZZZZZZZ	~~~~~	CFB3E087D3C4AB39	00d 00:58:52	1587031810

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

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 #27 on: Nov 4^th, 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

Pete Finnigan
PeteFinnigan.com Administrator

Oracle Security is easier if you design for it

View Profile | WWW | Email

Gender: male

Posts: 309

Output to file?
« Reply #28 on: Dec 30^th, 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

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 30^th, 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

Pages: 1 2

Reply | Notify of replies | Send Topic | Print


« Previous topic \| Next topic »

PFCLScan
Simply connect PFCLScan to your Oracle database and it will automatically discover the security issues that could make your Oracle database vulnerable to attack and to the potential loss of your data.

Learn more
PFCLObfuscate
PFCLObfuscate is the only tool available that can automatically add license controls to your PL/SQL code. PFCLObfuscate protects your Intellectual Property invested in your PL/SQL database code.

Learn more
PFCLCode
PFCLCode is a tool to allow you to analyse your PL/SQL code for many different types of security issues. PFCLCode gives you a detailed review and reports and includes a powerful colour syntax highlighting code editor

Learn more
PFCLForensics
PFCLForensics is the only tool available to allow you to do a detailed live response of a breached Oracle database and to then go on and do a detailed forensic analysis of the data gathered.

Learn more
PFCLReselling
PeteFinnigan.com Limited has partnered with a small number of relevant companies to resell their products where they enhance or compliment what we do

Learn more
PFCLATK
PFCLATK is a toolkit that allows detailed pre-defined policy driven audit trails for your Oracle database. The toolkit also provides for a centralised audit trail and centralised activity reporting

Learn more
PFCLCookie
PFCLCookie is a useful tool to use to audit your websites for tracking cookies. Scan websites in a natural way using powerful browser driven scanner

Learn more
PFCLTraining
PFCLTraining is a set of expert training classes for you, aimed at teaching how to audit your own Oracle database, design audit trails, secure code in PL/SQL and secure and lock down your Oracle database.

Learn more
PFCLServices
Choose PFCLServices to add PeteFinnigan.com Ltd to your team for your Oracle Security needs. We are experts in performing detailed security audits, data security design work and policy creation

Learn more
PFCLConsulting
Choose PFCLConsulting to ask PeteFinnigan.com Limited to set up and use our products on your behalf

Learn more
PFCLCustom
All of our software products can be customised at a number of levels. Choose this to see how our products can be part of your products and services

Learn more
PFCLCloud
Private cloud, public cloud, hybrid cloud or no cloud. Learn how all of our services, trainings and products will work in the cloud

Learn more
PFCLUserRights
PFCLUserRights allows you to create a very detailed view of database users rights. The focus of the reports is to allow you to decide what privileges and accounts to keep and which to remove.

Learn more
PFCLSTK
PFCLSTK is a toolkit application that allows you to provide database security easily to an existing database. PFCLSTK is a policy driven toolkit of PL/SQL that creates your security

Learn more
PFCLSFTK
PFCLSFTK is a toolkit that solves the problem of securing third party applications written in PL/SQL. It does this by creating a thin layer between the application and database and this traps SQL Injection attempts. This is a static firewall.

Learn more
PFCLSEO
PFCLSEO is a web scanner based on the PFCLScan technology so that a user can easily scan a website for technical SEO issues

Learn more