Hi all! Regulary we have some postings here, how to re-gain access to a database when the (Admin-)password is lost. It is well known, that in this case, there are two “standard-solutions”:
Type in 10 Questionmarks, receive code, request Password from NSC
Create new DB and restore FBK
But there’s also a third possibility: “Crack the Password” [:0] So, I tried this and that … and finally I created a NAVISION Report that cracks passwords with a kind of “Brute Force”-routine … This means, that ANY user could find out ANY other passwords! (To other Apollos: Don’t worry - I just tested with Ex-Apollo-Members [;)] )
What I would like to be discussed here:- Is this a practical alternative to the “standard solutions”?
Is this an option to check the own system-security (quality of passwords)?
Originally posted by stryk
This means, that ANY user could find out ANY other passwords!
What I would like to be discussed here:- Is this a practical alternative to the “standard solutions”?
Is this an option to check the own system-security (quality of passwords)?
Is it just a criminal act of hacking?
What do you think about this?
I do not agree that ANY user could find out ANY other passwords!! You used a report to gain the other PWDs. To use a Report u must have the apropriate rights (login, use that report exec=yes) and the report must be in the license-file!! But YES it is a practical alternative to the 2 standard ways! I think it isnt just a criminal act of hacking [}:)] OK usually it is a way to gain information which you shouldnt have! (can somebody understand me [xx(] ??) Further i think: Could u support us with the report u mentioned pls?? [:p] I would really like to test it!!!
Could you send me a copy of your report. I’ve got already Super User Access to our database it’s just that I would LOOOOOVE to look at the code … What you could also do is sent it to Navision so they can improve their encryption algorithm. This would give you another challenge to break [:D]
Jörg, To my knowledge, it is illegal to break into a computer system to gain access to data and/or services which you otherwise do not have the right and possibility to access and use. On the other hand, I seem to recall that there are special regulations with respect to unencrypting/hacking passwords or other encrypted information. So, from my POV, if you are already super user or admin on your own (read: your company’s) system, with access rights to each and everything, and you are cracking passwords merely because they have been forgotten, AND you do so in accordance with and with permission of your superiors, you are not committing any crime here. However, if you do it on your own, or just because you want to test the quality of user passwords, you might be asking for trouble. [:p] Tarek, from Jörg’s description I do not think that he is exploiting any weaknesses in the encryption algorithm. “Brute-force” to me sounds more like testing a gazillion different passwords until eventually one matches [:D]
I do not agree that ANY user could find out ANY other passwords!! You used a report to gain the other PWDs. To use a Report u must have the apropriate rights (login, use that report exec=yes) and the report must be in the license-file!!
Absolutely YES! What I was thinking about was this: Install it to the DB BEFORE you need it (when you have access!) and hide it: Rename/Renumber it, so that it looks like a “boring” standard-report which is licensed but not needed. Later if you need the “Cracker” you could log on as an ordinary user (Non SUPER), add the report to any Report-List an run it [:p]
quote:
I’ve got already Super User Access to our database it’s just that I would LOOOOOVE to look at the code … What you could also do is sent it to Navision so they can improve their encryption algorithm. This would give you another challenge to break
Well, as a serious member of NOLUG … uups … MBSUG [:D] I want to know your statements first. You would be surprised how simple the routine is! I don’t think that NAVISION could do anything against this, because - as I mentioned - it’s “Brute Force”: just trying all possible passwords (so depending on password-quality and computer-performance it’s just a matter of time (my tests ran a few days!)) Maybe I’m gonna place my “Password Cracker” in the Download-Section, depending on Eriks agreement (I’m not sure if he wants to provide “Hacker-Tools” [}:)] ) Regards, Jörg
Hi, this sounds to me like the famous “back-doors” that developers create in order to gain access again to their solution once they lost the key for the main door… I agree with Heinz that if you are Admin anyway then it’s ok, if not you definitly commit a criminal act in my opinion. I guess the weak point in this solution is to camouflage the report in a way that no “normal user” can’t execute it, not even accidentally… From the description, I guess the algorithm is something like creating the text string (brute force), encrypting it using the virtual table User, and compare it to the stored password… the following topic should give some input… http://www.navision.net/forum/topic.asp?TOPIC_ID=2023 The point is, and in that way MBS could improve the actual solution, that the encrypting routine should not be accesible. Saludos Nils
[quote]
Maybe I’m gonna place my “Password Cracker” in the Download-Section, depending on Eriks agreement (I’m not sure if he wants to provide “Hacker-Tools” [}:)] )
It’s ok with me, but I think you should keep it for your self for now. As to weather this is illigal or not, then I don’t think so. As long as you’re not using it to force you into a customers database with the purpose of doing something you’re not supposed to. I think it the same as if you have a gun. As long as you’re not killing anyone and only using it to go hunting or make you self feel safe, then it couldn’t be illigal (I know that it’s illigal in most countries to have a gun, but still…).
From the description, I guess the algorithm is something like creating the text string (brute force), encrypting it using the virtual table User, and compare it to the stored password… the following topic should give some input…
[:D] That’s it! The rest is just a bunch of loops, IFs and THENs - as I said: quite simple if you have some developing-experience! And that’s what is so dangerous to me: it’s too simple!
quote:
The point is, and in that way MBS could improve the actual solution, that the encrypting routine should not be accesible.
As Tarek mentioned, I’m gonna send a copy of this Report to NAVISION Germany. I hope they think the whole password/encryption stuff over, to make such an easy cracking-thing impossible, e.g. hide the “User-Table” …
Why don’t you just contact your local MBS office because they have a program that if you fax in a signed form they can generate a code to get in to any Navision database. It’s a simple form, doesn’t take but about 1 minute to complete and it’s completely legal. /Michael
Why don’t you just contact your local MBS office because they have a program that if you fax in a signed form they can generate a code to get in to any Navision database. It’s a simple form, doesn’t take but about 1 minute to complete and it’s completely legal.
The Problem is not how to re-gain access to a DB, the problem is, that with an “ordinary” report (and b.t.w. this works principally with object-types, too) ANY user could find out ANY passwords, because the “password-compare-function” (the “kernel” of BruteForce) only needs “Read”-access to the User-table, and EVERY user needs this right, otherwise he couldn’t log on to the DB! So, there’s no possibility for admins, to avoid reading the table and comparing hypothetical passwords. Well, a problem would be to implement the “BruteForce”-code, therefore you will need at least a “Report-Designer”-license (I suppose…). And the danger that results from this is, that a user - when knowing other passwords - could do anything (damage?) with a false identity … In the case of regaining DB-acces the only advantage of “cracking” is that there are no additional costs, for the 10x? - method you’ll have to pay … Best regards, Jörg
Joerg, I’d be definately interested in your report. As a developer, it’s hard to keep track of all my passwords that I’ve ever used, and so this would be a helpful tool. Regards
Hi all! Because some of you requested the objects or the code from me: I’m not gonna publish it or send it to anyone![}:)] As I mentioned: It so very simple, that a developer could create a BF-routine within a few minutes. I just want to avoid to give such a tool into wrong hands … But to make clear, what IMO the basic problem is, here a few lines (which were allready posted in NOLUG … uhh … MBSUG): Globals User1, Type: Record, Subtype: 2000000002 (User) User2, Type: Record, Subtype: 2000000002 (User) PassWdCompare, Type: Text, Length: 30 ... // Any User is able to read records of table 2000000002 (User) // Otherwise he could not access NAVISION at all User1.GET(<AnyUser>); User2.INIT; User2."User ID" := User1."User ID"; // PassWdCompare contains a password as it would be typed in // And here comes the trouble: User2.VALIDATE(Password, PassWdCompare); // Now User2.Password contains the crypted string!!! // Only "read" actions so far!!! IF (User1.Password = User2.Password) THEN MESSAGE('You found the password!); [xx(] ... So, what IMO has to be changed: The passwords must not be saved in a table which is accessable by C/AL! Best regards, Jörg
Hi Joerg I think you mix things up. The thing is that this C/AL code just makes is possibel to use the BF way of getting in. The case is that the BF program can guess the password ONLY if the password is NOT good. The function you use in C/AL is only a problem once the BF program get to guess the right password. Until then it’s not a problem. A good test password you may try is: xO1=T(eJqD Good luck. Per program You say a Apollo-Optik, IT/ERP
quote:
Originally posted by stryk
Hi all! Because some of you requested the objects or the code from me: I’m not gonna publish it or send it to anyone![}:)] As I mentioned: It so very simple, that a developer could create a BF-routine within a few minutes. I just want to avoid to give such a tool into wrong hands … But to make clear, what IMO the basic problem is, here a few lines (which were allready posted in NOLUG … uhh … MBSUG): Globals User1, Type: Record, Subtype: 2000000002 (User) User2, Type: Record, Subtype: 2000000002 (User) PassWdCompare, Type: Text, Length: 30 ... // Any User is able to read records of table 2000000002 (User) // Otherwise he could not access NAVISION at all User1.GET(<AnyUser>); User2.INIT; User2."User ID" := User1."User ID"; // PassWdCompare contains a password as it would be typed in // And here comes the trouble: User2.VALIDATE(Password, PassWdCompare); // Now User2.Password contains the crypted string!!! // Only "read" actions so far!!! IF (User1.Password = User2.Password) THEN MESSAGE('You found the password!); [xx(] ... So, what IMO has to be changed: The passwords must not be saved in a table which is accessable by C/AL! Best regards, Jörg
I think you do [;)] BRUTE FORCE WILL CRACK ANY PASSWORD - IT’S JUST A MATTER OF TIME! So it’s just a matter of how to create the “Guess Password” (“PassWdCompare” in my example) … and that’s just a litte string-processing … or just importing a “Password Dictionary” which is available on Internet …
quote:
xO1=T(eJqD
If you assign such password to users, the monitors would be full of sticky-notes [:D] Or such a password would be changed within a few seconds … I tested NaviBF with about a dozen users, and most of their passwords were 3 to 5 characters, all a to z, … In Standard-NAVISION you have no possibility to create rules on that: min.length, special-chars, duration, etc. Regards, Jörg
Originally posted by pjc
The case is that the BF program can guess the password ONLY if the password is NOT good. The function you use in C/AL is only a problem once the BF program get to guess the right password. Until then it’s not a problem. A good test password you may try is: xO1=T(eJqD
Well, at this moment I’m trying something I’ve put together based on Joerg’s idea… It can take a while but I’m quite sure it wil find your good test password. [:o)] I’ll let you know!
I agree with Joerg… brute force will work, it’s just a matter of time… including more difficult passwords. In fact most users have really easy to find passwords (remember we’re usually not talking about high-experienced on computer use users). It works fine on Unix, that’s a more secure system where you can set a lot more rules for the security, if you get a passwords file using brute force for getting the passwords… how do you expect Navision not to be breakable?? Regards,
Could someone please explain a little more about what is meant by BRUTE FORCE routines? Maybe some code examples? If Joerg’s not willing to send the example, maybe MarcoV will … please?!?
Regards,