[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
