Date: Wed, 13 Jul 2011 17:10:48 +0200 From: Maximilian Melcher <melcher.maximilian@...glemail.com> To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com> Subject: Re: Charset options Hi list, is it possible to crack SAP RFC password hashes (its from rfcdes like written here http://marc.info/?l=john-users&m=113450841312517 )? The format is: User Hash RFC_TEST C4520A225A6A69429C6C7689B85AB01F and thats longer than a sapB or sapG hash. The password is abcdefgh My first guess was that its md5 but when I start john with RFC_TEST:C4520A225A6A69429C6C7689B85AB01F it says LM and cant crack it with given wordlist. If I force it to md5 => no passwords loaded. Any clues? Thanks Max On Thu, Jul 7, 2011 at 22:58, Maximilian Melcher < melcher.maximilian@...glemail.com> wrote: > Hi Frank, > > Wild speculations ;) - the Betriebsrat (works committee) is not a > problem cause its not a German system - and its just a proove of > concept to "wake people up". > > I've read your papers - very interesting! > > I cant tell you what SAP release it is - I honestly do not know it. > But afaik there are several, I'll guess the data I have indicates is > pretty old because its sapB. > > Cracking the old passwords is certainly a good way to get a clue how > people build there passwords - but imho _one_ cracked password is > enough ;) > > Thanks for your help and time! > Max > > > Am 06.07.2011 um 23:06 schrieb Frank Dittrich <frank_dittrich@...mail.com > >: > > > Hi Maximilian, > > > > Am 05.07.2011 19:48, schrieb Maximilian Melcher: > >> Im doing a pentest with some SAP hashes (sapB, not case-sensitive) - > > > > Did the "Betriebsrat" agree? > > > > Which SAP basis release (SY-SAPRL)? > > > > Why does the system still generate CODVN B passwords instead of CODVN E > > passwords > > or just CODVN F or CODVN H passwords, depending on the SAP basis release > > and system > > configuration? > > (CODVN G means the system computes and stores both the CODVN B and the > > CODVN F > > hashes, CODVN I means, the system computes and stores both the CODVN B > and > > the CODVN H hashes.) > > > > Probably your customer should adjust some of the login/*password* > > profile parameters > > to a more secure setting. > > > > Depending on the SAP basis release, I would suggest using either CODVN E > > (with password > > length 8) or CODVN H (available for SAP-basis-releases > 7.0 (I think, > > from 7.02 on), > > but not CODVN F. > > > > CODVN F (cracked by john using sapg) allows case sensitive passwords > > with a lentgth > > of up to 40 characters, and allows to use all (even non-ascii) printable > > characters, > > but users can still pick easy to crack passwords, because the algorithm > > is relatively fast. > > CODVN E and CODVN H (with default iteration count) are much slower, and > > harder to crack. > > > > If the SAP basis release is >= 7.0, and SAP stores CODVN F or CODVN H > > hashes in > > addition to the CODVN B hashes (this depends on the > > login/password_downwards_compatibility > > profile parameter setting), I wouldn't filter candidates according to > > policy. > > In this case, the reason is similar to the reason I provided for LM > > hashes in my last reply. > > The digits and special characters could be located at an offset > 8, so > > that the password > > matching the CODVN B hash doesn't meet the policy requirements, while > > the real password does. > > > > You could filter passwords starting with '?' or '!' (or make sure your > > .chr file will generate those > > passwords at the end of thekey space (by excluding all passwords > > starting with '!' or '?' before > > generating the .chr file). > > > > Unfortunately, you can't even be sure it is correct to skip passwords > > shorter than 8 characters. > > A user might have picked the password "Secret# 1" > > It meets your policy. > > It is 9 characters long, contains letters, a digit and a special > > character (plus the space). > > > > If you convert it to a CODVN B password, it becomes "SECRET# ", with a > > trailing space. > > Unfortunately, trailing spaces are3 ignored by SAP, so john would have > > to calculate the hash > > for "SECRET#", not for "SECRET# ". > > You might filter passwords with a trailing space, though. > > Alternatively, you fix the sapb implementation, so that "SECRET# " will > > be converted to > > "SECRET#" before computing the hash. > > Then you can limit your search to password length 8, assuming nearly all > > passwords will > > be of a length >= 8 characters. > > > > Do you just have the hashes of current passwords, or hashes of > > previously used passwords? > > How old are the oldest hashes? > > > > May be the current password policy was not in place when these hashes > > were created. > > These profile parameters didn't exist in older releases: > > login/password_letters > > login/password_specials > > login/password_digits > > > > Just login/min_password_lng existed in earlier releases (with a default > > of 3, later increased to 6). > > > > Trying to crack older passwords causes little overhead and might provide > > information about > > possible currently used passwords. > > > > The explanation for these and other related profile parameters can be > > found searching > > SAP's online help at http://help.sap.com/ or searching for SAP notes on > the > > SAP service market place, https://service.sap.com/notes/ (requires > > authorization). > > > > > > Regards, > > > > Frank > -- Max
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.